1
КТО ТАКОЙ ВЛАДЕЛЕЦ ПРОДУКТА?
Однажды я работал над продуктом в области здравоохранения. Эта система должна была создавать больше ценностей для потребителей и обеспечить существенное преимущество над конкурентами. Через два с лишним года новый продукт был наконец запущен, на него возлагались большие надежды, но все обернулось провалом.
Что же произошло? Где-то по дороге между идеей и запуском концепция заблудилась. Маркетологи провели исследование рынка, сформулировали концепцию продукта и передали ее менеджеру продукта. Он написал спецификацию и вручил менеджеру проекта, который передал ее в разработку. Не нашлось никого, кто бы отвечал за создание успешного продукта, не существовало общего видения продукта и его функциональности. У всех были собственные подходы, своя концепция.
Как разрешить ситуацию? На всех этапах за продукт должен отвечать один человек — владелец продукта. Эта глава рассказывает о его полномочиях и обязанностях, а также о том, как правильно вести себя в этой роли.
РОЛЬ ВЛАДЕЛЬЦА ПРОДУКТА
В Scrum Guide Кен Швабер пишет о владельце продукта:
Владелец продукта — единственный человек, отвечающий за список требований к продукту и ответственный за результат работы команды. Этот человек составляет бэклог продукта и обеспечивает его доступность для всех членов команды.
Определение звучит вполне безобидно, пока мы не начнем оценивать его последствия. Владелец продукта возглавляет усилия разработчиков по созданию продукта, благодаря которому появляются желаемые преимущества. Это часто подразумевает формулирование концепции продукта, работу с бэклогом продукта, планирование релиза, привлечение клиентов, пользователей и других заинтересованных лиц, управление бюджетом, подготовку запуска продукта, посещение scrum-митингов и сотрудничество с командой. Владелец продукта играет ключевую роль не только в создании новых продуктов, но и в поддержании жизненного цикла продукта. Назначение одного человека ответственным за релизы обеспечивает их непрерывность и снижает количество передаточных звеньев, а также поощряет долгосрочное планирование. Исследование в SAP AG выявило и другие преимущества: сотрудники, работающие владельцами продукта, чувствовали себя уверенно, понимали степень своего влияния и то, что они на виду, были наиболее организованными и мотивированными для новой роли.
Но владелец продукта — это прежде всего член scrum-команды, он тесно сотрудничает с коллегами. Scrum-мастер и команда помогают владельцу продукта, совместно работая над бэклогом продукта, а владелец продукта отвечает за успех необходимых мероприятий.
Велик соблазн сравнить роль владельца продукта с традиционными ролями — менеджером продукта или руководителем проекта. Но любое сравнение будет неточным. Владелец продукта — это новая многогранная роль, которая объединяет власть и ответственность, традиционно распределявшиеся в руках разных людей, в том числе клиента, спонсора, менеджера продукта и руководителя проекта.
Конкретные задачи владельца продукта зависят от контекста: в частности, от типа продукта, стадии его жизненного цикла и размера проекта. Например, владельцу продукта, который состоит из программного обеспечения, аппаратного обеспечения и механических устройств, потребуются совершенно иные компетенции, чем человеку, возглавляющему работу по созданию веб-приложения. А владелец продукта, участвующий в большом scrum-проекте, должен иметь иные навыки, чем человек, сотрудничающий с одной-двумя командами.
В коммерческих проектах владелец продукта — обычно представитель клиента: менеджер продукта или маркетолог. Сам клиент принимает на себя эту роль, если продукт разрабатывается для конкретной организации. Например, это может быть внешний клиент, которому необходимо новое решение для хранилища данных, или внутренний клиент (в частности, отдел маркетинга), запрашивающий обновление сайта. Мне доводилось работать с клиентами, пользователями, менеджерами бизнес-направлений, менеджерами продуктов, руководителями проектов, бизнес-аналитиками и архитекторами, которые хорошо подходили на роль владельца продукта в конкретных обстоятельствах. Владельцем продукта может стать даже CEO. Например, Ript — визуальный планировщик, позволяющий пользователям копировать и вставлять изображения и тексты из одного приложения в другое, — это плод усилий Джерри Лейборна, CEO компании Oxygen Media, который взял на себя роль владельца продукта для первого релиза программы.
ХАРАКТЕРИСТИКИ ПРАВИЛЬНОГО ВЛАДЕЛЬЦА ПРОДУКТА
Выбор правильного владельца продукта необходим в любом scrum-проекте. Успешные владельцы продукта, с которыми я работал, обладали некоторыми общими чертами. Поскольку владелец продукта — это новая роль, людям часто требуются время и поддержка, чтобы приспособиться к ней и приобрести необходимые навыки. Основная проблема — найти сотрудников с приемлемым уровнем знаний и опыта, которые смогут хорошо выполнить задачу. (Переход к роли владельца продукта и самосовершенствование в этой должности описаны в главе 6.)
ВИЗИОНЕР И ЧЕЛОВЕК ДЕЙСТВИЯ
Писатель Джонатан Свифт заметил: «Видение — это искусство видеть невидимое». Владелец продукта — это визионер, который может представить себе конечный продукт и поделиться этим видением с другими. Но владелец продукта — это и человек действия, способный оценить трудоемкость всех этапов работы вплоть до ее завершения. Он может описывать требования, тесно сотрудничать с командой, принимать или отвергать рабочие результаты и руководить проектом, отслеживая и предсказывая его прогресс. Как предприниматель владелец продукта поощряет творческое мышление и инновации, уверенно чувствует себя в меняющихся условиях, обстановке неопределенности, спорах, конфликтах, он ценит и понимает юмор, поощряет эксперимент и обдуманный риск.
ЛИДЕР И КОМАНДНЫЙ ИГРОК
«Хорошие бизнес-лидеры создают концепцию, формулируют концепцию, страстно ее отстаивают и неумолимо ведут к завершению», — говорит Джек Уэлч, бывший председатель совета директоров и CEO компании General Electric. Владелец продукта — именно такой лидер. Отвечая за успех продукта, он обеспечивает руководство всеми, кто занят разработкой, и готов принимать сложные решения. Например, укажет, отложить дату запуска или ограничиться меньшей функциональностью. В то же время владелец продукта — командный игрок, он вступает в тесное сотрудничество с другими членами scrum-команды и не обладает формальной властью над ними. Мы можем определить владельца продукта как primus inter pares — первого среди равных в том, что касается продукта.
Двойственная природа владельца продукта (как лидера и командного игрока) накладывает свои ограничения. Он ни в коем случае не должен быть диктатором, но в то же время не может себе позволить нерешительности и мягкотелости в управлении.
Владелец продукта — это своего рода пастырь инновационного процесса, он направляет проект и стремится к согласию с командой при принятии решений. Совместное принятие решений обеспечивает общую вовлеченность, задействует знания и творческий импульс команды и в итоге дает лучшие результаты. Подобный метод работы требует терпения, поскольку члены команды поначалу часто спорят и лишь затем из различных идей формируется новое решение. Кейнер приводит в своей работе полезные сведения о коллективном принятии решений и связанных с ним методах координации (Kaner, 1996).
КОМАНДА ПРЕДПРИНИМАТЕЛЕЙ
Порой мы излишне концентрируемся на знаменитых предпринимателях и лидерах — Билле Гейтсе, Стиве Джобсе и других. На самом деле лишь немногие инновации — это действительно результат гениальности одного человека. И даже если владелец продукта — ходячая инновация, ему все равно требуется команда для воплощения идеи в жизнь. Ни один даже самый выдающийся предприниматель не сможет сам принять все нужные решения. Нейробиологи доказали, что даже сверхквалифицированный человек способен ошибиться, пытаясь справиться со всем в одиночку. Поэтому рекомендуется использовать еще хотя бы одного человека, чтобы было с кем проконсультироваться. Финкельштейн и его соавторы связывают это с работой человеческого сознания (Finkelstein, 2009).
В команде множество партнеров, способных проверить ваши идеи и тем самым стимулировать принятие верных решений. Эд Кэтмалл, президент Pixar, утверждает:
…если дать хорошей команде посредственную идею, она либо исправит ее, либо выбросит и придумает взамен что-то получше.
Мудрость многих лучше, чем гений одного.
ПРОПАГАНДИСТ И ПЕРЕГОВОРЩИК
Владелец продукта должен быть эффективным пропагандистом и переговорщиком. Этот человек общается с разными сторонами, объединяя клиентов, пользователей, разработчиков, инженеров, маркетологов, сотрудников отдела продаж, операционных сотрудников и руководство. Владелец продукта — это голос клиента, который доносит до исполнителей требования потребителя и заполняет лакуну между «пиджаками» и «технарями». Иногда от него требуется сказать «нет», а иногда — найти компромисс.
НАДЕЛЕННЫЙ ПОЛНОМОЧИЯМИ И ПРЕДАННЫЙ ДЕЛУ
У владельца продукта должно быть достаточно полномочий, чтобы возглавить разработку и объединить усилия всех заинтересованных лиц. В mobile.de, самом большом немецком онлайн-рынке автомобилей, высшее руководство избирает владельцев продуктов, обеспечивает им поддержку и выступает в роли старшего партнера. Столь тесное сотрудничество позволяет руководителям лучше следить за ходом выполнения конкретных проектов и отказываться от бесперспективных на раннем этапе.
Достаточные полномочия владельца продукта необходимы для руководства разработкой продукта. Владелец продукта должен обладать полнотой власти для принятия решений, касающихся любых аспектов — подбора подходящих членов команды, определения того, какая функциональность будет входить в тот или иной релиз, и т. д. Это человек, имеющий доступ к бюджету и способный создать рабочую среду, стимулирующую творческий импульс и инновации. Он должен быть предан делу разработки. Владелец продукта — это уверенный в себе энергичный энтузиаст, достойный доверия.
ДОСТУПНЫЙ И КВАЛИФИЦИРОВАННЫЙ
Владелец продукта должен быть доступным и иметь нужный уровень квалификации. Его роль обычно предполагает полную занятость. Важно предоставить владельцам продукта достаточно времени для эффективного выполнения своих обязанностей. Если человек перегружен, от этого страдает результат, а получившийся продукт бывает неоптимальным.
Необходимая квалификация предполагает хорошее знание клиентов и рынка, бережное отношение к пользовательскому опыту, способность доносить до сторон нужды потребителя, управлять бюджетом, руководить разработкой и комфортно чувствовать себя при работе с многофункциональным самоорганизующимся коллективом.
ВЛАДЕЛЕЦ ПРОДУКТА В PATIENTKEEPER
Джефф Сазерленд, один из создателей Scrum и бывший технический директор компании PatientKeeper, ведущего производителя интегрированных информационных систем в области здравоохранения, разъясняет необходимую квалификацию и полномочия владельцев продукта в этой компании:
[Владелец продукта] должен быть экспертом в своей отрасли, работать хотя бы пару дней в неделю как врач в одной из ведущих больниц Бостона… техническим специалистом, уже написавшим несколько приложений… экспертом в анализе пользовательских историй, сценариев использования и программных спецификаций, особенно в области здравоохранения… уметь находить общий язык с клиентами и отделом продаж, выяснять требования и набирать специалистов-медиков для тестирования прототипов с новой функциональностью… и при этом вести бизнес, заниматься выручкой, отношениями с клиентами и специалистами по продажам в части, касающейся функционала, создавать пользовательские истории и все дополнительные спецификации продукта, в том числе анализировать ожидания клиента. [Наши владельцы продукта] получают помощь только от разработчиков и членов своей команды. Первые два назначенных специалиста с задачей не справились. Но постоянное обучение, наставничество и верно выбранный сотрудник дали нужные результаты.
РАБОТА С КОМАНДОЙ
Владелец продукта — это такой же член scrum-команды, как и все остальные, он должен полагаться на сотрудничество с ней и со scrum-мастером. Команда представляет собой многофункциональную, самоорганизующуюся и при этом небольшую группу специалистов. В ней должны быть представлены все роли, необходимые для создания продукта. Члены scrum-команды работают в атмосфере доверия и сотрудничества, как равноправные коллеги. Исключается разделение людей на «мы и они». Должно присутствовать только понятие «мы».
Для создания атмосферы успешности в scrum-команде сведите к минимуму изменения в ее составе в течение релизов и между ними. Чтобы группа людей превратилась в сплоченную команду, потребуется время. Необходимо создать тесно спаянный коллектив, члены которого доверяют друг другу, эффективно работают вместе. Если изменить состав команды, процесс построения начинается заново и в результате снижаются продуктивность и самоорганизация. К тому же нужно установить долгосрочное партнерство между scrum-командой и ее продуктом. Каждый продукт должен разрабатываться одной или несколькими преданными ему командами. Это не только облегчает обучение, но и упрощает распределение людей и ресурсов.
Поскольку владелец продукта, scrum-мастер и команда должны постоянно и тесно сотрудничать, желательно разместить всех членов scrum-команды в одном помещении. Рассмотрим пример mobile.de. То, что владельцы продукта, scrum-мастер и команда находились в одном помещении, повысило производительность и боевой настрой команды. Если владелец продукта не имеет возможности постоянно находиться вместе с командой, он должен регулярно встречаться с ее членами. Владельцы продукта, работающие удаленно, могут приходить в офис и оставаться вместе с командой на протяжении нескольких дней при каждом спринте. Если владельцы находятся в том же комплексе, но располагаются далеко от команды, я рекомендую им выполнять «правило одного часа»: проводить как минимум час в день в помещении, где трудится команда.
Атмосфера в помещении, где работает команда, должна стимулировать творческий процесс, который включает взаимодействие и ощущение радости от работы, содержит ключевые маркеры информации (формулировку концепции, наиболее приоритетные элементы бэклога продукта, диаграмму архитектуры ПО, задания текущего спринта, график хода релиза и спринта). Лучшие рабочие помещения — те, где созданы условия для сочетания командной работы, личного пространства и деятельности небольших групп в комнатах отдыха.
ВЗАИМОДЕЙСТВИЕ СО SCRUM-МАСТЕРОМ
Чтобы постоянно играть на высшем уровне, спортивной команде необходим тренер, а scrum-команде — scrum-мастер. Он оказывает поддержку владельцу продукта и команде, защищает ее и процесс работы и при необходимости вмешивается, чтобы удостовериться, справляется ли команда с задачей, сохраняет ли здоровую атмосферу и мотивацию и не создает ли технического долга.
Роли владельца продукта и scrum-мастера дополняют друг друга. Владелец продукта в первую очередь отвечает за создание нужного продукта. Scrum-мастер в основном несет ответственность за то, «как» правильно использовать практики Scrum. Эти два аспекта проиллюстрированы на рисунке 1.1. Долгосрочный успех достигается, когда правильный продукт создается правильными методами.
Рисунок 1.1. Создание правильного продукта правильными методами
Поскольку роли владельца продукта и scrum-мастера призваны дополнять друг друга, выполнять их одному человеку невозможно: это создает чрезмерную нагрузку. Нельзя быть одновременно scrum-мастером и владельцем продукта.
РАБОТА С КЛИЕНТАМИ, ПОЛЬЗОВАТЕЛЯМИ И ДРУГИМИ ЗАИНТЕРЕСОВАННЫМИ ЛИЦАМИ
Клиент — это тот, кто приобретает продукт, а пользователь — человек, применяющий продукт. Они определяют его успех или неудачу. Продукт будет востребован на рынке, только если достаточное количество клиентов купят его, а пользователи сочтут выгодным приобретением. Заметьте, что клиент и пользователь могут не совпадать, а их потребности — различаться. Рассмотрим в качестве примера электронные таблицы. Пользователи особенно ценят простоту их применения и высокую производительность. В свою очередь, компания, приобретающая продукт, заинтересована в разумной стоимости использования и безопасности данных.
Для создания успешного продукта его владелец, scrum-мастер и команда призваны точно определить запросы клиента и пользователя, а также найти методы наилучшего удовлетворения их потребностей. Для этого нужно вовлечь в работу клиентов и пользователей на самом раннем этапе.
Предоставляя клиентам отзывы о прототипах, приглашая их представителей на рабочие совещания во время спринтов, выпуская быстрые и частые релизы ПО, команда сумеет многому научиться у клиентов. Продукт — это всего лишь средство, конечная цель — помочь покупателю и принести пользу компании-разработчику. Приведем известное высказывание Теодора Левитта по этому поводу: «Человеку, который покупает дрель, нужна не сама дрель, а отверстия в стене». Только сосредоточившись на нуждах покупателя, можно разработать оптимальное решение.
Помимо клиентов и пользователей производители продукта должны привлекать и других заинтересованных лиц — например, представителей служб маркетинга, продаж и клиентского обслуживания. Их с самого начала следует приглашать на рабочие совещания во время спринтов. Эти встречи позволят заинтересованным лицам увидеть, как создается продукт, наладить контакт со scrum-командой и обменяться мнениями. Брайсон (Bryson, 2004) предлагает обзор методов выявления заинтересованных лиц, анализа их требований и работы с ними.
МЕНЕДЖЕРЫ ПО ПРОДУКТОВОМУ МАРКЕТИНГУ И МЕНЕДЖЕРЫ ПРОДУКТА
Некоторые компании разграничивают стратегический и тактический продакт-менеджмент и выделяют отдельные должности для каждого из них: менеджер по продуктовому маркетингу и (технический) менеджер продукта. Деятельность менеджеров по продуктовому маркетингу обычно направлена вовне: в их обязанности входит понимать рынок, управлять планом развития продукта и следить за общими доходами после релизов. А менеджеры продукта смотрят внутрь: их задача — подробное описание функций, расстановка приоритетов и сотрудничество с командой разработчиков. В Scrum владелец продукта совмещает все эти обязанности. По стратегическим вопросам управления продуктом владелец продукта может получить поддержку от управляющего портфелем, вице-президента и даже CEO. Все зависит от размера компании и важности проекта. Помощь по ценообразованию и маркетинговым вопросам ему окажут менеджер по продуктовому маркетингу и руководитель отдела продаж. С точки зрения тактики владелец продукта должен рассчитывать на поддержку scrum-мастера и своей команды. Объединение обоих аспектов управления продуктом обеспечивает сквозное руководство и общую ответственность. Мы стараемся избегать появления лишних звеньев, необходимости ждать согласований и отсрочек, а также проблем, связанных с недопониманием одного работника другим.
Вы, наверное, заметили, что не упомянута роль руководителя проекта в scrum-команде. Причина в том, что обязанности по управлению проектом больше не входят в компетенцию одного человека. Они распределены между членами scrum-команды. Например, владелец продукта отвечает за дату релиза, его объем, управление бюджетом, сообщения о прогрессе и работу с заинтересованными лицами. Команда определяет и оценивает задачи, а затем работает над ними. Таким образом, роль руководителя проекта становится избыточной. Это не значит, что люди, которые работают в этой должности, больше не нужны. Очень часто они становятся успешными scrum-мастерами. Встречались мне и руководители проекта, отлично выполнявшие роль владельца продукта.
МОДЕЛИРОВАНИЕ РОЛИ ВЛАДЕЛЬЦА ПРОДУКТА
Прежде чем рассказать о методах работы владельца продукта в крупных 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-команда. Удаленным владельцам продукта нужно присутствовать хотя бы при планировании спринтов, на обзорных и ретроспективных совещаниях. Переход от удаленного к присутствующему владельцу продукта нередко требует времени. Иногда это связано с приемом на работу и обучением местного владельца продукта. В некоторых случаях требуется даже переосмысление стратегии продукта компании и изменение места его производства.
ЗАМЕСТИТЕЛЬ ВЛАДЕЛЬЦА ПРОДУКТА
Заместитель владельца продукта — это человек, который временно занимает место настоящего владельца. Мне доводилось видеть, как работают заместители слишком загруженных, частичных или удаленных владельцев продукта. Один вице-президент по управлению продуктом получил предложение занять должность владельца продукта, критичного для развития бизнеса. Хотя он идеально подходил для этой работы, ему с трудом удавалось проводить достаточно времени с командой. В результате бизнес-аналитику команды пришлось выступать в роли заместителя, когда настоящий владелец продукта не мог присутствовать. Он делал большую часть работы владельца, не имея соответствующих полномочий. Сам же владелец продукта принимал окончательные решения о приоритетах в бэклоге продукта, при планировании релизов, приеме результатов работы. В итоге увеличилось количество конфликтов, решения принимались медленнее, уменьшилась производительность и упал командный дух.
Использование заместителя владельца продукта — это попытка искусственно вылечить системную проблему. Вместо косметического ремонта организациям следует заняться причинами: например, освободить владельца продукта от других обязанностей, объединить его в одном помещении со scrum-мастером и командой или найти нового владельца продукта.
КОМИТЕТ ВЛАДЕЛЬЦЕВ ПРОДУКТА
Комитет владельцев продукта — это группа владельцев продукта, в которой никто персонально не отвечает за общий продукт. Ни один из них не руководит этой группой, не помогает выработать общую цель и принять решение. Комитет владельцев продукта может выродиться в бесконечные совещания по поводу конфликтующих интересов и методов. Иногда это называют «смерть от комитета». Никакого реального прогресса нет, сотрудники перестают работать вместе и начинают бороться друг против друга. Поэтому обязательно нужен главный владелец продукта, который руководит другими владельцами продукта, может помочь при принятии решений, в том числе по вопросу приоритетов в бэклоге продукта и планированию релизов.
ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ
Роль владельца продукта — это краеугольный камень успешного применения гибкого управления продуктом в Scrum. Времена одиноких менеджеров продукта, запирающихся в кабинете и напрягающих мозги, чтобы разработать идеальные требования, прошли. Владелец продукта — это член scrum-команды, он готов к тесному и постоянному сотрудничеству.
Следующие вопросы помогут успешно применить роль владельца продукта.
- Кто представляет клиентов и пользователей в вашей компании?
- Кто определяет и описывает потребности клиентов и функциональность продукта?
- Кто руководит выработкой концепции продукта и действиями по претворению ее в жизнь? Какую роль играют командная работа и совместное принятие решений?
- Что потребуется для внедрения роли владельца продукта в той форме, которая описана в данной главе?
