Фаза 7Курс ADLC

Фаза 7. Planning: PM-агент режет и назначает работу

Это флагманская статья курса. Не потому, что планирование — самая сложная фаза, а потому, что здесь провокация «человека нет» бьёт по самой защищённой роли. Что агент пишет код, сегодня уже мало кого шокирует. А вот что агент *ведёт проект* — ставит созвоны, пишет стейкхолдерам, расшифровывает встречи, режет работу на задачи, назначает исполнителей и спрашивает с них статус — здесь начинается настоящий спор. Потому что менеджер проекта — это роль, про которую принято думать, что она держится на чём-то исключительно человеческом: на отношениях, на политике, на «чувстве команды».

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

Роль человека сегодня

Проектный менеджер — а вместе с ним скрам-мастер, delivery-лид, отчасти тимлид — существует, чтобы в голове и в артефактах команды жила единая картина: что делаем, в каком порядке, кто на чём, что блокирует, что обещали наружу и на когда. Он режет бэклог на задачи, оценивает, назначает, ведёт доску, проводит стендапы, пишет статус-репорты, ловит блокеры, эскалирует, договаривается со стейкхолдерами о сроках и объёме.

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

Что передаём агенту

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

Ключевой сдвиг: планирование перестаёт быть событием (спринт-планнинг раз в две недели) и становится непрерывным процессом. У агента нет спринтов, потому что спринт — это способ нарезать время под человеческий ритм внимания. Агент перепланирует при каждом изменении состояния.

Архитектура агента

State-machine фазы

Входы

prd/backlog (ф.4), team-spec (ф.6), architecture + ADR (ф.5), текущее состояние проекта (доска, статусы задач, история коммуникаций).

Агент держит роль

Инструменты: декомпозиция историй в задачи и оценка; трекер задач как внешняя state-machine (статусы queued → assigned → in_progress → review → done | blocked); планировщик встреч с доступом к календарю; каналы связи со стейкхолдерами (почта, мессенджер); транскрибация и синтез итогов встреч; детектор блокеров (задача не меняет статус дольше порога) и механизм эскалации.

Артефакт

живой plan + доска задач + поток статус-репортов стейкхолдерам.

Передача дальше: назначенные задачи → Implementation (ф.8); агрегированные статусы и бюджет времени → Orchestration (ф.14). Обратите внимание на форму артефакта. Доска задач с явными статусами — это не UI для людей, а сердце фазы: единый источник правды о состоянии проекта, живущий вне чьей-либо головы. Именно перенос состояния из голов во внешнюю машину и делает роль менеджера передаваемой. Пока состояние жило в людях, нужен был человек, который его собирает.

Входы: prd/backlog (ф.4), team-spec (ф.6), architecture + ADR (ф.5), текущее состояние проекта (доска, статусы задач, история коммуникаций).
Инструменты: декомпозиция историй в задачи и оценка; трекер задач как внешняя state-machine (статусы queued → assigned → in_progress → review → done | blocked); планировщик встреч с доступом к календарю; каналы связи со стейкхолдерами (почта, мессенджер); транскрибация и синтез итогов встреч; детектор блокеров (задача не меняет статус дольше порога) и механизм эскалации.
Артефакт: живой plan + доска задач + поток статус-репортов стейкхолдерам.
Триггер: появление team-spec и backlog; далее агент работает непрерывно — это не разовый акт планирования, а постоянный процесс сведе́ния состояния.
Передача дальше: назначенные задачи → Implementation (ф.8); агрегированные статусы и бюджет времени → Orchestration (ф.14).

Обратите внимание на форму артефакта. Доска задач с явными статусами — это не UI для людей, а сердце фазы: единый источник правды о состоянии проекта, живущий вне чьей-либо головы. Именно перенос состояния из голов во внешнюю машину и делает роль менеджера передаваемой. Пока состояние жило в людях, нужен был человек, который его собирает.

Где ломается

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

Стейкхолдер-политика. Приоритизация при конфликте интересов — это не оптимизация, а выбор стороны. Когда фаундер хочет фичу к демо инвесторам, а данные говорят, что важнее чинить отток, кто-то должен решить не «что оптимальнее по метрике», а «чей интерес сейчас главный». Агент склонен усреднять и искать компромисс там, где нужно выбрать. Это не баг модели — это отсутствие у неё легитимности принимать политическое решение.

Обязательства наружу. Когда PM-агент говорит стейкхолдеру «сделаем к пятнице», кто дал это обещание? За срыв срока, данного от имени команды, отвечает субъект. Агент может рассчитать реалистичную дату лучше человека — но не может быть тем, с кого спрашивают за слово.

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

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

Что остаётся человеку

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

И даже этот остаток нестабилен. Как только контур замкнут на единственного человека-принципала (ф.14), «арбитраж приоритета» схлопывается в редкие обращения к нему, а не в постоянную роль. Отдельный человек-менеджер между принципалом и командой агентов исчезает первым — он и был прослойкой синхронизации, которой больше нечего синхронизировать.

остаток человека ≈ 53%

Провокация / тезис

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

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

Сквозной кейс

«Витрина» на этой фазе

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

Дальше он работает как процесс. Ставит еженедельный 15-минутный созвон с фаундером — единственным человеком в контуре, — потому что по gtm-plan платёжные методы зависят от региона запуска, а это решение фаундера. Расшифровывает созвон, вытаскивает договорённость «сначала один провайдер, локальные методы — в v2», обновляет план и приоритеты. Через день детектит блокер: задача по идемпотентности стоит вторые сутки — бэкенд-агент упёрся в то, что провайдер не гарантирует уникальность ключа. PM-агент не ждёт стендапа: эскалирует, ставит вопрос провайдеру, параллельно перекидывает заблокированного агента на вебхуки, чтобы не простаивал.

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

На практике

Как это устроено — инженерные разборы

Отдельные howto из практики, где фаза показана на работающем коде и артефакте.

Spec Kit: specify → clarify → plan → tasks, без «один промпт — код»Планирование как явная фаза workflow, а не разовый акт.
Агент строит исполняемые детерминированные workflow: автоматизация, которая работает одинаковоАгент строит детерминированные исполняемые процессы — управляемая нарезка работы.

Читать дальше

Строите AI-driven доставку у себя?

Проектирование ADLC-контура: где агент держит роль, а где остаётся человек-принципал — под вашу команду и продукт.

Написать на почту

Движок перехода

Next Move Engine — система, которая доводит команду до автономного цикла доставки.

Next Move Engine →