Пару слов о компании
Компания RDP.RU входит в группу компаний «Ростелеком» и специализируется на разработке инновационного программного обеспечения и программно-аппаратных комплексов для высокопроизводительной обработки сетевого трафика. Продукция компании широко востребована в сетях операторского класса, крупных предприятиях и Госсекторе.
Какие проблемы помогают решить Kaiten и PI-планирование
В своей работе с одним из ключевых заказчиков из Госсектора мы столкнулись со сложностями в коммуникациях, непрозрачностью процессов; стандартные инструменты и методы коммуникаций были неэффективны и мы задумались об улучшении взаимодействия.
Одни из основных проблем, которые мы пытались решишь:
Проблема №1: заказчик хотел общаться напрямую с инженерами и разработчиками, иметь минимальное число посредников, тем самым сократить время на коммуникации и доносить свое видение напрямую исполнителям.
Проблема №2: разные команды работают над разными продуктами, эти продукты вместе образуют комплексное решение, которое несет основную ценность для заказчика, однако иногда возникали сложности в синхронизации между командами, недопонимание влияния зависимостей между продуктами, что приводило к задержкам финальной поставки решения и неудовлетворенности заказчика.
Текущая модель взаимодействия не отвечала запросам заказчика по эффективности и оперативности. Необходимо было придумать новый формат.
Тогда у нас возникла идея попробовать визуальную систему управления процессами Kaiten, которую поддержал директор по развитию. Целью было создать кросс-функциональный бизнес-процесс между всеми заинтересованными лицами. Чтобы руководители, заказчики и исполнители всех направлений могли видеть происходящее без посредников и получать аналитику, когда им это потребуется.
В связи с масштабированием компании и ростом количества межкомандных зависимостей мы решили обратиться к SAFe 6.0 — это фреймворк, спроектированный для внедрения гибких методик разработки в крупных компаниях от 100 человек. Он применяется, когда компания вышла из состояния стартапа в матричную структуру, бизнес-процессы усложняются, но компания хочет оставаться достаточно маневренной.
Что такое PI-планирование
Одним из событий в рамках SAFe является PI-планирование (планирование программного инкремента) — это мероприятие, на котором владельцы бизнеса (Business Owners) и все команды (Agile Release Train) определяют высокоуровневые цели и согласно этим целям планируют свою работу на квартал.
Agile Release Train (ART, или поезд) — это несколько Agile-команд, которые на постоянной основе участвуют в едином потоке создания ценности, приносящей пользу заказчику. Они совместно планируют, принимают обязательства, разрабатывают и выпускают эту ценность.
Программный инкремент — это период времени до 12 недель, в течение которого команды выполняют запланированную работу над проектом.
PI-планирование обычно длится 2 дня. Все участники проекта собираются вместе, чтобы поставить цели на новый период, критически оценить, насколько они выполнимы, и услышать обратную связь от заказчиков.
В ходе PI-планирования обязательно применяется визуализация задач и строятся взаимосвязи между уровнями. В нашей компании это Epic – Feature/Enabler – Tasks. Это помогает командам увидеть, как конкретная точечная задача связана с глобальной целью компании, а также подсветить зависимости друг от друга — пока одна команда не сделает свою часть, другая не сможет выполнить следующую.
Результатом PI-планирования является детальный план на 3 месяца, который включает в себя согласованные цели команд, задачи, которые необходимо выполнить, а также оценку рисков.
Это дает ощущение стабильности и способствует сближению заказчика и команд.
Команды, которые ежедневно работают над продуктом, могут напрямую услышать от заказчика требования и ожидания. Заказчик транслирует цели конкретного квартала, и все участники понимают, куда нужно двигаться.
Заказчик видит, какие задачи команда берет в план и как она их декомпозирует. Он может задать свои вопросы напрямую исполнителям.
Все участники принимают на себя обязательства и точно знают, в какой точке будут находиться через квартал. Это исключает ситуации, когда заказчик может сказать «я вовсе не это имел в виду» или когда команда скажет «мы не учли риски, поэтому не успели». Так как на планировании открыто проговариваются все эти вопросы.
PI-планирование создает условия, в которых мозг работает быстрее. Все участники готовы обсуждать острые моменты здесь и сейчас, а не откладывать вопросы до какой-то встречи.
Как происходит PI-планирование на практике
В нашем случае планирование проводится 1 раз в квартал в формате живой встречи. В нем участвуют 16 команд, работающих над разными под-продуктами, владельцы бизнеса и заказчики. На текущий момент мы провели 5 подобных мероприятий.
3 уровня иерархии рабочих элементов
Мы решили, что у нас будет 3 уровня иерархии рабочих элементов:
самый верхний уровень — это эпики — глобальные цели на уровне представителей бизнеса;
второй уровень — это фичи и энейблеры. Фича — это часть функциональности, которая несет ценность для клиента. А энейблер — это техническая вспомогательная задача, которая обеспечивает создание этой ценности;
далее фичи и энейблеры декомпозируются на таски — это рабочие задачи, с которыми команды исполнителей взаимодействуют каждый день.
Для каждого из этих уровней предусмотрен свой тип карточек в Kaiten, а также особое место для визуализации — отдельные доски и пространства.
На PI-планировании нам необходимо синхронизировать работу всех участников процесса таким образом, чтобы в результате таски каждой команды вели к выполнению глобальных целей и не противоречили друг другу.
Подготовка к PI-планированию
Подготовка является важным этапом, без которого PI-планирование не будет результативным. Перед общим собранием на каждом из уровней определяются и декомпозируются рабочие элементы:
представители бизнеса устанавливают ключевые цели;
менеджер продукта, системный архитектор и Release Train Engineer раскладывают эти цели на составляющие и производят верхнеуровневую проработку идей;
Agile-команды вместе с владельцем продукта разбивают проработанные идеи на задачи и формируют свой бэклог.
Таким образом, все участники планирования заранее проводят отбор идей и задач, которые дальше им нужно будет синхронизировать друг с другом — найти зависимые задачи и договориться, к какому этапу какая команда выполнит свою часть поставляемой ценности.
Мы визуализировали этот процесс в Kaiten:
На уровне эпиков у нас расписан верхнеуровневый end-to-end процесс всего Agile Release Train, который обеспечивает поставку ценности. Для этого в Kaiten у нас есть верхнеуровневое пространство, на котором мы отображаем эпики. На нем показаны все этапы от зарождения идей, до их проработки, реализации и релиза.
Когда бизнес выдвигает идею, она прорабатывается сначала на верхнем уровне, а затем попадает в колонку «Предварительная оценка командой» и отправляется на пространство команд для технической оценки:
Команда, ответственная за определенный подпродукт, раскладывает идею на фичи и энейблеры на своем пространстве. Проработка задачи включает в себя описание, определение критериев готовности и оценку в стори-поинтах. После этого карточки попадают в колонку «to plan». Это означает, что они готовы к PI-планированию и этап подготовки завершен.
Погружение команд в бизнес-контекст
Само PI-планирование проходит в 2 дня. Все заинтересованные лица собираются в конференц-зале и общаются друг с другом лично.
Всё начинается с погружения команд в бизнес-контекст. Заказчик описывает, какие проблемы предстоит решить, а топ-менеджмент компании фокусирует внимание на верхнеуровневых целях.
Это позволяет командам понять полную картину и выйти за рамки мышления точечными задачами. В результате команды разработки не просто получают задачу, а понимают бизнес-цель — что именно нужно сделать и для чего. У них появляется место для маневра и возможность самостоятельно предлагать решение конкретной цели.
Планирование итераций
Дальше люди расходятся по своим командам. Их задача — договориться и разложить фичи и энейблеры по двухнедельным итерациям на квартал вперед. Из колонки «to plan» они распределяют карточки по колонкам на доске планирования на уровне команды:
Далее им также нужно разложить по итерациям таски, которые являются составными элементами фичей или энейблеров.
Здесь для каждой итерации важно учитывать емкость команды: сколько задач она сможет осилить. В этом помогает отчет Kaiten о средней скорости команды. Мы точно знаем, сколько стори-поинтов может выполнить команда и, соответственно, сколько работы она может взять за итерацию.
Также при планировании итераций мы оставляем командам буферы для внеплановых задач, чтобы у них оставалось пространство для маневра.
Определение зависимостей
В процессе распределения задач по итерациям командам нужно выявить зависимости и синхронизироваться между собой, потому что некоторые задачи находятся на стыке разных продуктов.
Мы визуализируем зависимости на специальной доске в Miro. На ней отмечены итерации и глобальные цели. А на пересечении находятся задачи, по которым есть несостыковки. Сами зависимости обозначаются красными стрелками.
Когда зависимости определены, командам нужно договориться, кто и в какую итерацию выполнит свою часть работы.
Определение рисков
Еще один шаг, который выполняется в рамках PI-планирования, — это определение рисков, с которыми мы можем столкнуться при выполнении плана.
Сначала команда фиксирует бэклог рисков на специальной доске. А далее они разбиваются на 4 колонки по категориям (по модели ROAM):
Accepted – риски, которые мы принимаем и берем на себя ответственность;
Owned – риски, за которые назначается ответственным определенный человек. Он будет наблюдать за развитием ситуации и принимать меры по их снижению или устранению;
Mitigated – риски, по которым мы заранее формируем план, как будем действовать в случае их наступления;
Resolved – риски, урегулированные в процессе самого планирования.
В карточках отмечается подробная информация по всем рискам, при необходимости назначаются ответственные, а с помощью меток отмечаем, какие команды и продукты этот риск может затронуть.
Защита планов команд и голосование
Когда план итераций составлен, зависимости определены, риски проработаны, команды переходят к защите своих планов. Обычно защита проходит в два этапа:
Предзащита в конце первого дня PI-планирования, когда команды приносят черновики, а руководство дает обратную связь.
Дальше команды дорабатывают и представляют скорректированные планы в конце второго дня PI-планирования.
Все участники обсуждают планы команд, анализируют зависимости и могут оставлять свои комментарии.
Для удобства у нас есть отдельное пространство в Kaiten, на котором видно, с какими фичами будет работать каждая команда в разбивке по итерациям:
Важный ритуал на защите планов — это пятибалльная оценка уровня доверия своему плану. Каждый участник команды рукой показывает, насколько он верит, что этот план выполним. Если кто-то ставит низкую оценку, это повод поговорить о том, какие риски он видит, и найти решение.
Завершение PI-планирования, реализация и контроль
После того как команды защитили все планы и определили риски, остается только зафиксировать итоговый план, поздравить всех участников и начать новый квартал.
На пространстве с верхнеуровневыми целями (эпиками) карточки распределяются по двум колонкам:
обязательные (Committed) – те, которые мы обязуемся выполнить;
необязательные (Uncommitted) – те, что мы планируем сделать, но учитываем, что есть риски, которые могут нам помешать.
Важно, что владельцы бизнеса и заказчики определяют бизнес-ценность для каждой цели и прописывают ее в карточке в виде коэффициента от 1 до 10. После мы сможем оценить, насколько эта ценность была выполнена.
Затем начинается непосредственно реализация планов. У команд уже составлен подробный бэклог на каждую итерацию. Они берут готовые таски и перетаскивают их на рабочую Канбан-доску в соответствии со своими алгоритмами пополнения.
В течение 2-х недельных итераций команды Agile Release Train встречаются между собой, чтобы обсудить, в правильном ли направлении движется каждая команда, насколько эффективно решаются зависимости, есть ли какие-то проблемы.
В конце итераций команды предоставляют готовые элементы функциональности системы и демонстрируют их заказчику. Он, в свою очередь, может дать обратную связь.
Также в конце итераций мы возвращаемся к верхнему уровню целей и оцениваем, насколько нам удалось их достичь. В каждой карточке с целью мы проставляем фактический коэффициент ее выполнения. То есть, если цель была оценена на 10 и выполнена на 100%, то в поле Actual BV (business value) будет стоять 10.
Это помогает нам контролировать, как выполнение точечных задач команд влияет на финальную ценность для заказчика.
Удалось ли достичь поставленных целей?
Пройдя через несколько циклов PI-планирования и визуализировав работу команд в Kaiten, мы можем смело говорить о достигнутых результатах на уровне всей компании.
В разы увеличилась продуктивность. Каждая команда точно знает, какие задачи ей надо и не надо делать для достижения верхнеуровневых целей. Соответственно, снизилось количество «работы ради работы». Команды занимаются только тем, что принесет результат.
Появилась прозрачность и доверие между исполнителями и заказчиками. Kaiten позволяет генерировать аналитику, которая показывает количество задач, трудоемкость, прогресс по задачам и другие метрики. Это становится хорошим аргументом для конструктивного диалога с заказчиками. Они видят, что наши слова обоснованы и подтверждаются аналитическими данными.
У менеджмента компании появился инструмент для быстрого отслеживания прогресса с минимальными издержками. Достаточно отслеживать задачи верхнего уровня, в которых автоматом отражается весь прогресс по подчиненным задачам. Это позволяет нам быстро получать актуальную информацию для принятия управленческих решений.
Выводы и работа над ошибками
В заключение хотим рассказать об ошибках, которые компании часто допускают при проведении PI-планирования, вследствие чего результат не совпадает с ожиданиями, а сам инструмент считают неэффективным.
Ошибка №1: Думать, что идеальное планирование получится провести с первого раза. Чтобы разобраться в основах, научиться основательно готовиться к планированию и организовывать коммуникацию команд, требуется время и опыт. Первый раз обычно получается пробным и служит тренировкой для будущих мероприятий.
Ошибка №2: Не доносить до всех уровней сотрудников «зачем мы это делаем». Довольно распространенная ситуация, когда менеджмент решает провести планирование, а сотрудники воспринимают это как «очередное ненужное собрание», потому что не понимают, в чем его смысл.
Ошибка №3: Недостаточное погружение команд в бизнес-контекст. В начале планирования владельцу продукта и заказчикам необходимо подробно рассказать командам о текущем положении и о глобальных целях бизнеса. Иначе не получится построить связь между точеными задачами и общими целями.
Ошибка №4: Не учитывать разную скорость работы команд. Кому-то будет вполне достаточно двух дней, чтобы запланировать свои задачи, а кому-то этого будет мало. Это сильно зависит от уровня подготовки команд к планированию.
Ошибка №5:На первое же планирование приглашать без разбора абсолютно все команды («вдруг пригодятся»). Пока инструмент не обкатан, лучше приглашать на планирование команды с большим количеством зависимостей и постепенно добавлять участников, а не звать всех подряд. Например, если команда никак не влияет на глобальные цели и не взаимодействует с другими командами, то участники могут не понять, для чего им это нужно, и даже начать саботировать мероприятие. В подобной ситуации можно пригласить хотя бы одного представителя команды, который при необходимости сможет ответить на вопросы или связаться с коллегами для уточнения.
