Друзья, всем привет!

Сегодня я расскажу вам, как проводил аудит продуктовых команд и искал точки роста, когда работал руководителем группы Lean&Agile адаптации в S7 Airlines.

Я выступал с этим докладом на Moscow Tech Week в 2022 году, поэтому если вам удобнее посмотреть видео, оно доступно здесь:

Начать хочу с того, что когда я пришел в S7 Airlines, продуктовая трансформация в компании уже прошла:

Продуктовая трансформация случилась пять лет назад. Менеджеры проектов превратились во Владельцев продуктов, системы стали продуктами.

Основные сущности трансформации: бизнес-направление, ИТ-стрим, Продукт, Владелец продукта и продуктовая команда.

Результат трансформации: 85% команд используют элементы Scrum-фреймворка, 15% – практики Канбан-метода. 15% команд используют продуктовые практики.

Мой подход к работе с продуктовым командами копировал путь эволюционных изменений, описанных Канбан Университетом.

Почему мы выбрали именно такой подход?

Передо мной не было запроса на единую продуктовую методологию SAFe, Scrum или Kanban, поэтому я мог экспериментировать.

Я решил начать с того, что есть: спросить у Владельцев продукта “Где болит?”. Я провел исследование команд по следующим направлениям:

1. Продуктовые практики.
2. Процессные практики.
3. Типизация и оценка задач.
4. Источники неудовлетворенности.
5. Артефакты.
6. Метрики поставки.

 Продуктовые практики

Я расспрашивал продуктов, что у них за продукт, какое видение у продукта, какие пользователи, какие проблемы пользователей решает продукт, как они генерят новые гипотезы в продукте, какие выгоды получают пользователи, пользуясь продуктом, какие продуктовые метрики они используют, какой у них KPI и т.д.?

Процессные практики

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

Типизация и оценка задач

Я спрашивал, как продакты оценивают задачи, в каких едеиницах, какие типовые рабочие элементы используют, как у них классы обслуживания, как управляют зависимостями от внешних сервисов и т.д.?

Источник неудовлетворенности

Я расспрашивал продактов, какие у них источники неудовлетворенности с точки зрения владельца продукта, команды разработки, заказчиков?

Артефакты

Я изучал все доступные артефакты: как выглядит бэклог продукта, как выглядит доска разработки?

Метрики поставки

Я считал метрики поставки: 

• диапазон минимального времени выполнения
• диапазон максимального времени выполнения
• среднее время выполнения 
• медианное время выполнения 
• 85 процентиль в днях
• средняя пропускная способность,
• средний прирост бэклога к пропускной способности, шт./неделю.

Заключение по итогам аудита

Заключение содержало три раздела:

1. Что хорошо?
2. Что можно улучшить?
3. Следующие шаги.

Выгоды от реализации рекомендаций

• Экономические
  • Сокращение времени поставки.
  • Повышение предсказуемости поставки.
• Социальные
  • Улучшение эмоционального фона в командах.
  • Более слаженная работа.
  • Видение общей цели.

Результат применения рекомендаций

45% – успех и улучшения.

55% – ничего не меняется.

Я порефлексировал о результатах и вот что получилось.

Что хорошо:

1. Сократилось время аудита.
2. Разработал чек-лист для аудита.
3. Смотрел только самое релевантное.

Что можно улучшить:

1. Найти реального заказчика улучшений.
2. Обязательное выполнение рекомендаций.
3. Каждому продукту свои метрики.
4. Определение пороговых значений метрик.

Пример из практики

Резюме

Начинайте с того, что есть – исследуйте контекст, фиксируйте начальные значения.

Найдите правильного человека для применения рекомендаций или согласуйте правила для их реализации.

Договоритесь о метриках продукта и процесса и их пороговых значениях.

Регулярно пересматривайте источники неудовлетворенности и метрики – это самый быстрый способ понять, есть ли проблемы с производительностью и востребованностью продукта.