Кто такой Product Owner

[zibsun]

Готовился к тренингу для Product Owners  и набросал заметки на тему кто такой Product Owner и зачем он нужен.

Был бы рад услышать комментарии и/или возражения

Под катом много буков.

Product Owner

Введение

В методологии Scrum есть роль ProductOwner. Зачем он нужени и какие проблемы он решает?
Давайте рассмотрим вполне типичный случай разработки продукта или сервиса. Предположим, что у вас есть множество заказчиков/стейкхолдеров и команда. Кроме того, есть цель (или цели) разработки. Какие? Не знаю. Но уверен, что цель у быть должна. Вы же зачем-то пишете код? Если у вас цели нет, самое время задуматься и ее сформулировать.
Предположим, вам удалось сформулировать цель. Например, "мы хотим к концу года заработать 10млн долларов" или "мы хотим занять 51% рынка к такому-то году".
Осталось выяснить, как этой цели добиться максимально оптимальным образом. Я попробую сформулировать некоторые проблемы, которые могут тут вам встретится.

Проблемы

• Проблема концепции. У каждого заказчика есть свои собственные интересы в системе - каждый хочет, чтобы продукт решал именно его задачи. Все заказчики говорят команде, что нужно делать. В итоге команда решает задачи того, кто более настойчив. Насколько это правильный и оптимальный выбор с точки зрения достижения цели?
  

• Проблема приоритетов. Заказчик знает, что единственный способ добиться, чтобы его работу все-таки сделали - объявить ее самой важной. В противном случае за нее никто никогда не возмется. В итоге у команда вся текущая работа идет с самым высоким приоритетом.
  

• Проблема контекста. В итоге команда бросается делать то одно, то другое. Помимо того, что это всех нервирует и демотивирует, существует проблема переключения контекста: переход от задачи к задаче занимает много времени. Это просто медленнее.
  

• Проблема прозрачности. Заказчики расстроены. Команда работает медленно (они не делают мои задачи!) и плохо (они делают мои задачи совсем не так, как я хочу!). Это действует в обе стороны. Заказчики иногда представляются команде неадекватными людьми, которые хотят странного.
  

• Проблема скорости разработки. Иногда ответы на вопросы заказчик не может ответить днями или даже неделями. Пока заказчик "думает", команда занимается низкоприоритетными, ненужными задачами, а иногда и вовсе бездельничает
  

Ну отлично, давайте думать как это поправить. Не мудрствуя лукаво воспользуемся "менеджерским" методом решения проблем: введем роль и распишем отвественности и полномочия. (а как, вы думали, в RUP появилось 33 роли?)

Новая роль ProductOwner

Новая роль в Scrum называется ProductOwner. Давайте проанализируем, какими полномочиями он должен обладать для решения поставленных проблем.

• Проблема концепции. Сделаем так, чтобы только один человек отвечал за концепцию продукта/сервиса. В своей голове он должен утрясти мнения многих заказчиков и исходя из сформулированной цели и интересов всех участников определить Концепцию (Vision) продукта/сервиса.
  

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

• Проблема контекста. Этот человек будет работать с командой так, чтобы ее производительность была максимальной в долгосрочной перспективе. В частности, это означает, что он будет заботится о стабильности объема работ в итерации (команда сосредотачивается на четком списке фич на итерацию) и берет на себя все заботы о заказчиках, которым вдруг нужен этот чертов функционал прямо сейчас!
  

• Проблема прозрачности. ProductOwner отвечает за обеспечение полной прозрачности всей разработки. Все должны иметь нужную им информацию - начиная от спонсора проекта/продукта/сервиса и заканчивая студентами-стажерами.
  

• Скорость разработки. ProductOwner отвечает за то, чтобы требования были готовы к началу итерации.ProductOwner может принять временное решение, если правильного ответа все-таки нет.
  

Итак, у нас появился человек, который отвечает за продукт/сервис. Это один человек, а не группа - иначе мы опять получим проблему множественности заказчиков. У него в голове сформулирован эффективный путь достижения целей, который он доносит до каждого, кто в том нуждается и, как говорят американцы, "he gets the job done".

Теперь мы готовы расписать его ответственность и полномочия (они будут у нас совпадать)

Ответственность и полномочия ProductOwner

Концепция

• Концепция продукта/сервиса


• ROI (возврат вложенных средств) по фичам (features)


• Координация и приоритезация списка фич [Backlog]


• Планирование фич на итерацию (кроме оценки!)
  

Общение с командой

• Отвечает за предоставление понятных и тестируемых требований


• Принимает результат в конце итерации. Команде нужна обратная связь.
  

Общение со стейкхолдерами и заказчиками

• Отвечает за сбор требований к продукту/сервису


• Разруливает конфликты


• Управляет ожиданиями стейкхолдеров и заказчиков
  

Пытливый ум некоторых читателей наверное заметил несколько "такнебывает". Они и правда есть. Сформулируем.

Так не бывает?

Такнебывает №1. Где гарантия, что узурпация власти ProductOwner решит проблему?

ProductOwner не занимается принятием решений вместо стейкхолдеров. Он должен понимать, что его основная задача - общение со всеми заинтересованными сторонами. Он не в коем случае не узурпирует власть. ProductOwner является представителем заказчика для команды и представителем команды для заказчиков.
Например, он может проводить регулярные встречи заказчиков для выработки совместных решений по приоритетам разработки.

Такнебывает №2. ProductOwner у вас быстро станет узким местом!

Отличный довод. Если бы ProductOwner определял приоритеты разработки, общался с заказчиками, разрабатывал требования и т.д. то очень скоро скорость разработки продукта определялась скоростью, с которой ProductOwner отвечает на запросы.
Однако, это не так. Как только план сформирован и цели итерации определены, команда сама может контактировать с заказчиками по поводу реализации конкретного плана. В частности, ProductOwner может работать с аналитиками в команде для определения требований.

Такнебывает №3. Бизнес-человек быстро завалит разработку нашего высоко-технологического продукта
Действительно, при разработке продуктов со сложной архитектурой приоритеты часто определяются не интересами бизнеса, а технологическими рисками. Кроме того, иногда архитекторы (особенно неопытные) заигрываются и планируют создание большого фреймворка в стиле лучше день потерять, а потом за пять минут долететь. Тем важнее иметь правильного ProductOwner, который сможет выслушать обе стороны и согласовать план, который удовлетворит обе стороны.