Владелец Продукта в SAFe® 6.0

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

Agile-манифест

Вольный перевод статьи: Product Owner — Scaled Agile Framework.

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

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

Обязанности PO можно разделить на пять основных доменов, как показано на Рисунке 1.

Каждый из этих доменов описывается в соответствующих разделах.

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

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

• Анализ клиента – Стоимость определяется клиентом; таким образом, Владелец Продукта хорошо осведомлен о потребностях людей, которым поставляется их продукция. Клиенты могут быть внутренними или внешними по отношению к предприятию и могут иметь прямые или косвенные отношения с Владельцем Продукта. Независимо от того, потребляют ли они продукты, услуги, системы, API, платформы или другие решения, Владелец Продукта постоянно изучает желания, потребности и предпочтения клиентов.
• Анализ заинтересованных сторон – Архитектура и реализация продукта также должны отражать потребности заинтересованных сторон, не являющихся клиентами. Представители Бизнеса, Lean-управление Портфелем, Менеджеры Продукта, Системные Архитекторы и другие Владельцы Продуктов, например, полагаются на темп и качество результатов работы команды. Владелец Продукта идентифицирует ключевых заинтересованных лиц и уравновешивает их потребности с потребностями клиента.
• Определение проблем, требующих решения – Хорошие продукты решают конкретные проблемы. Более того, они решают конкретные проблемы, которые стоит решить. Выявление проблем, которые клиенты хотят решить, является первым элементом дизайн-мышления. В этом контексте Владелец Продукта обнаруживает ряд потребностей клиентов с помощью инструментов дивергентного мышления (divergent thinking), а затем определяет работы, ради решения которых Клиент «нанимает» продукт (Jobs-To-Be-Done), которые больше всех заслуживают реализации.
• Разработка комплексных решений – Решения, отвечающие целому ряду потребностей клиентов, более ценны, чем те, которые ориентированы на одну потребность. Владелец Продукта стремится предоставлять всеобъемлющее решение, понимая желаемое качество обслуживания клиентов, направляя разработку вариантов дизайна с помощью процесса Lean UX и предоставляя проверенные концепции, которые максимизируют удовлетворенность и лояльность клиентов.

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

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

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

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

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

• Руководство созданием Историй – Хоть любой член команды может написать историю в любое время, но Владелец Продукта обязан следить за тем, чтобы они были правильно сформированы и соответствовали стратегии продукта. Владелец Продукта уточняет детали Истории, применяет формат истории языком пользователя, обеспечивает соответствие критериям INVEST, помогает разделить историю, формулирует Энейблеры и применяет разработку через поведение (Behavior-Driven Design, BDD), чтобы гарантировать, что Истории поддерживают непрерывность потока ценности. Владелец Продукта резервирует ёмкость для «локальных» Историй и Спайков, которые улучшают дизайн продукта, но не являются явными производными от Фичей уровня ART.
• Приоритизация элементов бэклога – Для достижения непрерывного потока ценности необходимо, чтобы наиболее ценные элементы невыполненной работы поставлялись в кратчайшие сроки и в правильной последовательности. Владелец Продукта обеспечивает это, регулярно упорядочивая элементы Бэклога Команды в соответствии с их стоимостью задержки и сообщая эту последовательность команде во время Уточнения Бэклога и Планирования Итерации.
• Приёмка историй – Владелец Продукта работает с командой, чтобы согласовать завершение Истории. Это включает в себя проверку того, что история соответствует критериям приемки (Acceptance Criteria, AC), что она проходит приемочные тесты и что соответствует определению готовности (Definition of Done, DoD). При этом Владелец Продукта обеспечивает встроенное качество (Built-In Quality).
• Поддержка Архитектурной Полосы – Владельцы Продуктов обычно не управляют технологическими решениями, но они выделяют место в Бэклоге Команды для поддержки реализации Архитектурной Полосы. Они сотрудничают с Системными Архитекторами для реализации Энейблеров и работают с заинтересованными лицами для определения надлежащего распределения ресурсов.

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

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

• Управление ожиданиями заинтересованных лиц – Владелец Продукта постоянно получает информацию, отзывы и идеи от клиентов, заинтересованных лиц, команд и инструментов, которые могут повлиять на разработку Решения. Эта информация может подтверждать, оспаривать или вообще опровергать принятые ранее решения. Более того, эти источники часто противоречат друг другу. Владелец Продукта уравновешивает эти ожидания. Для принятия оптимальных решений Владелец Продукта должен понимать потребности клиентов, взаимодействовать с заинтересованными лицами и командами, принимать во внимание стоимость задержки и зафиксированное распределение ёмкости.
• Проработка Историй – Истории обычно создаются до начала итерации, но требуют постоянной проработки. По мере реализации Историй, Владелец Продукта проводит регулярные встречи команды для решения вопросов, управления зависимостями и разъяснения приоритетов. Эта информация также помогает команде эффективно нарезать истории для повышения скорости и сокращения циклов обратной связи.
• Поощрение Встроенного Качества – Владелец Продукта, как основной представитель клиентов и заинтересованных лиц в команде, играет ключевую роль в оценке поставляемой ценности. Владелец Продукта регулярно оценивает достижение критериев приёмки Истории, в том числе соответствие критериям встроенного качества. В качестве таких критериев могут выступать нефункциональные требования (Non-Functional Requirements, NFR) и общее определение готовности, обеспечивающее интеграцию. Владелец Продукта тесно сотрудничает с командой, чтобы выявлять и исправлять проблемы с качеством по мере их возникновения.
• Участие во встречах команды и ART – Как член Agile-команды, Владелец продукта, естественно, посещает и активно участвует в командных мероприятиях во время PI. Он обеспечивает критически важную обратную связь о работе команды с внешней точки зрения во время Планирования Итерации, Уточнения Бэклога, Обзоров Итераций, Ретроспектив и командных синхронизаций. Участвуя в PO Sync и Системных Демонстраций, Владелец продукта помогает команде управлять зависимостями, поддерживать инкрементальную поставку и поддерживать единый ритм в ART.

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

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

• Тестирование гипотез о выгоде – ценность может быть измерена только, когда работающее решение оказывается в руках клиента. Таким образом, во время разработки о ценности можно только галлюцинировать. Чтобы снизить риски разработки Фичей с низкой ценностью, Владелец Продукта взаимодействует с Продуктовым Менеджментом, чтобы сформулировать гипотезы о выгоде, основанные на знаниях о клиентах и рынке. Эти гипотезы определяют реализацию и подтверждаются (или опровергаются) отзывами, которые Владелец Продукта получает от клиентов и заинтересованных сторон на протяжении всего жизненного цикла продукта.
• Сбор обратной связи от клиентов и заинтересованных лиц – Клиенты получают ценность, используя предоставленные решения. Их отзывы показывают, насколько хорошо решения отвечают их потребностям. Чем лучше решение закрывает потребности клиентов, тем чаще они выбирают ваше решение и тем выше их лояльность. Заинтересованные лица извлекают выгоду из доходов, экономии средств или снижения рисков, связанных с использованием заказчиками поставленных решений. Владелец Продукта собирает эту обратную связь напрямую через пользовательские интервью, в Гемба, Обзоры Итераций и Системные Демонстрации, а также косвенно через телеметрию приложений, аналитику использования, финансовую отчетность и аналитику рынка.
• Коммуникация обратной связи в ART – Поскольку для предоставления решения требуется координация и синхронизация всего потока ценности, отзывы, собранные Владельцем Продукта, ценны для всего ART. Владелец Продукта делится этой информацией с Продуктовым Менеджментом и Системным Архитекторами в рамках Непрерывного Изучения, с другими Владельцами Продуктов во время PO Sync, со своими командами во время Уточнения Бэклога, Планирования Итерации и Обзора Итерации, а также с ART во время PI-планирования, Системной Демонстрации и Инспекции и Адаптации.
• Развитие дизайна решения – Частые клиентоориентированные циклы обратной связи, поддерживают цикл Шухарта-Деминга, который обеспечивает непрерывную поставку ценности и постоянное, безжалостное улучшение самого потока ценности. Собирая и делясь этой важной информацией, Владелец Продукта позволяет постоянно совершенствовать концепцию продукта, дорожную карту, стратегию и архитектуру для достижения оптимальной ценности для бизнеса.

Ключевое партнерство

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

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

PO всегда находится в тесных отношениях с Продуктовым Менеджментом, чтобы получать идеи на макроуровне и применять их к конкретным доменам продуктов. Для правильного создания решений требуются Командная и Техническая Гибкость, практики DevOps и Конвейер Непрерывной Поставки. Эти технические возможности определяют скорость и качество, с которыми может быть доставлена ценность, и PO полагается на Agile-команду, чтобы обеспечить их.

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

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.