Product Developer

Зачем менеджеру AI Агенты

Меня частенько стебут инженеры: мол, ты же мемеджер, код совсем не пишешь, нахрена тебе подписка на клода за 200 баксов?

Вообще-то, с агентами вернулась радость созидания!

Но пост не об этом, а про мемеджерские применения агентов 🙂

Итак.
Я убежден, что хороший технический руководитель на технический вопрос должен уметь ответить сам.
С глубиной, достаточной для решения, и без отвлечения своих ребят.
Иначе это тот же мясной прокси, только без агента.

С агентами стало сильно проще.

Пример из недавнего. Пересылают встречу с говорящим (не очень) названием "Реквизиты клиента". В участниках — несколько топов (СЕО-1 и -2). И пересылают почтовый тред на 20 человек из пяти подразделений, под сотню длинных писем. Ни агенды, ни вопроса. Только культурный срач "кто кому чего был должен и не сделал". Обожаю такое. Явно происходит какая-то эскалация.

Сел с агентом готовиться ко встрече. Раздал сабагентам почту, чаты, трекер, вики, код сервисов, метрики.
Отдельной задачей попросил собрать таблицу: участник | должность | кому подчиняется | за что отвечает | какой основной интерес | что может.

• Один пишет в треде: "вы обещали сделать в прошлом квартале".
• Другой отвечает: "работы на 1–2 спринта".
• Третий: "метод уже есть".

По факту разбора:
1. В старом чате нашлась исходная договорённость: «постараемся взять, если влезет по приоритизации, без обязательства по сроку». Плохая, очень плохая формулировка! Не давайте таких мягких обещаний: их читают как нормальный коммит. И не принимайте: они вообще ни к чему не обязывают! Это и была причина эскалации и простой ответ чтобы потушить её.
2. Агент сходил в исходники и метрики. Метод действительно есть, но его никто не вызывает.
3. Среди участников переписки и встречи нет никого от команды, которая должна вызывать метод.
4. Этому методу вообще не место в том сервисе. Как и реквизитам клиента в целом. Зона ответственности и интересы одной команды протекли в сервис другой команды, а страдают третьи.

Руками на это ушла бы неделя работы и 5–10 запросов разным ребятам.
По факту — три часа с агентами и 15 минут перед встречей, чтобы выровняться со своими и перепроверить собранный контекст.

По итогу встречи проблему разложили на три конкретных задачи, для двух из них назначили исполнителя, и для третьей определили потенциального владельца.

Прошел месяц, передаю контекст новому руководителю юнита — отгрузил ему архив артефактов в html.
Удобно получилось. Почти два года назад я писал про талант и системность: агенды, заметки, фоллоу-апы и списки рисков съедали у меня половину времени, зато помогали не обосраться. Теперь эту работу делает агент -> поддерживать системность стало проще.

Хозяйке на заметку, два правила, без которых получится слоп.

1. Исходникам верить, доке меньше. В доке часто лежит устаревшая правда. Прочитал в вики — иди уточняй. У меня в брифе каждое утверждение идёт со статусом: «подтверждено», «частично», «не проверено», «вопрос».

2. В конце обязательно валидировать у тех, кто за это добро отвечает, что вы с агентом не херню насобирали. Подтвердить готовое им сильно быстрее, чем отвечать на мои вопросы с нуля.

———

Хороший менеджер сокращает энтропию вокруг себя. Упорядочивает реальность, помогает найти простой ответ на запутанный вопрос.
Плохой чайка-менеджер — энтропию порождает и всех запутывает.

Дай агента хорошему, и энтропии станет в 10 раз меньше. В примере выше я влез в тему с нуля и ради сбора информации не отвлёк ни одного человека. А на встрече разложил всю эту переписку в три простых пункта.

Дай агента плохому, и он наведёт в 10 раз больше энтропии, потому что начнёт проксировать слоповые идеи. Про таких сегодня пишет Андрей Романовский в @leadsnotes: мы договорились выпустить по посту на тему «AI в менеджменте», каждый в своём канале.

Андрей пишет про ту часть менеджмента, которую на агента не переложишь. Мне зашел его пост про ошибки начинающих мидл-менеджеров: https://t.me/leadsnotes/102.

Пойду читать его версию, и вам советую 🙂

Кого AI-агенты уже заменили
…часть 3, незапланированная

В прошлый раз я писал про мясного прокси: человека, который пересылает ответы агента и ничего к ним не добавляет. Думал, это дно, но снизу постучали.

Дело было буквально вчера, пост с пылу с жару, написан на тяге бомбежа 🍑!

———

Делаю ревью TDR нового продукта. TDR слоповатый, с первых строк создается впечатление что придется как следует поработать чтобы вникнуть. Стараюсь, тружусь, читаю глазами, оставляю комменты там, где непонятно.

Сейчас думаю: наверное, этот TDR писали агенты для агентов, читать его глазами никто и не планировал. Но тогда я ещё не догадывался, как глубока кроличья нора, и смотрел сам глазами.

Через полчаса отвечены все мои комменты. Ровным тоном, по существу, «договорились, поправил по всему документу». Формулировка вам ничего не напоминает? 🙂

«Ну, видимо, проксирует», думаю. Ничего, бывает. Главное, чтобы сутевые мысли в TDR были авторские, остальное лечится.

Среди ответов один на моё тупое уточнение по терминологии: кто такой «заявитель»? В ответ тыкают: «Термин есть в разделе Термины».

Думаю: как же так, Акела промахнулся, читать совсем разучился, вот же черным по белому написано. На всякий случай проверяю историю страницы. Нахожу изменение страницы "только что" с единственным добавлением — появился термин "заявитель" в разделе Термины.

Подлог, получается.

Тут-то меня и бомбануло. Написал его руководителю. Моя гипотеза: блуждающая мысль и расфокус при работе через агента. Попросил тимлида поговорить с инженером про гигиену.

А дальше…

Тимлид поговорил. Инженер подтвердил: у него крутился агент в автономном цикле. Читал рабочие чаты и Confluence и реагировал на изменения. Комментарии писал через MCP под личным токеном инженера. Для всех остальных это были ответы от имени инженера.

А в глобальных правилах агента, дословно:

«Write everything as if the user did it themselves. Never mention Claude, AI, or any AI tool. Never use phrases that signal LLM output».

Что стало с инженером, спросите вы?

Злого умысла тут нет, и я это понимаю. Инженер воодушевился лозунгами «агент работает, пока ты спишь», собрал себе тулинг и честно верил, что ускоряет команду.

Строчку «пиши так, будто это сделал пользователь» он, скорее всего, взял из чужого шаблона найденного на просторах интернетов.

Бомбит меня от того, что думал, что говорю с автором, который отвечает за решение. Я задаю вопрос, человек думает, иногда спорит.

Здесь думать было некому. Документ менялся под моими вопросами быстрее, чем я успевал их перечитать.

Вот это и есть косяк. Инженер написал себе тулинг, который производит дефекты нового типа.

Обычный слоп видно с первой строки. Этот слоп прикинулся коллегой и отвечал мне от его имени.

Добавленная ценность инженера в этом ревью ноль.

———

Два правила, которые я бы повесил на любой автономный цикл:

1. Должно быть видно, что писал агент. Пытаться это скрыть — значит обманывать читателя.
2. Ответы живым людям и правки документа для живых людей — только живым человеком.

В первой части я рассуждал, заменят ли агенты разработчиков.
Вот одного уже. Сам себя, добровольно, из лучших побуждений, с инструкцией «притворяйся мной».

Или это я отстал от жизни, и просто надо было посадить своего агента в цикл?

Теория Ограничений Систем
"команда идёт со скоростью самого медленного"

Disclaimer: пост — ТОС на пальцах + анонс бесплатного митапа от VK, где будет мастер-класс по ТОС.

В 1984 году физик Элияху Голдратт написал производственный роман «Цель». Директор завода ведёт в поход отряд скаутов. Отряд растягивается по тропе: жирный Херби с тяжёлым рюкзаком идёт в середине, передние убегают вперёд, задние упираются в Херби. Привалы уходят на то, чтобы собрать всех обратно. Директор ставит Херби первым и раздаёт его рюкзак остальным. Тогда отряд идёт со скоростью Херби, зато весь вместе и быстрее, чем раньше.

Так Голдратт объясняет теорию ограничений: пропускная способность системы равна пропускной способности узкого места.

Переложим на команду. Шесть инженеров кодят, а ревью делают между делом. С агентами кодить стали вдвое быстрее. А cycle time задачи не изменился. Задачи стоят в очереди на ревью, и чем быстрее кодим, тем длиннее очередь.

Голдратт предлагает пять шагов:

1️⃣ Найти ограничение. Этап, перед которым задачи ждут дольше всего. В джире это колонка, в которой копятся карточки. В нашем случае это ревью.

2️⃣ Помочь ограничению. В «Цели» перед станком поставили контроль качества, чтобы станок не точил уже бракованные детали. В случае ревью это:
• маленькие PR
• линтеры и зелёный CI до того, как PR попал человеку
• описание к PR, чтобы ревьюер не восстанавливал задачу по диффу.

3️⃣ Подчинить остальное ограничению. Ревью с утра, до своего кода. Разработчик, у которого три PR висят на ревью, не начинает четвёртую задачу, он идёт ревьюить чужую. Да, писать код приятнее. Нет, команде это сейчас не нужно.

4️⃣ Расширить ограничение. Нанять, отдать первый проход агенту, автоматизировать.

5️⃣ Ограничение переехало. Вернуться к 1.

Большая часть улучшений, которые делает команда, не меняет итоговую скорость системы. Каждый ускоряет свой этап, потому что это умеет.

Голдратт просит ускорять этап, который тормозит, даже если он чужой. У него же есть фраза для тимлидов, которые считают закрытые задачи на человека: «Скажи мне, как ты меня измеряешь, и я скажу, как буду себя вести».

———

У теории ограничений есть вторая часть: мыслительные инструменты.

Главный инструмент — дерево текущей реальности. Внизу симптомы, которые бесят: задачи висят на ревью, релиз раз в две недели, на ретро один и тот же пункт третий спринт. Вверх от них стрелки «потому что», и каждую стрелку проверяют по правилам.
1. Причина существует?
2. Её одной достаточно?
3. Если причина верна, какие ещё следствия мы должны наблюдать, и наблюдаем ли?

Проверка на себе. «Ревью медленное, потому что ревьюеры ленятся». Если это правда, маленькие PR должны висеть так же долго, как большие. Смотрю в джиру: PR на 100 строк уходят за день, на 1500 висят неделю. Причина в размере PR.

Второй инструмент, «туча», для конфликтов. Разработчик хочет писать свой код и хочет, чтобы команда катила быстро. Два желания тянут в разные стороны, и команда ищет компромисс: день кодим, час ревьюим. Голдратт просит компромисс не искать. Под каждой стрелкой конфликта лежит предположение, и его надо достать и проверить. Здесь оно звучит так: «моя задача закрыта, когда я написал код». Очевидно, это не так: задача закрыта, когда всё в проде и обмазано мониторингом. А что надо чтоб оно доехало в прод? Правильно, ревью!

На VK JT TeamLead 28 октября в Питере будет Мастер-класс по теории ограничений с Александрой Брызгаловой, сертифицированным тренером по ТОС Голдратта.

Еще будут:
— Дискуссия «Лидер и стратегия: насколько глубоко тимлид должен погружаться в бизнес»
— Менторская гостиная, встреча 1–1 с тимлидом VK
— «Своя игра» по управленческим кейсам

Санкт-Петербург, 28 октября, 17:30, офис VK у Красного моста.

Офлайн, бесплатно, нужна регистрация.

Зарегистрироваться