Друзья, всем привет!
Сегодня я расскажу вам, как проводил аудит продуктовых команд и искал точки роста, когда работал руководителем группы Lean&Agile адаптации в S7 Airlines.
Я выступал с этим докладом на Moscow Tech Week в 2022 году, поэтому если вам удобнее посмотреть видео, оно доступно здесь:
Начать хочу с того, что когда я пришел в S7 Airlines, продуктовая трансформация в компании уже прошла:
Продуктовая трансформация случилась пять лет назад. Менеджеры проектов превратились во Владельцев продуктов, системы стали продуктами.
Основные сущности трансформации: бизнес-направление, ИТ-стрим, Продукт, Владелец продукта и продуктовая команда.
Результат трансформации: 85% команд используют элементы Scrum-фреймворка, 15% – практики Канбан-метода. 15% команд используют продуктовые практики.
Мой подход к работе с продуктовым командами копировал путь эволюционных изменений, описанных Канбан Университетом.
Почему мы выбрали именно такой подход?
Передо мной не было запроса на единую продуктовую методологию SAFe, Scrum или Kanban, поэтому я мог экспериментировать.
Я решил начать с того, что есть: спросить у Владельцев продукта “Где болит?”. Я провел исследование команд по следующим направлениям:
- Продуктовые практики.
- Процессные практики.
- Типизация и оценка задач.
- Источники неудовлетворенности.
- Артефакты.
- Метрики поставки.
Продуктовые практики
Я расспрашивал продуктов, что у них за продукт, какое видение у продукта, какие пользователи, какие проблемы пользователей решает продукт, как они генерят новые гипотезы в продукте, какие выгоды получают пользователи, пользуясь продуктом, какие продуктовые метрики они используют, какой у них KPI и т.д.?
Процессные практики
С точки зрения процессов я спрашивал у продактов, какой фреймворк, подход к разработке они используют, какие менеджерские роли есть в команде, какая длина итерации, когда происходит планирование спринта, как часто они используют цель спринта и т.д.?
Типизация и оценка задач
Я спрашивал, как продакты оценивают задачи, в каких едеиницах, какие типовые рабочие элементы используют, как у них классы обслуживания, как управляют зависимостями от внешних сервисов и т.д.?
Источник неудовлетворенности
Я расспрашивал продактов, какие у них источники неудовлетворенности с точки зрения владельца продукта, команды разработки, заказчиков?
Артефакты
Я изучал все доступные артефакты: как выглядит бэклог продукта, как выглядит доска разработки?
Метрики поставки
Я считал метрики поставки:
- диапазон минимального времени выполнения
- диапазон максимального времени выполнения
- среднее время выполнения
- медианное время выполнения
- 85 процентиль в днях
- средняя пропускная способность,
- средний прирост бэклога к пропускной способности, шт./неделю.
Заключение по итогам аудита
Заключение содержало три раздела:
- Что хорошо?
- Что можно улучшить?
- Следующие шаги.
Выгоды от реализации рекомендаций
- Экономические
- Сокращение времени поставки.
- Повышение предсказуемости поставки.
- Социальные
- Улучшение эмоционального фона в командах.
- Более слаженная работа.
- Видение общей цели.
Результат применения рекомендаций
45% – успех и улучшения.
55% – ничего не меняется.
Я порефлексировал о результатах и вот что получилось.
Что хорошо:
- Сократилось время аудита.
- Разработал чек-лист для аудита.
- Смотрел только самое релевантное.
Что можно улучшить:
- Найти реального заказчика улучшений.
- Обязательное выполнение рекомендаций.
- Каждому продукту свои метрики.
- Определение пороговых значений метрик.
Пример из практики
Резюме
Начинайте с того, что есть – исследуйте контекст, фиксируйте начальные значения.
Найдите правильного человека для применения рекомендаций или согласуйте правила для их реализации.
Договоритесь о метриках продукта и процесса и их пороговых значениях.
Регулярно пересматривайте источники неудовлетворенности и метрики – это самый быстрый способ понять, есть ли проблемы с производительностью и востребованностью продукта.
