Как PI-планирование помогло выполнять задачи государственной важности и иногда немного спать

8c32d5c9f9dfe2d62a92ec80595cea2d.png

Каждый, кто сталкивался с внедрением новых подходов, испытывал весь спектр эмоций. Особенно, если дело касается государственного сектора. РТЛабс использует практики SAFe® с 2022 года. Как мы провели продуктовую трансформацию — подробно в другой статье. 

Здесь расскажем про важную часть SAFe® — PI-планирование: как мы готовимся к нему, проводим и как управляем планом в течение квартала. С какими ограничениями сталкиваемся и как обеспечиваем работу 1 500 человек в квартальном цикле.

Будет полезно тем, кто хочет изменить подходы к производству ПО, начинает или уже работает с государственным сектором. Мы — самый большой кейс внедрения практик SAFe® в России.

Кто рассказывает

84e539b511968afe6af983776e884c46.png

Илья Бушмелев. Занимается в РТЛабс внедрением производственной системы в компанию. Более 20 лет в ИТ и порядка 10 лет в ИТ-управлении. Большую часть этого времени работает с госсектором.

Виктор Редров, директор офиса Agile-практик в РТЛабс. Более 20 лет работает в госсекторе, занимался управлением проектами информатизации, оптимизацией процессов госуправления и проведением организационных изменений. 

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

РТЛабс давно в разработке ПО для госорганов, сейчас у нас более 100 продуктовых команд и более 2000 человек в производственном кластере, 13 офисов. Сотрудники разбросаны по всей территории России.

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

Содержание

  1. Да кто такой этот ваш SAFe®? И зачем он

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

  3. Инструктажи

  4. Как всё проходит

  5. Как всё помнить

  6. Ключевые результаты и итоговая презентация

  7. Как следим за выполнением

  8. Эскалации

  9. Видео-версия

Да кто такой этот ваш SAFe®? И зачем он

Scaled Agile Framework® (SAFe) — это набор принципов и практик для организации гибких рабочих процессов в ИТ-компании. Его-то мы и решили применить. Зачем?

Вернёмся в 2020 год, когда деревья были зелёные, потому что на улицу никто не ходил, а нам приходилось учиться выживать в небольших квартирах, работая из дома. Когда весь мир пытался понять, как переходить на удалённую работу и что с этим делать, в РТЛабс, к сожалению, не было времени задумываться вообще ни о чём. В условиях молниеносно переходящего на удалёнку мира, жестких требований к минимизации контактов людей, выплат дополнительных мер соцподдержки гражданам нам приходилось работать по 24 часа не 1 день подряд, мы устанавливали по 10 релизов за ночь. Заказчики требовали постоянного ускорения и не были довольны результатом. В таких условиях мы могли только мечтать о сне, большая доля сотрудников не пережила эти времена из-за тотального выгорания. 

С внедрением практик SAFe® наша жизнь кардинально поменялась. От жёстких госконтрактов по водопаду, в которых зафиксировано ТЗ на длительный период и есть большой риск отклонения от него, мы перешли к гибким контрактам. В них заявки формируются на работы по итогам PI-планирования и того, как команды взяли работы в свой квартальный план. Мы перешли к командному взаимодействию с заказчиком. Сформировали продуктовые команды и колодцы, команды теперь сгруппированы в продуктовые направления. Мы всё ещё теряем людей, но теперь этот показатель в норме. Текучесть кадров стала управляемой, а ночных релизов стало гораздо меньше.

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

Сейчас релизов почти в 2 раза больше, чем в 2021 году, при этом количество ночных релизов сильно сократилось. За первое полугодие 2022 года ночных релизов было меньше, чем за весь 2021 год. Количество аврала тоже снизилось и теперь мы можем им управлять. 

Первое честное внедрение SAFe 5.16

Первое честное внедрение SAFe 5.16

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

Подготовиться к PI планированию на 1,5 тысячи человек —отдельный подвиг, который сейчас мы научились воспроизводить почти на автомате.

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

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

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

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

Инструктажи

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

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

Дальше групповые инструктажи для отдельных ролей: продуктового менеджмента, оунеров Минцифры и архитекторов, RТЕ, Scrum-мастеров. Рассказываем, что должны делать сотрудники каждой роли и в какой день планирования. Даём чек-лист по ролям и дням.

Как всё проходит

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

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

  2. Начинается работа команд. Они оценивают свою ёмкость, декомпозируют задачи, примерно раскидывают их по спринтам, оценивают риски и зависимости. Зачастую команды приходят уже с черновиками своих квартальных планов, которые им надо синхронизировать и при этом правильно распределить задачи по спринтам предстоящего инкремента. Назначают ответственных и согласуют свои планы с зависимыми командами.

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

  4. Проходит показ презентаций. Он идёт по такому графику, чтобы команды могли друг к другу обратиться. Выделяется несколько стендов и распределение происходит по принципу: у кого больше зависимостей, тот идёт в первую очередь. Зависимые друг от друга команды стараемся не ставить выступать в один момент. Каждая команда рассказывает по черновикам своих планов о тех работах, которые они взяли в предстоящий инкремент. Что не могут взять, какие зависимости других команд могут не потянуть. Меняются приоритеты по некоторым задачам. Ключевые цели и результаты согласуют с оунерами Минцифры.

  5. На следующий день черновики и зависимости дорабатываются, итоговые результаты согласуются с оунерами Минцифры. Команды голосуют, согласны ли они с составленным планом, и собирают итоговые презентации.

  6. Проходит защита планов на следующий инкремент у заказчика.

Расписание PI-планирования

Расписание PI-планирования

Собрать 1 500 человек со всей страны в одном месте оказалась задача не только очень сложная, но и достаточно дорогая. Оптимальным решением стал гибридный формат проведения планирования: часть людей, около 400 человек, присутствуют очно в зале для планирования. В основном это сотрудники Минцифры и производственного кластера РТЛабс: министр, его заместители, курирующие сервисы электронного правительства, директора департаментов, оунеры Минцифры, генеральный директор РТЛабс, его заместители, продуктовый менеджмент, архитекторы, RTE, владельцы продуктов, продуктовые менеджеры, а также наши сервисные команды —эксплуатация, дизайнеры, редакторы и другие. Ещё порядка тысячи человек собираем онлайн — это все Scrum-мастера и команды.

3bdf116c0f1a978774e56d5706c91267.png

Как всё помнить

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

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

План шагов и подсказки

План шагов и подсказки

В течение всего цикла отслеживаем готовность. Регулярно проводятся Scrum-of-Scrums — раз в 45 минут, и RTE-синки — через 15 минут после окончания SOS. Scrum-мастера и RTE ходят по залу между своими независимыми командами. Есть чек-лист, по которому отслеживаем, кто не готов, кто отстающие, кто догоняющие и другие моменты.

Пример чек-листа

  1. Указали ёмкость для каждой итерации?

  2. Посчитаны ли ресурсы под 3 линию поддержки и аврал?

  3. Определили истории для 5 итераций и начали оценку?

  4. Закончили оценку историй на 5 итераций?

  5. Все фичи на доске зависимостей?

  6. Начали разрешать зависимости с другими командами?

  7. Отобразили все зависимости на доске зависимостей?

  8. Обсуждаете конфликты приоритетов и компромиссы с ОМЦ?

  9. Идентифицировали риски уровня программы?

  10. Записали цели с учетом рисков и зависимостей?

  11. Готовы через 15 минут начать презентацию?

  12. Внесли правки по замечаниям от ОМЦ?

  13. Финализировали зависимости?

  14. Разобрали все риски на RОАМ?

  15. Обходной лист согласован?

  16. Подготовили презентацию для защиты? Цели с метриками и рисками?

  17. Готовы к презентации перед комиссией?

  18. Готовы к защите плана?

Регулярные синхронизации на планировании

Регулярные синхронизации на планировании

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

Календарь спринтоов. Инкремент ≠ квартал

Календарь спринтоов. Инкремент ≠ квартал

Ключевые результаты и итоговая презентация

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

Древо целей и ключевых результатов (ценности)

Древо целей и ключевых результатов (ценности)

Итоговые презентации, как и черновые, формируются автоматически в реальном времени — на базе задач из Jira. Так не приходится не тратить много сил и времени на составление презентаций и вручную приводить их к единому формату. Команды видят список своих задач, голосуют, устраивает ли их такой набор и распределение, выполним ли объём. Если все согласны с планом, получаем презентацию.

Планирование и презентации 2022Q4

Планирование и презентации 2022Q4

Формирование итоговой презентации плана

Формирование итоговой презентации плана

Как следим за выполнением

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

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

Дополнительно, раз уж мы ИТ-компания, интегрировали всё это дело с Telegram.

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

Календарь квартала (инкремента)

Календарь квартала (инкремента)

Эскалации

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

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

Работа с эскалациями

Работа с эскалациями

Несмотря на то, что мы стали ставить больше релизов, почти в 2 раза по сравнению с 2021 годом, количество ночных релизов драматически сократилось. То есть за первое полугодие 2022 года у нас ночных релизов меньше, чем целиком по 2021 году. Количество аврала тоже снизилось. И мы теперь им можем управлять.

Видео-версия 

Эту статью мы написали на основе доклада Ильи Бушмелева и Виктора Редрова на конференции Enterprise Agile Russia 2022.

Посмотреть запись доклада

Как продолжается трансформация в РТЛабс будем рассказывать в нашем блоге.

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

© Habrahabr.ru