Владелец Области Продукта
Владелец Области Продукта специализируется в какой-либо ориентированной на клиента области и действует как Владелец Продукта по отношению к командам для этой области (см. Иллюстрация 1). Владелец Области Продукта выполняет ту же работу, что и Владелец Продукта, но с более ограниченной, но все же ориентированной на клиента точки зрения.
Команда Владельца Продукта
Команда Владельца Продукта - Владельцы Областей Продукта и сам Владелец Продукта вместе образуют команду - Команду Владельца Продукта. Эта команда принимает решения по расстановке приоритетов для всего продукта, но окончательное решение всегда остается за Владельцем Продукта. Решения, касающиеся объема работ и сроков, также остаются за Владельцем Продукта - он решает, когда и что выпустить.
Команды распределяются по Областям Требований исходя из приоритетов Владельца Продукта. Области имеют разный размер с точки зрения трудозатрат и поэтому содержат разное количество команд. Слишком маленькие области - не лучшая идея, потому что они приводят к большому количеству бэклогов и множеству Владельцев Областей Продукта. Общая картина теряется, и команды разрабатывают функциональность, которая имеет мало ценности для клиента. Скорее предпочтительнее объединить пару небольших областей в одну более крупную, повысив гибкость этой области. С другой стороны, слишком большие области будут сложностью для одного Владельца Области Продукта. Чтобы достичь баланса, придерживайтесь как минимум четырех и максимум десяти команд для одной области.
Зачем нужны Владельцы Областей Продукта?
Основная причина наличия Владельцев Областей Продукта - предотвратить перегруженность Владельца Продукта. В отсутствии Владельцев Областей перегруженность Владельца Продукта наступит по следующим причинам:
- Бэклог Продукта становится слишком большим
Бережливое Мышление поощряет поставки небольшими партиями и в коротких циклах. Мы предлагаем, чтобы у каждой команды было как минимум четыре элемента Бэклога Продукта на каждую итерацию, которые они могут независимо выполнять в рамках этой итерации. С 50 командами это приводит к Бэклогу Продукта с 200 элементами только для одной итерации. Приоритизация 200 элементов бэклога на итерацию - слишком большая работа для одного Владельца Продукта. - команды работают над всей системой
Команды работают над всей системой - Фиче-команды - это хорошо, так же как и изучение новых частей системы. Но слишком много обучения без поставок ценности клиенту - нехорошо. Так может произойти, когда команды работают над совершенно незнакомой функциональностью. В этом случае, у них нет возможности специализироваться, и это влияет на скорость работы команд. Как найти баланс? - Владелец Продукта работает со слишком большим количеством команд
Со всеми теми задачами, которые должен выполнять Владелец Продукта, кажется невозможным для него работать более чем с парой команд. Как с этим справиться? Один способ заключается в том, чтобы команды взяли на себя работу по уточнению элементов в Бэклоге Продукта, привлекая в команду экспертов предметной области. Альтернативой будет, чтобы кто-нибудь помог Владельцу Продукта в работе по уточнению элементов бэклога. Этот человек присоединяется к Команде Владельца Продукта, но не принимает решений, связанных с установлением приоритетов. Используя эти техники, один Владелец Продукта может работать с пятью или десятью командами. Превышение этого количества вызовет информационную перегрузку Владельца Продукта и затруднит планирование итераций.
Перевод статьи осуществлён Юрием Панкратьевым и Кротовым Артёмом.