Кейс Росбанка: кратное ускорение продуктовой разработки (1 часть)
Кейс Росбанка: кратное ускорение продуктовой разработки (3 часть)
Кейс Росбанка: кратное ускорение продуктовой разработки (3 часть)
Продуктовая группа транзакционного бизнеса состояла из четырёх узкоспециализированных кросс-функциональных команд. У каждой был собственный локальный Бэклог Продукта и локальный Area Product Owner (APO) хотя эта роль должна появляться только в LeSS Huge, где команд больше восьми. Мы столкнулись с типичной дисфункцией, Copy Paste Scrum — когда фреймворк применяется для отдельных частей, а не продукта целиком.
Узкоспециализированные команды закреплены за частями продукта
Основные проблемы
Работа не над самым важным:
- важные фичи не поставлялись вовремя, одна команда могла работать сверхурочно, чтобы довести фичу до клиента;
- другие команды занимались менее приоритетными задачами и не могли помочь коллегам или даже не знали о сложившейся ситуации.
Узкие горлышки и низкая адаптивность:
- уход ключевого специалиста в отпуск или на больничный создавал значительные риски для выполнения задач;
- узкие горлышки особенно часто возникали на этапе тестирования, что приводило к задержкам в поставке.
Длинные циклы разработки и избыточная утилизация:
- выполнение задач затягивалось, многие переносились из одного Спринта в другой по несколько раз;
- участники были полностью загружены, отсутствие свободных рук снижало гибкость и не давало быстро реагировать на изменения.
Большие рабочие пакеты:
- разработчик мог на несколько дней уйти работать над задачей и оставить команду без контекста;
- если задача задерживалась, предсказать или устранить задержку было сложно;
- команда не умела делить задачи на небольшие инкременты и ждала, пока один человек закроет большой объём работы;
- снижалась скорость поставки, так как остальные участники команды переключались на другие задачи.
Первичное обучение команд
Первое обучение провели за три месяца до изменения организационной структуры. Основной блок обучения состоял из обзора фреймворка масштабирования LeSS: его структуры, правил, техник координации. Мы также планировали измерить уровень готовности к изменениям.
Ключевые моменты
Первым делом перед командами выступила CEO:
- донесла важность и цели изменений (работа над самым важным, быстрые циклы обучения, адаптивность);
- убедила сотрудников, что они получат поддержку при решении вопросов в процессе трансформации.
Затем мы провели для участников обзорный воркшоп “Введение в LeSS”. Некоторые сотрудники восприняли изменения как угрозу и выразили давали токсичные комментарии, задавали скептические вопросы.
После закрытого голосования стало ясно, что 10% сотрудников не были готовы участвовать в трансформации.
Выбор целевого и промежуточного состояния трансформации
Целевое состояние трансформации предполагает, что все команды станут взаимозаменяемыми, чтобы достичь высокой степень адаптивности и выполнять любую задачу из общего Бэклога Продукта. Но исходя из обратной связи и пожеланий команд о плавном переходе после первичного обучения, мы решили разделить процесс на два этапа: State 1 и State 2. Это позволило нам снизить когнитивную нагрузку команд и обеспечить постепенные изменения.
Владельца Продукта мы разгрузили с помощью команды Владельца Продукта, куда присоединились бывшие APO на уровне команд.
Этапы трансформации
State 1:
- по две команды объединяются в области ценности Продукты и Сервисы;
- внутри каждой области команды становятся взаимозаменяемыми.
State 2:
- команды переходят к работе с общим Бэклогом Продукта и берут задачи из любой области;
- появляется полная взаимозаменяемость и радикальная гибкость.
Команды объединяются в два кластера «продукты» и «сервисы»
Мы также провели тренинг по управлению Бэклогом Продукта и воркшопы по декомпозиции, выработке Definition of Ready (DoR) и Definition of Done (DoD).
Работа с ограничениями
В рамках подготовки к трансформации мы выявили три ключевых ограничения, которые могли поставить изменения под угрозу:
- Работа с критичными инцидентами
- Разбор обращений клиентов
- Разрыв в знаниях между командами
Ещё надо было понять, что делать с сотрудниками, которые не видели себя в новой организационной структуре.
1. Критичные инциденты
Одной из приоритетных задач было обеспечить стабильность для клиентов и предотвратить негативные последствия во время трансформации. Вопрос, кто и как будет разбираться с критичными инцидентами, стал для нас ключевым.
На брейншторминге собрались волонтёры из всех команд и обсудили процесс работы с инцидентами. Разработчики сами предложили решения, распределили роли и определили порядок действий — с помощью техник координации из гайдлайна Создайте условия для возникающей координации. Этот процесс был презентован продуктовой группе и принят как стандарт.
2. Обращения клиентов
Также требовалось распределить ответственность за клиентские обращения после первичного анализа контактным центром и поддержкой.
Проблемы:
- отсутствие роли APO, который централизованно принимал эти решения;
- опасения, что ответственность размоется, а сервис ухудшится.
Решения:
- на встречах с волонтерами выявить потенциально сложные моменты;
- во время дискуссий выбрать оптимальные решения среди противоречивых вариантов;
- согласовать изменения с другими департаментами, которые взаимодействуют с разработчиками.
Результат:
- составили расписание дежурств по обращениям, описали критерии для эскалации, правила отслеживания и разбор каждого кейса;
- процесс заработал почти сразу после трансформации благодаря поддержке Leading Team.
3. Разрыв в областях знаний между командами
Перед работой с общим Бэклогом Продукта требовалось уменьшить разрыв, который образовался из-за работы команд в узких доменных областях.
Для этого запустили кросс-обучение между командами — они сами решали, чему и как друг друга обучать.
В результате у всех команд появился достаточный уровень экспертизы для любых задач из общего Бэклога Продукта.
Kick off продуктовой группы
После трехмесячной подготовки мы были готовы к переходу в новую организационную структуру. Опишем ключевые активности, из которых состоял командный старт.
Все участники объединились в группы и описали позитивные изменения, которые хотели бы увидеть: как в своих командах, так и в продукте в целом. Участники также зафиксировали критерии измерения этих улучшений.
На основе пяти ценностей Скрама команды сформулировали ожидаемые паттерны поведения, которые станут основой их взаимодействия:
- Я готов помогать коллегам с незнакомой для себя функциональностью
- Я всегда ищу решение проблемы, а не виноватых
Команды выбрали и оптимальную длину Спринта, которая позволит довести задачи до DoD. Она составила три недели.
Появилось расписание и обязательных, и кросс-командных событий для каждой команды. У встреч определился состав, формат и продолжительность.
Подготовка к изменениям велась без остановки текущей деятельности и часть задач оставалась незавершенной. Команды визуализировали их, чтобы оценить приоритет. Это помогло решить, что брать в первый Спринт, а что отложить.
В общем Бэклоге Продукта задачи стали оцениваться по технике RICE (Reach, Impact, Confidence, Effort). Командам описали процесс оценки, выбора приоритетов и назвали критерии для определения самых важных задач.
