Если спрашивать agile-коучей организаций об основных препятствиях гибкому процессу, многие из них упомянут роль владельца продукта. Так как это очень ответственная роль, которая требует и сильного игрока, и новых правил игры для бизнеса, с этим часто возникают проблемы. В этой статье мы рассмотрим анти-паттерны того, как функционирует роль PO в scrum-командах, и подумаем над тем, как с этим справиться.
Реальность такова, что владельцу продукта редко удаётся выполнить свою роль. Есть множество но.
Главная проблема в непонимании самой роли, эмпиризма в основе Scrum и объёма работы.
Во время agile-трансформации некоторые компании идут легким путём: меняют название у должности бизнес-аналитика, менеджера проектов и других ролей из старой структуры. Обязанности при этом не меняются. Дополнительно человек получает в нагрузку ведение бэклога продукта.
При этом фактически «владелец продукта» не может принимать решения, управлять бюджетом, изменять стратегию, определять порядок выпуска обновлений и фич на рынок. Он работает посредником между теми, кто реально принимает решения, и командой разработки. По сути, это автор пользовательских историй.
Этот подход приводит к тому, что Scrum не работает, как должен. Отсутствует последовательная доставка ценности, нет возможности реально использовать обратную связь и новые данные от предыдущего спринта. Также нет возможности общаться со всеми стейкхолдерами, типа представителей смежных отделом, и конечными пользователями.
Какую ценность приносит такой владелец продукта клиентам, продукту и организации?
- Клиенты не видят владельца продукта, а их отзывы не попадают к нему.
- Продукт не оптимизирован, это очередь из пожеланий стейкхолдеров.
- В организации принятие решения по продукту разбросано по отделам и начальникам. Распределённая ответственность равна её отсутствию, появлению конкурирующих требований и низкому качеству.
Путь владельца продукта
Нужно принять тот факт, что в большинстве случаев владелец продукта начнет как «прокси». В начале владения продуктом всё в порядке, но должно быть поле для роста, чтобы забрать ответственность за продукт.
Владелец продукта отвечает за оптимизацию стоимости и управление бэклогом. Мы должны стремиться к PO, который:
- имеет видение продукта и стратегию,
- сотрудничает со стейкхолдерами на равных,
- сотрудничает с клиентами,
- проверяет продукт и адаптирует его бэклог, согласно отзывам и условиям рынка.
И всё это делает один человек, а не группа.
Scrum Guide: «Чтобы владелец продукта добился успеха, вся организация должна уважать его или ее решения».
Как организация может помочь:
- Все заинтересованные стороны проходят коучинг, где основное — донести, что работа ведётся эмпирическим путём, на принципах прозрачности, проверки и адаптации.
- Кто-то из chief-менеджмента берёт на себя роль владельца продукта.
- Со стейкхолдерами со стороны бизнеса создаётся чёткое соглашение о правилах игры: у РО есть последнее слово по продукту.
- Обучение РО использовать фактические данные для обоснования своих решений. Вообще, не игнорировать курсы владельцев продуктов (к сожалению, это происходит часто).
- Активное сотрудничество со scrum-мастером для устранения препятствий в поставке ценности.
- Условия для синхронизации между отделами, которые имеют отношения к продукту.
- Команда должна стремиться к тому, чтобы взять часть обязанностей РО (сбор обратной связи, cust dev и прочее).
- Видение продукта поддерживается, доступно каждому, о нём регулярно напоминают.
Иногда коучинг и обучение владельца продуктом остаётся на втором плане, scrum-мастер концентрируется на команде, как это диктуют условия. Не забывайте, что он также работает с владельцем продукта. Scrum-мастер помогает найти инструменты работы с продуктом и продвигать ценности Scrum и Agile в организации.
Это некоторые, весьма абстрактные идеи. А у вас есть чек-листы того, как развивать компетенции владельца продукта?
