Привет, меня зовут Андрей Гирин, и я agile-коуч в РТЛабс. Это компания, которая развивает цифровую экосистему портала gosuslugi. ru. Я присоединился к проекту чуть больше года назад. Тогда как раз набиралась команда для проведения трансформации. Ключевая причина, по которой было принято решение о переменах, — желание облегчить жизнь наших с вами соотечественников. Предоставить им лучший клиентский опыт при взаимодействии с государством.
Профессия agile-коуч подразумевает, что мы внедряем новые сервисы, упрощаем клиентские пути, обеспечиваем омниканальность взаимодействия и т.д. Но делаем это не сами, а руками специалистов компании. Условно — нам надо было убедить людей, что работать — это хорошо. А стараться, чтобы эта работа с каждым днём несла всё больше ценности пользователям, — ещё лучше. Нужно было сделать так, чтобы оргструктура, культура, производственная система и система целеполагания с мотивацией поддерживали и усиливали желание сотрудников постоянно улучшать продукты для людей.
1 апреля РТЛабс исполнилось 20 лет. И в этой статье я от имени нашей большой команды расскажу, как мы провели свой 20-й год (спойлер: плодотворно и масштабно). Как и зачем мы ввязались в столь глобальноедело, как продуктовая трансформация. А также о том, как мы используем практики SAFe® и продуктового управления при развитии Госуслуг и не только.
Продуктовая трансформация — это всегда очень сложный и непонятный процесс, индивидуальный для компании. У каждой компании свой продукт, своё представление о нём, свой способ его позиционирования и свой самобытный способ перестройки. Нельзя было взять шаблон и переложить его на РТЛабс — компанию с долгой историей разработки и сложившимися процессами. Из статьи вы узнаете, как нам удалось сформировать продуктовые команды, оптимизировать HR-процессы и провести трансформацию на отлично.
Как всё началось
На текущий момент у РТЛабс 13 офисов по всей России, более 150 продуктовых команд и 1 600 сотрудников в производственном кластере. Но фактически наши сотрудники разбросаны по всей территории необъятной родины.
Мы уже очень давно в разработке ПО для госорганов. РТЛабс развивает высоконагруженные системы Госуслуг. Портал — это наш флагман, под капотом которого работает множество продуктов: единая система идентификации и аутентификации (ЕСИА), цифровой профиль, система межведомственного электронного взаимодействия (СМЭВ), цифровой помощник Робот Макс и т. д. Мы создаём сервисы, которыми ежедневно пользуются десятки миллионов людей, получая государственные услуги.
Различного рода трансформации сейчас проводят все компании на рынке. Но никто не мог подумать, что мы станем следующими: что именно во фразе «ПО для госорганов» может быть непонятным? И всё-таки трансформация стала для нас неизбежной.
В каждой истории должен быть конфликт. Наше столкновение с новой реальностью произошло в 2020 году. Ковидные сертификаты, детские выплаты и другие меры соцподдержки, постоянно сокращающиеся горизонты планирования и меняющиеся приоритеты. Выросла нагрузка на портал, как и потребность в его развитии. Мы работали сутками напролёт, по несколько дней кряду. Устанавливали по 10 релизов за 1 ночь.
Наши заказчики требовали постоянного ускорения и, конечно же, не были полностью довольны результатами. Текучесть сотрудников выросла до пугающих значений, в том числе на испытательном сроке, — ребята сгорали очень быстро. «Аврал» стало самым популярным словом в нашем словаре. В общем, всё шло очень тяжело. И именно тогда мы задумались — что нужно изменить, чтобы дать жителям России наилучший сервис в цифровых каналах и при этом выжить самим.
Тогда я почувствовала, насколько в РТЛабс тёплые ребята. Даже ночью, когда у нас был случай, что релиз не встал, мы всё равно собрались в 4 утра все вместе. Нет такого, что ты виноват — ты и разбирайся как хочешь. Наоборот, все собираются в любое время и решают проблему вместе.
Рассмотрев множество различных подходов, фреймворков и методов, мы остановились на Scaled Agile Framework® (SAFe®). SAFe® подкупает тем, что это готовая операционная система для компании нашего масштаба. В нём есть ответы на многие вопросы, которые тогда были у нас.
Цели и задачи трансформации
На старте трансформации состоялась стратегическая сессия топ-менеджмента компании, на которой выработали 4 ключевые цели:
- повышение точности планирования;
- рост удовлетворённости сотрудников, снижение текучести;
- рост продуктивности;
- рост надёжности, стабильности и отказоустойчивости решений.
Реализация трансформации предполагала несколько зон:
- Внедрение SAFe® — идентификация и формирование продуктовых направлений, внедрение практик SAFe®, в том числе PI-планирования
- HR-трансформация — создание новой оргструктуры, трансформация процессов рекрутмента, адаптации, коммуникаций и обучения, работа с индексом eNPS
- Создание agile-команд — запуск agile-команд, стандартизация их подходов к работе, повышение эффективности работы команд
Трансформация как она есть
Внедрение SAFe®
Готовая операционная система… Мы были уверены, что 2022 год начнётся с работы в уже новой производственной системе.
2021 год стал годом формирования «базы» для продуктовой трансформации 2022 года. Тогда была внедрена первая версия производственной системы, где можно было контролировать и перечень, и ход исполнения всех производственных задач, сформирован отдельный офис agile-практик и проведено первое пилотное PI-планирование.
В agile-среде распространено утверждение, что если вы хотите взять из SAFe® что-то одно, то берите PI-планирование.
PI-планирование — Program Increment Planning (Планирование Инкремента Программы). Это регулярно повторяющееся мероприятие по планированию в формате «лицом к лицу», которое является основополагающим для поезда и объединяет все команды поезда для движения в направлении озвученных миссии и концепции.
Поезд (Agile Release Train, ART) — это долгосрочная команда, состоящая из agile-команд (teams). Она совместно с другими заинтересованными лицами инкрементально разрабатывает, внедряет и эксплуатирует одно или несколько решений внутри потока поставки ценности.
Ковидный год хорошо показал, что длительный период планирования означает большой риск изменения ожиданий. А госконтракт не прощает отклонения от технического задания, что бьёт одним концом по исполнителю, а вторым по заказчику. Ни получать большие штрафы, ни платить за выполненную, но уже ненужную работу никому не хочется.
Первое в компании PI-планирование должно было пройти в декабре. Но как выяснилось, всё не так просто. Нам, команде Госуслуг в лице Минцифры и РТЛабс, требовалась серьёзная подготовка к тому, чтобы провести big room planning.
Нам пришлось сделать домашнюю работу. В целом, она описана в дорожной карте внедрения SAFe®. При помощи наших партнёров из ScrumTrek был определён пилотный контур, проведено обучение для лидеров и идентифицированы поезда.
Мы сформировали команду офиса agile-практик и за первый квартал обучили более 200 человек скраму, работе с бэклогом и проведению PI-планирования.
Разработали план подготовки, в котором зафиксировали список мероприятий, ответственных и даты, к которым эти мероприятия должны быть выполнены для успешного проведения планирования.
Дляпоездов мы подготовили чек-лист, в котором зафиксировали те вехи, которые должны быть пройдены к определённым датам, чтобы они смогли получить максимальный эффект от планирования.
Почти месячная подготовка не прошла даром. Мы смогли провести очно-заочное PI-планирование во втором квартале 2022 года на 1 500 человек. По результатам сформировали и защитили перед министром план на квартал, который лёг в основу заявок на работы. Таким образом, мы перешли от «спускания задач сверху» из Минцифры в РТЛабс, к формированию совместного плана на партнёрских основах. Win-win как он есть.
Мы перешли в работе на фреймворк SAFe®. Но не на чистый, а адаптированный под наши реалии работы с Минцифры. Можно назвать его госэджайлом.
Для достижения одной из главных целей нашей трансформации — предсказуемости, помимо формирования плана, нужно было сделать ещё один шаг. Очевидный, но от этого не менее сложный. Надо было научиться этого плана придерживаться.
На стратегической сессии весной 2022 года зафиксировали важный принцип «прекратим начинать — начнём заканчивать». Что это означало для наших команд? Прежде чем начать работать над очередной фичей, нужно посмотреть на тот скоуп, который прямо сейчас находится в работе. И принять осознанное решение, а действительно ли надо начать её сейчас, вместо того, чтобы завершить текущую работу и приступить к новой фиче через неделю.
Но и про гибкость забывать не стоит. Все мы знаем, как быстро может измениться ситуация как в мире вообще, так и в России. И наша производственная система не должна мешать нам делать то, что действительно важно делать прямо сейчас. Чтобы помочь командам, весь квартальный план делится на две неравные части: плановые фичи, которые гарантированно должны быть сделаны, и дополнительные — фичи, которые имеют высокие риски или невысокий приоритет. Если в течение квартала приходит новая важная авральная задача, она может заменить в квартале задачу из дополнительного плана со сходной оценкой.
От квартала к кварталу наша производственная система несколько менялась, сохраняя главное — ритм, сотрудничество и системность.
Крайне интересно было внедрение PI-планирования. Теперь заказчик в лице Минцифры начинал видеть внутреннюю кухню, каким образом формируется продукт. Продуктовые команды начали более плотно взаимодействовать между собой.
Более подробно о том, как мы готовимся к PI-планированию, проводим его, а затем управляем планом в течение квартала, вы можете почитать в статье «Как SAFe® помогает выполнять задачи государственной важности и иногда немного спать»
HR-трансформация
Так как трансформация касается и людей, то без изменения HR-процессов провести её невозможно. Компании и сотрудникам нужно приспосабливаться к новой реальности, изменяя свой образ мышления, поведение, подход к управлению и методы работы. Нужно учитывать все происходящие изменения и своевременно менять внутренние процессы.
При запуске проекта у нас были:
- стратегия по формированию и развитию продуктовых команд;
- опыт создания и внедрения новой оргструктуры и опыт работы с командами и практиками SAFe®;
- инструменты в сфере рекрутмента, обучения, коммуникаций, hr-аналитики, c&b.
У нас непростой продукт, некоммерческий, и это накладывает большой отпечаток на то, что такое для нас продуктовая трансформация. В компании существует много процессов, которые нужно синхронизировать. Это и понимание внутри самого продукта, и синхронизация между заказчиком и внутренними командами, и переструктурирование текущей модели управления, и налаживание определённых ритуалов. Получается, что трансформация затрагивает всю компанию и все процессы в ней.
Все производственные бизнес-процессы нужно не только перестроить, но и автоматизировать и стандартизировать. Обеспечить сбор данных, их передачу, обеспечить правильное функционирование между подразделениями. Это всё тоже затрагивает часть культуры, потому что люди должны начинать по-другому взаимодействовать, думать, подходить к решению задач.
Была сформирована определённая система hr-мероприятий. У нас изменилась оргструктура в компании. Теперь появились кросс-функциональные agile-команды, под которые сформировали программу адаптации и наставничества. Мы также провели в прошлом году огромную работу по набору новых людей с рынка уровня CPO.
Теперь за каждым продуктовым направлением закреплён RTE и hr-партнёр, а под все изменения в компании мы меняем систему KPI. Даже внутренняя программа признания теперь имеет новые продуктовые номинации.
RTE (Release Train Engineer) — лидер и коуч в поезде, который помогает в реализации процессов, мероприятий и достижении целей. Взаимодействует с заинтересованными лицами, сообщает о возникающих затруднениях на вышестоящий уровень, помогает управлять рисками и непрерывно совершенствоваться.
В рамках продуктовой трансформации мы обучили менеджеров и команды ключевым практикам применения SAFe®, провели 44 внутренних вебинара и курс по развитию управленческих компетенций для новых продуктовых ролей. Каждые полгода в компании проводятся исследования лояльности и индекса eNPS, чтобы отслеживать уровень удовлетворённости и настроения в компании.
Создание agile-команд
Раньше у нас не было постоянных команд. Было одно большое производство, разделённое на отделы, команда собиралась под каждую услугу. Нужно было всё время перестраиваться для того, чтобы сработаться. Более того, люди не аллоцировались на одну услугу и могли работать парт-тайм в нескольких командах. Ничего удивительного в этом нет, стандартный подход для системного интегратора.И этот подход нам предстояло изменить.
Фактически нам нужно было на полном ходу пересобрать двигатель электрички. Сказать, что у нас получилось это с первого раза быстро и хорошо — значит соврать. На протяжении кварталов у нас работали «команды» из 30—50 человек. Некоторые команды пересобирались по 2—3 раза за год. До сих пор между рядом команд существует множество зависимостей. Причин тому несколько:
- ряд продуктовых направлений не были включены в пилотный контур, зато потом оказались включёнными в боевое внедрение, без полноценной коммуникации причин и целей и без должного обучения;
- команда офиса agile-практик хоть и была уже укомплектована, но по-прежнему оставалась слишком маленькой и до некоторых продуктовых направлений добралась только через полгода трансформации;
- сотрудники обнаружили себя на новых ролях, таких как владелец продукта или скрам-мастер без понимания того, как выполнять свою новую работу;
- сложный ИТ-ландшафт и высокие требования к доступности ряда критических систем.
Да, к сожалению, не всегда возможно работать только с волонтёрами — сотрудниками, которые сами приняли решение перейти в скрам. Иногда необходим большой взрыв, даже если не все к нему готовы. Содержание двух производственных систем, действующих параллельно, штука дорогая и мы не могли себе её позволить.
В итоге благодаря поддержке консультантов, работе офиса agile-практик, вовлечённости скрам-мастеров, продактов и Минцифры, отзывчивости сотрудников бэк-офиса и невероятному профессионализму нашего инженерного состава нам удалось сделать главное — перестроить свою работу и достичь целей трансформации.
Во всех командах были внедрены двухнедельные итерации — спринты. В начале спринтов команды проводят планирование, а в конце ретроспективу. Ежедневные встречи были призваны помочь командам инспектировать и адаптировать свой прогресс. Обязательным событием стала системная демонстрация всего поезда. Проведение обзора спринта осталось опцией для команд, способных самостоятельно поставлять ценный инкремент в спринтах.
Отдельным вызовом стал переход от подхода «технический руководитель проекта говорит нам, что мы должны сделать и потом надзирает за ходом работ» к «владелец продукта приносит бэклог, вся команда планирует, что и как будет сделано, а в дальнейшем несёт ответственность за результаты спринта». Даже год спустя, после начала трансформации можно было услышать от владельцев продукта о том, что команда не сделала важную функциональность в спринте потому, что менеджер X заставил её делать что-то другое. Системный коучинг менеджмента позволил снизить количество таких инцидентов, и мы рассчитываем в дальнейшем свести их к нулю.
Увеличилась продуктивность команды. Как только ты начинаешь больше синхронизировать какие-то моменты, то, безусловно, это всегда приводит к улучшению показателя вывода функциональности в прод. Здесь я очень благодарна нашим скрам-мастерам. Они досконально проходят по всем задачам и могут помочь. Мы постоянно отслеживанием состояние готовности каждой задачи. Это позволяет сразу решить возникшую проблему, а не откладывать «на потом». Каждый день мы пробегаемся по тому, что сделали, чтобы получить успех по задаче. Для меня это показалось очень эффективным.
Серебряных пуль и правда не существует. Но правильное использование тех петель обратной связи, которые предоставляет нам скрам, позволяет увидеть реальное положение вещей. Остаётся только принять его и исправить.
Благодаря работе agile-команд и развитию инженерной культуры, нам удалось более чем вдвое увеличить количество релизов в прод. При этом количество ночных релизов сократилось более чем на треть, и среди них практически не встречается проблемных.
У нас и до этого были Daily Meeting, планирование спринтов и ретроспективы, но именно в данный период у нас дополнительно появились System Demo, а проведение ретроспективы обрело новый смысл.
После года экспериментов в разных командах, апробации различных подходов, мы запустили процесс конвергенции и стандартизации практик. Так как большинство agile-команд РТЛабс работает во фреймворке скрам, начали мы именно с него. После выбора пилотного контура разработали первую версию регламента работы скрам-команд. В регламенте мы зафиксировали практики, которые показали себя хорошо в нашем контексте, метрики эффективности команд, минимальные критерии готовности к взятию в работу и критерии готовности и т.д. Подготовили опросник и радары для определения имеющихся гэпов и автоматизировали сбор метрик из нашего регламента в дашборде.
Сейчас процесс внедрения регламента в самом разгаре. Мы продолжаем развивать и адаптировать его по мере подключения новых направлений.
Продуктовый подход как путь к лучшей жизни
Сегодня фактически любой бизнес уже стал ИТ, и с этим все свыклись. Технологии теперь и главный драйвер развития компании, и главный ограничитель. Новая реальность наступила, когда государство осознало, что на него распространяются те же естественные законы, что и на бизнес.
Классические подходы к планированию ведут к тому, что пока на приоритетных направлениях существует дефицит людей, интеллекта и капитала, рядом десятки и сотни талантливых и энергичных ребят завершают уже никому не нужную работу. Да, можно прожить в режиме подвига месяц или квартал, но делать это регулярно невозможно.
И вот, в январе 2023 года утверждены рекомендации по организации процесса разработки ГИСов с применением итерационного подхода. Эти рекомендации разработаны ГосТех, совместно с экспертами agile-практик и представителями бизнес-сообщества, в том числе с учётом нашего опыта. Мы вместе с вами становимся свидетелями того, как государство принимает эту новую реальность. И РТЛабс находится в лидерах этого движения.
Приятно видеть, что компания трансформируется, люди в ней растут, процессы становятся лучше, появляется продуктовое видение, а заказчик это принимает и растёт вместе с нами.
Наша продуктовая трансформация всё ещё в процессе — полностью трансформироваться за год невозможно. Большую часть работы мы сделали внутри: перестроили процессы, изменили оргструктуру, организовали все необходимые внутренние коммуникации, создали каналы и открытые площадки для обмена опытом, ввели новые роли и начали озвучивать людям наполнение этих ролей. Поэтому можно точно сказать, что основу для трансформации мы заложили.
Продуктовая трансформация — это очень круто. Мы стараемся совершенствовать свои процессы от квартала к кварталу, поэтому процесс трансформации пока что ещё не завершён, он только начался.
О том, как продолжается трансформация в РТЛабс, будем рассказывать в нашем блоге на Хабре.
Буду рад ответить на вопросы в комментариях к этой статье или узнать ваш опыт внедрения продуктового подхода в компании.
Жестокий и бессмысленный agile новой эры, который нам проповедуют теперь:
1. Нарисовать цели в очевидном виде - стать самыми хорошими, больше пахать, меньше ломать;
2. Двигать на доске карточки каждую неделю и поднимать одни и те же вопросы на ретроспективах;
3. Сделать красивенькую Jira, пофиг если задачи не закрываются, главное чтобы покрасивше;
4. Нанять специального человека, agile коуча, который читает 4 предложения agile манифеста лучше чем другие люди, но при этом судя по тому что видно в статье вообще не понимает его;
5. Сделать побольше тестов о том как вы любите нашу компанию.
1. Принято, спасибо. Цели, само собой, были про "изменить конкретную метрику с X до Y" для горизонта в год. Но как это понять из статьи и правда не очевидно;
2. А зачем поднимать одни и те же вопросы на ретро? Вы или меняете ситуацию, или принимаете её. Тут каждому своё, но выбрать надо;
3. Задачи должны закрываться. Особенно у нас ) мне казалось, этот аспект я в статье отразить смог. Оказалось, что лишь казалось...увы;
4. Простите, что разочаровал;
5. Вы так говорите, как будто это что-то плохое.
2. К сожалению miro замылена, поэтому у меня лишь подозрения этого момента;
3. Боюсь я вижу что задачи таскаются со спринта на спринта, конкретно 42 задачи, об этом и пишу.
2. На миро план по спринтам на квартал, составляемый на pi-планировании (скрин, примерно, с обеда первого дня);
3. Верно. Там и метрика исполнения спринта не фонтан, нет смысле её зеленить просто так. Пока 90 процентиль по cуcle time истории* больше двухнедельного спринта. Возвращать квартальные обязательства научились (всякое бывает, но научились), а возвращать обязательства в спринтах еще учимся. Ребята молодцы, прогресс есть. Но и зон роста еще хватает. Из части про agile-команды разве не текут кровь, пот и слёзы? )
*модель требований у нас примерно такая https://scrumtrek.ru/blog/enterprise-agility/7569/model-trebovanij-v-safe/ в pi планируются фичи, в спринты истории.
3. Я про то и говорю, что "Individuals and interactions over processes and tools", введут побольше фреймворков safов, jirов покрасивше и прочего обмазывания инструментами.
Суть то одна - "Responding to change over following a plan" задачи все равно на спринт толком не распределить когда sla. Люди не глупые, сами будут будут делать срочное и главное. Ну и пойдут эти спринты и магические цели нафиг.
Итого:
1. набрасываешь что надо сделать в jira кидаешь на нужного человека с комментарием или статусом, без процессов;
2. если не успеваете и нужно сделать другое, то согласуя выкидываете в бэклог или вообще, если оно не нужно, чтобы никто не отвлекался;
Всё, никакой магии, никакого супер процесса который может поломаться.
Да, я работал в аналогичной большой компании и там всегда хотели придумать эти бесполезные процессы, делать изменения в них ради новых изменений. Как хорошо что я ушел от этого и сейчас просто занимаюсь разработкой.
Я правда (искренне) рад, что в вашем контексте успешно так получается. Тогда, разумеется, фреймворки не несут добавленной стоимости. В нашем потребовалась некоторая работа, чтобы коммуникация между множеством заинтересованных сторон была успешной.
Я правильно понял, что на обучение ушел месяц с момента привлечения консультантов? и после него провели первой pi планирование?
Месяц усиленной подготовки и интенсивного обучения, да. Это не единственные обучения, которые проходили. В дальнейшем мы обнаружили ещё множество зон роста. Но да, оно позволило нам успешно провести наше первое PI-планирование.