Чем занимается Product Owner: задачи, навыки, компетенции. Пример работы PO

В статье рассказали, кто такой Product Owner, чем он занимается, за какие задачи отвечает и какими компетенциями должен обладать.

Владелец продукта: кто такой и каковы его обязанности

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

За порядок в этой работе отвечает владелец продукта. Разберем, какие задачи закреплены за ним в Скрам, чем он отличается от менеджера продукта и как организует работу команды разработки.

Кто такой владелец продукта

Владелец продукта - участник Скрам-команды, который отвечает за максимизацию ценности продукта и эффективное управление бэклогом. Так эта роль определена в Руководстве по Скрам 2020 года.

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

Согласно руководству, владелец продукта отвечает за четыре направления:

• Разработку и понятное объяснение цели продукта.

• Создание и четкое описание элементов бэклога.

• Определение порядка элементов бэклога.

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

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

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

Чем занимается владелец продукта

Управляет бэклогом и определяет приоритеты

Допустим, компания создает приложение для планирования рабочих задач. Заказчик хочет добавить уведомления, календарь и поиск по исполнителям. У команды пока нет возможности сделать все одновременно.

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

На практике он:

• Уточняет содержание и ожидаемый результат каждого элемента.

• Размещает более важную работу выше менее важной.

• Пересматривает порядок при появлении новой информации.

• Убирает или меняет устаревшие требования.

• Следит, чтобы команда понимала, что требуется от продукта.

Бэклог не равен жесткому календарному плану на год. Он регулярно меняется по мере развития продукта и уточнения потребностей бизнеса.

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

Здесь часто возникает путаница. Стратегическое видение бизнеса и цель продукта в Скрам - не одно и то же.

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

Но цель продукта в Скрам входит в его ответственность. Это описание будущего состояния продукта, к которому движется команда. Он формулирует ее с учетом бизнес-контекста и объясняет участникам разработки.

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

Уточняет требования для команды

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

Владелец продукта помогает преобразовать запрос в понятный элемент бэклога. Например: "После назначения новой задачи ответственный сотрудник получает уведомление с названием задачи и сроком выполнения".

Команда уточняет ограничения, обсуждает варианты реализации и оценивает объем работы. По Руководству по Скрам, оценку размера элементов выполняют разработчики. Владелец продукта может обсуждать с ними компромиссы, но не назначает оценки вместо команды.

О подходах к оценке можно прочитать в материале о покер-планировании задач.

Согласует ожидания заинтересованных сторон

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

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

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

О том, кто относится к заинтересованным сторонам, рассказали в статье про стейкхолдеров.

Участвует в планировании и обзоре спринтов

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

Распределение ответственности выглядит так:

• Владелец продукта предлагает, какую ценность может дать очередной спринт.

• Вся Скрам-команда совместно формулирует цель спринта.

• Разработчики выбирают объем работы, который смогут завершить.

• Разработчики самостоятельно решают, как выполнять выбранные элементы.

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

За что владелец продукта не отвечает по умолчанию

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

Скрам не возлагает на владельца продукта как обязательные отдельные функции:

• Исследование рынка и конкурентов.

• Самостоятельную разработку маркетинговой стратегии, позиционирования и ценовой политики.

• Организацию рекламных кампаний и продаж.

• Проведение пользовательских интервью и опросов.

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

• Управление персоналом команды разработки и назначение технических решений.

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

Также в Скрам нет требования вести дорожную карту развития продукта. Однако использовать такую карту как дополнительный инструмент планирования можно: она не заменяет бэклог и должна допускать изменения.

Чем владелец продукта отличается от менеджера продукта и руководителя проекта

Роль	Основная зона ответственности
Заказчик или руководитель продуктового направления	Бизнес-цели, стратегия и коммерческие ориентиры продукта.
Менеджер продукта	Исследования аудитории и рынка, развитие продуктового предложения, работа с пользовательскими потребностями.
Владелец продукта	Цель продукта в Скрам, управление бэклогом, приоритеты и разъяснение требований команде.
Продуктовый аналитик	Анализ использования продукта и продуктовых показателей.
Разработчики	Оценка трудоемкости, техническая реализация и создание готового результата.
Скрам-мастер	Помощь команде и организации в правильном применении Скрам.
Руководитель проекта	Сроки, бюджет, ресурсы и риски проекта, если такая должность предусмотрена компанией.

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

Роль руководителя проекта подробнее раскрыта в статье о менеджере проектов.

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

Приоритизация. Умение сравнивать запросы с целью продукта и выбирать последовательность работ. Без этого бэклог превращается в список пожеланий без ясного порядка.

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

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

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

Знание Скрам. Владелец продукта должен различать цель продукта, цель спринта, бэклог продукта и бэклог спринта, а также понимать границы ответственности участников.

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

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

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

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

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

3. Работа над требованиями. Возникает вопрос: кто может менять статус задачи? Владелец продукта уточняет ожидаемое правило у заказчика и сообщает его команде. Техническое решение принимают разработчики.

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

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

Типичные ошибки при организации этой роли

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

Успех измеряют только количеством закрытых задач. Команда может выполнить много мелких работ и почти не приблизиться к цели продукта. Число задач и скорость выполнения помогают анализировать ход разработки, но не равнозначны ценности результата. Руководство по Скрам не требует использовать скорость команды как персональный KPI владельца продукта.

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

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

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

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

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

Что проверить перед наймом владельца продукта

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

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

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

Кто оценивает объем и выбирает способ работы? Эти решения должны оставаться у разработчиков.

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

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

Также читайте: Что такое Waterfall методология в управлении проектами, её преимущества и недостатки