Перевод статьи Кена Швабера Product Owners not proxies.
Слишком часто продакт менеджеры отказываются брать на себя роль Владельца Продукта. Они настаивают, чтобы кто-то другой из бизнеса или аналитик "замещал" их, выполняя роль Владельца Продукта. Большинство книг и курсов, касающихся Владельца Продукта, описывают его как участника Скрам-команды, который пишет пользовательские истории и играет в планинг-покер, следуя правилам INVEST.
Человек, который пишет идеальные пользовательские истории, не использует Скрам для оптимизации продукта. Он превращается в бизнес-аналитика, инженера требований.
Когда Владелец Продукта делегирует свои полномочия, разрыв между разработчиками и клиентами усугубляется. Считаю, что Скрам-мастер должен возводить между ними мосты. Скрам-мастер учит бизнес гибкости и как брать на себя роль Владельца Продукта. Скрам-мастер помогает Владельцу Продукта разобраться, как использовать бизнес-возможности, оптимизировать стоимость, работая с командой.
Ни в коем случае я не задумывал Владельца Продукта как бизнес-аналитика, отвечающего за требования.
Скрам вышел из среды разработки программного обеспечения. Мы смотрим на Владельца Продукта глазами разработчиков и ждем от них помощи. Мы не воспринимаем их как ответственных за продукт, не думаем, как помочь Владельцам Продуктов выполнить их работу.
Люди из продуктового менеджмента и клиенты осознали это. Поэтому ушли, оставив осиротевшую позицию в виде Владельца Продукта/бизнес-аналитика. Конечно, это подкрепляет водопадную модель, когда кто-то стоит между разработчиками и лицом, отвечающим за продукт и его использование.
Владелец Продукта не может быть Скрам Мастером. У обоих четкие интересы и привычки. Изменить привычки сложно. Изменить их так, чтобы они видели обе точки зрения, невозможно. Прежде всего, они должны научиться новому способу гибко выполнять свою работу.
Я собираюсь устранить эту проблему с помощью нового курса для Владельцев Продукта, который сосредоточен на том, чтобы менеджер продукта был гибким. Он может использовать Scrum или любые другие итеративные и инкрементные техники, но суть в том, чтобы быть гибким, ориентироваться на ценность и прибыльность, а не сидеть и писать пользовательские истории.
Кен
