От проектного менеджера к проектному инженеру: как AI меняет управление проектами

Меня зовут Михеенков Никита, я со-основатель digital-агентства Nimax. Мы ведем множество проектов в рекламе, дизайне и разработке. Каждый день это несколько десятков параллельных проектов. А за 25 лет существования компании мы сдали проекты для сотен клиентов. У нас есть проектный офис, который переваривает все эти объемы работы. И целая команда проектных менеджеров. Управление проектами - очень важная часть работы агентства. Искусственный интеллект начинает влиять на эту деятельность. В этой статье я собрал наблюдения, как именно трансформируется сейчас профессия PM.

Обычно про AI говорят применительно к производству — разработке, дизайну, копирайтингу и т.д. Но он меняет и то, как мы ведём проекты. И это, кажется, более глубокое изменение.

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

Я собрал наблюдения о том, что происходит с профессией проектного менеджера. Если забежать вперёд, мой вывод такой: PM постепенно превращается в проектного инженера. Он сам производит часть результата, собирает систему работы людей и агентов и всё чаще отвечает на продуктовые вопросы.

Менеджер тоже начинает производить

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

Теперь PM может не только ставить задачи, но и выполнять часть работы самостоятельно. Собрать аналитику, подготовить структуру проекта/продукта, сделать прототип, проверить гипотезу. Иногда это быстрее, чем сформулировать задачу для другого человека, дождаться исполнителя и принять результат.

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

На небольших цифровых проектах менеджер уже может самостоятельно пройти путь от идеи до работающего прототипа. Профессия расширяется: вместе с возможностями растёт и зона ответственности.

Людей в команде может стать меньше. Возможностей у каждого — больше

Одно из супер-свойств AI — он позволяет нам делать то, чего раньше мы делать не умели.

Дизайнер может собрать работающий интерфейс. Разработчик — подготовить визуальную концепцию. Менеджер — сделать небольшой внутренний инструмент, для которого раньше пришлось бы искать отдельного исполнителя.

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

Этому уже есть экспериментальные подтверждения: исследования показывают, что AI помогает специалистам выходить за границы своей специализации. Например, это наблюдали в исследовании Harvard Business School с сотрудниками Procter & Gamble.

Для проектного управления это меняет сам подход к декомпозиции. Раньше одну задачу приходилось разбивать между несколькими специализациями. Теперь более законченный кусок работы можно поручить одному человеку.

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

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

Коммуникация становится проще

Сегодня огромная часть работы PM — это переноска контекста:

1. собрать требования;
2. пересказать дизайнеру;
3. уточнить у клиента;
4. передать разработчикам;
5. напомнить всем, что решили на встрече.

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

При правильно настроенной системе контекст реже теряется, договорённости проще найти, а участникам легче войти в курс дела.

Но передать информацию и договориться — разные задачи. AI может пересказать обсуждение. Разрешить конфликт интересов, согласовать ожидания и добиться общего понимания результата по-прежнему приходится людям.

Поэтому коммуникация остаётся важной частью профессии. Меняется её содержание: меньше пересказов и напоминаний, больше работы с решениями и ответственностью. Задача PM — выстроить процесс, в котором доступная информация помогает участникам действовать согласованно.

Этапы сжимаются

Из вороха клиентской информации уже можно быстро получить первый прототип или эскизы. В относительно простых случаях — за один проход генерации. Он ещё потребует проверки и доработки, но с ним можно обсуждать конкретное поведение продукта.

Это меняет последовательность работы. Вместо длинного пути от требований через несколько этапов к первой демонстрации появляется короткий цикл: гипотеза — прототип — проверка.

Утром собрал вводные, днём получил работающую версию, вечером показал пользователям. Для некоторых цифровых задач такой ритм уже реалистичен.

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

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

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

Граница между планированием и исполнением размывается: мы пробуем, узнаём новое и сразу меняем план.

Приоритеты выравниваются

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

Приоритизация определяла почти всё: какие фичи делать, кому поручать работу, какие ошибки исправлять сейчас, а какие оставить до лучших времён. За место в плане разработки постоянно шла конкуренция.

С AI это ограничение ослабевает. Больше задач можно запускать параллельно, небольшие изменения и часть багфиксов — выполнять сразу, без долгого ожидания свободного разработчика. Задачи, которые раньше месяцами лежали в бэклоге, получают шанс быть сделанными просто потому, что стоимость их выполнения снизилась.

В этом смысле приоритеты выравниваются. Уже не всегда нужно долго выбирать между двумя улучшениями — иногда проще сделать оба и посмотреть на результат.

Но дальше возникает другое ограничение: всё сделанное нужно проверить и решить, что выпускать в свет. Изменения могут конфликтовать друг с другом, усложнять продукт или просто не приносить пользы.

Поэтому приоритизация смещается к проверке и выпуску. Что проверяем первым? Что готово к релизу? Что выкатываем в рабочую версию продукта, а что пока оставляем экспериментом?

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

Проектный менеджер смещается в сторону продуктового

Когда команда меньше, а производство быстрее, у менеджера меняется распределение внимания.

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

И вопросы о его востребованности тоже возникают раньше. Нужен ли он вообще? Понятно ли людям, как им пользоваться? Возвращаются ли они? Какие изменения влияют на метрики?

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

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

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

Способность быстро сделать продукт повышает ценность ответа на вопрос: «Что именно стоит делать дальше?»

Агентами тоже нужно управлять

Кроме людей, в команде появляются агенты, которые достаточно автономно закрывают часть работы.

Им нужно ставить задачи, давать контекст, определять ожидаемый результат и возвращать обратную связь, когда они делают что-то не то. Это становится отдельной частью управленческой работы.

Причём важно заранее определить границы самостоятельности. Что агент может решить сам? В какой момент должен остановиться и позвать человека? Какие действия требуют согласования?

Подготовить предложение по новому плану — одна степень свободы. Самостоятельно изменить обещанный клиенту срок — совсем другая.

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

Отсюда растёт и слой контроля качества:

1. критерии приёмки;
2. автоматические проверки;
3. тестовые сценарии;
4. оценка результатов AI;
5. проверка человеком там, где цена ошибки высока.

Сам факт, что агент закончил задачу, ещё не означает, что результат можно использовать. PM должен выстроить процесс, который позволяет это установить.

У менеджера появляется собственный copilot

Совершенно новая возможность — собрать личного AI-ассистента или second brain под свои проекты.

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

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

Это не делает забытые задачи и потерянные договорённости невозможными. Но снижает зависимость проекта от памяти одного человека и облегчает повседневный контроль.

А самому менеджеру позволяет держать в поле внимания больше происходящего, не тратя весь день на сбор статусов.

Экономику проекта приходится пересчитывать

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

Когда отдельные операции выполняются значительно быстрее, привычная связь между количеством часов и объёмом результата становится слабее. Работу, которую раньше оценивали в несколько дней специалиста, иногда можно выполнить за короткую сессию с AI.

При этом стоимость проекта не сводится к токенам. Остаются постановка задачи, проверка, интеграция, сопровождение и ответственность за результат. Где-то бюджет сократится, где-то за те же деньги получится сделать больше.

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

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

Ответственности становится больше

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

Теперь менеджеру нужно понимать, где в проекте используется AI, какие решения на него опираются и как обнаружить ошибку до того, как она станет проблемой для клиента или пользователя.

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

Организовать такую проверку — тоже часть управления.

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

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

Чем доступнее становится разработка с помощью ИИ, тем важнее становится ответственность за результаты.