Все о SCRUM. Изучение, разработка, интеграция

Получается восемь часов, примерно 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 Обмен с заинтересованными лицами и пользователями