Как провести продуктовую трансформацию в компании с устоявшимися процессами: опыт РТЛабс

Привет, меня зовут Андрей Гирин, и я agile-коуч в РТЛабс. Это компания, которая развивает цифровую экосистему портала gosuslugi. ru. Я присоединился к проекту чуть больше года назад. Тогда как раз набиралась команда для проведения трансформации. Ключевая причина, по которой было принято решение о переменах, — желание облегчить жизнь наших с вами соотечественников. Предоставить им лучший клиентский опыт при взаимодействии с государством.

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

1 апреля РТЛабс исполнилось 20 лет. И в этой статье я от имени нашей большой команды расскажу, как мы провели свой 20-й год (спойлер: плодотворно и масштабно). Как и зачем мы ввязались в столь глобальноедело, как продуктовая трансформация. А также о том, как мы используем практики SAFe® и продуктового управления при развитии Госуслуг и не только.

Продуктовая трансформация — это всегда очень сложный и непонятный процесс, индивидуальный для компании. У каждой компании свой продукт, своё представление о нём, свой способ его позиционирования и свой самобытный способ перестройки. Нельзя было взять шаблон и переложить его на РТЛабс — компанию с долгой историей разработки и сложившимися процессами. Из статьи вы узнаете, как нам удалось сформировать продуктовые команды, оптимизировать HR-процессы и провести трансформацию на отлично.

На текущий момент у РТЛабс 13 офисов по всей России, более 150 продуктовых команд и 1 600 сотрудников в производственном кластере. Но фактически наши сотрудники разбросаны по всей территории необъятной родины.

Мы уже очень давно в разработке ПО для госорганов. РТЛабс развивает высоконагруженные системы Госуслуг. Портал — это наш флагман, под капотом которого работает множество продуктов: единая система идентификации и аутентификации (ЕСИА), цифровой профиль, система межведомственного электронного взаимодействия (СМЭВ), цифровой помощник Робот Макс и т. д. Мы создаём сервисы, которыми ежедневно пользуются десятки миллионов людей, получая государственные услуги.

Различного рода трансформации сейчас проводят все компании на рынке. Но никто не мог подумать, что мы станем следующими: что именно во фразе «ПО для госорганов» может быть непонятным? И всё-таки трансформация стала для нас неизбежной.

В каждой истории должен быть конфликт. Наше столкновение с новой реальностью произошло в 2020 году. Ковидные сертификаты, детские выплаты и другие меры соцподдержки, постоянно сокращающиеся горизонты планирования и меняющиеся приоритеты. Выросла нагрузка на портал, как и потребность в его развитии. Мы работали сутками напролёт, по несколько дней кряду. Устанавливали по 10 релизов за 1 ночь.

Наши заказчики требовали постоянного ускорения и, конечно же, не были полностью довольны результатами. Текучесть сотрудников выросла до пугающих значений, в том числе на испытательном сроке, — ребята сгорали очень быстро. «Аврал» стало самым популярным словом в нашем словаре. В общем, всё шло очень тяжело. И именно тогда мы задумались — что нужно изменить, чтобы дать жителям России наилучший сервис в цифровых каналах и при этом выжить самим.

Рассмотрев множество различных подходов, фреймворков и методов, мы остановились на Scaled Agile Framework® (SAFe®). SAFe® подкупает тем, что это готовая операционная система для компании нашего масштаба. В нём есть ответы на многие вопросы, которые тогда были у нас.

На старте трансформации состоялась стратегическая сессия топ-менеджмента компании, на которой выработали 4 ключевые цели:

Реализация трансформации предполагала несколько зон:

Внедрение SAFe®

Готовая операционная система… Мы были уверены, что 2022 год начнётся с работы в уже новой производственной системе.

В agile-среде распространено утверждение, что если вы хотите взять из SAFe® что-то одно, то берите PI-планирование.

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

Первое в компании PI-планирование должно было пройти в декабре. Но как выяснилось, всё не так просто. Нам, команде Госуслуг в лице Минцифры и РТЛабс, требовалась серьёзная подготовка к тому, чтобы провести big room planning.

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

Мы сформировали команду офиса agile-практик и за первый квартал обучили более 200 человек скраму, работе с бэклогом и проведению PI-планирования.

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

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

Почти месячная подготовка не прошла даром. Мы смогли провести очно-заочное PI-планирование во втором квартале 2022 года на 1 500 человек. По результатам сформировали и защитили перед министром план на квартал, который лёг в основу заявок на работы. Таким образом, мы перешли от «спускания задач сверху» из Минцифры в РТЛабс, к формированию совместного плана на партнёрских основах. Win-win как он есть.

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

На стратегической сессии весной 2022 года зафиксировали важный принцип «прекратим начинать — начнём заканчивать». Что это означало для наших команд? Прежде чем начать работать над очередной фичей, нужно посмотреть на тот скоуп, который прямо сейчас находится в работе. И принять осознанное решение, а действительно ли надо начать её сейчас, вместо того, чтобы завершить текущую работу и приступить к новой фиче через неделю.

Но и про гибкость забывать не стоит. Все мы знаем, как быстро может измениться ситуация как в мире вообще, так и в России. И наша производственная система не должна мешать нам делать то, что действительно важно делать прямо сейчас. Чтобы помочь командам, весь квартальный план делится на две неравные части: плановые фичи, которые гарантированно должны быть сделаны, и дополнительные — фичи, которые имеют высокие риски или невысокий приоритет. Если в течение квартала приходит новая важная авральная задача, она может заменить в квартале задачу из дополнительного плана со сходной оценкой.

От квартала к кварталу наша производственная система несколько менялась, сохраняя главное — ритм, сотрудничество и системность.

Более подробно о том, как мы готовимся к PI-планированию, проводим его, а затем управляем планом в течение квартала, вы можете почитать в статье «Как SAFe® помогает выполнять задачи государственной важности и иногда немного спать»

HR-трансформация

Так как трансформация касается и людей, то без изменения HR-процессов провести её невозможно. Компании и сотрудникам нужно приспосабливаться к новой реальности, изменяя свой образ мышления, поведение, подход к управлению и методы работы. Нужно учитывать все происходящие изменения и своевременно менять внутренние процессы.

При запуске проекта у нас были:

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

Была сформирована определённая система hr-мероприятий. У нас изменилась оргструктура в компании. Теперь появились кросс-функциональные agile-команды, под которые сформировали программу адаптации и наставничества. Мы также провели в прошлом году огромную работу по набору новых людей с рынка уровня CPO.

Теперь за каждым продуктовым направлением закреплён RTE и hr-партнёр, а под все изменения в компании мы меняем систему KPI. Даже внутренняя программа признания теперь имеет новые продуктовые номинации.

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

Создание agile-команд

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

Фактически нам нужно было на полном ходу пересобрать двигатель электрички. Сказать, что у нас получилось это с первого раза быстро и хорошо — значит соврать. На протяжении кварталов у нас работали «команды» из 30—50 человек. Некоторые команды пересобирались по 2—3 раза за год. До сих пор между рядом команд существует множество зависимостей. Причин тому несколько:

Да, к сожалению, не всегда возможно работать только с волонтёрами — сотрудниками, которые сами приняли решение перейти в скрам. Иногда необходим большой взрыв, даже если не все к нему готовы. Содержание двух производственных систем, действующих параллельно, штука дорогая и мы не могли себе её позволить.

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

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

Отдельным вызовом стал переход от подхода «технический руководитель проекта говорит нам, что мы должны сделать и потом надзирает за ходом работ» к «владелец продукта приносит бэклог, вся команда планирует, что и как будет сделано, а в дальнейшем несёт ответственность за результаты спринта». Даже год спустя, после начала трансформации можно было услышать от владельцев продукта о том, что команда не сделала важную функциональность в спринте потому, что менеджер X заставил её делать что-то другое. Системный коучинг менеджмента позволил снизить количество таких инцидентов, и мы рассчитываем в дальнейшем свести их к нулю.

Серебряных пуль и правда не существует. Но правильное использование тех петель обратной связи, которые предоставляет нам скрам, позволяет увидеть реальное положение вещей. Остаётся только принять его и исправить.

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

После года экспериментов в разных командах, апробации различных подходов, мы запустили процесс конвергенции и стандартизации практик. Так как большинство agile-команд РТЛабс работает во фреймворке скрам, начали мы именно с него. После выбора пилотного контура разработали первую версию регламента работы скрам-команд. В регламенте мы зафиксировали практики, которые показали себя хорошо в нашем контексте, метрики эффективности команд, минимальные критерии готовности к взятию в работу и критерии готовности и т.д. Подготовили опросник и радары для определения имеющихся гэпов и автоматизировали сбор метрик из нашего регламента в дашборде.

Сейчас процесс внедрения регламента в самом разгаре. Мы продолжаем развивать и адаптировать его по мере подключения новых направлений.

Сегодня фактически любой бизнес уже стал ИТ, и с этим все свыклись. Технологии теперь и главный драйвер развития компании, и главный ограничитель. Новая реальность наступила, когда государство осознало, что на него распространяются те же естественные законы, что и на бизнес.

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

И вот, в январе 2023 года утверждены рекомендации по организации процесса разработки ГИСов с применением итерационного подхода. Эти рекомендации разработаны ГосТех, совместно с экспертами agile-практик и представителями бизнес-сообщества, в том числе с учётом нашего опыта. Мы вместе с вами становимся свидетелями того, как государство принимает эту новую реальность. И РТЛабс находится в лидерах этого движения.

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

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

Буду рад ответить на вопросы в комментариях к этой статье или узнать ваш опыт внедрения продуктового подхода в компании.