Agile
Agile-коуч
Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
Enterprise Agile Russia
HR
Kanban
KPI
LeSS
Nexus
OKR
OKR Russia
OKR-инструменты
PMI
Project management
SAFe
Scrum
Scrum in Hardware
Scrum-мастер
Spotify
XM
Архитектура
Бюджетирование
Владелец продукта
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Продуктовый менеджмент
Самоорганизация
Тренинг
Фасилитация
Финансы
Холакратия
Применить

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

28 апр 2021, Климент Кузьмин

О роли Владельца Продукта в корпорациях согласно Scaled Agile Framework® (SAFe®), секторах ответственности, взаимодействии с Agile-командами, другими Владельцами и Менеджерами Продуктов.

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

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

Agile-манифест

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

Product Owner (PO) или Владелец Продукта — это член Agile-команды, который отвечает за определение Историй и их приоритета в Бэклоге Команды в целях оптимизации выполнения первоочередных задач программы, сохраняя при этом концептуальную и техническую целостность Фич или компонентов для команды.

PO играет важную роль в максимальном увеличении ценности продукта, создаваемого командой, и обеспечении того, чтобы реализованные Истории отвечали потребностям пользователя и соответствовали Критериям Готовности (Definition of Done). Для большинства предприятий, переходящих на Agile, это новая и важная должность, обычно предполагающая полную занятость, так как один PO требуется для поддержки каждой Agile-команды (или, самое большее, двух команд).

Эта роль имеет важные связи и обязанности за рамками локальной команды, включая работу с Продуктовым Менеджментом (Product Management), Клиентами (Customers), Представителями Бизнеса (Business Owners) и другими заинтересованными лицами.

Владелец продукта — член Agile-команды, который выступает в роли доверенного лица клиента, ответственного за работу с Продуктовым Менеджментом и остальными заинтересованными лицами, включая других PO, для определения и приоритизации Историй в Бэклоге Команды. Это позволяет Решению (Solution) — продукту, услуге или системе, эффективно определять приоритеты Программы (Фичи и Enablers), сохраняя при этом техническую целостность. В идеале PO находится в одном месте с остальной командой, обычно разделяя с ними единые подходы к менеджменту, стимулам и культуре. Но PO также посещает соответствующие мероприятия Продуктового Менеджмента для планирования, уточнения Концепции (Vision) и Бэклога Программы (Program Backlog).

Обязанности 

PO выполняет следующие обязанности:

Подготовка и участие в PI-планировании 

  • Как член расширенной команды Продуктового Менеджмента, PO активно участвует в уточнении Бэклога Программы и подготовке к Планированию Инкремента Программы (PI-планированию), а также играет важную роль в самом мероприятии по планированию. Непосредственно перед этим мероприятием PO, как правило, анализирует Бэклог Команды и вносит свой вклад в концепцию программы, Дорожную Карту (Roadmap) и содержание презентаций.
  • Во время мероприятия PO участвует в определении Историй, предоставляя необходимые разъяснения, чтобы помочь команде с оценкой Историй и порядком их реализации. Agile-команда вместе с входящим в нее PO в сотрудничестве друг с другом работает над определением командных целей для предстоящего Инкремента Программы (Program Increment (PI)).

Выполнение Итерации

  • Поддержка Бэклога Команды — при участии Системного Архитектора/Инженера (System Architect/Engineering) и других заинтересованных лиц, PO несет основную ответственность за формирование, изменение и поддержание в актуальном состоянии Бэклога Команды. Состоящий в основном из пользовательских Историй, бэклог также включает дефекты и Enablers. Элементы Бэклога распределяются по приоритетам на основе пользовательской ценности, времени и других зависимостей команды, определенных во время PI-планирования и уточняемых во время реализации PI.
  • Планирование Итерации — PO просматривает и изменяет приоритеты Бэклога в рамках подготовительной работы к Планированию Итерации, включая координацию зависимостей с другими PO. Во время Планирования Итерации PO сообщает подробности Истории и приоритеты, а также обеспечивает согласованность и утверждение командой окончательного плана Итерации.
  • Своевременная разработка Историй — большинство элементов Бэклога разрабатываются в формате пользовательских Историй. Это может произойти в любое время до начала Итерации, во время планирования Итерации или во время Итерации. Любой член команды может разрабатывать Истории и их Критерии Готовности, но PO поддерживает надлежащий ход этой работы.
  • Применение BDD (Behavior-Driven Development) – Владельцы Продукта сотрудничают со своей командой, чтобы детализировать Истории с Критериями Готовности и примерами в форме приемочных тестов.
  • Приемка Историй — РО работает с командой, чтобы согласовать приемлемый вариант завершения Истории. Это включает проверку: наличие соответствующих постоянных приемочных тестов и что в остальном она соответствует Критериям Готовности. При этом PO также обеспечивает определенный уровень качества, ориентируясь в первую очередь на пригодность к использованию.
  • Понимание работы Enabler — хотя не ожидается, что Владельцы Продукта будут управлять технологическими решениями, они должны понимать объем предстоящей работы Enabler и сотрудничать с Системным Архитектором/Инженером, чтобы помочь с принятием решений и определением последовательности критически важных технологических инфраструктур, которые будут обеспечивать реализацию нового бизнес-функционала. Зачастую лучше всего этого добиться, установив распределение нагрузки.
  • Участие в командной демонстрации и ретроспективе  — PO сотрудничают со своей командой и любыми другими заинтересованными лицами на командной демонстрации. Они также принимают участие в Ретроспективе Итерации, где команды собираются, чтобы улучшить свои процессы, и активно участвуют в сессии Инспекции и Адаптации (Inspect and Adapt, I&A) Agile Release Train (ART).

Выполнение Программы

  • Итерации и Agile-команды служат важной цели: частый, надежный и непрерывный выпуск решений с добавленной ценностью. Во время каждого PI Владелец Продукта координирует зависимости с другими POs. Это часто происходит во время еженедельных мероприятий PO Sync.
  • PO также играет важную роль в подготовке Системной Демонстрации (System Demo) для заинтересованных лиц программы и потока создания ценности (Value Stream).

Инспекция и Адаптация 

  • Команды решают свои наиболее серьезные проблемы на I&A-встрече. Там PO работает с командами, чтобы определить и внедрить истории улучшений, которые повысят скорость и качество Программы.
  • Системная Демонстрация PI (PI System Demo) является частью I&A-встречи. Владелец Продукта играет важную роль в организации и проведении Системной Демонстрации PI для заинтересованных лиц Программы.
  • Чтобы гарантировать показ наиболее важных аспектов решения заинтересованным лицам, Владельцы Продуктов также участвуют в подготовке Системной Демонстрации PI.

Состав полномочий

SAFe® использует ряд артефактов, таких как Фичи, Истории, Нефункциональные Требования, артефакты дизайна и прочее, чтобы направлять ART во время создания решения. Бэклог Программы и Бэклог Команды определяют приоритетность этих рабочих элементов. Продуктовый Менеджер (Рroduct Мanager) и Владелец Продукта управляют Бэклогами и их приоритетами. Это сотрудничество работает наиболее эффективно при использовании дизайн-мышления (Design Thinking) и таких инструментов Непрерывного Изучения как Персоны (Personas), Карты Эмпатии (Empathy Maps), Карты Пути Клиента (Customer Journey Maps), Карты Историй (Story Maps), которые приносят открытия и больше понимания.

Ниже приведены рекомендации по разграничению обязанностей между этими ролями. В зависимости от размера и архитектуры решения (и в некоторой степени от культуры организации) полномочия могут стать более децентрализованными, смещаясь вправо. Например, стабильные Agile-команды, которые становятся все более осведомленными о проблемах клиентов и контексте решения, способны напрямую вносить непосредственный вклад в Фичи и Истории для управления продуктом (см. Принцип SAFe № 9 — Децентрализация принятия решений).

Менеджер Продукта Владелец Продукта Agile-команда
Управляет PI и продуктом Управляет Итерацией Управляет выполнением Программы
Владеет Бэклогом Программы Владеет Бэклогом Команды Встраивает качество и развивает Agile-архитектуру
Определяет Фичи, Инкременты Программы и Релизы Определяет Итерации и Истории Определяет оценки
Владеет Концепцией, Дорожной Картой, ценообразованием, лицензированием и возвратом инвестиций (ROI) Участвует в разработке Концепции, Дорожной Карты, возврата инвестиций (ROI) Развивает Конвейер Непрерывной Поставки (Continuous Delivery Pipeline, CDP)
Участвует в обсуждении Enablers Принимает Инкременты Итераций
Создание правильных вещей… …Создание вещей правильно

Модель взаимодействия Менеджера Продукта, Владельца Продукта и Agile-команд

Успешная разработка в крупной организации — это отчасти игра в числа. Без нужного количества людей на нужных ролях «узкие места» будут сильно ограничивать скорость. Следовательно, количество Менеджеров Продукта, Владельцев Продукта и Agile-команд должно быть примерно сбалансированным, чтобы управлять ART. Иначе вся система будет тратить большую часть своего времени в ожидании определения, разъяснения и принятия решений. Вместо этого SAFe рекомендует модель разветвления, как показано на рисунке ниже.

Как правило, в схеме взаимодействия в рамках единой концепции участвуют:

  • Менеджер Продукта, ориентированный на рынок/клиента.
  • Владелец Продукта, ориентированный на решение, технологию и команду.
  • Agile-команды, ориентированные на реализацию.

Каждый Менеджер Продукта обычно может поддерживать до четырех Владельцев Продукта, каждый из которых может отвечать за Бэклог одной или двух  Agile-команд.

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

Автор
Климент Кузьмин
Эксперт в запуске продуктов с 0. Участвовал в реализации более 30 продуктов. Основатель и играющий тренер в школе Продакт менеджеров Product School  Личный профиль на Facebook   Ключевые реализованные продукты: ...
Другие статьи
25 апр 2021, Алексей Трещилов
Эффективный шаблон описания Фичей в SAFe®

Шаблон описания Фичи от Марка Ричардса, поддерживающий следование Lean UX.

3 апр 2021, Александр Троицкий
Relentless Improvements или долгий путь стратегических и тактических изменений

История Технологического Центра Дойче Банка про 3 года трансформации в сторону выстраивания команд вокруг цепочек создания ценности.

2 апр 2021, Андрей Гирин
Эволюция Потребности или в прошлом квартале было по-другому

История Ак Барс Банка про эволюцию процесса управления бэклогом портфеля на протяжении года.