Блог
Владелец Продукта (Product Owner)

Владелец Продукта (Product Owner)

31 октября 2022

«На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.»

Манифест Гибкой Разработки (Agile Manifesto)

Владелец Продукта — кто это?

Владелец продукта (Product Owner, PO) является членом Agile команды. Он отвечает за максимизацию ценности, доставляемой командой, и обеспечивает соответствие беклога команды потребностям клиентов и заинтересованных лиц.

Владелец продукта является основным представителем клиента для команды и ключевым связующим звеном между бизнес-стратегией и технологической стратегией. Владелец продукта также является участником расширенного состава функции Управления продуктами (Product Management). Все это в результате позволяет команде находить баланс между требованиями многих заинтересованных лиц в процессе постоянного развития Решения.

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

Роли в SAFe, принимающие продуктовые решения включают в себя функцию LPM, роль Владельцев Бизнеса (Business Owners), функции Управления Решением (Менеджмент Решения, Solution Management) и Управления Продуктом (Менеджмент Продукта, Product Management), роль Владельцев Продукта (Product Owners).

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

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

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

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Для большинства предприятий, переходящих на Agile, Владелец продукта является как правило, новой, выделенной на 100% ролью в каждой Agile команде. Каждый Владелец Продукта является представителем потребностей клиентов и бизнеса в определенном домене Решения, обычно выполняя эту работу совместно c Менеджером Продукта. Вместе они гарантируют, что стратегия продукта и реализация остаются связанными во всем потоке создания ценности.

Разделение управления продуктом между ролями Владельца Продукта и Менеджера Продукта (Управляющим Продуктом) является ключевым для успешной реализации продуктовой стратегии и достижения конкурентного преимущества в XXI веке.

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

Если обобщать разделение обязанностей между Владельцем Продукта и Менеджером Продукта, то основная задача Владельца Продукта более тактическая – проработка продукта с командой разработки и максимизация ценности, создаваемой Agile командой.

Управляющий Продуктом (Менеджер Продукта) в первую очередь отвечает за более стратегическую часть – непрерывные исследования, изыскания, коммуникации с бизнесом и общие показатели развития продукта.

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

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

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

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

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

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

Рисунок 1. Зоны ответственности Владельца Продукта

Каждая из этих областей ответственности описана дальше в этой статье.

Связь с клиентом

Организация и выстраивание работы таким образом, чтобы Релизные Поезда (Agile Release Train, ART) непрерывно создавали правильные вещи правильным образом, является непрерывным процессом, не имеющим окончания. Продуктовая стратегия, дизайн и реализация должны развиваться вместе с постоянно меняющимися желаниями клиентов и потребностями бизнеса. Владелец Продукта в тесном партнерстве с Менеджментом Продукта (Product Management) применяет клиентоцентричное мышление наряду с инструментами дизайн-мышления, чтобы направлять Agile Release Train к доставке желаемых, жизнеспособных, осуществимых и устойчивых решений. Владелец Продукта применяет клиентоцентричность и дизайн-мышление следующими способами:

Знать клиента – Ценность определяется клиентом, поэтому Владелец Продукта хорошо осведомлен о потребностях людей, которым доставляются разрабатываемые его командой продукты. Клиенты могут быть внутренними или внешними по отношению к предприятию, они могут иметь прямые или косвенные отношения с Владельцем Продукта. Независимо от того, что покупают клиенты — продукты, услуги, системы, API, платформы или другие решения — Владельцы Продукта постоянно изучают их желания, потребности и предпочтения.
Знать заинтересованных лиц – Разработка и внедрение продукта должны также отражать потребности заинтересованных лиц, не являющихся клиентами. Например, Владельцы Бизнеса, функция (команда) Бережливого Управления Портфелем (Lean Portfolio Management, LPM), Менеджеры Продукта, Архитекторы Систем, Владельцы Продукта других команд (коллеги по роли) – все они выстраивают собственную работу на базе каденции и качества результатов работы Agile команд. Владелец Продукта определяет ключевых заинтересованных лиц и обеспечивает оптимальное соотношение между потребностями со стороны клиента и этих заинтересованных лиц.
Выявить проблему, которую необходимо решить – Хорошие продукты решают конкретные проблемы. Более того, они решают конкретные проблемы, которые действительно необходимо решать. Выявление проблем, которые в первую очередь беспокоят клиентов, является первым элементом дизайн-мышления. Таким образом, сначала Владелец Продукта обнаруживает ряд потребностей клиентов с помощью инструментов дивергентного мышления, а затем определяет «работы для выполнения» этого Клиента (Jobs to be Done, JTBD), выбирая наиболее ценные из них для реализации.
Разрабатывать цельно-продуктовые решения – Решения, которые отвечают целому ряду потребностей клиентов, более ценны, чем те, которые нацелены на одну потребность. Владельцы Продукта нацелены на создание цельно- продуктовых решений (whole-product solutions). Для этой цели используется понимание ожидаемого опыта пользователя (user experience) и процесс LeanUX, через который проходят дизайн-кандидаты. В результате появляются протестированные концепции, которые максимизируют удовлетворенность и лояльность клиентов.

Внесение вклада в Видение и Дорожную Карту

Менеджеры продукта обдумывают решения и функциональные возможности, которые ожидаются от Agile Release Train. Владельцы Продукта при этом обладают пониманием, какие решения и функциональные возможности могут доставить команды. Это практическое понимание является ценным вкладом в Видение и Дорожные карты, которые направляют реализацию Решения. Владелец Продукта применяет эту практическую информацию следующими способами:

Понимать факторы рынка – Рыночные ритмы и события, неожиданные возможности, угрозы со стороны конкурентов и меняющаяся законодательная база существенно влияют на стратегию продукта. Владельцы Продукта регулярно взаимодействуют с Менеджерами Продукта для анализа маркетинговых исследований и понимания бизнес-факторов, которые являются источниками запросов на разработку Фич.
Быть представителем интересов конечного пользователя — Благодаря частым интервью, гембе и отчетности, Владельцы Продукта постоянно и тесно связаны с потребностями конечных пользователей и их опытом использования разрабатываемых продуктов. Объективное понимание того, как конечные пользователи взаимодействуют с решениями и фичами (функциональностью), которые им наиболее необходимы, гарантируют, что Видение и Дорожная карта содержат реальную ценность.
Помогать в расстановке приоритетов в Беклоге Поезда (ART Backlog) – В сотрудничестве с Менеджментом Продукта, Архитекторами Систем, Инженерами Релизных Поездов (Release Train Engineer, RTE) и другими заинтересованными лицами Владельцы Продукта помогают управлять последовательностью разработки фич на протяжении всего периода работы над решением для достижения наилучших экономических результатов. Владельцы Продукта понимают, какие проблемы являются наиболее важными и какие Решения наиболее необходимы. Кроме этого, Владельцы Продукта владеют пониманием о практических возможностях реализации этих решений. С помощью перечисленных знаний Владельцы Продукта помогают обеспечить, чтобы Видение и Дорожная карта наилучшим образом отражались в Беклоге Поезда.

Беклог Поезда в SAFe состоит из Фич, которые декомпозируются на Истории, из которых составляется Беклог Команды.

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Предоставлять информацию Релизному Поезду во время PI Планирования – Видение и Дорожная карта являются живыми артефактами, которые создаются и корректируются в соответствии с бизнес- и технической (технологической) стратегией. Часть содержания этих артефактов всегда находится в списке задач для непосредственной реализации в краткосрочной перспективе. Во время PI Планирования Владелец Продукта помогает транслировать Видение и Дорожную карту командам. Это обеспечивает единое понимание (выравнивание) команд и их готовность к работе в соответствии с Видением и Дорожной картой.

Управление и приоритизация Беклога Команды

Владелец Продукта несет основную ответственность за поддержание содержания и концептуальной и технической целостности беклога команды. С этой целью Владелец Продукта собирает и анализирует информацию от Менеджеров Продукта, Архитекторов Систем и других заинтересованных лиц. Беклог команды состоит из Пользовательских Историй, Энейблеров (Технических Историй) и дефектов. Он всегда должен содержать работу, которая соответствует самым актуальным потребностям клиентов, заинтересованных лиц и может быть немедленно «вытянута» в разработку. Владелец Продукта управляет поддержанием целостности беклога команды, осуществляя следующие действия:

Направление процесса создания Историй – Любой член команды в любое время может создавать истории. Однако именно Владелец Продукта отвечает за то, чтобы истории были хорошо сформулированы и были написаны в соответствии со стратегией продукта. Владелец Продукта разъясняет команде детали историй, выстраивает истории, чтобы они использовали формат «голос пользователя», контролирует отражение историями всех признаков правила «INVEST», помогает разделить крупную историю на более мелкие, определяет энейблеры и встраивает в истории дизайн на основе поведения (BBD). Все это гарантирует, что истории поддерживают непрерывный поток ценности. Владелец Продукта также оставляет место для «локальных» историй и спайков, которые продвигают разработку продукта вперед, но явно не отражены в фичах уровня Поезда.

В данной статье SAFe дается достаточно гибкое определение работы Владельца Продукта в части изначального формулирования Историй. Если посмотреть на некоторые другие материалы фреймворка, а также заглянуть в Скрам Гайд последней версии, там явно говорится о том, что Владелец Продукта именно создает истории, а не просто направляет процесс.

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

В качестве анти-паттерна здесь можно привести Владельца Продукта-Начальника, который не погружается в истории и «диктует под запись» команде свои мысли, которые всегда оформляет в виде историй кто-то в команде кроме него. Такого «начальника» будет неправильно называть полноценным Владельцем Продукта, а его команда скорее всего не будет являться Agile командой.

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Расставлять приоритеты в элементах беклога – Достижение непрерывного потока ценности требует, чтобы элементы беклога с наибольшей ценностью доставлялись в наикратчайшие стабильные сроки (shortest sustainable lead time) и в правильной последовательности. Владелец Продукта обеспечивает это, регулярно обновляя расположение элементов в беклоге в соответствии с их стоимостью задержки (Cost of Delay, CoD) и коммуницируя эту последовательность команде во время Уточнений Беклога и Планирования Итерации.
Принимать истории – Владелец Продукта работает с командой, чтобы договориться о принятии завершенной истории. Это включает в себя проверку того, что история соответствует критериям приемки, что у нее есть актуальные, постоянно выполняемые приёмочные тесты и что во всех остальных аспектах она соответствует Определению Выполненности (Definition of Done, DoD). Выполняя перечисленные действия Владелец Продукта обеспечивает, что в историю встроено качество.
Поддерживать Архитектурное Русло – Владельцы Продукта обычно не управляют технологическими решениями, но они оставляют место в беклоге для поддержки реализации Архитектурного Русла. Они взаимодействуют с Архитекторами Систем для подготовки Энейблеров и работают с заинтересованными лицами для установления надлежащей аллокации ёмкости.

Поддержка команды в доставке ценности

Ценность создается, когда Agile команды вытягивают элементы из беклога, разрабатывают истории, интегрируют и тестируют изменения, а затем доставляют инкремент решения. Эти действия по созданию ценности совершаются главным образом во время выполнения итерации. Будучи неотъемлемым членом команды и основным доверенным лицом клиента, Владелец Продукта каждый день предоставляет информацию, которая направляет разработку к наиболее ценным результатам, а команду к достижению целей итерации. Это позволяет команде и, в свою очередь, Релизному Поезду Agile (Agile Release Train), постоянно доставлять ценность. Обязанности Владельца Продукта в части доставки ценности включают в себя:

Обеспечить баланс взглядов заинтересованных лиц – Владельцы Продукта постоянно получают информацию, отзывы и идеи от клиентов, заинтересованных лиц, команд и различных инструментов, которые могут повлиять на разработку решения. Эта информация может подтвердить правильность принятых решений, признать их несостоятельными или оспорить решения относительно реализации самым неожиданным образом. Более того, эти источники часто конфликтуют друг с другом. Владельцы Продукта уравновешивают эти точки зрения, понимая целевые задачи, которые управляют теми или иными источниками, оставаясь клиентоцентричными, соблюдая принятую аллокацию ёмкости, оценивая стоимость задержки и сотрудничая с заинтересованными лицами и командами для принятия решений по реализации, которые приведут к наиболее благоприятным результатам.
Конкретизировать Истории – Истории обычно создаются перед выполнением итерации, но требуют постоянной проработки. Владелец Продукта фасилитирует частые обсуждения со своей командой для решения появляющихся вопросов, управления зависимостями и уточнения приоритетов задач, возникающих по мере реализации историй. Эта информация также помогает команде эффективно нарезать истории, чтобы увеличить пропускную способность и сократить время циклов обучения.
Способствовать встраиванию качества – Являясь представителем клиента и заинтересованных лиц в команде, Владелец Продукта играет ключевую роль в оценке ценности, доставленной на основе беклога. Он регулярно оценивает прогресс в разработке относительно критериев приемки, включая соответствие критериям встроенного качества, таким как масштабируемое определение выполненности (DoD) и нефункциональные требования (NFR). Владелец Продукта тесно сотрудничает с командой, чтобы выявлять проблемы качества по мере появления и исправлять их в режиме реального времени или близко к нему.
Участвовать в мероприятиях команды и Поезда – Как член Agile команды, Владелец Продукта посещает и активно участвует в мероприятиях команды во время выполнения Интервала Планирования (PI) (Примечание: Интервал Планирования (Planning Interval, PI — это термин версии SAFe 6.0, который заменяет используемый ранее термин «Инкремент Программы»). Во время планирования итерации, уточнений беклога, обзоров итераций, ретроспектив команды и синхронизаций команд Владелец Продукта дает важную обратную связь о работе команды с клиентоцентричной точки зрения. Участвуя в Синхронизации Владельцев Продукта (PO Sync) и Демонстрациях Системы (System Demo), Владелец Продукта помогает команде выполнять обязательства в части зависимостей, демонстрировать инкремент ценности и поддерживать единую каденцию с Релизным Поездом (Agile Release Train).

Получение и применение обратной связи

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

Тестирование гипотезы выгоды – Ценность может быть реализована только тогда, когда работающее решение находится в руках клиента. И даже в этом случае это не гарантируется. Поэтому во время разработки можно только предположить какую-либо ценность. Чтобы снизить риск доставки решения с небольшой ценностью, Владелец Продукта взаимодействует с Менеджментом Продукта для определения гипотез выгоды, основанных на глубоких знаниях клиентов и рынка. Эти гипотезы управляют реализацией и подтверждаются (или опровергаются) обратной связью, которую Владелец Продукта собирает от клиентов и заинтересованных лиц на протяжении всего жизненного цикла продукта.
Получение обратной связи от клиентов и заинтересованных лиц – Клиенты получают ценность от использования доставляемых решений. Их отзывы показывают, насколько хорошо решения отвечают их потребностям, что стимулирует принятие решения об использовании функционала и повышает лояльность. Заинтересованные лица получают ценность в виде дохода, экономии затрат или снижения рисков – все перечисленное может являться результатами использования клиентами доставляемых решений. Владелец Продукта собирает эту обратную связь напрямую с помощью глубинных интервью (empathy interview), гембы, обзоров итераций и демонстраций системы, а также косвенно через телеметрию приложений, аналитику использования, финансовую отчетность и вторичные данные рынка.
Делиться обратной связью с Релизным Поездом (ART) – Доставка решения требует координации и синхронизации по всему потоку создания ценности. Поэтому обратная связь, собранная Владельцем Продукта, ценна для всего Релизного Поезда. Владелец Продукта делится этой информацией со следующими участниками:
- с Менеджерами Продукта и Архитекторами Системы в рамках Непрерывного Исследования
- с другими Владельцами Продукта во время синхронизации Владельцев Продукта (PO Sync)
- со своими командами во время Уточнений Беклога, Планирования Итерации и Обзора Итерации
- с Релизным Поездом во время PI Планирования, Демонстраций Системы и, если применимо, мероприятий Инспект-Адапт (Inspect & Adapt, I&A)
Обеспечивать эволюцию дизайна решения – Частые клиентоцентричные циклы обратной связи подпитывают цикл «планируй-делай-проверяй-корректируй» (PDCA). Это обеспечивает непрерывную доставку ценности и постоянное, неустанное улучшение самого потока создания ценности. Владелец Продукта собирает и делится этими критически важными знаниями, что позволяет непрерывно совершенствовать видение продукта, дорожную карту, стратегию и дизайн для достижения оптимальной бизнес-ценности.

С кем взаимодействует Владелец Продукта?

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

Создание правильных решений требует глубоких знаний бизнес-стратегии, клиентских сегментов, динамики рынка и экономики потока создания ценности. Владелец Продукта устанавливает тесные отношения с Менеджментом Продукта, чтобы получить эту макроинформацию и применить ее к конкретным областям (доменам) продукта. Правильная разработка решения требует Командной и Технической Гибкости, практик DevOps и наличия Конвейера Непрерывной Доставки (Continuous Delivery Pipeline, CDP). Эти технические возможности определяют скорость и качество доставки ценности. Владелец Продукта полагается на свою Agile команду в создании и использовании этих возможностей.

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