В 2006 году, прочитав одну статью, я стал употреблять термин менеджер по продукту. В течение нескольких месяцев упоминал это словосочетание в постах в моем блоге.
Статья о Scrum во французской версии Википедии тоже использовала этот термин, подтверждая успех этого перевода. В переводе книги «Scrum и XP: заметки с передовой» на французский язык также можно встретить менеджера по продукту.
Но я перестал использовать этот термин и вернулся к Product Owner (пробовал даже переиначить на французский лад – productoneur). Слово менеджер не проходило для организаций: тот, кто занимал эту роль, не являлся менеджером по организационной иерархии.
Владелец продукта указывает направление, но у него нет иерархической ответственности за людей.
На данный момент французское сообщество Scrum использует формулировку Product Owner.
Вот мое определение этой роли:
Владелец продукта (Product Owner, PO) – роль, занимаемая участником команды. Владелец продукта несет ответственность за результат продукта перед заинтересованными сторонами.
Слово продукт следует рассматривать в широком смысле как результат того, что проделано командой. Фактически, не имеет значения, разрабатывает ли команда продукт, услугу или приложение: Владелец продукта несет ответственность за результат.
Когда мы будем в дальнейшем говорить о Владельце продукта, мы будем иметь в виду либо человека, либо роль, которую он играет.
4.2 Функции владельца продукта
Владелец продукта влияет одновременно и на стратегию, и на тактику.
✓ Он принимает решения на стратегическом уровне, которые ранее были обязанностью руководителя проекта или руководящих комитетов. Это, например, выбор даты поставки продукта или приоритизация функций для разработки.
✓ Он также принимает много тактических решений, которые ранее, из-за отсутствия специальной роли, принимались командой разработчиков – например, положение элемента на веб-странице или лейбл к нему. По сути, чтобы двигаться вперед, разработчики были вынуждены делать выбор, который в принципе не был их обязанностью.
Роль Владельца продукта разнится от компании к компании. Но у него есть основные обязанности. Перечислим их.
Владелец продукта определяет порядок, в котором будут разрабатываться компоненты продукта. Он снабжает команду функциональными свойствами, которые необходимо разработать. Стремится максимизировать ценность продукта, расставляет задачи в приоритетном порядке.
Рисунок 4.2 – PO постановляет бэклог
Владелец продукта определяет основные компоненты продукта. Функциональные свойства продукта, полученные от заинтересованных сторон и включенные в список – это бэклог.
На практике это означает, что Владелец продукта занимается ведением бэклога и проводит значительную часть времени за его составлением и поддержанием в ожидании следующих спринтов.
Эта работа выполняется в команде, но Владелец продукта, как правило, проводит за ней больше времени и является главным решающим лицом в случае необходимости.
Владелец продукта отвечает за информирование заинтересованных сторон о предварительных результатах работы команды.
Он предлагает цель спринта, согласовывает ее с командой и публикует: она должна быть известна всем участникам процесса.
Именно Владелец продукта определяет момент ввода в эксплуатацию пользователями.
Во время спринта Владелец продукта должен убедиться, что команда разработчиков четко понимает элементы бэклога. Во время разговоров к нему могут обращаться с просьбой принять тактическое решение, поэтому его присутствие в команде имеет важное значение.
Владелец продукта не принимает решение самостоятельно. Большую часть его работы выполняет команда, все его решения принимаются, когда это необходимо, в согласии с командой.
Таким образом, при отсутствии каких-либо иерархических полномочий в отношении людей Владелец продукта оказывает большое влияние на производимый продукт.
4.3 Желательные компетенции
В идеале, у Владельца продукта должны быть разнообразная подготовка и опыт.
Владелец продукта не обязан быть провидцем, как Стив Джобс. Но в отношении продукта ему стоит быть дальновидным. Уже в самом начале разработки у него должна быть концепция, которая в дальнейшем будет обрастать деталями и закрепляться.
Обычно эта концепция состоит из:
✓ причины, по которой создается продукт или услуга,
✓ цели следующей версии,
✓ ожидаемого влияния на заинтересованные стороны,
✓ списка основных функций, которые этому способствуют.
Все участники команды и заинтересованные стороны должны придерживаться одной концепции, ответственность за это лежит на Владельце продукта. Поэтому лучше всего строить концепцию вместе с заинтересованными сторонами, приглашая их к участию в собраниях и играх.
Знание бизнеса и основных рабочих процессов (core business) напрямую связано со знанием рынка и пользователей продукта.
Хорошее знание бизнеса имеет основополагающее значение для Владельца продукта: внутри команды он представляет всех людей, которые будут использовать продукт.
Владелец продукта может владеть этой компетенцией, поскольку сам является пользователем. Такая ситуация часто бывает в компаниях, разрабатывающих продукты для внутреннего использования. В компаниях, производящих продукты для внешних клиентов, Владелец продукта зачастую приходит из команды маркетологов или менеджеров продукта.
Владелец продукта не обязан знать все о функциональности продукта: в крупных проектах это может быть затруднительно или требовать больших временных затрат.
Чтобы в полной мере выполнять возложенные на него функции, Владелец продукта всегда может обратиться к определенным людям, которые также вносят свой вклад и заинтересованы в результатах команды. Если он сам не разбирается в чем-то, он знает тех, кто разбирается. Его задача – создавать и поддерживать хорошие отношения с этими людьми.
Во время работы над проектом часто возникает ситуация, когда в вопросах различной важности приходится делать выбор. По соображениям эффективности Владелец продукта должен иметь возможность делать это самостоятельно, не обращаясь к иерархии или начальству. Важно, чтобы он пользовался доверием заинтересованных сторон и команды.
Он консультируется с заинтересованными сторонами по важным вопросам. Если мнения не совпадают, у Владельца продукта есть полномочия принять окончательное решение.
Решать – значит выбирать и уметь отказать заинтересованным сторонам.
Как только выбор касательно содержания продукта сделан, PO гарантирует, что все члены команды с ним согласны.
В компаниях принятие решений часто осуществляется на уровне комитетов. Это прямая дорога к развитию конфликтов на почве противоречия интересов, затянувшихся решений, трудностей в расстановке приоритетов.
Рисунок 4.3 – Комитет к концу собрания
Чтобы избежать таких ситуаций, Scrum рекомендует иметь только одного человека на этой роли. Как говорится в «Руководстве по Scrum»:
Роль Владельца продукта осуществляется только одним человеком, а не группой людей.
Поэтому принятие решений Владельцем продукта не является ни авторитарным, ни согласованным. Оно основано на запрашивании мнений. Чем важнее решение, тем больше мнений должно быть на этот счет.
При Agile-подходе спецификации не детализируются с самого начала разработки. Владелец продукта знает – в зависимости от прогресса – в какой момент элементы бэклога требуют более детальной проработки.
Он умеет предвосхищать, расставлять приоритеты среди элементов бэклога: что имеет наивысший приоритет, должно быть сделано в первую очередь.
Владелец продукта знает, когда нужно детализировать содержание бэклога.
Главный инструмент Владельца продукта – бэклог – живет и развивается на протяжении всего проекта. В этом принципиальное отличие от практик, внедренных в традиционную организационную культуру, где четкие спецификации установлены уже в самом начале работы над проектом.
Владелец продукта запрашивает и учитывает обратную связь после каждой поставки версии продукта заинтересованным сторонам. Корректировка плана и обновление бэклога в соответствии с этой обратной связью – доказательство его открытости для изменений.
Готовность к переменам не подразумевает право Владельца продукта постоянно менять свою точку зрения. Он придерживается установленного курса: его видение во время сезона принципиально не меняется. Открытый к переменам, Владелец продукта, тем не менее, не должен метаться.
РО расставляет приоритеты таким образом, чтобы максимизировать ценность продукта. Но это не единственный параметр, который следует принимать во внимание. В частности, в начале сезона появляются технические риски, а затем и технический долг. Диалог с командой необходим для взвешивания критериев отбора при установлении приоритетов.
Во время оценочных сессий с командой Владелец продукта демонстрирует преподавательские способности, объясняя, что он предлагает добавить в продукт. И слушает мнение команды!
Владелец продукта часто общается с командой, консультируется с участниками и объясняет свою позицию.