Кто такой владелец продукта? Важная роль для успеха Scrum-команды

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

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

Что такое владелец продукта?

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

Владелец продукта — это одна из трёх стандартных ролей в Scrum-команде: 

• Владелец продукта: работает с заинтересованными сторонами, конечными пользователями и Scrum-командой, чтобы убедиться, что конечный продукт соответствует требованиям пользователей и бизнес-целям. 

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

• Команда разработчиков: работает над результатами, которые должны быть завершены в каждом спринте. Разработчики являются ядром Scrum-команды, поскольку они отвечают за выполнение элементов продуктового бэклога, которые превращаются в новые функции продукта.

Ответственный за продукт и мастер Scrum

Владелец продукта и Scrum-мастер — две неотъемлемые, но разные роли в Scrum-команде. 

Scrum-мастера отвечают за:

• Управление внутренними процессами, необходимыми Scrum-командам для завершения работы, и их улучшение

• Помощь команде в подготовке и успешном проведении спринтов, чтобы разработчики могли сосредоточиться на своей работе, а не на логистических задачах

• Содействие проведению совещаний по планированию, ежедневных стендапов и ретроспектив спринта 

• Устранение препятствий для разработчиков и обеспечение соответствия принципам фреймворка Scrum.

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

Ответственные за продукт отвечают за:

• Учёт отзывов заинтересованных сторон и конечных пользователей.

• Преобразование этой обратной связи в конкретные функции продукта и элементы бэклога для работы Scrum-команды

Обязанности владельца продукта

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

Определение функций и целей продукта

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

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

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

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

Создавайте элементы бэклога на основе целей продукта

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

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

Приоритет информации от заинтересованных сторон и конечных пользователей

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

Поскольку владелец продукта обладает аналитикой приоритетов Business, он понимает, почему важны конкретные инициативы и как в них вписывается работа. Это означает, что он может расставлять приоритеты в обратной связи от заинтересованных сторон и помогать Scrum-команде сосредоточиться на наиболее важной работе. Без ответственного за продукт Scrum-команды часто в конечном итоге расставляют приоритеты в работе на основе указаний межфункциональных команд. 

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

Создание пользовательских историй

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

Пользовательские истории часто выражаются в виде одного предложения, структурированного следующим образом: 

«Как [персонаж], я хочу [цель программного обеспечения], чтобы [результат]».

В нашем примере с приложением «Календарь» владелец продукта Scrum может создать следующую пользовательскую историю, чтобы определить цели функции: 

«Как руководитель удалённой команды, я хочу понимать, когда работают мои сотрудники, чтобы планировать встречи в удобное для всех время». 

Расставляйте приоритеты и управляйте продуктовым бэклогом

Наряду с определением функций продукта, владелец продукта отвечает за уточнение бэклога. Это включает в себя:

• Создание и управление продуктовым бэклогом 

• Приоритизация задач с учётом потребностей бизнеса, целей продукта и требований пользователей

• Четкое определение всех задач и доведение продуктового бэклога до сведения всех участников команды

• Определение требований к продукту и ожиданий пользователей вместе со Scrum-командой

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

• Как Scrum-команда преобразует обратную связь в конкретные функции продукта

• Почему одни задачи важнее других

• Как выглядит реалистичный график для запросов новых функций

Контроль этапов разработки продукта

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

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

1. Генерация идей: коллективное обсуждение концепций продукта с учётом потребностей клиентов и результатов рыночных исследований

2. Определение продукта: определение функций, ценностного предложения и показателей успешности

3. Прототипирование: создание концептуальной версии продукта для определения целесообразности различных функций и разработки стратегии развития

4. Первоначальный дизайн: создание первой версии продукта, которую можно использовать для сбора отзывов от заинтересованных сторон и конечных пользователей

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

6. Коммерциализация: запуск и реализация конечного продукта

Следование этому процессу гарантирует, что Scrum-команда создаст наилучший продукт с наименьшим риском. 

Обеспечение соблюдения Scrum-командой рекомендаций по разработке продукта

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

• Создание прототипа для проверки исходной концепции

• Выполнение тестов интерфейса для выявления любых ошибок или рисков разработки

• Проведение пользовательского тестирования, чтобы убедиться, что готовый продукт соответствует ожиданиям и требованиям конечных пользователей

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

Почему владельцы продуктов так важны?

От управления обратной связью с заинтересованными сторонами до разработки всеобъемлющего продуктового бэклога — владельцы продуктов играют важную роль в процессе разработки продукта. Эти ключевые участники Scrum-команды помогают решать проблемы проектирования и координации между заинтересованными сторонами и разработчиками, обеспечивая при этом соответствие продукта целям компании. 

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

Улучшение общения между заинтересованными сторонами

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

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

Назначение ответственного за продукт для управления общением между заинтересованными сторонами:

• Улучшает общение между всеми сторонами

• Повышает эффективность при определении приоритетов функций продукта и элементов бэклога

• Позволяет Scrum-команде или заинтересованным сторонам принимать важные решения на основе обратной связи от обеих сторон процесса

Улучшает процесс создания продукта

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

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

Более эффективные процессы с продуктовым бэклогом

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

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

• Повышать эффективность за счёт создания плавного и прозрачного процесса разработки

• организовывать задачи и соблюдать дедлайны;

• Расставлять приоритеты для работы и запросов заинтересованных сторон

• Снизить риск разрастания объёма и держать команду в нужном русле

Создавать более качественные продукты с ответственным за продукт

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