Кейс Росбанка: кратное ускорение продуктовой разработки (1 часть)
Кейс Росбанка: кратное ускорение продуктовой разработки (2 часть)
Кейс Росбанка: кратное ускорение продуктовой разработки (2 часть)
После изменения организационной структуры мы столкнулись с новыми сложностями, которые потребовали внимания.
Работа с недостаточной утилизацией разработчиков
Раньше ожидалась полная загрузка в Спринте, но с фокусом на Цели Спринта и задачах с прогнозом доведения до DoD это стало невозможным.
Некоторые разработчики периодически оставались без задач по ключевой специализации и возникал ряд проблем:
- T-shape мультифункциональные специалисты не были готовы расти в смежных компетенциях и подключаться к Цели Спринта;
- простой приводил к дискомфорту и снижению вовлеченности.
Для устранения этой проблемы составили инструкцию, которая описывает приоритетный алгоритм действий свободного участника команды:
- Помочь команде довести задачи в Спринте до DoD. Это может включать работу вне своей специализации.
- Подготовить задачи на следующий Спринт и помочь команде довести задачи до DoR, даже если это вне основной зоны экспертизы.
- Обратиться к соседней команде и проверить, нужна ли ей помощь с доведением задач до DoD.
- Поработать над собственными инструментами. Выполнить рефакторинг, устранить технический долг или заняться другой задачей, которая не требует участия остальных членов команды и может принести пользу продукту.
- Обратиться к ITAL и запросить техническую задачу для выполнения в одиночку.
- Заняться саморазвитием. Сосредоточиться на обучении до следующего планирования.
Для упрощения поиска задач в течение Спринта создали доску объявлений. Любой участник команды мог разместить на ней сообщение о готовности взять задачу. Несмотря на редкое использование, доска оказалась эффективной. Разработчики, которые публиковали на ней сообщения, сразу же получали от соседних команд задачи, где требовалась помощь со стороны.
Решение проблемы узкого горлышка на этапе тестирования
Некоторые разработчики заметили, что большинство задач в Спринте застревают на этапе тестирования. Оказалось, что занятость тестировщиков ограничила выполнение большинства задач в течение трех недель.
Самые открытые и мотивированные участники команд проявили инициативу. Они обучились у тестировщиков основам тестирования и созданию тест-кейсов, а после начали подключаться к тестированию, чтобы помочь своим командам. Это позволило разгрузить тестировщиков и ускорить выполнение задач.
С учетом ограничения на этапе тестирования команды адаптировали процесс планирования:
- Сфокусировались на тестируемом объеме работы. При наполнении Бэклога Спринта команды начали ориентироваться только на тот объем задач, который они могли протестировать с доступными ресурсами.
- Стали минимизировать незавершенные задачи. Команды взяли себе за правило не допускать большого количества задач, чтобы они не застревали на этапе тестирования и завершились к концу Спринта.
Уточнение элементов Бэклога Продукта (PBR)
Для решения проблемы больших рабочих пакетов внедрили обязательный процесс декомпозиции и уточнения задач Бэклога Продукта. Он состоял из двух этапов: Overall PBR и Multi-Team PBR (гайдлайн Создайте условия для возникающей координации).
1. Overall PBR
Представители команд собирались для анализа и декомпозиции задач.
- Владелец Продукта или бизнес-эксперт рассказывал командам о проблеме клиента, которую решает задача, и о её влиянии на Цель Продукта.
- Представители команд делились на мини-группы и разбивали задачу на небольшие части, каждую из которых можно было поставить клиенту отдельно. Варианты декомпозиции обсуждались всей группой и оценивались фасилитатором, после чего выбирался лучший подход.
- Выбранные части задачи доводились до DoR, чтобы задача была готова к следующему этапу.
2. Multi-Team PBR
Когда задача предположительно достигала DoR, проводилась встреча с участием всех команд направления.
Перед встречей участники знакомились со спецификацией и декомпозированными частями задачи.
На встрече участники проверяли соответствие задачи критериям DoR. Если она им соответствовала и была понятна всем командам, её включали в Бэклог Спринта без дополнительных уточнений. Если же находились расхождения с критериями DoR, задача возвращалась на доработку.
Результаты трансформации
Для оценки результатов трансформации мы использовали потоковые метрики:
- Cycle Time (CT) — время выполнения задачи от начала разработки до выхода на рынок.
- Throughput (TH) — количество завершенных задач за единицу времени.
- Work-In-Progress (WIP) — количество задач, которые выполняются одновременно.
Измерения начали проводить, когда команды освоили новый процесс и завершили несколько Спринтов. Замеры выполняли в два этапа: за девять недель до организационных изменений и через девять недель после.
Ключевые результаты
Сократился средний CT. До трансформации он занимал 43 дня, после — 19 дней. Объем выполнения задач (TH) сохранился на уровне 30 задач за 9 недель.
После трансформации время от начала разработки до выхода на рынок сократилось в два-три раза (желтые стрелки)
Команды начали брать задачи из общего Бэклога Продукта, что обеспечило фокус на самых важных задачах с точки зрения продукта.
Хотя у нас не было количественных метрик, Владелец Продукта отметила значительную разницу между работой, которая бралась в Спринты раньше, и работой, за которую стали браться после организационных изменений.
Что можно было сделать по-другому
Исходя из результатов трансформации мы выявили несколько аспектов, которые могли бы улучшить.
Работа с сопротивлением
Стоит как можно быстрее выявлять сотрудников, которые саботируют изменения, и изолировать их от процесса трансформации. Как вариант предлагать им альтернативные роли вне этого процесса, чтобы сводить влияние на других участников к минимуму.
Раннее подключение команд к созданию изменений
Основная работа над проектированием организационного дизайна велась с топ-менеджментом на протяжении полугода, и все ключевые решения по организационной структуре принимались без команд.
Команды следует подключать к трансформации на самых ранних этапах. Такой подход повысит доверие к процессу и снизит сопротивление.
