Поставка: быстро и качественно

Поставка держит скорость, когда руководитель не обходит команды за статусом, а получает их состояние до разговора и тратит время только на отклонения. Агенты собирают, наблюдают и считают; решения, обещания и проверку каждого утверждения до источника оставляет себе человек. Обещание со стадии «Обязательства» здесь не забывают — его каждый спринт сверяют с фактом.

Шаг 1. Карта делегирования

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

Класс	Пример	Сильная сторона	Где опасен
Агент над репозиторием, по команде	Claude Code	одни правила дают одинаковый результат	не работает, пока его не запустили
Постоянный агент с памятью	Hermes Agent	работает по расписанию, помнит контекст	навыки дрейфуют — для правил это минус
Шлюз мессенджеров	OpenClaw	видит поток в чатах и почте	может действовать от вашего имени

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

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

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

Инструменты:

• Тема «Команда агентов» — классы агентов, ролевые боты и права.
• Тема «Контекст для агентов»: без зрелого контекста агент уверенно достраивает недостающее сам.
• Презентация «Claude Desktop с китайскими моделями» — как запустить Claude Code на GLM, когда доступ к зарубежным моделям закрыт.

Шаг 2. Ритм без обхода

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

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

Когда	Вопрос вслух	Что готовит агент
Каждый день, 5 минут	«Изменилось ли что-то по зависимостям?»	где подтверждение устарело, где нет движения
Середина спринта	«Успеем ли получить ответ или прогнать тест?»	какие проверки не двинулись
Конец спринта	«Под что можем подписаться, а под что нет?»	что подтверждено только словами, моками или демо
Середина квартала	«Дойдём ли до цели при текущем темпе?»	хватит ли времени до срока

Кто что делает. Агент собирает снимок трекера и сводит строки техлидов в список красных строк. PO читает и задаёт вопрос точки. Команде не нужны термины методологии — ей нужны два вопроса: что изменилось по зависимостям и под что можно подписаться.

Результат. Состояние каждого потока до встречи; договорённости прошлой недели лежат в том же эпике.

Инструменты:

• Презентация «Спринты под управлением руководителя» и навык poh-sprint-agents.
• Презентация «Утренняя планёрка с ИИ-агентом».
• Тема «Ритуалы для решений, а не для пересказа».

Шаг 3. Задачи на выяснение

Процесс разработки остаётся любым — scrum или kanban. Меняется то, что считается работой.

Зона	Было	Стало
Спринт	задачи реализации	плюс spike, PoC, замер ответа смежной системы — наравне с фичами
Цель спринта	«сделали»	может быть «выяснили»: получили письмо, прогнали тест против реального API
Обещание срока	дата под давлением	«беру проверку, дату назову после неё»
План на 2–3 спринта	кто перегружен	плюс карта хрупкости: что стоит на чужих неподтверждённых обещаниях

Техлид даёт то, чего не даст никто другой: техническую правду — прогон на моках и прогон против реальной системы доказывают разное. Ещё он даёт ранний сигнал деградации («отвечают вместо двух дней девять») и возражения, когда руководитель переоценивает готовность.

Кто что делает. Инженер закрывает spike не словом «сделано», а строкой «что выяснили». Агент проверяет, что у каждого вывода есть источник: факт — то, что открывается по ссылке с датой и автором, остальное — гипотеза. Агент не создаёт факты: переносит их с источником, считает по правилам и указывает на пустоту.

Результат. Проверки, закрытые артефактом, и карта хрупкости плана.

Инструменты:

• Тема «Инженерные практики скорости».
• Тема «Навыки работы с ИИ» — метапознание: замечать границы своего знания и проверять результат агента.
• Тема «Контекст в репозитории, а не в головах»: история коммитов показывает, кто и когда записал знание.

Шаг 4. Дрейф и светофор

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

Цвет	Условие	Что происходит
Зелёный	дрейфа нет, требования актуальны	работа идёт по плану
Жёлтый	дрейф есть, но меньше порога, или буфер исчерпан	PO смотрит причину на ближайшей точке контроля
Красный	дрейф достиг порога — по умолчанию 2 спринта	сигнал и новая базовая линия

Отдельный сигнал — скрытый дрейф: автор требования не обновлял его статус два синка подряд. Для обещания уровня Commitment («обещаем») любое изменение объёма — это новая базовая линия, а не тихая правка.

Кто что делает. Агент пересчитывает дрейф по расписанию и поднимает сигнал. Изменение требований оформляют запросом на изменение с именем автора. PO решает по жёлтому и красному.

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

Инструменты: модель дрейфа и навык release-guard — Release Management в po-helper-org/docs; тема «Обязательства» — уровни Intent («хотим»), Target («целимся»), Commitment («обещаем»).

Шаг 5. Решение по отклонению

Сигнал без решения — прикрытие спины. На каждое отклонение — одно из трёх решений, и у каждого своя механика.

Отклонение	Что делаете
Блокер смежника	Три хода без войны: свой тест против его реального API, фиксация договорённости в его же Jira-эпике, письмо с неудобным дефолтом — «фиксирую 15.10; если не успеваете, поставлю 30.10». Молчание — не подтверждение
Красный дрейф	Новая базовая линия: сократить объём, сдвинуть дату или отказаться — и записать, кто утвердил
Смена стратегии	Пять вопросов автору изменения, разбор обещаний на три корзины, работу доводят до ближайшего гейта. Обесцениваются обещания, а не знание, поэтому хватает двух дней вместо двух-трёх недель заморозки

Эскалация идёт по уровням: команда решает в своей зоне, PO — ресурс между потоками, CTO, CPO или CEO — бюджет, найм и приоритет. На экваторе квартала эскалация — управление, через месяц та же эскалация — оправдание.

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

Результат. Каждое отклонение закрыто решением с датой и автором и записано в журнал решений — его прочитают на стадии «Эффект».

Инструменты:

• Презентация «Где и почему команда разработки была заблокирована» — кого ждали и где стояли задачи, без опроса команды.
• Тема «Решения при неопределённости».
• MCP-сервер для Jira и Confluence — доступ агента к трекеру на чтение.

Почему так, а не через обход команд за статусом

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

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

Артефакт: карточка делегирования и запись об отклонении

Задача: <что делаем, например «сводка недельных строк техлидов»>
Агент: <над репозиторием | постоянный с памятью | шлюз мессенджеров>
Автономия: <только чтение | черновик | предлагает запись | сам>
Куда пишет: <инбокс | черновики | журнал наблюдений>
Куда не пишет: узлы знания, обещания, правила
Источник каждого утверждения: <ссылка · автор · дата>
Кто проверяет и подтверждает: <ФИО, роль>
Чего агент не делает: <отправка от моего имени | даты наружу | изменение правил>
Доступы: <системы>; согласовано с безопасностью: <дата, кто>
Куда уходят запросы к модели: <своя инфраструктура | внешний провайдер>
Пересмотр прав: <дата — не раньше месяца работы только на чтении>

Отклонение: <обещание, поток> — <дд.мм>
Цвет: <жёлтый | красный | скрытый дрейф>
Дрейф: спрос <n спринтов, автор изменения> + поставка сверх буфера <n спринтов, причина>
Тип: <блокер смежника | красный дрейф | смена стратегии>
Решение: <снять блокер | сократить объём | сдвинуть дату | отказаться | довести до гейта>
Основание: <ссылка на артефакт>
Кто утвердил: <ФИО, роль>; новая базовая линия: <версия, дата>
Сообщено: <кому, когда — за сколько недель до срока>

С чего начать завтра

• Выпишите задачи недели, которые сводятся к сбору, подготовке и наблюдению, и на каждую заполните карточку делегирования — только с правом чтения.
• Попросите техлидов присылать раз в неделю пять строк вместо устного статуса; первые недели заполните сами после разговора и попросите подтвердить одним словом.
• Зафиксируйте базовую линию каждого обещания и порог дрейфа; заведите журнал изменений требований с автором.
• Попросите инженеров закрывать spike строкой «что выяснили».
• Найдите блокер, который стоит дольше всех, и выберите один из трёх ходов на эту неделю.

Источники

• PAF Product Ops для корпоративного PO, адаптация А. Ишманова: П4 «Замена присутствия артефактом», П9 «Команда агентов», П3-кватер «Стратегия поменялась, команда на финальном шаге», шаги 3, 5 и 6, разделы 13 «Факт, гипотеза, галлюцинация» и 14 «git как носитель истины».
• Release Management — управление релизами и дрейфом объёма: модель дрейфа и светофор.
• Operating Model — правила игры AI-Native продуктовой команды: «сначала Нексус, потом Кортекс» и фильтр рабочего мусора.
• Product Architecture Framework, Сергей Тихомиров: Нексус (модель знания о продукте) и Кортекс (агенты и правила работы с ней). CC BY-SA 4.0.