Масштабируем Владельца Продукта с помощью 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.
Мы позвали на эту активность всех желающих разработчиков, ведь делегировать задачи можно только в команды, в Скраме нет никаких других ролей для этого.
Каждую из задач, которые выполняет Владелец Продукта, мы отнесли к одному из семи уровней:
Tell (я сообщу им решение)
Sell (я попробую объяснить и продать решение)
Consult (я посоветуюсь с ними, но приму решение сам)
Agree (мы договоримся о решении вместе)
Advise (я предложу решение, но последнее слово за ними)
Inquire (я узнаю решение после его принятия)
Delegate (я полностью делегирую решение)
В итоге за Владельцем Продукта остались задачи, относящиеся к продуктовой стратегии и порядку Бэклога Продукта. Остальные мы делегировали разработчикам. Конечно, делегирование не произошло в один день. Мы запустили продуктовое сообщество и стали “отдавать” задачи постепенно. Но об этом расскажем уже в другой статье.