История появления и развития роли Product Owner

С популярностью Agile-подходов в обиходе менеджмента компаний начали использовать термин Владелец Продукта. Хотя для многих до сих пор остается загадкой, чем эта новая роль отличается от Менеджера Продукта. А еще больше путаницы добавляет тот факт, что и Product Manager и Product Owner стали сокращенно называть «продакт».

В этом цикле статей попробуем найти ответы на следующие вопросы:

• Product Manager и Product Owner — это разные роли?
• Кто кому подчиняется?
• У кого больше полномочий и зона ответственности?

Для поиска ответов пришлось изучить несколько десятков статей и книг по темам Product Management и Product Ownership. В первой части мы рассмотрели историю появления деятельности по управлению продуктом (Product Management). Сегодняшняя статья посвящена летописи роли Product Owner. И завершим цикл статей сравнением полномочий и зон ответственности. 

Первая часть: История появления и развития Product Management

Всем известно, что термин владелец продукта (Product Owner) пришёл к нам из фреймворка Scrum. И всё же, сам был удивлен, когда узнал, что роль владельца продукта появилась в Скраме не сразу. Заваривайте чай, начинаем разбираться в истории появления владельца продукта.

Scrum и Product Manager

В 1995 году Кен Швабер и Джефф Сазерленд на конференции OOPSLA (“Object-Oriented Programming, Systems, Languages & Applications”) представили Scrum. В документе указано, что управление (management) возглавляет менеджер по продукту, который определяет наполнение и сроки релиза, управляет проектом и рисками по мере его развития. В первом документе про Scrum, управление продуктом возлагается на менеджера по продукту через приоритизацию и наполнение бэклога. 

Основной посыл от авторов Scrum был в следующем: существует команда менеджмента и команды разработки, и чтобы облегчить их коммуникацию, предлагалось Менеджеру по Продукту возглавить команду менеджмента, а скрам-мастеру возглавить команду разработки. То есть основной акцент ставится на процессы коммуникации и разработки, которые направлены на лучшее понимание командами разработки своих заказчиков.

В 1998 году выходит статья SCRUM: An extension pattern language for hyperproductive software development, в которой впервые упоминается Персона, которая единолично должна заниматься приоритезацией бэклога и несла бы ответственность за то, чтобы работа, выполняемая Scrum командой, вела к достижению видения продукта. В статье сообщают, что обычно в компаниях эту должность занимают менеджеры по продукту (product manager) или менеджеры по маркетингу продукта (product marketing manager). 

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

Здесь важно отметить тот факт, что авторы делают акцент на единоличной ответственности за приоритезацию бэклога продукта. При этом, эта таинственная персона все еще рассматривается отдельно от команды разработчиков, которые работают по Scrum. Мне кажется именно эти идеи можно считать начальной точкой формирования роли владельца продукта.

Появление Product Owner

В 2001 году выходит первая книга про Scrum Agile Software development with Scrum от Кена Швабера и Майкла Бидла. И в этой книге нашей “персоне” впервые дали имя — Владелец продукта (Product Owner). Спустя 6 лет после публичной презентации Scrum, эта роль обретает свое название, под которым мы его знаем и сейчас.

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

Получается, бэклог продукта состоит из issues (вопросы/проблемы), конкретных фич и технических задач. В общем, как мне кажется, это “айсберг бэклога”, где на поверхности находятся “видимые” детализированные, оцененные и понятные элементы для команды разработки. А внизу “айсберга бэклога” находятся неопределенные задачи и вопросы, которые остаются “невидимыми” (unworkable) для команды разработки. Думаю, этим авторы хотят подсветить, что в разработке продуктов всегда есть место неопределенности, которая имеет своё место в бэклоге продукта и с которой разбирается владелец продукта. 

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

Также авторы подчеркивают, что владелец продукта — это один человек, а не комитет. Комитеты могут консультировать или влиять на этого человека, но любое лицо или группа людей, желающих изменить приоритеты в бэклоге продукта, должна сначала убедить в этом владельца продукта. Отмечу важный пункт: убедить, а не попросить или дать указание. Также читателям напоминают, что без единого лица, которое осуществляет приоритезацию работы для команд разработки, возникают проблемы, споры и разочарования. И конечно же, чтобы владелец продукта добился успеха в своей работе, все в организации должны уважать его/её решения. Как и раньше, пока еще владелец продукта рассматривается как роль вне Scrum-команды.

Product Owner роль внутри Scrum

В 2003 году в статье Кена Швабера “What is Scrum?” владелец продукта официально включается как роль в Scrum-команду.

Это важный момент, потому что с этих пор ответственность за ценность продукта постепенно начинает распространяться на всю Scrum-команду, а не только на одного владельца продукта.

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

В 2004 году Кен Швабер выпускает книгу Agile Project Management with Scrum, где приводятся истории применения Scrum и подробно описываются элементы фреймворка. Из новенького отметим, что владелец продукта несет ответственность перед теми, кто финансирует проект, за реализацию видения (vision) таким образом, чтобы максимизировать рентабельность инвестиций (ROI). Здесь впервые упоминается термин “максимизация”, да еще и в привязке к ROI, что возлагает на плечи владельца продукта еще больше ответственности.

В 2007 году выходит книга The Enterprise and Scrum, где Кен пишет, что мир разработки продуктов изменился, и теперь Клиенты становятся истинными владельцами продуктов, другими словами, клиенты должны определять, что необходимо сделать в продукте в первую очередь. Кажется, этим Кен явно указывает, что основная задача команд разработки — обслуживать потребности рынка, а не менеджмента. И всё же в компаниях существуют как клиенты, так и топ-менеджмент, и они порой по-разному смотрят на развитие продукта. Ответственность за объединение этих разных взглядов в одной голове возлагается на владельца продукта, который максимизирует ценность и контролирует риски проекта/продукта из спринта в спринт. Кен пишет, что владелец продукта несет ответственность перед высшим руководством за успех или неудачу проекта/продукта. Как мне кажется, Кен сообщает о двух важных вещах. Во-первых, что ключевым заинтересованным лицом становится клиенты. Во-вторых, что в компаниях владельцем продукта является самый высокопоставленный руководитель.

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

Также нам напоминают, что по мере изменения приоритетов и появления новых возможностей мы можем перестроить нашу работу таким образом, чтобы максимизировать рентабельность возврата инвестиций (ROI). 

Мне кажется, что Кен явно обозначает свою позицию относительно владельца продукта в больших компаниях и приравнивает роль к высшему менеджменту. Думаю это сделано для того, чтобы владелец продукта не только играл по придуманным топ-менеджментом правилам, но и на равных выступал в создании этих правил. Сюда входят такие вопросы, как инвестиционная политика компании, показатели ROI, рынки присутствия и способы монетизации.

В 2010 году выходит Scrum Handbook от Джеффа Сазерленда, где нас знакомят со знакомыми по предыдущим книгам и статьям зонами ответственности владельца продукта. И всё же есть пара новых моментов. 

Например, владелец продукта несет ответственность за прибыль и убытки только в том случае, если это коммерческий продукт. А в случае внутренних разработок, владелец продукта отвечает за максимизацию рентабельности расходов на Scrum-команду, другими словами обеспечивать в каждом спринте работу с наивысшей бизнес-ценностью при наименьших затратах. Это интересный пункт: как мне кажется, Джефф отмечает как важность приоритезации элементов бэклога, так и важность того, как будут реализованы эти элементы. Если первая часть — это зона ответственности владельца продукта, то реализация — это зона ответственности команды разработки. Авторы Скрама снова показывают, насколько связаны между собой роли во фреймворке и что каждая роль вносит свой вклад в максимизацию ценности продукта.

Также Джефф посвящает отдельный абзац тому, что владелец продукта — это не менеджер по продукту. Например, автор отмечает, что владелец продукта активней и чаще взаимодействует с командой (в книжке Джефф не называет их командой разработчиков, отмечая, что в команду могут входить разработчики, дизайнеры и тестировщики), регулярно анализируя результаты каждой итерации. Еще одним интересным и, как мне показалось, странным моментом является объяснение роли владельца продукта при работе с несколькими командами. 

Мне показалось странным то факт, что автор Скрама допускает наличие делегатов от владельца продукта в командах, вместо того, чтобы делегировать часть своей работы в команды. Возможно, автор предполагал, что эти представители будут членами команды и заниматься так же созданием инкремента, а возможно, Джефф закладывал фундамент для фреймворков масштабирования Scrum. Комментариев на этот счет в книге не обнаружил.

Первый Scrum Guide 2010 от ScrumAlliance

В первой версии руководства по Скрам в роль владельца продукта собрали следующее:

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

Мне даже стало интересно, почему в первую версию не включили максимизацию ROI и обеспечение финансирования, про которые писали Кен и Джефф. Здесь могу только предполагать, что это было сделано для того, чтобы использование Скрама не воспринималось высшим менеджментом как слишком радикальные изменения, особенно в такой щекотливой теме как финансирование проектов и ROI. А возможно, это было связано с тем, что не так много людей готовы брать на себя столь большую ответственность.

Scrum Guide 2011 от Scrum.org

Давайте посмотрим, что попало в роль владельца продукта в первую версию Scrum Guide от Кена Швабера и Джефа Сазерленда.

Аспекты роли владельца продукта от Scrum.org 2011:

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

И снова ни слова про ответственность за максимизации ROI, обеспечение финансирования, доходы и расходы. Складывается ощущение, что было принято использовать эвфемизм — «максимизация ценности продукта», видимо предполагалось, что его будут расшифровывать, как было задумано авторами.

Для меня долгое время оставалось загадкой следующая фраза, которая сохраняется во всех последующих руководствах по Scrum:

У меня в голове не стыковалось, зачем владельцу продукта делегировать эту работу, если он всё равно остается ответственным. Для себя позже нашел такой ответ, в идеале вся Scrum-команда должна думать о ценности продукта, а не только владелец продукта. Другими словами все участники Scrum-команды помогают владельцу продукта максимизировать ценность продукта. Также в больших и сложных продуктах, быть экспертом во всех аспектах разрабатываемого решения сложно, поэтому владелец продукта часто полагаться на помощь в принятии решений на остальных участников Scrum-команды. Кстати в зрелых Scum-командах часть работы владельца продукта берут на себя участники Scrum-команды, например исследование клиентов, наполнение бэклога продукта и проведение экспериментов.

В первой версии руководства по Скрам от создателей Scrum, мы видим менее конкретную зону ответственности владельца продукта. До появления руководства по Scrum владелец продукта отвечал за максимизацию ROI, доходы и расходы, которые замаскировали под максимизацию ценности продукта. А так же отметили, что способы достижения (максимизации ценности) могут отличаться в зависимости от типов продуктов и организаций. Так же меня не покидает чувство, что это было осознанное срезание углов для более мягкого восприятия и принятия Скрама.

Развитие роли Product Owner в Scrum Guide

В Руководстве по Scrum 2013 (scrum.org) в роли Product Owner произошли минимальные изменения:

Ensuring можно перевести как обеспечивает или гарантирует, в официальной русской версии руководства используется перевод обеспечивает (2011), который был заменен на оптимизирует (2013). По моему мнению, это уменьшение зоны ответственности владельца продукта, потому что “гарантировать или обеспечивать” ценность, предполагает наличие какого-то уровня гарантий или обеспечения, а “оптимизация” предполагает более широкие трактовки и оценки деятельности роли.

Следующее обновление руководства по Скрам прилетело в 2017 году (scrum.org) . В разделе про владельца продукта изменили лишь одно предложение.

С 2017 года владелец продукта максимизирует ценность продукта как результата работы команды разработки. А в 2013 году он максимизировал ценность продукта и ценность работы команды разработки. Предполагаю, что это было сделано для того, чтобы владелец продукта имел одну шкалу определения ценности продукта, которая теперь напрямую связана с тем, что делает команда разработки. Это добавляет прозрачности к оценке работы владельца продукта и предполагает более тесное взаимодействие с командой разработки.

В 2020-м выходит очередное обновление Scrum Guide (scrum.org), где нам сообщают, что теперь ответственность за все продуктовые активности возложена на Scrum Team.

На деле, это фраза — напоминание, которое возвращает нас в 2003 год к статье Кен Швабера “What is Scrum?”, где произошло включение владельца продукта в Scrum-команду.

Далее нам напоминают, что и ответственность за создание ценного инкремента в каждом Спринте также возложена на Scrum-команду, а не только на владельца продукта.

И вишенка на торте свежей версии Scrum Guide — это отказ от термина «роли», теперь владелец продукта, скрам-мастер и разработчики — это зоны ответственности.

Мне кажется, это внесло больше сложности в понимание Scrum, хоть и сделано для того, чтобы сблизить и сплотить Scrum команду, потому как термин “роль” предполагает наличие своих целей, ради которых она служит.

Кое-что также поменялось в разделе про зону ответственности владельца продукта.

На русский язык оба термина могут быть переведены как “нести ответственность”, только вот “responsible” — это ответственность как обязательство за выполнение работы, которая может быть разделена между другими, но не предполагается отвечать за последствия. С “accountable” всё серьезнее, это подотчетность и обязательство за работу, которую также могут выполнять другие люди, но за последствия будет отвечать один человек. Здесь мы видим, что зону ответственности владельца продукта подняли, то есть, он/она единолично отчитывается и отвечает за максимизацию ценности продукта перед заинтересованными лицами.

Аналогично была повышена ответственность владельца продукта за управление бэклогом продукта.

Остальные изменения касаются непосредственно управления бэклогом продукта.

2017: 

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

2020:

• Developing and explicitly communicating the Product Goal
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items;
• Ensuring that the Product Backlog is transparent, visible and understood.

Основным нововведением является пункт “разрабатывает и точно коммуницирует Product Goal”, которой раньше не было в Scrum. Product Goal в руководстве по Скрам имеет два описания.

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

Product Goal — это долгосрочный ожидаемый результат Scrum Team.

Также в руководстве сказано, что команда может достичь или отказаться от Product Goal, прежде чем начнет достигать новую цель. Авторы точно дают нам понять, что Product Goal это центральный элемент вокруг которого владелец продукта фокусирует Scrum Team и осуществляет управление бэклогом продукта. И максимизация ценности продукта теперь также выстраивается на основе Product Goal.

Product Owner vs Product Manager

В 2021 году Джефф (автор и создатель Scrum) сделал пост на Quora, где выразил своё мнение касательно полномочий Владельца Продукта.

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

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

В сухом остатке, владелец продукта — это человек, который несет единоличную и нераздельную ответственность за максимизацию ценности продукта, как результата работы Scrum команды. Как и в чем выражается эта ценность, определяется каждой организацией по своему. Надеюсь, что теперь крылатая фраза «Product Owner = mini CEO» приобрела для вас больше веса.

Третья часть: Владелец продукта в зависимости от фреймворка масштабирования: LeSS, Nexus, SAFe®

Подключайтесь к Telegram-каналу, где мы делимся практиками и опытом.