Владелец Продукта, а не прокси

Перевод оригинальной статьи Кена Швабера «Product Owner, not proxies»

Очень часто продуктовые менеджеры отказываются от роли Владельца Продукта. Они пытаются договориться с командой о том, что бизнес-аналитик или аналитик по Продукту станут их «прокси» Владельцем Продукта. Это можно понять — ведь многие книги и курсы рассматривают Владельца Продукта лишь как довесок к Скрам-команде. Всё, что ему надо делать, это писать пользовательские истории и играть в покер планирования по критериям INVEST. Такое представление о Владельце Продукта вытекает из того, как его определяют разработчики.

Скрам не даёт предписаний относительно того, как использовать Бэклог Продукта или что должен делать Владелец Продукта. Человек, который пишет отличные пользовательские истории, не будет использовать Скрам для оптимизации ценности продукта. Такие люди становятся бизнес-аналитиками, разработчиками технических требований.

Делегирование задач Владельца Продукта аналитику лишь сильнее отдаляет разработку от бизнеса. В моем понимании Скрам-мастер должен их сближать. Скрам-мастер должен научить компанию гибкости через введение роли Владельца Продукта. Скрам-мастер должен помочь Владельцу Продукта понять, как извлечь выгоду из представляющихся возможностей, оптимизировать ценность и сотрудничать с командой.

Я никоим образом не предполагал, что Владелец Продукта станет бизнес-аналитиком, отвечающим за разработку технических требований.

Скрам возник в сообществе разработчиков программного обеспечения. Думаю, именно поэтому мы рассматриваем Владельца Продукта с точки зрения нас, разработчиков. Что он может сделать, чтобы помочь нам работать лучше? Мы не смотрели на Владельца Продукта с точки зрения его ответственности за продукт и его ожиданий относительно того, как мы, разработчики, можем с ним сотрудничать и помогать ему лучше делать его работу.

Суть уловили клиенты и те, кто занимается управлением продуктом. Они поняли, что мы относимся к ним с позиции пользы для себя — хотим, чтобы они помогали нам делать нашу работу.

И они испарились, оставив после себя сильно «выпотрошенную» должность Владельца Продукта — Владелец Продукта / бизнес-аналитик.

Разумеется, это просто усиливает каскадную модель, когда кто-то стоит между разработчиками и лицом, ответственным за Продукт и его использование.

Владелец Продукта не может быть Скрам-мастером. У них обоих есть четкие интересы и привычки. Изменить свои привычки сложно. Изменить их так, чтобы видеть обе точки зрения, невозможно. Владельцам Продукта сначала нужно научиться делать свою работу по-новому, гибко.

Я планирую решить эту проблему с помощью нового курса для Владельцев Продукта, который будет полностью посвящён гибкости для продуктовых менеджеров. Они могут использовать Скрам или любой другой инкрементальный подход. Главное, чтобы они были гибкими, руководствовались ценностью и использовали бизнес-возможности, а не просто сидели, сложа руки, и писали пользовательские истории.

Кен

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *