Как провести PI-планирование на 100+ человек в Kaiten

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

Мы пообщались с Ириной Бобрихиной, одиним из скрам-мастеров IT-компании RDP. Она поделилась подробным кейсом проведения PI-планирования в крупной компании с помощью Kaiten.

Пару слов о компании

Компания RDP входит в группу компаний «Ростелеком» и специализируется на разработке инновационного программного обеспечения и программно-аппаратных комплексов для высокопроизводительной обработки сетевого трафика. Продукция компании широко востребована в сетях операторского класса, крупных предприятиях и Госсекторе.

Какие проблемы помогают решить Kaiten и PI-планирование

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

Основные трудности, требовавшие решения:

• Проблема №1: клиент стремился к прямому диалогу с инженерами и разработчиками, минимизируя количество посредников, чтобы ускорить процесс общения и передавать свои идеи непосредственно тем, кто работает над проектом.
• Проблема №2: работа различных команд над отдельными продуктами, которые в совокупности формировали комплексное решение, представляющее ценность для клиента, иногда сталкивалась с трудностями синхронизации и взаимопонимания, особенно при учете зависимостей между продуктами. Это приводило к задержкам в поставке конечного решения и недовольству со стороны клиента.

Мы решили использовать Kaiten. Цель состояла в том, чтобы создать кросс-функциональный бизнес-процесс, который бы объединил всех участников проекта — от руководителей до заказчиков и исполнителей, позволяя им наблюдать за ходом работы в реальном времени и получать необходимую аналитику без посредников.

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

Что такое PI-планирование

PI-планирование, стоящее в центре методологии SAFe, представляет собой ключевое событие, в ходе которого руководители бизнеса и команды Agile Release Train определяют стратегические направления и формируют планы на следующий квартал, опираясь на поставленные цели.

Двухдневное PI-планирование собирает всех участников проекта для установления новых целей, анализа их достижимости и обмена мнениями с заказчиками.

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

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

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

Таким образом, PI-планирование является мощным инструментом для ускорения мыслительных процессов и эффективного взаимодействия в рамках больших проектов.

Процесс PI-планирования в действии

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

Структура рабочих элементов на трех уровнях

Мы определились с тремя уровнями иерархии рабочих элементов для нашего проекта:

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

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

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

Подготовка к PI-планированиею

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

• ключевые цели формулируются представителями бизнеса;
• менеджер продукта, системный архитектор и Release Train Engineer приступают к декомпозиции этих целей, разрабатывая основные направления идей;
• Agile-команды в кооперации с владельцем продукта делят полученные идеи на конкретные задачи, формируя свой список предстоящих работ.

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

Мы визуализировали этот процесс в Kaiten.

На уровне эпиков у нас расписан верхнеуровневый end-to-end процесс всего Agile Release Train, который обеспечивает поставку ценности. Для этого в Kaiten у нас есть верхнеуровневое пространство, на котором мы отображаем эпики. На нем показаны все этапы от зарождения идей, до их проработки, реализации и релиза.

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

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

Погружение команд в бизнес-контекст

Процесс PI-планирования занимает два дня и проводится в формате личных встреч всех ключевых участников в конференц-зале.

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

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

Планирование итераций

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

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

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

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

Определение зависимостей

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

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

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

Анализ рисков в контексте PI-планирования

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

Сначала команда фиксирует бэклог рисков на специальной доске. А далее они разбиваются на 4 колонки по категориям (по модели ROAM):

• Принятые (Accepted) – риски, с которыми мы согласны работать и берем на себя ответственность за их управление;
• Ответственные (Owned) – риски, для которых определяется конкретный человек, ответственный за мониторинг ситуации и принятие мер по минимизации или устранению;
• Минимизированные (Mitigated) – риски, для которых заблаговременно разрабатывается стратегия действий в случае их реализации;
• Решенные (Resolved) – риски, которые были урегулированы на этапе планирования.

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

Презентация и оценка планов команд

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

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

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

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

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

Заключительный этап PI-планирования и реализация

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

На доске с общими целями (эпиками) карточки разделяются на две категории:

• Обязательные (Committed) — задачи, выполнение которых гарантировано;
• Условные (Uncommitted) — задачи, реализация которых планируется, но под влиянием потенциальных рисков.

Ключевым моментом является оценка бизнес-ценности каждой цели представителями бизнеса и заказчиками, отраженная в карточке по шкале от 1 до 10. Это позволит в дальнейшем оценить степень достижения запланированной ценности.

Далее начинается этап реализации: команды, имея четкий план на каждую итерацию, распределяют задачи на Канбан-доске в соответствии с установленными процессами.

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

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

В конце итерации команды указывают реально достигнутую бизнес-ценность в карточках. Например, если цель была оценена в 10 и достигнута полностью, в графе реальной бизнес-ценности (Actual BV) также отмечается 10.

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

Удалось ли достичь поставленных целей?

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

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

Выводы и работа над ошибками

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

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

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

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

Ошибка №4: Игнорирование различий в работоспособности команд. Время, необходимое для планирования, может значительно варьироваться в зависимости от опыта и подготовленности команд.

Ошибка №5: Приглашение всех команд без отбора на первое планирование. Лучше начать с команд, имеющих наибольшее количество взаимосвязей, и постепенно расширять круг участников, избегая приглашения тех, кто не вносит прямого вклада в глобальные цели. Это предотвратит потенциальное недовольство и сопротивление участия в мероприятии. Возможно, стоит включать по одному представителю от менее вовлеченных команд для обеспечения коммуникации и быстрого реагирования на вопросы.