Все статьи
Как SAFe® помогает выполнять задачи государственной важности и иногда немного спать
Дата: 07.02.2023
История компании «РТ Лабс», разработчиков сервисов Госуслуг, которыми ежедневно пользуются десятки миллионов людей, про внедрение Scaled Agile Framework® (SAFe®) на контур 1.5+ тысяч сотрудников.
Доклад с конференции Enterprise Agile Russia 2022.
Мы работаем в компании РТЛабс и сегодня мы расскажем, как используем практики SAFe и с какими ограничениями мы сталкиваемся, как проводим планирование и обеспечиваем работу 1,5 тыс. человек в квартальном цикле. Наш опыт будет интересен всем, кто задумался о том, что надо менять подходы к производству программного обеспечения, всем, кто начинает или уже работает с государственным сектором. Мы — самый большой кейс внедрения практик SAFe в России.
Название нашей компании РТЛабс многим ничего не говорит. Но когда говоришь, что мы делаем Госуслуги, то многое меняется. Госуслуги — это мы.
Мы уже очень давно в разработке ПО для госорганов. На текущий момент у нас более 100 продуктовых команд и более чем 2000 человек в производственном кластере, а также 13 офисов. Но фактически наши сотрудники разбросаны по всей территории нашей необъятной родины.
Мы являемся единственным исполнителем работ по созданию инфраструктуры электронного правительства, где заказчиком выступает Минцифра России. Мы занимаемся развитием высоконагруженных систем Госуслуг. Портал Госуслуги — это всего лишь вершина айсберга, за которым скрыто множество информационных систем: единая система идентификации и аутентификации, цифровой профиль, система межведомственного электронного взаимодействия и другие важные государственные информационные системы, участвующие в процессе предоставления государственных услуг. Мы создаем сервисы, которыми ежедневно пользуются десятки миллионов людей, получая госуслуги.
Содержание статьи
Как мы внедрили практики SAFe®
Сейчас мы перейдем к самому важному, о чем мы хотели рассказать — это наш опыт внедрения практик SAFe в нашей организации. Для того чтобы было понятно, что произошло за последние 2 года, мы вернемся в далекий 2020 год, когда деревья были еще зеленые, потому что на улицу никто не ходил, когда нам приходилось учиться выживать в небольших квартирах, работая из дома. И когда весь мир пытался понять, как же переходить на удаленную работу и что с этим делать, в РТЛабс, к сожалению, не было времени задумываться вообще ни о чем. В условиях молниеносно меняющегося на удаленку мира, жестких требований к минимизации контактов людей для распространения COVID-19, проведения различных голосований за принятие поправок в конституцию РФ нам приходилось работать по 24 часа не 1 день к ряду, мы устанавливали по 10 релизов за 1 ночь. Наши заказчики требовали постоянного ускорения и конечно же не были довольны результатом… В таких условиях мы могли только мечтать о сне, большая доля сотрудников не пережила эти времена из-за тотального выгорания. В тот момент в наших головах стала все чаще и чаще появляться мысль о том, что «нам бы просто, чтобы нас перестали хреначить и спать побольше…»
С внедрением практик SAFe вот так наша жизнь поменялась.
Мы до сих пор остаемся единственным исполнителем работ «по электричке». От жестких госконтрактов по водопаду, в которых зафиксировано техническое задание на длительный период, и где есть большой риск отклонения от этого технического задания, потому что получишь большие штрафы, мы перешли к гибким контрактам, где заявки формируются на работы по итогам PI-планирования, по итогам того, как команды взяли работы в свой квартальный план. От модели «я заказчик — ты дурак» мы перешли к командному взаимодействию по принципу «доверяй, но проверяй». Мы сформировали продуктовые команды, перенарезав свои колодцы, и сгруппировав эти команды в продуктовые направления. Особые условия у нас остались. Теперь это ИТ-льготы. Мы все еще теряем людей, но не так, как это было 2 года назад. Текучесть кадров стала управляемой, а ночных релизов стало гораздо меньше.
Нас спасла ритмичность и PI-планирование, а также то, что мы научились итерационно доводить те работы, которые взяли в квартальный план, до финального результата, до цели.
Подготовка к PI-планированию
Подготовиться к PI планированию на 1,5 тысячи человек — это отдельный подвиг, который мы научились воспроизводить почти на автомате.
У нас подготовлена карта подготовки с ответственными ролями и конкретными сроками, когда тот или иной пункт должен быть выполнен. Нам остается только на каждое PI-планирование выбрать ответственных, кто будет следить за их выполнением.
Мы очень быстро растущая организация и обязательным условием подготовки к планированию является проведение различных инструктажей и серий встреч по мониторингу готовности команд к планированию.
PI-планирование мы проводим практически по канонам SAFe. Единственное, у нас добавился еще третий день. Как мы упомянули раньше, у нас планируется очень много команд одновременно. И квартальные планы этих команд и, вообще, задачи и продукты очень сильно взаимосвязаны друг с другом. Есть большие зависимости. Поэтому все проходят планирование в едином цикле.
Мы начинаем свое PI-планирование с того, что заместители министра и директора департаментов доводят фокусы на предстоящий инкремент до продуктовых команд. Также в этот момент мы определяем и доводим до команды новые практики, новые принципы, которые будут у нас применяться в новом инкременте. Рассказываем им, как изменится наш процесс и что мы будем делать по-новому, что нам поможет достичь большего успеха.
Дальше начинается работа команд. На данном этапе команды оценивают свою емкость, декомпозируют задачи, раскидывают их по спринтам (примерно) и начинают оценивать риски и зависимости, которые у них могут быть. Зачастую команды приходят уже с черновиками своих квартальных планов, которые им необходимо синхронизировать и при этом правильно распределить задачи по спринтам предстоящего инкремента.
После работы с зависимостями и с рисками, где были назначены ответственные и достигнуты согласования с зависимыми командами, у нас проводится работа по формированию перечня ключевых результатов и ценностей, которые мы берем для себя в инкремент. То, чего мы достигнем.
Дальше у нас идет галерея презентаций, где каждая команда рассказывает по своим черновикам планов о тех работах, которые они взяли в предстоящий инкремент. Что они не могут взять, какие зависимости других команд они могут не потянуть. Здесь осуществляется переприоритизация некоторых задач. Возможно, где-то что-то убирается, где-то что-то добавляется. И происходит согласование ключевых целевых результатов с оунерами Минцифры.
Еще раз скажу, что галерея презентации у нас проводится по графику, чтобы команды могли друг к другу обратиться. В основном, выделяется несколько стендов, и распределение происходит по принципу: у кого больше зависимостей, тот идет в первую очередь. При этом команды, имеющие между собой зависимости, мы стараемся не ставить в один график, то есть в один момент проведения этого мероприятия.
На следующий день идет осуществление доработки черновиков, а также зависимостей и согласование итоговых результатов с оунерами Минцифры. Потом происходит голосование команд и формирование итоговых команд. Но об этом чуть дальше я более детально расскажу.
Когда у нас готовы итоговые презентации, то проходит защита планов на следующий инкремент у заместителя министра и у министра.
Третий день мы добавили, потому что у нас очень большое количество команд. Вообще, задача собрать 1500 человек в одном месте со всей страны оказалась не только очень сложная, но еще и достаточно дорогая. Поэтому демократическим, авторитарным решением мы выбрали гибридный формат проведения планирования: часть людей присутствуют очно в зале для планирования, это порядка 400 человек, сотрудников Минцифры и производственного кластера РТЛабс. А онлайн мы собираем еще порядка тысячи человек. И это специально организованная ВКС, где подключаются все Scrum-мастера и команды.
Очно у нас присутствуют на встрече на PI-планировании Министр, заместители министра, курирующие сервисы электронного правительства, директора департаментов, оунеры Минцифры. От РТЛабс присутствует все руководство компании: генеральный директор, заместители генерального директора, продуктовый менеджмент, архитекторы, RTE, владельцы продуктов, продуктовые менеджеры, а также наши вспомогательные команды (сервисные команды) — это эксплуатация, дизайнеры, редакторы и другие.
RACI-матрица
Чтобы все прошло хорошо, каждый должен знать, что он должен делать. Для этого мы со своей стороны составили RACI-матрицу, где есть роли, ответственность и кто за что отвечает, как бы страхует и т.д. Мы всегда можем направить нашего сотрудника в эту матрицу, если он в 16-й раз пришел спросить, что же надо все-таки делать.
Инструктаж: что надо сделать и о чем не забыть
Для того чтобы команды работали в едином ритме и успели запланироваться к концу PI-планирования, чтобы все дошли с одинаковыми результатами и защитили свои презентации, мы проводим инструктажи. Сначала общий инструктаж для всех ролей, где рассказываем, как необходимо подготовиться к PI-планированию, и что необходимо делать, как мы будем измерять готовность к PI-планированию. Дальше мы проводим групповые инструктажи для всех ролей. Мы рассказываем, что должны делать владельцы продукта и продуктовые менеджеры. Мы рассказываем, что должны делать в первый день планирования, во второй и в третий. Получается, несколько этапов. Мы даем определенный чек-лист, когда говорим, что вы должны перед PI-планированием вот в такой-то роли сделать раз, два, три. И на каждый день есть определенный чек-лист, определенный набор инструкций для каждой роли.
Инструктажи мы проводим для продуктового менеджмента, оунеров Минцифры и архитекторов, RTE, Scrum-мастеров. С каждой группой и каждой ролью мы проговариваем алгоритм того, что должно быть сделано.
План шагов и подсказки для команд
Вообще, мы точно знаем, что память у человека не очень хорошая. Все равно все забывается. Поэтому у нас на каждом этапе планирования организована подсказка, кто что опять должен делать. У нас есть огромная доска в Miro, на которой мы отслеживаем готовность команд, список, куда они движутся и т.д., а также какие активности необходимо сделать. У каждой команды есть еще отдельное свое пространство и там то же самое написано, что вот вы в это время с такого-то по такое-то согласно расписанию должны сделать то-то, то-то. Результат должен быть такой-то. Проверять будем и т.д.
В течение всего цикла мы отслеживаем готовность. Регулярно проводятся Scrum-of-Scrums и RTE-синки. Наши Scrum-мастера и RTE бегают по огромному залу между своими независимыми командами. И еще в определенное место, где мы собираемся и отслеживаем. У нас небольшой чек-лист, всего 18 вопросов, которые мы отслеживаем, для того чтобы понять, кто не готов, кто отстающие, кто догоняющие и т.д.
На самом PI-планировании у команд есть календарь спринтов. Мы всегда готовим его заранее, чтобы было понятно, что, когда, где должно быть, а также даты демо. И что самое важное, емкость команд на каждый спринт. Исходя из этого команды распределяют свои задачи по инкременту. Мы стараемся делать так, чтобы это было равномерно и прямолинейно. Планируем, как по книжке, 6 двухнедельных спринтов: 5 функциональных и один инновационный.
Формирование ключевых результатов и итоговой презентации
Когда наши команды формируют свои квартальные планы, они собирают задачи на предстоящий инкремент и формируют ключевые результаты. По этим ключевым результатам они определяют те метрики, которые они должны достичь в рамках инкремента. То, как будут измеряться их результаты. Эти ключевые результаты обязательно должны соответствовать стратегическим целям развития продукта, которые определены в долгосрочной перспективе.
Для того чтобы снизить высокие трудозатраты на формирования отчетных итоговых презентаций по своему квартальному плану, а также исключить различные форматы, который представляются на защиту, обеспечить синхронизацию всех команд по зависимостям и учет этих зависимостей, было разработано уникальное решение, которое позволяет в режиме реального времени формировать как черновик презентации своего плана квартального, так и его финальный вариант. И все это на базе задач Jira.
Дальше команды проводят голосование за свой план. Если все произошло успешно, и вся команда подтверждает, что успешность плана гарантирована, все проголосовали за его реализуемость, то у нас автоматически формируется итоговая презентация, с которой все идут на защиты.
Один отчет = ясная картина
После защиты планов начинается инкрементальный марафон. Только в России смерть не является уважительной причиной не выполнить свои обещания, поэтому нам необходимо всячески помогать и сопровождать команды в этом нелегком деле.
Несмотря на огромное количество производственных задач и навыки наших разработчиков по управлением изменением содержимого информационных систем, мы точно знаем, что запланировали и как мы движемся по этому плану и все это на базе всего 1 отчета.
Отчет — это такой дашборд, который позволяет нам мониторить выполнение квартальных планов от уровня портфеля до конечных задач, взятых в инкремент, определять их статус и определять результативность команд на этапах реализации квартальных планов.
А поскольку мы еще и IT-организация, то, конечно же, не смогли не интегрировать это все дело с Telegram.
Исполнение квартальных планов у нас идет в соответствии с определенным графиком. Мы используем ключевые мероприятия от дейликов до статуса у министра. Раз в квартал мы проводим стратегический обзор, на котором смотрим и анализируем достижения, имеющиеся у нас на текущий момент. И при необходимости корректируем наши фокусы.
Эскалация: как с ней работать
По нашему рассказу может создаться впечатление, что у нас все проходит гладко. Но на самом деле, из-за того, что у нас очень большая связанность наших продуктов и большое количество зависимых задач, то в нашей работе то тут, то там пролетают шальные проблемы и сложности, мы культурно называем это процессом работы с эскалациями.
Если команды не смогли решить проблемы у себя внутри одного продукта, то оформляется эскалация, которая должна пройти путь к своему решению. Для того чтобы всякая мелочь не доходила до уровня Министра (да, такое у нас тоже было), мы определили для себя несколько базовых правил, которые и внедряем.
Несмотря на то, что мы стали ставить больше релизов, почти в 2 раза по сравнению с 2021 годом, количество ночных релизов драматически сократилось. То есть на текущий момент у нас ночных релизов меньше, чем целиком по прошлому году. У нас уменьшился отток персонала на четверть. Количество аврала тоже снизилось. И мы теперь им хоть как-то можем управлять.
Видео и слайды
