Текст книги "Управление продуктом в Scrum. Agile-методы для вашего бизнеса"

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

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

Владелец продукта в PatientKeeper

Джефф Сазерленд, один из создателей Scrum и бывший технический директор компании PatientKeeper, ведущего производителя интегрированных информационных систем в области здравоохранения, разъясняет необходимую квалификацию и полномочия владельцев продукта в этой компании:

[Владелец продукта] должен быть экспертом в своей отрасли, работать хотя бы пару дней в неделю как врач в одной из ведущих больниц Бостона… техническим специалистом, уже написавшим несколько приложений… экспертом в анализе пользовательских историй, сценариев использования и программных спецификаций, особенно в области здравоохранения… уметь находить общий язык с клиентами и отделом продаж, выяснять требования и набирать специалистов-медиков для тестирования прототипов с новой функциональностью… и при этом вести бизнес, заниматься выручкой, отношениями с клиентами и специалистами по продажам в части, касающейся функционала, создавать пользовательские истории и все дополнительные спецификации продукта, в том числе анализировать ожидания клиента. [Наши владельцы продукта] получают помощь только от разработчиков и членов своей команды. Первые два назначенных специалиста с задачей не справились. Но постоянное обучение, наставничество и верно выбранный сотрудник дали нужные результаты[6]6
  Из письма Джеффа Сазерленда на рассылку scrum-тренеров Yahoo! от 2 октября 2008 года и из личного сообщения Джеффа Сазерленда от 16 декабря 2008 года.


[Закрыть].

Работа с командой

Владелец продукта – это такой же член scrum-команды, как и все остальные, он должен полагаться на сотрудничество с ней и со scrum-мастером. Команда представляет собой многофункциональную, самоорганизующуюся и при этом небольшую группу специалистов. В ней должны быть представлены все роли, необходимые для создания продукта. Члены scrum-команды работают в атмосфере доверия и сотрудничества, как равноправные коллеги. Исключается разделение людей на «мы и они». Должно присутствовать только понятие «мы».

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

Поскольку владелец продукта, scrum-мастер и команда должны постоянно и тесно сотрудничать, желательно разместить всех членов scrum-команды в одном помещении. Рассмотрим пример mobile.de. То, что владельцы продукта, scrum-мастер и команда находились в одном помещении, повысило производительность и боевой настрой команды[7]7
  Личное сообщение Филиппа Мисслера, CTO компании mobile.de, 22 июня 2009 года.


[Закрыть]. Если владелец продукта не имеет возможности постоянно находиться вместе с командой, он должен регулярно встречаться с ее членами. Владельцы продукта, работающие удаленно, могут приходить в офис и оставаться вместе с командой на протяжении нескольких дней при каждом спринте. Если владельцы находятся в том же комплексе, но располагаются далеко от команды, я рекомендую им выполнять «правило одного часа»: проводить как минимум час в день в помещении, где трудится команда.

Атмосфера в помещении, где работает команда, должна стимулировать творческий процесс, который включает взаимодействие и ощущение радости от работы, содержит ключевые маркеры информации (формулировку концепции, наиболее приоритетные элементы бэклога продукта, диаграмму архитектуры ПО, задания текущего спринта, график хода релиза и спринта). Лучшие рабочие помещения – те, где созданы условия для сочетания командной работы, личного пространства и деятельности небольших групп в комнатах отдыха.

Взаимодействие со scrum-мастером

Чтобы постоянно играть на высшем уровне, спортивной команде необходим тренер, а scrum-команде – scrum-мастер[8]8
  Например, у профессиональных регбистов есть несколько тренеров: по атакам, защите, схваткам, ударам, тренеры форвардов, а также главный тренер.


[Закрыть]. Он оказывает поддержку владельцу продукта и команде, защищает ее и процесс работы и при необходимости вмешивается, чтобы удостовериться, справляется ли команда с задачей, сохраняет ли здоровую атмосферу и мотивацию и не создает ли технического долга[9]9
  О техническом долге и оптимальном темпе работы подробно говорится в главах 4 и 5.


[Закрыть].

Роли владельца продукта и scrum-мастера дополняют друг друга. Владелец продукта в первую очередь отвечает за создание нужного продукта. Scrum-мастер в основном несет ответственность за то, «как» правильно использовать практики Scrum. Эти два аспекта проиллюстрированы на рисунке 1.1. Долгосрочный успех достигается, когда правильный продукт создается правильными методами.

Рисунок 1.1. Создание правильного продукта правильными методами

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

Работа с клиентами, пользователями и другими заинтересованными лицами

Клиент – это тот, кто приобретает продукт, а пользователь – человек, применяющий продукт. Они определяют его успех или неудачу. Продукт будет востребован на рынке, только если достаточное количество клиентов купят его, а пользователи сочтут выгодным приобретением. Заметьте, что клиент и пользователь могут не совпадать, а их потребности – различаться. Рассмотрим в качестве примера электронные таблицы. Пользователи особенно ценят простоту их применения и высокую производительность. В свою очередь, компания, приобретающая продукт, заинтересована в разумной стоимости использования и безопасности данных.

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

Предоставляя клиентам отзывы о прототипах, приглашая их представителей на рабочие совещания во время спринтов, выпуская быстрые и частые релизы ПО, команда сумеет многому научиться у клиентов. Продукт – это всего лишь средство, конечная цель – помочь покупателю и принести пользу компании-разработчику. Приведем известное высказывание Теодора Левитта по этому поводу: «Человеку, который покупает дрель, нужна не сама дрель, а отверстия в стене». Только сосредоточившись на нуждах покупателя, можно разработать оптимальное решение.

Помимо клиентов и пользователей производители продукта должны привлекать и других заинтересованных лиц – например, представителей служб маркетинга, продаж и клиентского обслуживания. Их с самого начала следует приглашать на рабочие совещания во время спринтов. Эти встречи позволят заинтересованным лицам увидеть, как создается продукт, наладить контакт со scrum-командой и обменяться мнениями. Брайсон (Bryson, 2004) предлагает обзор методов выявления заинтересованных лиц, анализа их требований и работы с ними.

Менеджеры по продуктовому маркетингу и менеджеры продукта

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

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

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

Прежде чем рассказать о методах работы владельца продукта в крупных scrum-проектах, хочу дать совет: избегайте больших проектов! Начинайте с малого и быстро разрабатывайте продукт с минимальной функциональностью. Об этом пойдет речь в главе 2. Если приходится заниматься крупным проектом, увеличивайте объемы медленно. Пусть он растет естественным образом, прибавляя по одной команде за раз. Если работу начинает слишком большое число людей, то проект может стать чересчур сложным, так что последующие обновления потребуют массу времени и денег[10]10
  Эта идея излагается в законе Конвея (Conway, 1968). Он гласит, что структура организации, разрабатывающей продукт, часто влияет на архитектуру самого продукта. Например, если в проекте участвуют три команды, то архитектура нередко будет состоять из трех основных подсистем.


[Закрыть].

В крупных scrum-проектах принимает участие несколько небольших команд. Каждой из них требуется владелец продукта, но в одиночку он может заниматься лишь ограниченным количеством команд. Сколько команд может быть доверено одному владельцу продукта без сверхурочной работы и пренебрежения своими обязанностями, – зависит от ряда факторов. Среди них новизна и сложность продукта, а также знание предмета командами. Обычно владельцу продукта удается плодотворно работать не больше чем с двумя командами. Если их больше, то должны сотрудничать несколько владельцев продукта. Возникает противоречие: владелец продукта – это один человек, но для крупного scrum-проекта их нужно несколько. Поэтому необходимо назначить ответственного за создание и внедрение концепции продукта. Таким образом, вводится иерархия сотрудничающих владельцев продукта, один из которых – главный. Такая же система существует в ресторанах, где есть несколько шеф-поваров во главе с главным шеф-поваром[11]11
  Владелец продукта верхнего уровня не всегда именуется главным владельцем продукта. Швабер использует термин владелец общего продукта (Schwaber, 2007); Ларман и Водде называют главного владельца продукта просто владельцем продукта (Larman & Vodde, 2009).


[Закрыть].

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

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

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

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

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

Организация проекта, частично изображенная на рисунке 1.3, состоит из четырех уровней и девяти владельцев продукта[12]12
  Кен Швабер (Schwaber, 2007; 71) предлагает каждому владельцу продукта стать частью интегрированной scrum-команды, в которую входят также scrum-мастер и команда. Каждая интегрированная scrum-команда поддерживает команды более низкого уровня. Так, на рисунке 1.3 интегрированная scrum-команда «Игры» поддерживает scrum-команды «Тетрис» и «Шахматы».


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

Рисунок 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-команда. Удаленным владельцам продукта нужно присутствовать хотя бы при планировании спринтов, на обзорных и ретроспективных совещаниях. Переход от удаленного к присутствующему владельцу продукта нередко требует времени. Иногда это связано с приемом на работу и обучением местного владельца продукта. В некоторых случаях требуется даже переосмысление стратегии продукта компании и изменение места его производства.

Заместитель владельца продукта

Заместитель владельца продукта – это человек, который временно занимает место настоящего владельца. Мне доводилось видеть, как работают заместители слишком загруженных, частичных или удаленных владельцев продукта. Один вице-президент по управлению продуктом получил предложение занять должность владельца продукта, критичного для развития бизнеса. Хотя он идеально подходил для этой работы, ему с трудом удавалось проводить достаточно времени с командой. В результате бизнес-аналитику команды пришлось выступать в роли заместителя, когда настоящий владелец продукта не мог присутствовать. Он делал большую часть работы владельца, не имея соответствующих полномочий. Сам же владелец продукта принимал окончательные решения о приоритетах в бэклоге продукта, при планировании релизов, приеме результатов работы. В итоге увеличилось количество конфликтов, решения принимались медленнее, уменьшилась производительность и упал командный дух.

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

Комитет владельцев продукта

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