Блог

Масштабируем Владельца Продукта с помощью Delegation poker

Если вы работаете над большим продуктом, то, скорее всего, ваш Владелец Продукта топ-менеджер и он использует масштабируемый Скрам. Мы подробно рассмотрели этот вопрос в статье Product Owner vs. Product Manager. Как Владельцу Продукта выжить и не разорваться? Ответ прост — делегирование. Находим все активности, занимающие время Владельца Продукта и решаем, какие из них делегировать.
В этой статье вы найдете детальное описание процесса на примере продуктовой группы, где 8 команд работают в масштабируемом Скраме с общим Владельцем Продукта.
Находим все активности Владельца Продукта
Мы встретились с Владельцем Продукта и для начала, решили выписать все активности, относящиеся к Владельцу Продукта из Руководства по Скраму:
Владелец Продукта несет ответственность за максимизацию ценности продукта, получаемого в результате работы Скрам команд. Product Owner также несет ответственность за эффективное управление Product Backlog, в том числе он:
  • разрабатывает и точно коммуницирует Product Goal;
  • создает и четко объясняет элементы Product Backlog;
  • упорядочивает элементы Product Backlog; а также, обеспечивает прозрачность, доступность и понимание Product Backlog.
Это описание слишком верхнеуровневое и большинство активностей Владельца Продукта находятся за периметром Руководства по Скраму. Например, там ничего не сказано про стратегию, метрики, взаимоотношение со стейкхолдерами и т.д.
Поэтому мы решили декомпозировать список из Руководства по Скраму до конкретных активностей. А еще мы фиксировали работу Владельца Продукта в течение одного Спринта и записывали все, что ему по факту приходилось делать.
И вот список, который у нас получился:
  • Создание элементов Бэклога Продукта
  • Детальное описание элементов Бэклога Продукта
  • Удаление элементов Бэклога Продукта
  • Изменение порядка Бэклога Продукта
  • Создание видения продукта
  • Описание требований для разработчиков
  • Анализ метрик продукта
  • Интервью с пользователями продукта
  • Обсуждение деталей продукта со стейкхолдерами
  • Посещение Ежедневного Скрама, чтобы быть в курсе прогресса достижения Цели Спринта
и многое многое другое….
Решаем, что делегировать с помощью Delegation Poker
Теперь предстояло разобраться, что из этого списка Владелец Продукта может делать только сам (суть роли), что может делегировать другим, а что не должен делать вообще.
Для этого упражнения мы выбрали простой инструмент — Delegation poker, созданный Юргеном Аппело (Jurgen Appelo), автором книги Management 3.0.
Мы позвали на эту активность всех желающих разработчиков, ведь делегировать задачи можно только в команды, в Скраме нет никаких других ролей для этого.
Каждую из задач, которые выполняет Владелец Продукта, мы отнесли к одному из семи уровней:
  1. Tell (я сообщу им решение)
  2. Sell (я попробую объяснить и продать решение)
  3. Consult (я посоветуюсь с ними, но приму решение сам)
  4. Agree (мы договоримся о решении вместе)
  5. Advise (я предложу решение, но последнее слово за ними)
  6. Inquire (я узнаю решение после его принятия)
  7. Delegate (я полностью делегирую решение)
В итоге за Владельцем Продукта остались задачи, относящиеся к продуктовой стратегии и порядку Бэклога Продукта. Остальные мы делегировали разработчикам. Конечно, делегирование не произошло в один день. Мы запустили продуктовое сообщество и стали “отдавать” задачи постепенно. Но об этом расскажем уже в другой статье.