Как агентный кодинг изменил вес навыков продакт-менеджера

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

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

Главное, что произошло, это сдвиг внутри привычной роли продакта. Прежние навыки в 2026 году имеют другие веса. Часть из того, что раньше было просто полезным, стала решающим фактором, без которого вся команда тормозится. Часть, наоборот, обесценилась настолько, что выполнять эти задачи стало скорее имитацией работы. И появилось одно требование, которого в роли продакт-менеджера до 2026 года не было.

Главное, что произошло с командной скоростью

Инженеры с Claude Code в командах, с которыми мы работаем, регулярно ускоряются индивидуально в два-три раза по своей производительности. Параллельно этому командный throughput за тот же период часто не сдвигается. В индустрии это называют team-level gains not materializing, и у многих компаний это становится нормой.

Картина обычно похожая. Кто-то ускорился в три раза, кто-то в полтора, кто-то пользуется агентами неохотно. Код пишется намного быстрее, чем ревьюится. AI-сгенерированный код требует более внимательного чтения, потому что в нем регулярно встречаются логически работающие, но архитектурно неуместные решения. Три разных разработчика получают три разных решения от агента, и каждое работает, поэтому архитектура потихоньку размывается. QA тестирует в три раза больший поток с прежней скоростью. Продакт смотрит в Jira, видит, что velocity вырос, и какое-то время этому радуется, пока на встрече с CTO не звучит та самая фраза.

Что меняется в работе продакта, чтобы это конвертировалось в командный результат. Ему нужно увидеть, что узкое горлышко переехало, и перепроектировать процесс под него. Раньше bottleneck был в написании кода. Это был очевидный и стабильный факт, и улучшать процесс особо незачем, потому что главное узкое место сидело в часах разработчика. Сейчас bottleneck подвижный. Он переехал в ревью, интеграцию, стабильность, иногда в работу самого продакта. Без активной работы продакта он будет блуждать с места на место, не давая команде использовать ускорение в коде.

Вопросы, которые раньше казались скучной операционкой, стали стратегическими. Какое ревью оставить человеческим и где хватит автоматической проверки. Как не дать PR-очереди стать новым узким местом. Что делать с оценками, когда velocity между спринтами скачет в 2-3 раза, и как менять ретроспективу, когда «сколько сделали» перестает быть осмысленной метрикой.

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

Outcome measurement без бейзлайна превращается в спор об ощущениях

Главный навык, на котором рассыпаются такие команды, мы называем outcome measurement. Слово звучит как набор метрик, и DORA в этой паре действительно важна. Но фундамент здесь именно в дисциплине отделять индивидуальные ощущения от командного результата, без чего любые цифры по DORA превратятся в формальность.

Если продакт опирается на self-reported данные от инженеров («я стал быстрее»), он работает с метрикой производительности отдельных людей. Это не равно throughput команды. И если разговор с менеджментом про «работает ли у нас AI» строится на этой подмене, он быстро превращается в обмен ощущениями, в котором каждая сторона остается при своем.

На практике эта работа требует нескольких привычных навыков продакта, но в обостренной форме. Снимать бейзлайн до внедрения инструмента (DORA, инцидент-рейт, lead time, стабильность). Уметь объяснить менеджменту, чем индивидуальная productivity отличается от командной, и почему вторая важнее. Делать pushback, когда планы строятся на хайпе («ну AI же, почему не в десять раз быстрее»), без опоры на метрики.

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

Скептицизм в команде это операционная работа продакта

В каждой команде из десяти человек обычно находится четверо-пятеро, кто относится к AI со скепсисом. И часть из них скептики по делу.

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

Change management внутри команды стал частью повседневной работы продакта, и его приходится держать в фокусе постоянно. Скептицизм бывает разной природы. Иногда он обоснован, когда AI-сгенерированный код в специфической кодовой базе действительно создает больше работы (это не редкость). Бывает инерционным, в духе «я всегда делал руками, и мне комфортно так». А иногда за ним стоит страх потери профессии, и тогда работает только честный разговор о том, что меняется в роли.

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

Что обесценилось в роли продакта и что появилось нового

События, завязанные на стабильную velocity, в новых условиях не работают. Planning poker для таска, который агент делает за час, выглядит избыточным. Story points при размахе скорости 2-3 раза от спринта к спринту теряют точность как единица измерения. На практике эти события постепенно заменяются outcome-метриками, и команды, которые держатся за старый формат, тратят время на церемонии, переставшие что-либо говорить о реальной скорости.

Роль ticket janitor, где основная функция продакта была держать Jira в порядке, теряет ценность быстрее остальных навыков. Эту работу довольно эффективно режут агенты и автоматизация. То, что от нее остается, перестает быть отдельной должностью и становится частью повседневной работы любого продакта.

Производство первичных драфтов документов сместилось к AI. PRD, decision doc, release notes генерируются за минуты, правки вносятся быстро. Ценность продакта в документах перешла от производства текста к ясности мышления и точности формулировок после того, как драфт уже есть.

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

Все остальное, что часто называют «навыками PM в эпоху AI», по большей части является переоцененной классикой. Discovery, приоритизация, change management, stakeholder management остаются теми же навыками, что и в 2022 году. Просто их веса в 2026 году поменялись.

Перестройка процесса команды как работа продакт-менеджера

Большинство ситуаций, в которых продакт оказывается без хороших ответов, имеют один общий корень. Команда живет в новой механике (дешевый build, плавающая velocity, разные темпы адопции у разных людей), а процесс работы команды собран под старую. Перепроектировать этот процесс должен продакт-менеджер. Scrum-мастер смотрит на церемонии, CTO на архитектуру и инструменты, а системный взгляд на то, как процесс команды конвертируется в скорость выпуска продукта, остается ответственностью продакта. В 2026 от того, насколько он эту работу делает, зависит, превращается ли индивидуальное ускорение разработчиков в результат для бизнеса.

В практике agile-transformation большая часть нашей работы в последние полтора года связана именно с перестройкой процессов в командах после внедрения AI. У клиентов это обычно начинается с того же мотива, с которого начался этот пост. У вас, возможно, такой разговор уже был.

Частые вопросы

Что такое team-level gains not materializing и как заметить это у себя?

Ситуация, при которой индивидуальная производительность разработчиков с AI-инструментами заметно растет (в наблюдаемых командах ускорение в два-три раза по story completion это норма), а командный throughput при этом не двигается. Чаще всего причина в том, что процесс работы команды остался прежним, в то время как узкое горлышко переехало из написания кода в ревью, интеграцию и работу самого продакта. Узнать у себя несложно, достаточно сравнить, насколько ускорились отдельные разработчики, и насколько сжались релизный цикл и lead time.

Какие метрики снимать до внедрения AI в команду?

Базовый набор это DORA-метрики (delivery throughput, lead time for changes, change failure rate, MTTR), инцидент-рейт, стабильность релизов. Без этих базовых метрик до внедрения сравнить эффект после невозможно, и разговор с менеджментом про результат AI превращается в обмен ощущениями. Бейзлайн желательно собрать минимум за два-три месяца до старта эксперимента, иначе разброс между спринтами съест сигнал.

Чем отличается приоритизация бэклога в эпоху агентного кодинга?

Методики приоритизации остались прежними, RICE, WSJF и cost of delay работают как и работали. Изменился сам поток вариантов, к которому они применяются. Если раньше команда могла сделать 15 фич из 50, и продакт выбирал лучшие 15, то сейчас сделать можно почти все 50, и каждая выбранная означает несколько невыбранных одновременно. Решения стали болезненнее, и навык приоритизации с явной альтернативной стоимостью подорожал.

Что делать со скептиками в команде, которые отказываются использовать AI?

Продавливать адопшн в лоб обычно дает один из вариантов неуспеха, формальное использование без реальной перестройки работы, потерю людей, или подорванное доверие к руководству. Эффективнее разделить скептицизм на обоснованный (когда AI-код в специфической кодовой базе действительно создает больше работы) и инерционный, и для каждого случая работать отдельно. Безопасное экспериментирование с возможностью отказаться часто работает лучше, чем вебинары про возможности AI.

Какие технические навыки нужны продакту, чтобы работать с AI-командой?

Чтобы разумно договариваться с командой, в 2026 году продакт-менеджеру нужно понимать архитектуру достаточно глубоко. Production-кода писать не приходится, и эта граница не сдвинулась. Граница сложности с появлением агентов изменилась, и вещи, которые раньше стоили недели, теперь стоят часы. И наоборот, что выглядит простым для агента, может сломать систему при интеграции. Без технической интуиции продакт либо блокирует команду лишней осторожностью, либо отдает в работу неподъемные задачи.

Какие Scrum-события становятся неактуальными в эпоху агентного кодинга?

События, завязанные на стабильную velocity, теряют смысл при разбросе скорости в 2-3 раза между спринтами. Planning poker для таска, который агент делает за час, перестает быть осмысленным. Командная оценка каждого элемента бэклога под velocity-планирование заменяется outcome-метриками. Ретроспектива, в основе которой лежит «сколько сделали», тоже требует пересмотра в сторону outcome-вопросов.

Что входит в перестройку процесса команды после внедрения AI?

В нашей практике agile-transformation перестройка обычно включает диагностику нового узкого горлышка, пересборку основных событий (ревью, интеграция, оценки, ретро), и настройку outcome-метрик, на которые можно опираться при разговоре с менеджментом. Работа с командой и продакт-менеджментом идет параллельно, чтобы изменения закрепились в повседневной работе. От диагностики до первых видимых результатов обычно 4-6 недель.