Клод Обри
Все о SCRUM. Изучение, разработка, интеграция
4
Роль Владельца продукта
Было время, когда я работал в компании по разработке программного обеспечения. Занимался маркетингом – ошибиться может каждый – для продукта, который сегодня уже не выпускается. Продукт включал в себя графический редактор, симулятор и генератор кода. Целью была разработка распределенных систем.
Я сам был разработчиком и менеджером проектов в области телекоммуникаций, поэтому хорошо знал потенциальных пользователей продукта. С моей должностью в компании я в некотором роде их представлял.
Но во главе компании стояли технологи. В конечном счете, именно технический директор решил, какие функции добавлять в продукт.
Функции были мощные. Например, исчерпывающее моделирование на основе конечных автоматов. Использовать продукт было непросто, и, на мой взгляд, предлагаемые функции не учитывали потребности пользователей.
Чтобы избежать такой ситуации, в Scrum существует роль Владельца продукта. Она гарантирует, что проделанная работа приносит пользу и нужна пользователям. Наличие Владельца продукта позволяет не допустить, как в моей истории, доминирования техники или начальства при выборе содержания продукта.
Если бы в то время существовала такая роль, я бы хотел стать Владельцем продукта. Прошло много времени, я начал практиковать Scrum, и эту роль мне все же довелось исполнить: в частности, на протяжении долгих лет я являюсь Владельцем продукта iceScrum.
Именно об этой роли и моем опыте будет эта глава.
4.1 Product что?
Но начнем с терминологии.
Впервые я прочитал о Scrum в книгах и статьях на английском языке. Я, разумеется, перевел Product Owner как собственник продукта. Но собственник не отражает распределение и обмен, присущие этой роли.
Рисунок 4.1 – Собственник продукта
В 2005 году я участвовал в тренинге по Scrum. Его вел уроженец Квебека Франсуа [21]. Материал курса был на французском языке. Product Owner, о котором речи тогда было мало, переводился как администратор продукта. Это название так и не прижилось во Франции. Я думаю, наши канадские братья также от него отказались.
В 2006 году, прочитав одну статью, я стал употреблять термин менеджер по продукту. В течение нескольких месяцев упоминал это словосочетание в постах в моем блоге.
Статья о Scrum во французской версии Википедии тоже использовала этот термин, подтверждая успех этого перевода. В переводе книги «Scrum и XP: заметки с передовой» на французский язык также можно встретить менеджера по продукту.
Но я перестал использовать этот термин и вернулся к Product Owner (пробовал даже переиначить на французский лад – productoneur). Слово менеджер не проходило для организаций: тот, кто занимал эту роль, не являлся менеджером по организационной иерархии.
Владелец продукта указывает направление, но у него нет иерархической ответственности за людей.
На данный момент французское сообщество Scrum использует формулировку Product Owner.
Вот мое определение этой роли:
Владелец продукта (Product Owner, PO) – роль, занимаемая участником команды. Владелец продукта несет ответственность за результат продукта перед заинтересованными сторонами.
Слово продукт следует рассматривать в широком смысле как результат того, что проделано командой. Фактически, не имеет значения, разрабатывает ли команда продукт, услугу или приложение: Владелец продукта несет ответственность за результат.
Когда мы будем в дальнейшем говорить о Владельце продукта, мы будем иметь в виду либо человека, либо роль, которую он играет.
4.2 Функции владельца продукта
Владелец продукта влияет одновременно и на стратегию, и на тактику.
✓ Он принимает решения на стратегическом уровне, которые ранее были обязанностью руководителя проекта или руководящих комитетов. Это, например, выбор даты поставки продукта или приоритизация функций для разработки.
✓ Он также принимает много тактических решений, которые ранее, из-за отсутствия специальной роли, принимались командой разработчиков – например, положение элемента на веб-странице или лейбл к нему. По сути, чтобы двигаться вперед, разработчики были вынуждены делать выбор, который в принципе не был их обязанностью.
Роль Владельца продукта разнится от компании к компании. Но у него есть основные обязанности. Перечислим их.
4.2.1 Приоритизация
Владелец продукта определяет порядок, в котором будут разрабатываться компоненты продукта. Он снабжает команду функциональными свойствами, которые необходимо разработать. Стремится максимизировать ценность продукта, расставляет задачи в приоритетном порядке.
Рисунок 4.2 – PO постановляет бэклог
4.2.2 Доработка бэклога
Владелец продукта определяет основные компоненты продукта. Функциональные свойства продукта, полученные от заинтересованных сторон и включенные в список – это бэклог.
На практике это означает, что Владелец продукта занимается ведением бэклога и проводит значительную часть времени за его составлением и поддержанием в ожидании следующих спринтов.
Эта работа выполняется в команде, но Владелец продукта, как правило, проводит за ней больше времени и является главным решающим лицом в случае необходимости.
4.2.3 Планирование деятельности
Владелец продукта отвечает за информирование заинтересованных сторон о предварительных результатах работы команды.
Он предлагает цель спринта, согласовывает ее с командой и публикует: она должна быть известна всем участникам процесса.
Именно Владелец продукта определяет момент ввода в эксплуатацию пользователями.
4.2.4 Обеспечение взаимопонимания в команде
Во время спринта Владелец продукта должен убедиться, что команда разработчиков четко понимает элементы бэклога. Во время разговоров к нему могут обращаться с просьбой принять тактическое решение, поэтому его присутствие в команде имеет важное значение.
Владелец продукта не принимает решение самостоятельно. Большую часть его работы выполняет команда, все его решения принимаются, когда это необходимо, в согласии с командой.
Таким образом, при отсутствии каких-либо иерархических полномочий в отношении людей Владелец продукта оказывает большое влияние на производимый продукт.
4.3 Желательные компетенции
В идеале, у Владельца продукта должны быть разнообразная подготовка и опыт.
4.3.1 Дальновидность
Владелец продукта не обязан быть провидцем, как Стив Джобс. Но в отношении продукта ему стоит быть дальновидным. Уже в самом начале разработки у него должна быть концепция, которая в дальнейшем будет обрастать деталями и закрепляться.
Обычно эта концепция состоит из:
✓ причины, по которой создается продукт или услуга,
✓ цели следующей версии,
✓ ожидаемого влияния на заинтересованные стороны,
✓ списка основных функций, которые этому способствуют.
Все участники команды и заинтересованные стороны должны придерживаться одной концепции, ответственность за это лежит на Владельце продукта. Поэтому лучше всего строить концепцию вместе с заинтересованными сторонами, приглашая их к участию в собраниях и играх.
4.3.2 Знание бизнеса
Знание бизнеса и основных рабочих процессов (core business) напрямую связано со знанием рынка и пользователей продукта.
Хорошее знание бизнеса имеет основополагающее значение для Владельца продукта: внутри команды он представляет всех людей, которые будут использовать продукт.
Владелец продукта может владеть этой компетенцией, поскольку сам является пользователем. Такая ситуация часто бывает в компаниях, разрабатывающих продукты для внутреннего использования. В компаниях, производящих продукты для внешних клиентов, Владелец продукта зачастую приходит из команды маркетологов или менеджеров продукта.
Владелец продукта не обязан знать все о функциональности продукта: в крупных проектах это может быть затруднительно или требовать больших временных затрат.
Чтобы в полной мере выполнять возложенные на него функции, Владелец продукта всегда может обратиться к определенным людям, которые также вносят свой вклад и заинтересованы в результатах команды. Если он сам не разбирается в чем-то, он знает тех, кто разбирается. Его задача – создавать и поддерживать хорошие отношения с этими людьми.
4.3.3 Полномочия в плане быстрого принятия решений
Во время работы над проектом часто возникает ситуация, когда в вопросах различной важности приходится делать выбор. По соображениям эффективности Владелец продукта должен иметь возможность делать это самостоятельно, не обращаясь к иерархии или начальству. Важно, чтобы он пользовался доверием заинтересованных сторон и команды.
Он консультируется с заинтересованными сторонами по важным вопросам. Если мнения не совпадают, у Владельца продукта есть полномочия принять окончательное решение.
Решать – значит выбирать и уметь отказать заинтересованным сторонам.
Как только выбор касательно содержания продукта сделан, PO гарантирует, что все члены команды с ним согласны.
В компаниях принятие решений часто осуществляется на уровне комитетов. Это прямая дорога к развитию конфликтов на почве противоречия интересов, затянувшихся решений, трудностей в расстановке приоритетов.
Рисунок 4.3 – Комитет к концу собрания
Чтобы избежать таких ситуаций, Scrum рекомендует иметь только одного человека на этой роли. Как говорится в «Руководстве по Scrum»:
Роль Владельца продукта осуществляется только одним человеком, а не группой людей.
Поэтому принятие решений Владельцем продукта не является ни авторитарным, ни согласованным. Оно основано на запрашивании мнений. Чем важнее решение, тем больше мнений должно быть на этот счет.
4.3.4 Способность детализировать в нужное время
При Agile-подходе спецификации не детализируются с самого начала разработки. Владелец продукта знает – в зависимости от прогресса – в какой момент элементы бэклога требуют более детальной проработки.
Он умеет предвосхищать, расставлять приоритеты среди элементов бэклога: что имеет наивысший приоритет, должно быть сделано в первую очередь.
Владелец продукта знает, когда нужно детализировать содержание бэклога.
4.3.5 Открытость переменам
Главный инструмент Владельца продукта – бэклог – живет и развивается на протяжении всего проекта. В этом принципиальное отличие от практик, внедренных в традиционную организационную культуру, где четкие спецификации установлены уже в самом начале работы над проектом.
Владелец продукта запрашивает и учитывает обратную связь после каждой поставки версии продукта заинтересованным сторонам. Корректировка плана и обновление бэклога в соответствии с этой обратной связью – доказательство его открытости для изменений.
Готовность к переменам не подразумевает право Владельца продукта постоянно менять свою точку зрения. Он придерживается установленного курса: его видение во время сезона принципиально не меняется. Открытый к переменам, Владелец продукта, тем не менее, не должен метаться.
4.3.6 Навыки ведения переговоров
РО расставляет приоритеты таким образом, чтобы максимизировать ценность продукта. Но это не единственный параметр, который следует принимать во внимание. В частности, в начале сезона появляются технические риски, а затем и технический долг. Диалог с командой необходим для взвешивания критериев отбора при установлении приоритетов.
Во время оценочных сессий с командой Владелец продукта демонстрирует преподавательские способности, объясняя, что он предлагает добавить в продукт. И слушает мнение команды!
Владелец продукта часто общается с командой, консультируется с участниками и объясняет свою позицию.
4.3.7 Владение навыками определения продукта
В задачи Владельца продукта входит определение того, что же делает продукт. Нужно владеть приемами сбора потребностей и внедрения их в бэклог.
Scrum не предлагает какой-либо конкретный метод определения элементов бэклога, но наиболее частая практика – пользовательские истории.
Рисунок 4.4 – PO практикует паттерн историй
4.4 Выбор владельца продукта
По мере формирования Scrum-команды необходимо найти подходящего человека на эту роль. Организации совершенно не похожи друг на друга, возможности выбора очень разнообразны.
Можно опираться на желательные компетенции Владельца продукта, описанные выше. Правда, невозможно найти того, кто бы обладал одновременно всеми этими качествами. Даже если такой человек и существует, не факт, что у него будет достаточно времени для работы в этой роли.
4.4.1 Готовность уделять проекту время
Наличие времени – непременное условие при выборе человека на роль Владельца продукта. В отличие от классических методик ведения проектов, где важно вмешательство клиента (или его представителя) в начале работы и в конце, но не в процессе, здесь участие Владельца продукта является постоянным на всех этапах спринта.
• Постоянная готовность
Предполагается, что работа с командой из пяти и более человек требует участия не менее трех часов в день.
Чем ближе релиз, тем больше времени Владелец продукта должен уделять проекту: расстановка приоритетов становится все труднее, а количество проверок возрастает.
• Участие в Scrum-событиях
Владелец продукта является полноправным членом команды и участвует в собраниях.
На практике это не всегда так. Иногда при выборе Владельца продукта меня спрашивают, сколько минимально нужно времени для осуществления этой роли. Если у потенциального Владельца продукта, помимо нашего проекта, есть и другие задачи (например, является пользователем старой версии продукта), будьте уверены: начнет экономить время, затраченное на этот конкретный проект, в частности, на встречи с командой.
Вот вариант, как Владелец продукта может распределить свое время для участия в Scrum-собраниях проекта с двухнедельными спринтами:
✓ собрание, посвященное планированию спринта: приблизительно два часа;
✓ ежедневный Scrum, минимум дважды в неделю: 60 минут на четыре сессии;
✓ доработка: примерно три часа;
✓ обзор спринта и ретроспектива: по часу на каждый этап.
Получается восемь часов, примерно 10 % его времени.
• Ежедневное участие
Помимо участия в событиях, Владелец продукта также должен:
✓ разрабатывать и поддерживать бэклог, корректировать приоритетные задачи;
✓ отвечать на вопросы о продукте;
✓ определять условия приемки;
✓ выполнять проверки по окончании работы над тем или иным элементом.
4.4.2 Человек с мотивацией
Владелец продукта, недавно приступивший к роли, часто владеет довольно поверхностными знаниями о Scrum и Agility. Он может обратиться за помощью к Scrum-мастеру и поучиться. При выборе человека на эту роль в первую очередь надо убедиться в его приверженности ценностям Agile-движения.
Невозможно стать успешным РО, если у тебя нет мотивации. К счастью, она быстро появляется, потому что роль крайне захватывающая.
4.4.3 Где в организации найти РО?
Владельца продукта надо искать там, где есть контакт с пользователями или их представителями – как правило, вне команды.
Например, в компании по разработке программного обеспечения Владельца продукта можно найти среди маркетологов или менеджеров по продукту – у них могут быть навыки, необходимые для успешного РО.
Именно среди маркетологов и менеджеров по продукту я встретил лучших Владельцев продукта.
В крупных компаниях с внутренними пользователями логично искать Владельца продукта в отделе, где работают пользователи и их представители. Им может стать бизнес-аналитик, помощник владельца проекта или менеджер проекта.
В организациях такого типа я сталкивался с Владельцами продукта, испытывающими трудности на этой роли: им попросту не хватало на нее времени.
В организациях, где для каждого проекта избирается руководитель, при переходе к Scrum Владельцем продукта обычно становится менеджер проекта. В действительности, РО – это лидер (но не руководитель!), который четко видит цели и принимает решения, связанные с продуктом.
4.5 Владелец продукта внутри экосистемы
Владелец продукта входит в Scrum-команду. Но чтобы хорошо играть эту роль, очень важно тесно сотрудничать с людьми в экосистеме.
Рисунок 4.5 – Обмен с Владельцем продукта в зонах экосистемы
4.5.1 Присутствие в команде
Физическое присутствие РО в команде:
✓ В идеале Владелец продукта находится в одном рабочем пространстве с командой. Но вполне достаточно, если он будет находиться рядом – так, чтобы команда могла к нему подойти и попросить разъяснений. И наоборот, чтобы он мог легко встретиться с командой.
✓ Если Владелец продукта не может находиться рядом с командой, осуществление его обязанностей будет несколько затруднительным. Но есть решения, чтобы восполнить недостаток физического присутствия.
Во время спринта важно, чтобы Владелец продукта часто общался с остальной командой. Это касается ежедневного участия в Scrum. Хорошо, если разговор с разработчиками продолжается и после встречи: еще раз убеждаемся, что разрабатываемая функция хорошо понята всеми.
Тесное сотрудничество с разработчиком – отличная возможность узнать о технической стороне историй, над которыми идет работа, поделиться идеями, как улучшить работу.
Рисунок 4.6 – Тесное сотрудничество
4.5.2 Обмен с привилегированными заинтересованными лицами
Это то, что относится к Зоне 3.
Бывает, что РО не имеет достаточных полномочий, чтобы решить, какую из заинтересованных сторон слушать в первую очередь.
Чтобы решить эту проблему, в некоторых организациях роль Владельца продукта делят на две части: Proxy PO и (реальный) PO. Часто встречающийся в связи с этим антипаттерн представлен в конце главы. Scrum 3.0 также предлагает разделить роль PO на две: первый остается в Scrum-команде (его называют Team Captain), а второй (собственно PO) – в контакте с заинтересованными сторонами.
Я считаю, создавать новую роль нет смысла. Рекомендую налаживать обмен с привилегированными заинтересованными сторонами.
Заинтересованная сторона, обладающая властью и легитимностью, становится для Владельца продукта привилегированным собеседником. РО и привилегированный собеседник в общих чертах распределяют задачи по степени важности. Они проводят доработку на высоком уровне и договариваются о стратегии.
С другой стороны, Владелец продукта – единственный, кто разрабатывает тактику для команды и детально приоритизирует задачи. В ином случае существует риск возникновения конфликтов и противоречий.
Команде нужен только один собеседник. Это Владелец продукта.
4.5.3 Обмен с заинтересованными лицами и пользователями
Результат работы команды предназначен для людей – конечных пользователей. Владелец продукта ориентируется на них, когда направляет команду на пути к продукту (в зависимости от контекста конечные пользователи будут в Зоне 4 или в Зоне 5).
Поэтому важно, чтобы он регулярно с ними виделся и наблюдал за ними на их рабочем месте.
4.5.4 Обмен в границах экосистемы
Это то, что входит в Зону 5.
✓ Для обмена опытом Владельцу продукта рекомендуется посещать конференции, посвященные этой роли и новым тенденциям, подходам.
✓ В рамках своей организации он может присоединиться к сообществу РО для обмена практиками или, если такого сообщества нет, создать его.
4.6 Обычный день владельца продукта
Селина выполняет роль Владельца продукта для команды Peetic.
4.6.1 Сотрудничество с командой
Как Владелец продукта, Селина не просто представляет для команды клиентов и пользователей, но сама активно участвует в работе команды в течение всего спринта.
Селина учится слушать и слышать. Она понимает озабоченность участников по поводу сроков и качества, поэтому не давит на них и не подталкивает к предоставлению все большего и большего количества функций.
4.6.2 Определение условий приемки
Она определяет, что должен делать продукт. Селина устанавливает критерии приемки – условия, которые позволят ей убедиться, что работа над тем или иным элементом окончена.
На этапе доработки Селина сформулировала для команды свое видение функции продукта. Вместе с участниками команды она определила условия приемки, которые помогут удостовериться, что результат работы соответствует требованиям.
4.6.3 Использование продукта
Селина любит свой продукт. Она использует его каждый день, это вдохновляет ее дальше его совершенствовать. Селина видит, как новые функции добавляют продукту ценность. Знание продукта хорошо сказывается на репутации Селины и помогает ей в принятии решений.
В ее задачу входит представление продукта пользователям. Она пользуется этой возможностью, чтобы проверить гипотезы о новшествах, которые она планирует включить в продукт.
4.6.4 Вовлечение заинтересованных сторон
Селина отвечает за результаты перед заинтересованными сторонами. Чтобы хорошо выполнять свою роль, она должна поддерживать с ними связь.
Это касается не только конечных пользователей продукта, но еще ветеринаров и основателей – Жиля и Моны. Селина приглашает их на обзоры после каждого спринта, привлекает их к активному участию, потому что во время обзора проверяется состояние продукта.