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