Рисунок 4.3 – Комитет к концу собрания
Чтобы избежать таких ситуаций, Scrum рекомендует иметь только одного человека на этой роли. Как говорится в «Руководстве по Scrum»:
Роль Владельца продукта осуществляется только одним человеком, а не группой людей.
Поэтому принятие решений Владельцем продукта не является ни авторитарным, ни согласованным. Оно основано на запрашивании мнений. Чем важнее решение, тем больше мнений должно быть на этот счет.
При Agile-подходе спецификации не детализируются с самого начала разработки. Владелец продукта знает – в зависимости от прогресса – в какой момент элементы бэклога требуют более детальной проработки.
Он умеет предвосхищать, расставлять приоритеты среди элементов бэклога: что имеет наивысший приоритет, должно быть сделано в первую очередь.
Владелец продукта знает, когда нужно детализировать содержание бэклога.
Главный инструмент Владельца продукта – бэклог – живет и развивается на протяжении всего проекта. В этом принципиальное отличие от практик, внедренных в традиционную организационную культуру, где четкие спецификации установлены уже в самом начале работы над проектом.
Владелец продукта запрашивает и учитывает обратную связь после каждой поставки версии продукта заинтересованным сторонам. Корректировка плана и обновление бэклога в соответствии с этой обратной связью – доказательство его открытости для изменений.
Готовность к переменам не подразумевает право Владельца продукта постоянно менять свою точку зрения. Он придерживается установленного курса: его видение во время сезона принципиально не меняется. Открытый к переменам, Владелец продукта, тем не менее, не должен метаться.
РО расставляет приоритеты таким образом, чтобы максимизировать ценность продукта. Но это не единственный параметр, который следует принимать во внимание. В частности, в начале сезона появляются технические риски, а затем и технический долг. Диалог с командой необходим для взвешивания критериев отбора при установлении приоритетов.
Во время оценочных сессий с командой Владелец продукта демонстрирует преподавательские способности, объясняя, что он предлагает добавить в продукт. И слушает мнение команды!
Владелец продукта часто общается с командой, консультируется с участниками и объясняет свою позицию.
В задачи Владельца продукта входит определение того, что же делает продукт. Нужно владеть приемами сбора потребностей и внедрения их в бэклог.
Scrum не предлагает какой-либо конкретный метод определения элементов бэклога, но наиболее частая практика – пользовательские истории.
Рисунок 4.4 – PO практикует паттерн историй
4.4 Выбор владельца продукта
По мере формирования Scrum-команды необходимо найти подходящего человека на эту роль. Организации совершенно не похожи друг на друга, возможности выбора очень разнообразны.
Можно опираться на желательные компетенции Владельца продукта, описанные выше. Правда, невозможно найти того, кто бы обладал одновременно всеми этими качествами. Даже если такой человек и существует, не факт, что у него будет достаточно времени для работы в этой роли.
Наличие времени – непременное условие при выборе человека на роль Владельца продукта. В отличие от классических методик ведения проектов, где важно вмешательство клиента (или его представителя) в начале работы и в конце, но не в процессе, здесь участие Владельца продукта является постоянным на всех этапах спринта.
• Постоянная готовность
Предполагается, что работа с командой из пяти и более человек требует участия не менее трех часов в день.
Чем ближе релиз, тем больше времени Владелец продукта должен уделять проекту: расстановка приоритетов становится все труднее, а количество проверок возрастает.
• Участие в Scrum-событиях
Владелец продукта является полноправным членом команды и участвует в собраниях.
На практике это не всегда так. Иногда при выборе Владельца продукта меня спрашивают, сколько минимально нужно времени для осуществления этой роли. Если у потенциального Владельца продукта, помимо нашего проекта, есть и другие задачи (например, является пользователем старой версии продукта), будьте уверены: начнет экономить время, затраченное на этот конкретный проект, в частности, на встречи с командой.