Эффективное онлайн PI-планирование для Delivery и Project менеджеров

Подготовка к онлайн PI-планированию: настройка инструментов, логистика и готовность бэклога

Добро пожаловать на курс «Эффективное онлайн PI-планирование для Delivery и Project менеджеров». Это первая статья нашего цикла, и мы начнем с фундамента — подготовки. Как гласит старая управленческая мудрость: «Провал в подготовке — это подготовка к провалу». В контексте PI-планирования (Program Increment Planning), особенно проводимого в онлайн-формате, эта фраза становится аксиомой.

PI-планирование — это сердцебиение Agile Release Train (ART). Это событие, которое синхронизирует все команды, стейкхолдеров и руководство для создания общего видения и плана на следующие 8–12 недель. В офлайне это два дня живого общения, стикеров на стенах и энергии в одной большой комнате. В онлайне — это сложный логистический и технический вызов, который ложится на плечи Delivery и Project менеджеров.

В этой статье мы разберем три кита успешного PI-планирования: логистику, инструментарий и готовность бэклога.

1. Логистика: время, люди и расписание

Перенос планирования в онлайн требует пересмотра стандартной двухдневной повестки SAFe (Scaled Agile Framework). Сидеть перед монитором 8 часов подряд невозможно — внимание падает, эффективность стремится к нулю.

Адаптация расписания

Вместо двух полных дней рекомендуется разбить мероприятие на 3 или даже 4 дня с более короткими сессиями (по 4–5 часов).

Ключевые принципы составления расписания:

• Учет часовых поясов. Если у вас распределенная команда (например, Европа и Азия), ищите «золотые часы» пересечения. Обычно это 3–4 часа в середине дня для одних и вечером/утром для других.
• Обязательные перерывы. Планируйте 10–15 минут перерыва каждый час. Это не рекомендация, это биологическая необходимость.
• Буферы времени. Онлайн-коммуникация всегда медленнее. Закладывайте +20% времени на переключения между виртуальными комнатами и технические заминки.

Коммуникационный план

До начала ивента каждый участник должен знать, где он должен находиться в любую минуту времени. Создайте единый документ (Wiki-страницу или PDF), содержащий:

1. Общее расписание.
2. Ссылки на общую встречу (Main Room).
3. Ссылки на командные комнаты (Breakout Rooms).
4. Контакты поддержки (RTE, Delivery Manager, IT-support).

2. Настройка инструментов: создание виртуальной «Большой комнаты»

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

«Святая троица» инструментов

Для эффективного планирования необходимы три типа инструментов, работающих в связке:

1. Видеоконференцсвязь (Zoom, MS Teams, Google Meet).
   • Требуется возможность создания сессионных залов (Breakout Rooms).
   • Убедитесь, что у фасилитаторов есть права организаторов для управления залами.
2. Визуальная коллаборация (Miro, Mural, Lucidspark).
   • Это ваша «стена». Здесь располагается Program Board (доска программы), доски команд, ROAM-доска рисков.
3. Система трекинга задач (Jira, ADO, Targetprocess).
   • Здесь хранятся реальные данные: фичи, истории, оценки.

Подготовка досок для коллаборации

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

Чек-лист готовности Miro/Mural:

• Создан фрейм для каждой команды с зонами для итераций (спринтов).
• Подготовлен центральный Program Board для визуализации зависимостей.
• Загружены шаблоны для целей PI (PI Objectives) и рисков.
• Настроены права доступа (проверьте, что все участники могут редактировать, а не только просматривать).

«Инструмент должен помогать процессу, а не становиться препятствием. Если команда тратит 10 минут на то, чтобы понять, как создать стикер, вы провалили подготовку».

3. Готовность бэклога: контент — это король

Никакая логистика не спасет планирование, если нечего планировать. Подготовка бэклога (Backlog Refinement) должна завершиться до начала PI-планирования.

Иерархия требований

Убедитесь, что все участники понимают структуру:

• Epics (Эпики): Глобальные инициативы.
• Features (Фичи): Функциональность, которая должна быть доставлена за один PI. Именно ими оперируют на планировании.
• User Stories (Пользовательские истории): Детализация фич для команд.

Definition of Ready (DoR) для фич

К моменту старта планирования, Топ-10 (или более, в зависимости от емкости) фич должны соответствовать критериям готовности.

Типичный DoR для фичи:

1. Четко сформулирована ценность (Benefit Hypothesis).
2. Определены критерии приемки (Acceptance Criteria).
3. Фича оценена (например, в Story Points или T-shirt sizes) для понимания масштаба.
4. Выявлены предварительные зависимости.

Роль Product Management и System Architect

Delivery Manager должен работать в тесной связке с Продуктовым менеджментом и Архитекторами.

• Product Management готовит видение (Vision) и приоритезированный бэклог фич.
• System Architect готовит архитектурное видение и Enabler-фичи (технические задачи, необходимые для реализации бизнес-фич).

4. Расчет доступной емкости (Capacity Planning)

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

Формула расчета емкости команды на спринт:

$$C_{sprint} = \sum_{i=1}^{n} (D_{work} - D_{off}) \times K_{focus}$$

Где:

• $C_{sprint}$ — емкость команды в человеко-днях (или часах/пунктах, в зависимости от единиц измерения) на один спринт.
• $n$ — количество участников команды.
• $D_{work}$ — количество рабочих дней в спринте (обычно 10 для двухнедельного спринта).
• $D_{off}$ — дни отсутствия конкретного сотрудника $i$ (отпуска, праздники, обучение).
• $K_{focus}$ — фокус-фактор (коэффициент эффективности). Обычно составляет 0.7–0.8, учитывая встречи, переключения контекста и непредвиденные задачи.

Пример: В команде 5 человек. Спринт 10 дней. Один человек уходит в отпуск на 2 дня. Фокус-фактор 0.8.

1. Полные дни: 4 человека $\times$ 10 дней = 40 дней.
2. Человек с отпуском: 1 $\times$ (10 - 2) = 8 дней.
3. Итого «грязных» дней: 48.
4. С учетом фокуса: $48 \times 0.8 = 38.4$ человеко-дня.

Это число — тот бюджет, который команда может «тратить» на задачи в планировании.

5. Синхронизация перед стартом

За неделю до события проведите встречу IPM (Innovation and Planning Iteration) sync или просто организационный синк.

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

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

Заключение

Подготовка к онлайн PI-планированию — это не просто административная работа. Это создание среды, в которой сотня людей сможет эффективно договориться о будущем продукта. Если вы настроили инструменты, адаптировали расписание и убедились в качестве бэклога, вы уже сделали 50% работы.

В следующей статье мы поговорим о том, как фасилитировать само мероприятие: от открытия до финального голосования уверенности.

Фасилитация первого дня: контекст бизнеса и создание черновиков планов в виртуальных комнатах

Рады видеть вас снова на курсе «Эффективное онлайн PI-планирование». В прошлой статье мы подготовили фундамент: настроили инструменты, рассчитали емкость и причесали бэклог. Теперь наступает момент истины — старт самого мероприятия.

Первый день PI-планирования (Program Increment Planning) — это день расхождения и схождения. Мы начинаем все вместе, затем расходимся по командам, чтобы создать черновики планов, и снова сходимся для синхронизации. В онлайн-формате роль Delivery и Project менеджера трансформируется из наблюдателя в активного «дирижера», который должен удерживать ритм и энергию распределенных команд.

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

1. Установка контекста: как не усыпить участников

Классическая повестка SAFe (Scaled Agile Framework) предполагает, что утро первого дня посвящено презентациям. Обычно это выглядит так:

1. Бизнес-контекст: Исполнительный директор или владелец бизнеса рассказывает о текущем состоянии компании и рынка.
2. Видение продукта/решения: Менеджмент продукта представляет видение (Vision) и топ-10 фич.
3. Архитектурное видение: Системный архитектор показывает технические изменения и новые подходы.

В офлайне это занимает 3–4 часа. В онлайне слушать «говорящие головы» столько времени невозможно. Внимание теряется через 20 минут, и участники начинают читать почту или листать ленту новостей.

Стратегии удержания внимания

Как менеджер, вы должны помочь спикерам адаптировать контент:

• Правило «TED Talk»: Ограничьте каждый слот выступления до 15–20 минут. Если тема требует больше времени, разбейте её на блоки с сессиями вопросов и ответов (Q&A).
• Предварительная запись: Рассмотрите возможность записать основные доклады заранее и выслать их участникам за 2 дня до события. Тогда синхронное время можно потратить исключительно на Q&A и обсуждение. Это экономит силы и время.
• Интерактивность: Используйте инструменты для опросов (Menti, Slido) прямо во время презентации. Например, после презентации бизнес-контекста спросите: «Какая из озвученных целей кажется вам наиболее амбициозной?».

«Цель утренней сессии — не просто передать информацию, а вдохновить команды. Если люди не понимают

Управление зависимостями и рисками между кросс-функциональными командами на цифровой Program Board

Добро пожаловать обратно. В предыдущих статьях мы подготовили инструменты и логистику, а также запустили первый день планирования, где команды разошлись по виртуальным комнатам для создания черновиков планов. Теперь мы подходим к самому сложному и критически важному этапу PI-планирования (Program Increment Planning) — синхронизации.

Если бы команды работали в вакууме, PI-планирование заканчивалось бы через 2 часа. Но в крупных проектах ценность создается на стыке работы нескольких команд. Именно здесь возникают «узкие места»: зависимости и риски. Ваша задача как Delivery или Project менеджера — визуализировать эти невидимые нити и превратить хаос взаимосвязей в структурированный план.

В этой статье мы разберем работу с цифровой доской программы (Program Board), математику влияния зависимостей на успех и технику ROAM для управления рисками.

1. Цифровая доска программы: Единый источник правды

В офлайне Program Board — это огромная физическая доска с нитками, соединяющими стикеры. В онлайне (Miro, Mural) это пространство должно быть организовано еще более строго, так как мы лишены возможности физически «подойти и показать пальцем».

Структура доски

Цифровая доска программы — это матрица, которая показывает, когда (в какой итерации) и кем (какой командой) будет доставлена ценность.

• Колонки (По вертикали): Итерации (Спринты) внутри PI. Обычно это 4–5 спринтов разработки и 1 спринт IP (Innovation and Planning).
• Строки (По горизонтали): Команды, входящие в Agile Release Train (ART).
• Контент: Сюда помещаются только Фичи (Features) и значимые Зависимости (Dependencies). Пользовательские истории (User Stories) остаются на досках команд.

Правило «Красной нити»

В цифровых инструментах зависимости отображаются линиями (connectors). В методологии SAFe (Scaled Agile Framework) принято использовать красный цвет для зависимостей, чтобы они бросались в глаза.

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

2. Математика зависимостей: Почему их нужно минимизировать

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

Давайте рассмотрим это с точки зрения теории вероятностей. Предположим, у нас есть цепочка из 3 команд, где Команда А должна передать работу Команде Б, а та — Команде В.

Формула вероятности успеха последовательных событий (цепной зависимости) выглядит так:

$$P_{total} = \prod_{i=1}^{n} P_{i} = P_1 \times P_2 \times \dots \times P_n$$

Где:

• $P_{total}$ — общая вероятность успешного завершения всей цепочки задач в срок.
• $n$ — количество зависимых этапов (команд/задач).
• $P_{i}$ — вероятность успешного выполнения задачи $i$-й командой в срок (допустим, она составляет 90% или 0.9).
• $\prod$ — знак произведения (перемножения всех элементов последовательности).

Пример: Если у вас есть цепочка из 5 зависимых фич, и каждая команда уверена в успехе на 90% ($0.9$), то общая вероятность успеха составит:

$$P_{total} = 0.9 \times 0.9 \times 0.9 \times 0.9 \times 0.9 \approx 0.59$$

Это означает, что при, казалось бы, высокой надежности каждой отдельной команды, общая вероятность успеха падает до 59%. Именно поэтому ваша цель на Program Board — не просто нарисовать красивые линии, а попытаться их убрать (развязать зависимости).

3. Фасилитация сессии управления зависимостями

Во второй половине первого дня или утром второго дня проводится Management Review и синхронизация. Как Delivery Manager, вы должны модерировать этот процесс.

Алгоритм действий:

1. Выявление: Попросите представителей команд (обычно Scrum Master или Product Owner) озвучить свои зависимости. Не принимайте ответ «мы договорились в чате». Если зависимости нет на доске — её не существует.
2. Проверка логики: Убедитесь, что фича-предшественник стоит в более раннем спринте, чем фича-последователь.
3. Переговоры: Если Команда Б не может взять задачу от Команды А в нужном спринте, инициируйте диалог. Возможно, нужно изменить приоритеты или упростить скоуп (объем работ).

«Зависимость — это не просто линия на экране. Это обещание одной команды другой. Если обещание не может быть выполнено, об этом нужно знать сейчас, а не в конце спринта».

4. Управление рисками: Техника ROAM

После того как план черновика готов и зависимости обозначены, команды выявляют риски. Риск — это событие, которое может произойти и негативно повлиять на план. В онлайне для этого создается отдельная область на доске — ROAM Board.

Каждый риск должен быть зачитан вслух перед всей аудиторией (или на уровне ART sync) и категоризирован в одну из четырех групп ROAM:

Расшифровка категорий ROAM:

1. Resolved (Решено): Команды обсудили риск и нашли решение прямо во время планирования. Риск больше не угрожает плану.
   • Пример: «Мы боялись, что не будет доступа к тестовой среде, но DevOps только что выдал нам права».
2. Owned (Взято во владение): Риск нельзя решить прямо сейчас, но назначен конкретный человек (Owner), который берет на себя ответственность разобраться с ним после планирования.
   • Пример: «Неясно, поддержит ли вендор новый API. Архитектор берет задачу связаться с вендором на следующей неделе».
3. Accepted (Принято): Мы понимаем риск, но ничего не можем с ним сделать (или стоимость решения превышает ущерб). Мы принимаем его как данность («If it happens, it happens»).
   • Пример: «Есть риск задержки релиза из-за штормового предупреждения в регионе дата-центра. Мы не можем управлять погодой».
4. Mitigated (Смягчено): Мы разработали план действий, который снижает вероятность или влияние риска.
   • Пример: «Есть риск болезни ключевого разработчика. Мы договорились о парном программировании, чтобы передать знания дублеру».

Ваша задача — убедиться, что на доске не осталось «висящих» рисков без категории.

5. Финальное голосование уверенности (Confidence Vote)

Когда зависимости улажены, а риски прошли через ROAM, наступает кульминация — голосование уверенности. В онлайне это делается через инструменты опросов или «пальцы в камеру».

Используется шкала «Fist of Five» (от 1 до 5 пальцев):

• 1-2 пальца: Нет уверенности, план нереалистичен. Требуется перепланирование.
• 3 пальца: Есть сомнения, но готов попробовать. Приемлемый уровень, но требует внимания.
• 4-5 пальцев: Полная уверенность и готовность коммититься.

Математика голосования: Если средний балл по поезду (ART) низкий, или если есть хотя бы один человек, показавший «1» или «2», планирование не заканчивается. Вы должны спросить этого человека: «Что нужно изменить в плане, чтобы ты поднял 3 пальца?».

Заключение

Управление зависимостями и рисками на цифровой доске — это то, что отличает набор разрозненных команд от слаженного «поезда» (Agile Release Train). Визуализация связей и честный разговор о рисках позволяют превратить неопределенность в управляемый план.

Помните формулу вероятности: каждая лишняя зависимость снижает шансы на успех. Будьте тем менеджером, который помогает командам «развязывать узлы», а не просто документировать их.

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

Второй день планирования: обзор менеджмента, финализация целей и проведение Confidence Vote

Добро пожаловать на финишную прямую нашего курса. Мы прошли через сложную логистику подготовки, пережили хаос первого дня и распутали клубок зависимостей. Теперь наступает решающий момент — второй день PI-планирования (Program Increment Planning).

Если первый день — это дивергенция (расширение, генерация идей и выявление проблем), то второй день — это конвергенция (схождение, принятие решений и финализация обязательств). Для Delivery и Project менеджера это день, когда дипломатия и жесткая приоритизация выходят на первый план.

В этой статье мы разберем, что происходит за закрытыми дверями на Management Review, как правильно сформулировать цели PI (PI Objectives) и как провести финальное голосование уверенности так, чтобы оно не стало формальностью.

1. Утро второго дня: результаты Management Review

Второй день начинается не с кофе, а с объявления решений, принятых руководством накануне вечером. В конце первого дня, когда команды уходят отдыхать, менеджмент (RTE, Product Managers, System Architects, Business Owners) собирается на встречу Management Review and Problem Solving.

Зачем это нужно?

В ходе первого дня команды неизбежно сталкиваются с проблемами:

• Объем работы превышает емкость (Capacity).
• Критические зависимости невозможно разрешить без изменения дат.
• Не хватает компетенций или ресурсов.

Менеджмент должен решить эти проблемы, изменив объем (Scope). В треугольнике ограничений (Время, Бюджет, Объем) на PI-планировании время (длина PI) и бюджет (люди) фиксированы. Единственный рычаг управления — это объем работ.

Математика перегрузки

Чтобы принять решение о сокращении объема, менеджеры анализируют коэффициент утилизации поезда (ART). Формула утилизации выглядит так:

$$U_{art} = \frac{\sum_{i=1}^{n} L_{planned_i}}{\sum_{i=1}^{n} C_{avail_i}}$$

Где:

• $U_{art}$ — коэффициент утилизации Agile Release Train (поезда).
• $n$ — количество команд в поезде.
• $L_{planned_i}$ — запланированная нагрузка $i$-й команды (в Story Points или часах).
• $C_{avail_i}$ — доступная емкость $i$-й команды.

Если $U_{art} > 1$ (или $100\%$), это сигнал тревоги. Система перегружена, и риск провала стремится к максимуму. На утренней встрече второго дня вы, как менеджер, должны транслировать командам решения: какие фичи были удалены из бэклога, какие приоритеты изменены, чтобы вернуть $U_{art}$ к безопасному значению (обычно $0.8 - 0.9$).

2. Вторая сессия команд: финализация планов

Получив новые вводные, команды возвращаются в свои виртуальные комнаты (Breakout Rooms). У них есть несколько часов, чтобы обновить планы, пересчитать нагрузку и, самое главное, сформулировать цели.

От фич к целям (PI Objectives)

Частая ошибка новичков — считать, что список фич в Jira и есть план. Это не так. Фичи — это что мы делаем. Цели PI — это зачем мы это делаем и какую ценность доставляем.

Цели должны быть написаны на языке бизнеса, а не на техническом жаргоне. Мы используем формат SMART:

• Specific (Конкретные)
• Measurable (Измеримые)
• Achievable (Достижимые)
• Relevant (Значимые)
• Time-bound (Ограниченные во времени — в данном случае рамками PI)

Разделение целей: Committed vs Uncommitted

Не все цели одинаковы. SAFe предлагает разделять их на две категории:

1. Committed Objectives (Обязательные цели): Команда уверена в их выполнении на 100%. Это основное обязательство.
2. Uncommitted Objectives (Необязательные цели): Цели, которые команда планирует сделать, но риски слишком высоки.

Важно: Необязательные цели — это не «дополнительная работа, если останется время». Это работа, которая уже включена в план и емкость команды, но имеет высокую неопределенность (например, ожидание поставки от третьей стороны).

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

3. Присвоение бизнес-ценности (Business Value)

Когда черновики целей готовы, в виртуальные комнаты заходят Бизнес-владельцы (Business Owners). Начинается процесс «торговли» и выравнивания ожиданий.

Бизнес-владельцы присваивают каждой цели (включая Uncommitted) рейтинг ценности от 1 до 10.

• 10: Критически важно для бизнеса, без этого PI провален.
• 1: Полезно, но можно прожить и без этого.

Этот процесс критичен для Delivery менеджера. Он показывает, понимает ли команда приоритеты бизнеса. Если команда считает технический рефакторинг целью на «10», а бизнес ставит «2», у вас серьезный рассинхрон, который нужно обсудить прямо сейчас.

4. Финальный обзор плана (Final Plan Review)

В онлайн-формате мы не можем позволить каждой из 10-12 команд выступать по 15 минут. Это убьет динамику. Используется формат «Pitch» (короткая презентация).

Каждая команда имеет строго 3-5 минут, чтобы показать:

1. Свою доску с итерациями.
2. Список целей PI с оценками бизнес-ценности.
3. Оставшиеся риски и зависимости.

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

5. Голосование уверенности (Confidence Vote)

Это кульминация двухдневной работы. Весь Agile Release Train (все участники, от разработчиков до директоров) голосует за то, верят ли они в реалистичность созданного плана.

Мы используем метод «Fist of Five» (Кулак пяти). В Zoom или Teams участники поднимают руку перед камерой или пишут цифру в чат.

Шкала голосования:

• 5 пальцев: Полная уверенность. Отличный план.
• 4 пальца: Хороший план, уверен, что сделаем.
• 3 пальца: Приемлемо. Есть сомнения, но готов взять обязательства.
• 2 пальца: Серьезные сомнения. Не готов коммититься.
• 1 палец: План нереалистичен. Это катастрофа.

Обработка результатов

Если средний балл высокий, но есть хотя бы один голос «1» или «2», процесс останавливается. Мы не игнорируем меньшинство.

Вы, как фасилитатор, обращаетесь к проголосовавшему:

«Я вижу двойку. Пожалуйста, включи микрофон. Какой риск или проблему ты видишь, которую мы упустили? Что нужно изменить в плане, чтобы ты поднял три пальца?»

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

Rework (Перепланирование)

Если голосов «1» и «2» много, или выявленная проблема критична, объявляется Rework. Команды снова расходятся по комнатам на 30-60 минут, чтобы перестроить план с учетом новой информации. После этого голосование повторяется.

Никогда не давите на людей, заставляя их голосовать «за». Выдавленное согласие приведет к провалу через месяц. Лучше потратить час сейчас, чем потерять 10 недель потом.

6. Завершение и Ретроспектива

После успешного голосования (когда все показали 3 и выше) план считается принятым. Но работа Delivery менеджера не закончена. Необходимо сразу же провести короткую ретроспективу самого события PI-планирования.

В онлайне хорошо работает формат «Plus / Delta»:

• Plus (+): Что прошло хорошо? (Например: «Miro работало быстро», «Тайминг соблюдался»).
• Delta (Δ): Что улучшить в следующий раз? (Например: «Слишком длинные презентации», «Плохой звук у архитекторов»).

Заключение

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

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

Поздравляем! Вы успешно спланировали инкремент программы. Но планирование — это только карта, а путешествие еще впереди. В следующих материалах мы могли бы рассмотреть исполнение PI, но на этом наш текущий цикл статей о планировании завершен. Удачи в ваших Agile Release Trains!

Завершение и пост-планирование: ретроспектива события и переход к исполнению инкремента

Поздравляем! Вы только что пережили два (или три) самых напряженных дня в календаре Delivery-менеджера. Онлайн PI-планирование завершено, Confidence Vote показал высокий уровень доверия, а виртуальные доски пестрят стикерами и связями.

Многие менеджеры в этот момент совершают фатальную ошибку: они выдыхают и «уходят в закат» на пару дней, чтобы восстановить силы. Однако пост-планирование — это критическая фаза, определяющая, останется ли план красивой картинкой в Miro или превратится в работающий софт. Как говорят опытные RTE (Release Train Engineers): «План — ничто, исполнение — всё».

В этой заключительной статье курса мы разберем, что делать сразу после закрытия Zoom-конференции, как измерить успешность самого процесса планирования и как настроить ритм исполнения (Execution) на следующие 10 недель.

1. Цифровая гигиена: Синхронизация инструментов

В офлайне главной проблемой было перенести физические стикеры со стены в Jira. В онлайне проблема иная: у вас есть «красивая версия» плана в инструменте визуализации (Miro/Mural) и «суровая реальность» в трекере задач (Jira/ADO/Targetprocess).

Ваша первая задача — обеспечить Single Source of Truth (Единый источник истины).

Алгоритм синхронизации (Post-PI Cleanup)

Этот процесс должен быть завершен в течение 24–48 часов после окончания планирования.

1. Экспорт целей PI. Цели, сформулированные на слайдах, должны быть оцифрованы. В Jira это часто делается через создание тикетов типа «Objective» или использование специальных плагинов (например, Jira Align или Structure).
2. Фиксация зависимостей. Красные нити на Program Board должны превратиться в линки типа blocks / is blocked by в трекере задач.
3. Чистка бэклога. Все фичи, которые не вошли в план (Cut scope), должны быть возвращены в бэклог программы или удалены из итераций.
4. Проверка Capacity. Убедитесь, что в трекере задач capacity команд настроена так же, как это было в Excel-табличках на планировании.

«Если задачи нет в Jira, разработчик её не делает. Если зависимости нет в Jira, Delivery Manager её не видит».

2. Ретроспектива события планирования

Не путайте это с ретроспективой спринта. Это ретроспектива самого ивента PI-планирования. Вам нужно понять, насколько эффективной была логистика, инструменты и фасилитация.

Кто участвует?

• Лидеры (RTE, Product Management, System Architect).
• Scrum-мастера всех команд.
• Представители команд (по желанию).

Метрики качества планирования

Помимо субъективных ощущений («было скучно», «было весело»), используйте данные. Оцените событие по следующим критериям:

1. Техническая стабильность: Сколько времени было потеряно из-за проблем со связью или доступом?
2. Соблюдение тайминга: Закончили ли мы вовремя или сидели до полуночи?
3. Качество целей: Сколько целей соответствуют критериям SMART?

3. Измерение успеха: Program Predictability Measure

Как понять, хорошо ли мы работаем? В SAFe (Scaled Agile Framework) основной метрикой надежности поезда является Program Predictability Measure (PPM) — мера предсказуемости программы.

Эта метрика рассчитывается не в конце планирования, а в конце PI (Program Increment), но базу для неё мы закладываем именно сейчас, фиксируя Planned Business Value (Планируемую бизнес-ценность).

Математика предсказуемости

Формула расчета PPM для одной команды выглядит следующим образом:

$$PPM_{team} = \frac{\sum_{i=1}^{n} BV_{actual_i}}{\sum_{j=1}^{m} BV_{planned_j}} \times 100\%$$

Где:

• $PPM_{team}$ — показатель предсказуемости команды в процентах.
• $n$ — количество всех достигнутых целей (включая Committed и Uncommitted).
• $BV_{actual_i}$ — фактическая бизнес-ценность $i$-й цели, присвоенная бизнес-владельцами в конце PI (от 0 до 10).
• $m$ — количество только обязательных (Committed) целей.
• $BV_{planned_j}$ — плановая бизнес-ценность $j$-й обязательной цели, присвоенная на планировании.

Важный нюанс: В знаменателе (делителе) мы учитываем только Committed Objectives. В числителе (делимом) мы суммируем ценность всех выполненных целей, включая Uncommitted.

Это позволяет команде достичь более 100% выполнения, если они сделали и обязательные, и дополнительные рискованные цели. Целевой диапазон «здорового» поезда — 80–100%.

Пример расчета: Команда запланировала 5 целей с общей ценностью 40 баллов (все Committed). Также была одна Uncommitted цель на 5 баллов. В конце PI они выполнили все Committed цели (получили 40 баллов) и справились с Uncommitted целью (получили 5 баллов).

$$PPM = \frac{40 + 5}{40} \times 100\% = 112.5\%$$

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

4. Переход к исполнению: Ритм поезда

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

Scrum of Scrums (SoS)

Это встреча для Scrum-мастеров и RTE.

• Частота: 1–2 раза в неделю.
• Длительность: 30–45 минут.
• Фокус: Зависимости, препятствия (Impediments) и риски.
• Анти-паттерн: Превращать SoS в статус-митинг («Мы сделали задачу 123»). На SoS нужно говорить только о том, что блокирует другие команды.

PO Sync (Product Owner Sync)

Встреча для Product Owners и Product Management.

• Частота: 1 раз в неделю.
• Фокус: Изменения в скоупе, уточнение требований, подготовка к следующему PI.
• Цель: Убедиться, что мы строим правильный продукт, и приоритеты не изменились.

System Demo

В конце каждой итерации (спринта) команды должны показывать не просто свой кусочек кода, а интегрированное решение.

«Интеграция — это момент истины. Если части работают по отдельности, но не работают вместе — работа не сделана».

В онлайн-формате System Demo требует тщательной подготовки сценария, так как переключение между экранами 10 команд может убить динамику.

5. Inspect and Adapt (I&A)

Курс был бы неполным без упоминания того, чем заканчивается PI. Последний спринт (IP Iteration) посвящен не разработке, а инновациям и планированию. Ключевое событие здесь — Inspect and Adapt.

Это глобальная ретроспектива, где мы смотрим на метрики (включая тот самый PPM), проводим System Demo всего инкремента и запускаем мастерскую по решению проблем (Problem Solving Workshop).

Именно на I&A закрывается цикл обучения, и мы готовимся к новому PI-планированию, начиная процесс заново, но уже на более высоком уровне зрелости.

Заключение курса

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

Ключевые выводы курса:

1. Подготовка решает всё. Онлайн не прощает импровизации. Логистика и инструменты должны быть безупречны.
2. Визуализация — ваш главный инструмент. Если зависимости не видны, они ударят вам в спину.
3. Разговор важнее документа. Инструменты нужны, чтобы инициировать диалог, а не заменить его.
4. Доверие через прозрачность. Честное обсуждение рисков (ROAM) и голосование уверенности создают культуру ответственности.

Роль Delivery и Project менеджера в современном мире — это роль садовника. Вы не можете заставить растение (продукт) расти быстрее, потянув его за верхушку. Но вы можете создать идеальные условия: полив (ресурсы), свет (видение) и отсутствие сорняков (препятствий).

Удачного вам планирования и предсказуемых релизов!