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. Пойду читать его версию, и вам советую 🙂