Самостоятельная путаница между владельцем продукта и менеджером продукта, которая понизила владельца продукта в должности
Неспособность Scrum охватить мир управления продуктами путем введения отдельной ответственности владельца продукта (PO) была ошибкой. Все началось с добрых намерений, чтобы дать менеджеру по продукту (PM) больше полномочий, назвав его владельцем продукта.
Теперь мы можем с уверенностью сказать, что ребрендинг владельца продукта имел неприятные последствия. Владельцы продукта обычно имеют меньше полномочий, чем менеджеры продукта. Это противоположно тому, чего должен был достичь ярлык владельца продукта.
Когда вы разговариваете с менеджерами по продукту и объясняете им, что владелец продукта на самом деле является человеком, который несет наибольшую ответственность за продукт, они смотрят на вас с недоверием.
Существует большой разрыв между миром управления продуктами и сферой Scrum, и я вижу, что он только увеличивается, если неправильные представления об управлении продуктами не будут лучше рассмотрены в Руководстве по Scrum.
С решением переименовать менеджера продукта в владельца продукта возникшая путаница привела к тому, что мир управления продуктом постепенно ускользнул за пределы сферы Scrum. Путаница с владельцем продукта — вот почему у нас до сих пор ведутся дискуссии между менеджером продукта и владельцем продукта.
Люди начали придавать собственное значение роли владельца продукта, потому что эта роль не масштабируется. *Пуф* из ящика Пандоры сбежал сумасшествие подбоченившегося менеджера по продукту/владельца продукта. Бюрократическое решение, которое категорически не нравится как сообществу Product Management, так и Scrum-сообществу.
Теперь мы видим, как менеджеры по продукту работают вне спринта вместе с владельцами продукта. В такой схеме Владельцы Продукта оказываются в ловушке пузыря Спринта, и им обычно предоставляется меньше прав на максимизацию доставки ценности, чем Менеджеру Продукта.
Даже в компаниях, в которых нет менеджеров по продукту, многие из них даже не имеют настоящих владельцев продукта. Ярлык Product Owner на практике означает совсем другое, чем в теории. Компании обычно имеют несколько владельцев продукта для каждого продукта, а не одного владельца продукта, что нарушает правило единого владельца продукта для каждого продукта.
К сожалению, сообщество Scrum, похоже, не желает проверять и адаптироваться. Он цепляется за идеал Владельца Продукта, который редко используется на практике и не масштабируется. Проще указать пальцем и заявить, что люди с решениями PM/PO или несколькими PO для каждого продукта не используют Scrum.
Как мы оказались в этой сумасшедшей ситуации? И что нам с этим делать?
Давайте начнем возвращаться в историю Scrum, чтобы увидеть, как появился Владелец Продукта.
Менеджер по продукту и менеджер по продукту постепенно уходят из Scrum
В ранних описаниях Scrum управление продуктами занимало гораздо более заметное место, чем сейчас.
В основополагающем документе OOPSLA 1995 года о Scrum управление продуктом и менеджер продукта обсуждаются ровно один раз. Может показаться, что это немного, но имейте в виду, что ни одно слово не посвящено Владельцу Продукта или Скрам-мастеру. Оба они еще не вошли в картину.
Давайте посмотрим на описание Product Manager:
«Управление: под руководством менеджера по продукту он определяет начальное содержание и сроки выпуска, а затем управляет их развитием по мере развития проекта и изменения переменных. Менеджмент занимается отставанием, рисками и выпуском контента». - Процесс разработки Scrum, OOPSLA, 1995 г.
Резюмируя этот абзац: руководство отвечает за управление невыполненной работой с продуктом, и им руководит менеджер по продукту.
Наблюдаем ли мы первые ростки роли Владельца Продукта под личиной Менеджера Продукта? Я так считаю.
Меня не впечатляет то, как описаны обязанности менеджера по продукту. Описание имеет больше общего с менеджером проекта, чем с менеджером продукта.
Кроме того, ни одно слово в этом фрагменте не говорит о ценности. На самом деле, во всей статье значение слова упоминается ноль раз. Для сравнения с текущим Scrum Guide: там слово value упоминается 25 раз.
Давайте посмотрим, что написано в статье, когда мы ищем «Управление продуктом»:
«За каждым спринтом следует обзор, характеристики которого таковы:
Вся команда и управление продуктом присутствуют и участвуют». - Процесс разработки Scrum, OOPSLA, 1995 г.
Управление продуктом упоминается отдельно как важная заинтересованная сторона, которая должна присутствовать на обзоре спринта. Остальное сосредоточено под ярлыком всей команды. Присутствие менеджера по продукту на обзоре спринта очень похоже на текущую важную роль владельца продукта на обзоре спринта, верно?
Присутствие менеджера по продукту на обзоре спринта — это второй проблеск того, что в конечном итоге превратится в роль владельца продукта. Для меня совершенно очевидно, что менеджер продукта и управление продуктом, о которых идет речь, позже попадут в компетенцию владельца продукта.
Но подождите, есть еще! В первом воплощении Руководства по Scrum, где описана роль Владельца Продукта, появляется следующий совет:
«Для коммерческой разработки владельцем продукта может быть менеджер по продукту. Для внутренних разработок Владелец продукта может быть менеджером пользовательского отдела». - Руководство по скраму, версия 1, 2010 г.
Теперь пусть не будет путаницы: роль владельца продукта уходит своими корнями в управление продуктом. На него налепили красивый ярлык, который может создать впечатление или иллюзию, что это что-то другое, но в конце концов Владелец Продукта должен быть Менеджером Продукта!
Какая идея стояла за тем, что основатели Scrum решили по-другому называть менеджера по продукту?
Почему менеджер продукта Scrum был переименован в владельца продукта?
Я считаю, что причиной ребрендинга Менеджера продукта в качестве Владельца продукта было четкое указание широкой полноты владения продуктом.
Ярлык «Владелец» без малейших сомнений установил бы, что продуктом владеет один человек, а не несколько человек. Часть собственности считалась более важной, чем четкое понимание необходимости управления продуктом для владельца продукта.
Руководство по Scrum не остановилось на ребрендинге менеджера продукта как владельца продукта. В последней версии Руководства по Scrum 2020 года любое упоминание слова «Управление продуктом» было удалено, что еще больше увеличило разрыв между Scrum и Управлением продуктом.
Я предполагаю, что цель состояла в том, чтобы сделать руководство по Scrum более общим, чтобы его можно было еще лучше адаптировать к вашему конкретному контексту. Однако это только добавило путаницы между Владельцем Продукта и Управлением Продуктом.
Придумывание новой роли владельца продукта, а затем полное удаление управления продуктом из Scrum было большой ошибкой, которая теперь успешно используется масштабируемыми фреймворками, такими как Scaled Agile Framework (SAFe), для понижения уровня владельца продукта до владельца командного бэклога.
Проблема в том, что это не просто фреймворки масштабирования.
На прошлой неделе владелец продукта в LinkedIn рассказал мне, что, когда его менеджер по продукту ушел, бывший коллега посоветовал ему подать заявку на должность менеджера по продукту, так как это будет продвижение по службе. Писать об этом кажется мне абсурдным, но я слышу это не в первый раз.
Более серьезная проблема заключается в том, что, по моему опыту, эти понижения уровня владельца продукта являются не изолированными случаями, а системными. Расскажу историю из личного опыта.
Я помню, как мой менеджер сказал мне, что мы все делаем неправильно и что мы должны нанять менеджеров по продукту, чтобы они работали вместе с нашими владельцами продукта. Я пытался спорить и объяснять идею роли Владельца Продукта, но безрезультатно.
В конечном итоге решение о совместной работе менеджеров по продукту и владельцев продукта было отменено. Никто не был доволен этой договоренностью, и все менеджеры по продукту и владельцы продукта не верили, что она работает.
Я полагаю, что эти недоразумения становятся возможными, потому что Руководство по Scrum не имеет прямой, явной связи между владельцем продукта и его возможностями управления продуктом. Ярлык «Владелец продукта» не звучит достаточно серьезно или тяжело для реальной роли. Должность менеджера по продукту имеет больший вес, чем должность владельца продукта. Это абсурдно, когда вы понимаете, что истинная ответственность владельца продукта намного выше, чем у обычного менеджера продукта.
По мере роста числа Скрам-команд совершенно неясно, как должны масштабироваться действия по управлению продуктами. Для каждого продукта недостаточно одного владельца продукта, кроме нескольких команд, а опыт управления продуктом нелегко делегировать.
Несмотря на то, что история Scrum и Руководства по Scrum показывает, что в прошлом существовала явная связь между Управлением продуктом и владельцем продукта, эта связь была полностью разорвана в Руководстве по Scrum 2020 и в популярной практике Scrum.
Вуаля, вот и мы сейчас, когда люди ведут дискуссии между менеджером продукта и владельцем продукта и масштабируют фреймворки, используя путаницу, создавая ложное разъединение между менеджером продукта и владельцем продукта.
Ложный разрыв между менеджментом продукта и владельцем продукта
Вот комбинация PM/PO, предложенная SAFe и ставшая возможной благодаря иллюзорному разрыву между управлением продуктом и владением продуктом:
Единственная причина, по которой шаткое решение PM/PO становится доступным, заключается в том, что люди не понимают, в чем разница между менеджером по продукту и владельцем продукта. Владелец продукта кажется менее важным, чем менеджер продукта. Следовательно, это решение, заключающееся в том, что менеджер по продукту направляет запросы владельцу продукта, имеет смысл для людей, незнакомых со Scrum.
Scrum определяет владельца продукта как ответственность, принадлежащую одному человеку. Тот, кто в конечном итоге несет ответственность за ценность продукта, поставленного Скрам-командой. Кто выполняет обязанности Владельца Продукта, значения не имеет. Эти обязанности могут быть делегированы любому, кто способен это сделать.
Когда у вас несколько команд, продакт-менеджером может быть один человек. За пределами нескольких команд это становится трудным, если не невозможным. Я считаю, что именно поэтому сегодня мы видим разделение между менеджерами по продукту и владельцами продукта — чтобы иметь дело с масштабом, потому что Scrum не предлагает адекватного готового решения.
В зависимости от контекста и масштаба вашей организации вашим владельцем продукта может быть генеральный директор, директор по продукту (CPO), вице-президент по продукту, (старший) менеджер по продукту. Тот, кто в конечном итоге несет ответственность за максимизацию ценности Продукта. Вот почему подход, при котором PM отправляет запросы PO, не имеет смысла.
Путаница усугубляется тем фактом, что люди ошибочно полагают, что владение продуктом и управление продуктом — это разные вещи. Да, Владелец Продукта — это ответственность, но эта ответственность бессильна без управления продуктом на уровне команды.
Мы должны напомнить себе, что комбинация PM/PO — это благонамеренное решение проблемы, которую не масштабирует один владелец продукта, несущий ответственность и обязанности.
Уполномоченным командам требуется опыт управления продуктами для коротких циклов обратной связи по ценности.
Scrum говорит о наделенных полномочиями/самоорганизующихся/самоуправляемых командах, а это означает, что опыт управления продуктом, если необходимо, является частью команд, которые выполняют работу. Либо через владельца продукта, если у вас мало команд, либо благодаря опыту управления продуктом в составе вашей команды разработчиков.
И менеджеры по продукту, и сообщество Scrum осознают важность наделенных полномочиями команд. Вот почему Scrum-команды не должны полагаться на одного человека вне команды, чтобы получить полномочия. Насколько у вас есть полномочия, если вы должны выполнять каждый запрос через одного человека, называемого владельцем продукта?
Вот как это будет выглядеть, если у вас есть один владелец продукта для каждого продукта со многими командами и опытом управления продуктом в составе Scrum-команд:
Растущий разрыв между владением продуктом и управлением продуктом
Пришло время для тревожного звонка в сообществе Scrum: вместо того, чтобы указывать на то, чего должен был достичь ярлык Владельца Продукта, давайте взглянем на обломки и путаницу, которые он оставляет после себя, и возьмем на себя ответственность.
Один владелец продукта для каждого продукта не может масштабироваться, если в командах нет специалистов по управлению продуктами. Как вы называете человека, который приносит знания командам, менеджером по продукту, владельцем продукта или кем-то еще, не имеет значения. Это просто семантика. Это даже не обязательно должен быть отдельный заголовок, если он присутствует.
В шквале самостоятельно придуманных и запутанных объяснений Владельца Продукта, которые существуют в дикой природе, максимизация доставки ценности с помощью Scrum вытащила самую короткую соломинку. Это то, о чем мы все, практикующие Scrum, должны беспокоиться.
Давайте снова уделим управлению продуктом центральное место в Руководстве по Scrum. Давайте определим, как это должно быть, вместо того, чтобы давать волю воображению внешнего мира.
Давайте изменим ярлык «Владелец продукта» на более понятный. Соответствие существующим этикеткам, хорошо известным в сообществе управления продуктами, может быть хорошим началом. Никто в здравом уме не посмеет предложить решение PM — CPO.
Таким образом, Scrum может получить шанс противостоять решениям Frankenstein PM/PO, которые делают людей несчастными во всем мире и снижают производительность.
