Владелец продукта во фреймворках масштабирования: LeSS, Nexus, SAFe®
Это третья часть цикла из 4-х статей про Менеджера продукта и Владельца продукта, которая поможет вам понять, откуда взялся весь продуктовый менеджмент.
С популярностью Agile-подходов в обиходе менеджмента компаний начали использовать термин Владелец продукта. Хотя для многих до сих пор остается загадкой, чем эта новая роль отличается от Менеджера продукта. А еще больше путаницы добавляет тот факт, что и product manager и product owner стали сокращенно называть «продакт».
В этом цикле статей попробуем найти ответы на следующие вопросы:
- Product Manager и Product Owner — это разные роли?
- Кто кому подчиняется?
- У кого больше полномочий и зона ответственности?
Для поиска ответов пришлось изучить несколько десятков статей и книг по темам product management и product ownership. В первой части мы рассмотрели историю появления деятельности по управлению продуктом (product management). Во второй части разобрали историю появления и эволюции владельца продукта. В этой статье разбираемся, а чем же отличается роль владельца продукта в зависимости от фреймворка масштабирования Nexus, LeSS и SAFe. Завершим цикл статей сравнением полномочий, зон ответственности и компетенций. Садитесь поудобней, начинаем разбор масштабирования роли владельца продукта.
Первая часть: История появления и развития Product Management
Вторая часть: История появления и развития роли Product Owner
В этой статье не рассматриваем особенности фреймворков масштабирования и области их применения, а смотрим только на то, как меняется наполнение определения владелец продукта.
LeSS (Large-Scale Scrum)
В 2005 году Крэг Ларман и Бас Водди объединились для совместной работы по масштабированию cкрама у крупных клиентов, так появился фреймворк LeSS.
LeSS is Scrum applied to many teams working together on one product.
Роль владельца продукта в LeSS концептуально совпадает с ролью в scrum по версии руководства по Скрам 2017. В LeSS один владелец продукта может охватывать до восьми scrum команд, которые работают над одним бэклогом продукта. владелец продукта поощряет и помогает командам напрямую работать с реальными пользователями и клиентами для актуализации элементов Бэклога. При этом владелец продукта действует как связующее звено, а не как посредник. Фокус внимания владельца продукта в LeSS смещается в сторону видения продукта и обеспечения максимальной отдачи от инвестиций в продукт (ROI — Return on Investment, возврат инвестиций).
The Product Owner focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.
В LeSS делается акцент на прямом взаимодействии команд разработки и клиентами по трем причинам:
- Это предотвращает искажение и потерю информации, которая возникает при наличии передаточных звеньев.
- Это способствует коллаборации разработчиков и клиентов при создании решений, что позволяет лучше решать проблемы пользователей.
- Это повышает мотивацию и эмпатию разработчиков к пользователям.
В том случае, если ваш масштаб более 8 команд в продукте, то в игру вступает LeSS-Huge. В этой ситуации у владельца продукта появляется несколько помощников — Area Product Owner (APO — владелец области продукта. Каждый из APO вместе с минимум тремя командами отвечает за развитие определенной клиент-ориентированной области продукта, важное замечание, что у APO нет своего бэклога продукта, сколько бы не помогало владельцу продукта APO, бэклог продукта остается единым для всех команд. В общем и целом, владелец продукта в LeSS — это хорошо уже нам знакомый product owner из scrum.
Nexus
В 2015 году Кен Швабер выпускает фреймворк Nexus, который основан на фреймворке Scrum с некоторыми доработками.
Nexus is a framework for developing and sustaining scaled product delivery initiatives.
Во фреймворке nexus, так как автором является один из основателей scrum, определение владельца продукта перекочевало из scrum guide 2020 с некоторыми особенностями фреймворка.
The Product Owner is accountable for maximizing the value of the product and the work performed and integrated by the Scrum Teams in a Nexus.
В Nexus несколько Scrum команд (от 3 до 9 команд) работают с одним бэклогом продукта и управляет им один владелец продукта. И как мы видим, в Nexus, владелец продукта всё тот product owner из scrum.
Scaled Agile Framework®
В 2011 году Дин Лёфингвэлл представил первую версию SAFe 1.0.
SAFe® for Lean Enterprises is a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps.
В SAFe дела с Владельцем продукта обстоят куда интересней, но замечу, что SAFe не говорит о том, что это фреймворк масштабирования Scrum. И всё же, в SAFe используется термин Product Owner, поэтому давайте разбираться с самым популярным фреймворком масштабирования Agile-практик.
Во-первых, на уровне команд в SAFe находится не scrum, а ScrumXP (созданный SAFe-сообществом скрамоподобный процесс). В нем — отличное от оригинала понимание роли владельца продукта. Во-вторых, в SAFe имеются еще две роли, которые участвуют в управлении ценностью продукта, — Product Manager и Business Owner. Давайте рассмотрим все пазлы по отдельности для полной картины.
Начнем с определения ScrumXP:
ScrumXP is a lightweight process to deliver value for cross-functional, self-organized teams within SAFe. It combines the power of Scrum project management practices with Extreme Programming (XP) practices.
Как видно из определения, это точно не хорошо нам знакомый scrum, это процесс в котором работают кросс-функциональные и самоорганизующиеся команды, которые используют практики экстремального программирования и scrum.
Теперь давайте посмотрим на определение владельца продукта (PO — Product Owner):
The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team. The PO has a significant role in maximizing the value produced by the team and ensuring Stories meet the user’s needs and comply with the Definition of Done. This role has significant relationships and responsibilities outside the local team, including working with Product Management, Customers, Business Owners, and other stakeholders.
Важно отметить, что в SAFe Владелец Продукта управляет Бэклогом Команды, а не бэклогом продукта. Product Owner в SAFe несет ответственность за определение и создание историй (краткое описание небольшой части желаемой функциональности, написанное на языке пользователя) и приоритезацией бэклога команды. Также владелец продукта в SAFe взаимодействует с менеджментом продукта, клиентами, представителями бизнеса (Business Owners) и другими заинтересованными лицами.
Возможно, мы сможем разглядеть облик владельца продукта в других ролях SAFe? Следующим по иерархии идет менеджер по продукту (PM — product manager, так же может быть группа лиц product management).
Product Management is responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle. To do this, they collaborate with a wide range of people to identify and define customer needs, understand the Solution Context, and develop the Program Vision, Roadmap, and Features required to meet these needs. The role scales in relation to the complexity of a solution: some solutions may only need a single Product Manager while others will need a team.
В SAFe ответственность за управление ценностью продукта на всём жизненном цикле возлагается на менеджера по продукту. Вот тут мы уже можем разглядеть облик владельца продукта из scrum. Также, мы видим, что большая часть зоны ответственности владельца продукта из cкрам, осела в роль менеджера по продукту: исследования клиентов, создания vision, построение roadmap и т.д.
Давайте посмотрим, есть ли что-то от владельца продукта у представителей бизнеса (BO — Business Owners). В SAFe business owners — это небольшая группа заинтересованных лиц (топ-менеджмент), которая отвечает за риски на уровне бизнеса и несет ответственность за показатель возврата инвестиций (ROI).
Business Owners Business Owners are a small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART).
Вот и нашлись недостающие пазлы владельца продукта из cкрам, но эти пазлы являются составляющими владельца продукта с практической стороны. С точки зрения руководства по Scrum и Nexus, эти составляющие называются одной фразой — максимизация ценности продукта. В LeSS например, есть более детальное, по сравнению с руководством по scrum, описание взаимодействия владельца продукта с клиентами, стейкхолдерами, командой и скрам-мастером, где можете найти практические составляющие роли владельца продукта.
Итого, если пытаться найти владельца продукта из scrum в SAFe, то ищите его отражения в трех ролей: PO team+PM+BO.
Когда собирал материалы для статьи, то заметил, что в англоязычных статьях на тему сравнения “Product Owner vs Product Manager”, авторы часто ссылаются на определения взятые из SAFe®. Мне кажется, что это одна из основных причин, почему многие считают владельца продукта человеком, плотно работающим с командой разработки для обслуживания интересов менеджеров по продукту и топ-менеджмента.
На этом мы заканчиваем рассматривать многогранного владельца продукта. Надеюсь, вам удалось расширить собственную картину и понимание роли product owner. В следующей части собираем и сравниваем навыки и полномочия product manager и product owner.
Подключайтесь к Telegram-каналу, где мы делимся практиками и опытом.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
Хочу рассказать вам о методе Бережливого планирования продуктов и месте, которое он занимает в современной деятельности по созданию технически сложных и комплексных продуктов, таких как беспилотный автомобиль, аэротакси или современные космические ракеты. А заодно порассуждать, почему некоторые технологические стартапы превращаются в глобальные корпорации, как например Tesla, а некоторые входят в анналы истории как имена нарицательные для обозначения кринжовых концепций и безумных проектов, например как ё-Мобиль.
Что такое минимально жизнеспособный продукт (MVP)? Почему MVP так важен в процессе разработки и как его эффективно использовать? В этой статье ответим на все эти вопросы и посмотрим примеры самых узнаваемых брендов, история которых начиналась с MVP.
Обсудим, как написать хорошую User Story, какие существуют паттерны декомпозиции пользовательских историй, как их использовать и главное — зачем на самом деле декомпозиция нужна команде.