В Scrum Guide особенно отмечается, что роль владельца продукта выполняет только один человек. Это не комитет, не собрание, а один ответственный за бэклог сотрудник. Он может делегировать часть обязанностей, но конечное решение принимает единолично.
Наличие более одного владельца продукта и бэклога в конечном итоге только замедлит команду. Почему этого правила нужно придерживаться? Давайте узнаем в статье.
Когда компания масштабирует разработку, она, как правило, копирует состав Scrum-команд, включая владельца продукта. Вскоре компания поймёт, что роль PO не так хорошо работает на ctrl+c, ctrl+v. Появляются различные дифференцированные типы владельца продукта: владелец функции, владелец эпика, компонента и прочее. Направление верное, но слишком сложное. При работе даже с несколькими командами над одним продуктом нужен ровно один владелец продукта. Продукт нужно выделять вокруг того, что реально ( и полноценно) удовлетворяет потребности клиента.
Не мало компаний начинают изменять Scrum Guide в этой части, оправдываясь тем, что Scrum у них не заработает с одним владельцем.
Во многих случаях нет проблемы в передаче полномочий и ответственности за весь продукт одному человеку. Тем не менее, люди отказываются от единственного PO, потому что считают эту концепцию нереальной. Они считают, что наличие нескольких владельцев и нескольких бэклогов продукта необходимо по разным причинам:
- в Scrum Guide говорится, что одной команде нужен один владелец продукта, а это значит, что у нас должно быть несколько PO, так как у нас несколько команд. Это неверная интерпретация, на самом деле — один бэклог продукта на одного владельца продукта.
- Знать предметную область целого продукта слишком сложно.
- Рабочая нагрузка для создания всех элементов бэклога велика, а владельцу продукта трудно оставаться одинаково доступным для всех команд.
- Один владелец продукта не попадёт на все Scrum-события нескольких команд.
- Некуда деть старых PO из прошлой структуры, чтобы оставить только одного.
Почему плохо иметь нескольких PO на один продукт
Наличие большого количества PO поощряет микроуправление внутри команд. Появляется локальная оптимизация, а приоритеты расставляются не по всему продукту, а по одной его части.
Когда РО обладает только частью продукта, он транслирует команде, чтобы она сосредоточилась на готовности истории, а не на создании ценности. Это происходит тогда, когда сама по себе история является декомпозированной частью более глобального требования. Чтобы запустить процесс дальше, команда должна сделать свою часть работы. Только это как раз каскадный подход.
Еще один негативный эффект — растёт отсутствие экспертных знаний в командах. Знание предметной области сконцентрировано у владельца продукта, что заставляет команду придерживаться выполнения задач, а не решения проблемы клиента. Выбор модели «один PO на одну команду» уменьшает возможности для обучения и самоорганизации.
Другая проблема в том, что нескольким PO нужна координация. Клиентские фичи разделены на части, и каждая из них получает свой порядок в нескольких бэклогах. Работа разделена на произвольные и искусственные части, и это вынуждает дополнительно координироваться для доставки продукта к концу спринта. Кроме того, расстановка приоритетов децентрализована. Это приводит к асинхронным зависимостям между командами, так как некоторые команды «перегружены» и не могут выполнять работу, от которой зависят другие команды.
Команды не имеют полного представления о продукте и теряют представление о том, что является ценностью для клиента. Наличие только одного PO, управляющего одним бэклогом продукта для нескольких команд, создает прозрачность, необходимую для эмпиризма.
Когда на один продукт несколько владельцев
Есть другая ситуация, когда продукт более менее выделен и не зависит от других, но у него оказывается несколько владельцев продукта.
В этой ситуации ответственность и степень владения остаются неясными. Получается конфликт интересов. Самый простой выход — определиться с ролями. Чаще всего в этой ситуации названные «владельцы продуктов» на самом деле ключевые стейкхолдеры, которые просто хотят держать разработку под контролем.
Что если один PO не справляется?
Быть владельцем продукта — сложная работа. Вполне возможно, что не каждый может справиться.
— Наймите кого-нибудь ещё или отправьте владельца продукта на обучение.
— Сократите количество фич (пользовательских историй) в бэклоге, поскольку они, вероятно, слишком подробны.
— Соберите спецификации для небольшого числа (от 3 до 5 историй на команду на спринт) для эксперимента.
— Владелец продукта может делегировать часть работы, связав команду со стейкхолдерами или клиентом.
— Ограничьте горизонт планирования не более чем на 2–3 спринта вперёд.
— Предотвратите возникновение невыполненных обязательств по продукту за счёт расширения DoD.
Вывод
Роль PO лучше не масштабировать путем умножения PO, поскольку этот подход имеет минусы. При разработке одного продукта нужен один владелец и один бэклог, тогда как команд может быть несколько. Наличие единственного Владельца продукта создает прозрачность и обеспечивает эмпиризм. При масштабировании команд попробуйте сместить фокус работы PO с уточнения историй на расстановку приоритетов и исследования.
