Владелец продукта и прокси-владелец продукта
Коротко Во многих гибких командах владелец продукта не может быть с командой каждый день, поэтому его повседневным голосом становится прокси-владелец продукта — часто бизнес-аналитик. Такая схема работает, только если обе стороны договорились, кто что решает. На этой странице — практическое разделение обязанностей.
По материалам: учебные материалы по бизнес-анализу (матрица ответственности PO/PPO); IIBA, Руководство BABOK® v3, разд. 11 (ракурс Agile).
На этой странице
Главные идеи#
Зачем нужна роль прокси-владельца#
Ракурс Agile в Руководстве BABOK® отмечает, что роль аналитика в гибкой команде может играть владелец продукта, менеджер продукта, бизнес-аналитик или кто-то ещё. На практике владельцами продукта часто бывают руководители высокого уровня со стороны бизнеса, и времени у них мало. Этот разрыв закрывает прокси-владелец продукта (proxy product owner, PPO): он доступен команде каждый день, но действует от имени владельца продукта (product owner, PO), за которым остаётся направление развития продукта.
Что остаётся за владельцем продукта#
Матрица ответственности, которую используют на обучении бизнес-анализу, делит обязанности PO на пять областей:
- Владение. Решает, что делать и в каком порядке; владеет видением, стратегией, дорожной картой и бэклогом продукта.
- Направление. Ставит цели проекта и релизов, понимает бюджет и ограничения, следит за ходом работ.
- Требования. Определяет темы и эпики («что»), оценивает влияние новых бизнес-запросов, рассматривает и утверждает пользовательские истории, критерии приёмки и критерии готовности (DoD).
- Работа с командой. Служит источником знаний для PPO, участвует в планировании, уточнении бэклога и обзорах, задаёт цель спринта, принимает или отклоняет результаты.
- Координация. Управляет ожиданиями как руководства, так и команды, поддерживает приёмочное тестирование и обучение бизнес-пользователей, работает с другими ИТ-командами и заинтересованными сторонами, разрешает конфликты.
Что делает прокси-владелец продукта#
Та же матрица отводит PPO четыре области:
- Коммуникация. Эскалирует вопросы к PO, изо дня в день говорит от его имени, следит, чтобы команда понимала требования.
- Требования. Разбивает эпики на пользовательские истории для бэклога спринта, пишет подробные критерии приёмки, каждый день отвечает на уточняющие вопросы, выявляет детальные требования у заинтересованных сторон из бизнеса.
- Поддержка PO. Проводит демонстрации для бизнеса, делает быстрые проверки работоспособности (sanity checks) в тестовой и рабочей среде, согласует цель спринта с PO.
- Часть команды. Помогает поставлять продукт, готовит технические артефакты, вместе с тестировщиками составляет тестовые сценарии.
Закономерность видна сразу: за PO — направление и решения, за PPO — детали и доступность.
Как применять#
- Письменно согласуйте разделение в самом начале. Используйте шаблон ниже. Пройдите его строка за строкой с PO и командой.
- Определите границы решений PPO. Например: PPO может менять порядок историй в рамках цели спринта, но любое изменение цели спринта или границ релиза решает PO.
- Задайте ритм эскалации. Постоянная еженедельная встреча с PO плюс канал для блокирующих вопросов, на которые нужен ответ в тот же день.
- Не давайте PO пропасть из виду. PO по-прежнему должен приходить на обзоры спринта и принимать результаты; иначе команда теряет связь с тем, кто на самом деле принимает решения.
- Пересмотрите разделение через несколько спринтов. Поправьте его там, где решения застревают, или там, где PPO решает без полномочий.
Шаблон#
| Обязанность | PO | PPO | Примечания |
|---|---|---|---|
| Видение продукта, дорожная карта | Отвечает | Участвует | |
| Порядок бэклога (уровень релиза) | Решает | Предлагает | |
| Эпики и темы | Определяет | Уточняет | |
| Пользовательские истории и критерии приёмки | Утверждает | Пишет | |
| Ежедневные пояснения для команды | Только эскалация | Отвечает | |
| Цель спринта | Задаёт | Согласует с PO | |
| Обзор спринта: принять или отклонить | Решает | Демонстрирует | |
| Детальное выявление требований с бизнес-пользователями | Поддерживает | Отвечает | |
| Приёмочное тестирование (UAT) и обучение бизнес-пользователей | Отвечает | Поддерживает | |
| Тестовые сценарии с QA | — | Отвечает | |
| Конфликты заинтересованных сторон | Разрешает | Эскалирует | |
Пример#
В «Мастерской», вымышленной сети из 12 веломастерских, владелец сети выступает владельцем продукта для новой системы записи и уведомлений, но большую часть дней объезжает мастерские. Бизнес-аналитик становится PPO для внешней команды разработки. Они договариваются:
- Владелец решает, что входит в релиз: сначала онлайн-запись, затем уведомления о статусе, заказ запчастей — позже.
- Аналитик пишет истории и критерии приёмки, каждый день отвечает на вопросы разработчиков и по пятницам во второй половине дня показывает владельцу результаты спринта.
- Любая история, которая меняет то, сколько платят клиенты или как подтверждается запись, попадает к владельцу до того, как её возьмут в спринт.
Подводные камни#
- PPO без полномочий. Если PPO вынужден эскалировать каждый мелкий вопрос, команда простаивает. Задайте чёткие границы решений.
- Исчезающий PO. Когда PO перестаёт ходить на обзоры, PPO фактически становится владельцем продукта, но без мандата.
- Тихая смена приоритетов. PPO, который незаметно переставляет бэклог, подрывает доверие PO. Делайте изменения видимыми.
- Два голоса. Если PO и PPO дают команде противоречивые ответы, договоритесь, какой канал главный для каждого типа вопросов.
Источники и что почитать#
- Учебные материалы по бизнес-анализу (практические примеры и шаблоны): матрица ответственности владельца продукта и прокси-владельца продукта.
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Разд. 11.1 (ракурс Agile).