Kitabı oxu: «Управление продуктом в Scrum. Agile-методы для вашего бизнеса», səhifə 3

Моделирование роли владельца продукта

Прежде чем рассказать о методах работы владельца продукта в крупных scrum-проектах, хочу дать совет: избегайте больших проектов! Начинайте с малого и быстро разрабатывайте продукт с минимальной функциональностью. Об этом пойдет речь в главе 2. Если приходится заниматься крупным проектом, увеличивайте объемы медленно. Пусть он растет естественным образом, прибавляя по одной команде за раз. Если работу начинает слишком большое число людей, то проект может стать чересчур сложным, так что последующие обновления потребуют массу времени и денег¹⁰.

Главный владелец продукта

В крупных scrum-проектах принимает участие несколько небольших команд. Каждой из них требуется владелец продукта, но в одиночку он может заниматься лишь ограниченным количеством команд. Сколько команд может быть доверено одному владельцу продукта без сверхурочной работы и пренебрежения своими обязанностями, – зависит от ряда факторов. Среди них новизна и сложность продукта, а также знание предмета командами. Обычно владельцу продукта удается плодотворно работать не больше чем с двумя командами. Если их больше, то должны сотрудничать несколько владельцев продукта. Возникает противоречие: владелец продукта – это один человек, но для крупного scrum-проекта их нужно несколько. Поэтому необходимо назначить ответственного за создание и внедрение концепции продукта. Таким образом, вводится иерархия сотрудничающих владельцев продукта, один из которых – главный. Такая же система существует в ресторанах, где есть несколько шеф-поваров во главе с главным шеф-поваром¹¹.

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

Иерархия владельцев продукта

Иерархия варьирует от небольшой команды владельцев продукта с главным владельцем до сложной структуры, состоящей из нескольких уровней сотрудничающих владельцев продукта. Рассмотрим оба варианта, начав с наиболее простого.

Организация проекта, изображенная на рисунке 1.2, состоит из трех команд и трех владельцев продукта. Каждый владелец продукта отвечает за свою команду. В свою очередь, владельцы продукта тоже формируют команду, и владелец продукта В выступает в роли главного. Эта иерархия считается горизонтальной, несмотря на наличие главного владельца. Приведу пример, как можно применить такую организацию проекта: клиент нанимает команду владельца продукта, отвечающую за веб-портал и его приложения. Четыре владельца продукта и главный владелец продукта тесно сотрудничают, при этом каждый отвечает за конкретное предложение, а главный владелец продукта – за весь продукт, включающий в себя все приложения и портал.

Рисунок 1.2. Простая иерархия владельцев продукта

На рисунке 1.3 представлен другой вариант, подходящий для больших scrum-проектов и заимствованный из книги Кена Швабера (Schwaber, 2007; 70–73).

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

Рисунок 1.3. Сложная иерархия владельцев продукта

Сложная иерархия владельцев продукта предполагает специализацию деятельности каждого из них. Главный владелец продукта возглавляет общую разработку, координируя свою деятельность с клиентами и другими заинтересованными лицами. Владельцы продукта более низкого уровня сосредоточены на своих функциях или подсистемах и тесно сотрудничают с командами разработчиков. Швабер (Schwaber, 2007; 72) отмечает:

Владелец продукта планирует, расписывает, распределяет и отслеживает работу со своего уровня вниз… Чем выше его уровень, тем сложнее работа. Объем ответственности владельца продукта высшего уровня обычно предполагает, что им становится должностное лицо не ниже вице-президента или CEO.

Как правильно выбрать владельцев продукта

Найти подходящего человека на роль владельца продукта непросто, даже когда нужен только один такой кандидат. По каким же критериям выбирать правильных владельцев продукта для больших проектов? Ответ на этот вопрос дает понимание разных способов организации команд в большом проекте. Существует всего два варианта: функциональные команды и компонентные команды (Pichler, 2008; Larman and Vodde, 2009). Функциональная команда внедряет сквозной набор требований – например, одну или несколько тем или функций. В результате появляется сквозной вертикальный срез, который проходит через основные части программной архитектуры. Компонентная команда выдает компонент или подсистему.

Эти два варианта ортогональны друг другу: функциональные команды организуются вокруг бэклога продукта, а компонентные – вокруг программной архитектуры. У обоих есть свои преимущества и недостатки. Например, компонентные команды обеспечивают целостность архитектуры и многократное использование кода. К сожалению, они часто не могут воспользоваться бэклогом продукта, оформленным в виде пользовательских историй или сценариев использования, а нуждаются в детально прописанных технических требованиях. Кроме того, им приходится для создания обновления продукта интегрировать результаты своей работы. Эти свойства ведут к непроизводительным издержкам. Напротив, функциональные команды обычно могут работать параллельно друг другу. У них меньше проблем с интеграцией, и им достаточно требований, указанных в обычном списке. Однако обеспечение архитектурной целостности и многократное использование кода не всегда возможны. Обычно организации применяют функциональные команды, а компонентные привлекают только при необходимости.

Поскольку владелец продукта компонентной команды должен помогать переводить элементы бэклога продукта в технические требования, то лучший кандидат на эту роль не менеджер продукта, а архитектор или старший разработчик. Если проект состоит, например, из трех функциональных команд и одной компонентной, то на должности владельцев проекта стоит пригласить трех менеджеров продукта и одного архитектора. При этом предполагается, что один из владельцев продукта будет главным владельцем продукта.

Распространенные ошибки

Введение роли владельца продукта для многих организаций означает вход на новую для них территорию. И путь к эффективному использованию этой должности полон опасностей и ловушек. Данный раздел поможет избежать некоторых наиболее распространенных ошибок.

Владелец продукта с недостаточными полномочиями

Проект, в котором владелец продукта не обладает достаточными полномочиями, похож на автомобиль с маломощным двигателем: он, конечно, едет, но с увеличением скорости возникнут проблемы. Владельцу продукта с недостаточными полномочиями не хватает власти. Причин может быть несколько: ему мало внимания уделяет руководство, поддержка поступает не с того уровня или не от того человека, руководитель не до конца доверяет владельцу продукта или не может по каким-то причинам делегировать ему полномочия по принятию решений. В результате владелец продукта прикладывает для эффективной работы – например, для объединения scrum-команды, заинтересованных лиц и клиентов или для исключения требований из релиза – слишком большие усилия. Так, владелец продукта в проекте по разработке одного нового продукта вынужден был при принятии любого серьезного решения советоваться с руководителем бизнес-отдела. Неудивительно, что это приводило к задержкам и подрывало веру команды в своего лидера. Полномочия владельца продукта должны быть достаточными, к тому же он должен пользоваться необходимой поддержкой и доверием.

Перегруженность владельца продукта

Перегрузка на работе пагубно отражается на здоровье и моральном состоянии любого человека. А перегруженные владельцы продукта часто оказываются слабым звеном, ограничивающим прогресс проекта. Симптомы перегрузки владельца продукта – это недостаточная работа над бэклогом продукта, пропуски планирования спринтов или обзорных совещаний, невозможность задать им вопрос и слишком длительное время, требующееся для ответов. Перегруженные владельцы продукта не соответствуют идее agile-манифеста о постоянном темпе. «Agile-процессы подразумевают равномерное развитие. Заказчики, разработчики и пользователи должны постоянно поддерживать один и тот же темп» (Beck et al., 2001).

Перегруженность владельца продукта наступает вследствие двух основных причин: нехватки времени на исполнение своих обязанностей и недостатка поддержки со стороны команды. Доступность владельца продукта оказывается под угрозой, если эта роль – лишь одна из нескольких задач, которые он вынужден выполнять, или если ему приходится следить за большим количеством продуктов и командами. Недостаток поддержки со стороны команды – результат неправильного понимания роли владельца продукта. Хотя он один, большая часть его работы требует коллективного труда. Команда и scrum-мастер должны поддерживать владельца продукта.

Чтобы не перегружать владельца продукта, попробуйте для начала освободить этого человека от всех остальных обязанностей. Ведь он занимается постоянной работой и может отвечать только за один продукт и одну команду. Кроме того, убедитесь, что команда в каждом спринте находит время для сотрудничества с владельцем продукта. Scrum отводит для этого до 10 % действий команды (Schwaber, 2007). Такое сотрудничество не только позволяет более равномерно распределить бремя нагрузки, но и дает возможность использовать коллективное мышление и творческий импульс всей команды.

Частичный владелец продукта

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

Нужно не расщеплять роль владельца продукта, а правильно ее использовать. За тактические и стратегические вопросы управления продуктом должен отвечать один человек. Это может потребовать перемен в организации – например, адаптации служебных обязанностей и путей карьерного роста, увеличения спектра обязанностей отдельных сотрудников, о чем пойдет речь в главе 6.

Удаленный владелец продукта

Удаленный владелец продукта работает отдельно от команды. Слово «удаленный», возможно, вызывает представление, что владелец продукта находится на одном континенте, а команда – на другом. На самом деле удаленность имеет самые разные формы и степени. Так называют и ситуации, когда владелец продукта работает с командой в одном здании, но в разных помещениях, и случаи, когда они находятся на разных континентах и в различных часовых поясах (Simons, 2004). Проблемы, связанные с удаленными владельцами, повсюду одинаковы: недостаток доверия, недопонимание, отсутствие единства и медленный темп работы. И причина понятна: «Самый экономичный и эффективный способ передачи информации команде разработчиков – это личная беседа» (Beck et al., 2001).

Избегайте удаленных владельцев продукта, размещайте всех членов scrum-команды рядом. Как уже говорилось, компания mobile.de резко повысила производительность и боевой настрой, когда владелец продукта, scrum-мастер и команда стали работать в одном помещении. Если это невозможно, то владелец продукта должен проводить как можно больше времени в том же помещении, что и остальная scrum-команда. Удаленным владельцам продукта нужно присутствовать хотя бы при планировании спринтов, на обзорных и ретроспективных совещаниях. Переход от удаленного к присутствующему владельцу продукта нередко требует времени. Иногда это связано с приемом на работу и обучением местного владельца продукта. В некоторых случаях требуется даже переосмысление стратегии продукта компании и изменение места его производства.