Каждый, кто сталкивался с внедрением новых подходов, испытывал весь спектр эмоций. Особенно, если дело касается государственного сектора. РТЛабс использует практики SAFe® с 2022 года. Как мы провели продуктовую трансформацию — подробно в другой статье.
Здесь расскажем про важную часть SAFe® — PI-планирование: как мы готовимся к нему, проводим и как управляем планом в течение квартала. С какими ограничениями сталкиваемся и как обеспечиваем работу 1 500 человек в квартальном цикле.
Будет полезно тем, кто хочет изменить подходы к производству ПО, начинает или уже работает с государственным сектором. Мы — самый большой кейс внедрения практик SAFe® в России.
Кто рассказывает
Илья Бушмелев. Занимается в РТЛабс внедрением производственной системы в компанию. Более 20 лет в ИТ и порядка 10 лет в ИТ-управлении. Большую часть этого времени работает с госсектором.
Виктор Редров, директор офиса Agile-практик в РТЛабс. Более 20 лет работает в госсекторе, занимался управлением проектами информатизации, оптимизацией процессов госуправления и проведением организационных изменений.
В 2021 году познакомился с SAFe и практиками, повышающими эффективность управления, позволяющими быть гибкими в условиях быстро меняющегося мира, не распыляться, удерживать в фокусе долгосрочные цели и выдавать результаты в краткосрочной перспективе, в том числе за счёт формирования виртуальных организационных структур, при сохранении управленческой иерархии.
РТЛабс давно в разработке ПО для госорганов, сейчас у нас более 100 продуктовых команд и более 2000 человек в производственном кластере, 13 офисов. Сотрудники разбросаны по всей территории России.
Занимаемся развитием высоконагруженных систем Госуслуг. Госуслуги —лишь вершина айсберга, под которым множество информационных систем: Единая система идентификации и аутентификации, Цифровой профиль, Система межведомственного электронного взаимодействия и другие государственные информационные системы, участвующие в процессе предоставления госуслуг. Сервисами ежедневно пользуются десятки миллионов людей.
Содержание
Да кто такой этот ваш SAFe®? И зачем он
Scaled Agile Framework® (SAFe) — это набор принципов и практик для организации гибких рабочих процессов в ИТ-компании. Его-то мы и решили применить. Зачем?
Вернёмся в 2020 год, когда деревья были зелёные, потому что на улицу никто не ходил, а нам приходилось учиться выживать в небольших квартирах, работая из дома. Когда весь мир пытался понять, как переходить на удалённую работу и что с этим делать, в РТЛабс, к сожалению, не было времени задумываться вообще ни о чём. В условиях молниеносно переходящего на удалёнку мира, жестких требований к минимизации контактов людей, выплат дополнительных мер соцподдержки гражданам нам приходилось работать по 24 часа не 1 день подряд, мы устанавливали по 10 релизов за ночь. Заказчики требовали постоянного ускорения и не были довольны результатом. В таких условиях мы могли только мечтать о сне, большая доля сотрудников не пережила эти времена из-за тотального выгорания.
С внедрением практик SAFe® наша жизнь кардинально поменялась. От жёстких госконтрактов по водопаду, в которых зафиксировано ТЗ на длительный период и есть большой риск отклонения от него, мы перешли к гибким контрактам. В них заявки формируются на работы по итогам PI-планирования и того, как команды взяли работы в свой квартальный план. Мы перешли к командному взаимодействию с заказчиком. Сформировали продуктовые команды и колодцы, команды теперь сгруппированы в продуктовые направления. Мы всё ещё теряем людей, но теперь этот показатель в норме. Текучесть кадров стала управляемой, а ночных релизов стало гораздо меньше.
Спасла ритмичность и PI-планирование, а также то, что мы научились итерационно доводить работы, которые взяли в квартальный план, до финального результата.
Сейчас релизов почти в 2 раза больше, чем в 2021 году, при этом количество ночных релизов сильно сократилось. За первое полугодие 2022 года ночных релизов было меньше, чем за весь 2021 год. Количество аврала тоже снизилось и теперь мы можем им управлять.
Подготовка к PI-планированию
Подготовиться к PI планированию на 1,5 тысячи человек —отдельный подвиг, который сейчас мы научились воспроизводить почти на автомате.
Для этого сделали карту подготовки — с ответственными, их ролями и конкретными сроками, когда тот или иной пункт должен быть выполнен. Остаётся только на каждое PI-планирование выбирать ответственных, которые будут следить за выполнением пунктов.
Обязательное условие подготовки — проведение инструктажей и серий встреч для мониторинга готовности команд к планированию.
Инструктажи
Они нужны, чтобы команды работали в едином ритме и успели запланироваться, чтобы в результате все дошли до конца с нормальными результатами и защитили свои итоговые презентации.
Сначала проходит общий инструктаж для всех ролей: как подготовиться к PI-планированию, что делать, как будем измерять готовность.
Дальше групповые инструктажи для отдельных ролей: продуктового менеджмента, оунеров Минцифры и архитекторов, RТЕ, Scrum-мастеров. Рассказываем, что должны делать сотрудники каждой роли и в какой день планирования. Даём чек-лист по ролям и дням.
Как всё проходит
Практически по всем канонам SAFe®. Единственное отличие — к обычным двум дням на проведение у нас добавился третий. Это из-за того, что планируется одновременно очень много команд и их квартальные планы, задачи и продукты сильно взаимосвязаны, все проходят планирование в едином цикле.
Заказчик и директора департаментов доводят фокусы на предстоящий инкремент до продуктовых команд. В этот момент определяем и сообщаем команде новые практики и принципы, которые будут применяться в следующем инкременте. Рассказываем, как изменится процесс и что будем делать по-новому, что поможет достичь большего успеха. Важно помнить, что инкремент ≠ квартал. Квартал — промежуток времени, а инкремент — ступенька к достижению цели продукта. Но в контексте планирования эти понятия могут слиться воедино.
Начинается работа команд. Они оценивают свою ёмкость, декомпозируют задачи, примерно раскидывают их по спринтам, оценивают риски и зависимости. Зачастую команды приходят уже с черновиками своих квартальных планов, которые им надо синхронизировать и при этом правильно распределить задачи по спринтам предстоящего инкремента. Назначают ответственных и согласуют свои планы с зависимыми командами.
Формируется список ключевых результатов и ценностей, которые берём в инкремент.
Проходит показ презентаций. Он идёт по такому графику, чтобы команды могли друг к другу обратиться. Выделяется несколько стендов и распределение происходит по принципу: у кого больше зависимостей, тот идёт в первую очередь. Зависимые друг от друга команды стараемся не ставить выступать в один момент. Каждая команда рассказывает по черновикам своих планов о тех работах, которые они взяли в предстоящий инкремент. Что не могут взять, какие зависимости других команд могут не потянуть. Меняются приоритеты по некоторым задачам. Ключевые цели и результаты согласуют с оунерами Минцифры.
На следующий день черновики и зависимости дорабатываются, итоговые результаты согласуются с оунерами Минцифры. Команды голосуют, согласны ли они с составленным планом, и собирают итоговые презентации.
Проходит защита планов на следующий инкремент у заказчика.
Собрать 1 500 человек со всей страны в одном месте оказалась задача не только очень сложная, но и достаточно дорогая. Оптимальным решением стал гибридный формат проведения планирования: часть людей, около 400 человек, присутствуют очно в зале для планирования. В основном это сотрудники Минцифры и производственного кластера РТЛабс: министр, его заместители, курирующие сервисы электронного правительства, директора департаментов, оунеры Минцифры, генеральный директор РТЛабс, его заместители, продуктовый менеджмент, архитекторы, RTE, владельцы продуктов, продуктовые менеджеры, а также наши сервисные команды —эксплуатация, дизайнеры, редакторы и другие. Ещё порядка тысячи человек собираем онлайн — это все Scrum-мастера и команды.
Как всё помнить
Чтобы планирование прошло хорошо, каждый должен знать, что ему делать. Для этого мы составили RACI-матрицу, где обозначены роли, ответственность и другие моменты. Можно направить коллегу в эту матрицу, если он в десятый раз пришёл спросить, что же надо всё-таки делать. О матрице напишем подробно в следующих статьях.
Ещё есть огромная доска в Miro, на которой отслеживаем готовность команд, их список, куда они движутся, что предстоит сделать. Также у каждой команды есть отдельное пространство с подсказками, какие шаги нужно пройти, чтобы сформировать свой план, и как эти шаги делаются.
В течение всего цикла отслеживаем готовность. Регулярно проводятся Scrum-of-Scrums — раз в 45 минут, и RTE-синки — через 15 минут после окончания SOS. Scrum-мастера и RTE ходят по залу между своими независимыми командами. Есть чек-лист, по которому отслеживаем, кто не готов, кто отстающие, кто догоняющие и другие моменты.
Пример чек-листа
Указали ёмкость для каждой итерации?
Посчитаны ли ресурсы под 3 линию поддержки и аврал?
Определили истории для 5 итераций и начали оценку?
Закончили оценку историй на 5 итераций?
Все фичи на доске зависимостей?
Начали разрешать зависимости с другими командами?
Отобразили все зависимости на доске зависимостей?
Обсуждаете конфликты приоритетов и компромиссы с ОМЦ?
Идентифицировали риски уровня программы?
Записали цели с учетом рисков и зависимостей?
Готовы через 15 минут начать презентацию?
Внесли правки по замечаниям от ОМЦ?
Финализировали зависимости?
Разобрали все риски на RОАМ?
Обходной лист согласован?
Подготовили презентацию для защиты? Цели с метриками и рисками?
Готовы к презентации перед комиссией?
Готовы к защите плана?
Есть календарь спринтов. Мы готовим его заранее, чтобы было понятно, что, когда и где должно быть, каковы даты демо и ёмкость команд на каждый спринт. Исходя из этого команды распределяют свои задачи по инкременту. Стараемся, чтобы они распределялись равномерно и прямолинейно. Планируем 6 двухнедельных спринтов: 5 функциональных и один инновационный.
Ключевые результаты и итоговая презентация
Когда команды подготовили свои квартальные планы, они собирают задачи на предстоящий инкремент и обозначают ключевые результаты. По этим результатам определяют, какие показатели и по каким метрикам нужно достичь в рамках инкремента. Ключевые результаты обязательно должны соответствовать стратегическим целям развития продукта, которые определены в долгосрочной перспективе.
Итоговые презентации, как и черновые, формируются автоматически в реальном времени — на базе задач из Jira. Так не приходится не тратить много сил и времени на составление презентаций и вручную приводить их к единому формату. Команды видят список своих задач, голосуют, устраивает ли их такой набор и распределение, выполним ли объём. Если все согласны с планом, получаем презентацию.
Как следим за выполнением
После защиты планов для каждой команды автоматически формируется отчёт, по которому будем следить за выполнением плана.
Отчёт — это такой дашборд, который позволяет мониторить выполнение квартальных планов от уровня портфеля до конечных задач, взятых в инкремент, определять их статус и результативность команд на этапах реализации квартальных планов. После защиты планов он формируется автоматом для каждой команды.
Дополнительно, раз уж мы ИТ-компания, интегрировали всё это дело с Telegram.
Исполнение планов идёт по определённому графику. Как чек-поинты мы используем ключевые мероприятия — от дейликов до статуса у министра. Раз в квартал проводим стратегический обзор, на котором смотрим и анализируем достижения на текущий момент. При необходимости корректируем фокусы.
Эскалации
По рассказу может создаться впечатление, что у нас всё проходит гладко. Но на самом деле из-за большой связанности продуктов друг с другом и множества зависимых задач, в работе часто пролетают шальные проблемы и сложности.
Если команды не смогли решить вопрос внутри одного продукта, оформляется эскалация, чтобы решение приняли на более высоком уровне. Чтобы всякая мелочь не доходила до уровня министра (да, такое у нас тоже было), мы определили несколько базовых правил:
Несмотря на то, что мы стали ставить больше релизов, почти в 2 раза по сравнению с 2021 годом, количество ночных релизов драматически сократилось. То есть за первое полугодие 2022 года у нас ночных релизов меньше, чем целиком по 2021 году. Количество аврала тоже снизилось. И мы теперь им можем управлять.
Видео-версия
Эту статью мы написали на основе доклада Ильи Бушмелева и Виктора Редрова на конференции Enterprise Agile Russia 2022.
Как продолжается трансформация в РТЛабс будем рассказывать в нашем блоге.
Задавайте вопросы в комментариях к этой статье, будем рады ответить. Круто, если расскажете про ваш опыт проведения планирования и внедрения изменений.
AnonimYYYs
Но вот того, что за весь 2022 было меньше чем за весь 2021 - не сказано ツ