Портал №1 по управлению цифровыми
и информационными технологиями

Менеджер продукта vs Владелец продукта

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

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

В небольших или средних компаниях, как правило, нет необходимости в разделении этих ролей. Один человек может (и я часто утверждал, что должен) справиться со всеми задачами: определять направление развития продукта и, совместно с командами разработчиков, подробно прорабатывать требования и баланс ресурсов разработки. Но в более крупных организациях в гибких командах обязанности обычно делятся на две части из-за сложности и внимания, необходимого для качественного выполнения каждой задачи.

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

Так зачем же разделять лидера продукта на две роли? Это подталкивает к распределению зон внимания, способствующих развитию бизнеса.

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

Но на самом деле роли не всегда так чётко разграничены. Неопределённые, расплывчатые или частично совпадающие обязанности могут привести к путанице в отношении того, кто чем занимается. А взаимоисключающие взгляды часто вызывают раздражение.

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

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

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

Стратегия

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

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

Как создать правильные отношения? Чаще обсуждайте стратегию. Менеджеру продукта стоит открыто делиться целями с владельцем продукта и обозревать дорожную карту развития продукта. Это помогает владельцу продукта избегать случайных решений при расстановке приоритетов, которые могут противоречить приоритетам бизнеса. В свою очередь, владельцы продуктов должны просить у менеджера продукта разъяснений, что является наиболее важным, всегда стараясь понять, почему.

Обязанности

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

Владелец продукта координирует команду разработчиков. Он фиксирует требования и пользовательские истории, управляет бэклогом продукта и отвечает на вопросы команды разработки о том, что следует создавать дальше. В Agile-командах владелец продукта управляет спринтами и участвует в ретроспективах.

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

Клиенты

Менеджер продукта глубоко знает, чего хотят достичь клиенты и какие у них болевые точки. Помимо создания образов пользователей, менеджеры продукта собирают обратную связь и идеи клиентов, основывающиеся на их пользовательском опыте. Некоторые менеджеры продукта также развивают эмпатию к клиентам, планируя персональные сеансы – онлайн общение с покупателями, чтобы узнать больше об их потребностях и возможностях, которые они хотели бы получить от использования продукта в будущем.

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

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

Влияние

Менеджер продукта возглавляет кросс-функциональную продуктовую команду. Хотя обычно он не управляет людьми, менеджер продукта тесно взаимодействует с сотрудниками отдела продаж, поддержки, маркетинга и ИТ. Он также сообщает о текущем прогрессе руководству и в итоге несёт ответственность за достижение целей бизнеса и развития продукта.

Владелец продукта направляет команду прилагать усилия к развитию продукта. Он работает в тесном сотрудничестве с менеджером продукта и другими участниками продуктовой группы, чтобы определить, над какими задачами команда будет работать дальше. Он также может работать с UX для определения подробных требований и создания макетов.

Как выстроить правильные отношения? Признайте друг друга равными. Хотя у менеджера продукта больше стратегической ответственности, он не важнее, чем владелец продукта или кто-либо ещё в команде. С организационной точки зрения разумно, чтобы владелец продукта не отчитывался перед менеджером продукта, а оба подчинялись одному и тому же человеку (обычно директору по продукту).

В итоге и менеджер, и владелец продукта работают на достижение одной и той же цели – обеспечить качество, которое удовлетворит клиентов.

Конструктивные отношения вырастают из чётко определённых ожиданий и регулярного общения. Но для них также нужны эмпатия, компромисс и гибкость. Например, если объем работы изменился в последнюю минуту, не поддавайтесь желанию обвинить кого-то или подорвать авторитет своего коллеги перед командой. Будьте единым фронтом и работайте вместе, чтобы найти решения, которые устроят всех.

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

А у вас есть примеры того, как могут складываться такие отношения?

by Brian de Haaff
Оригинал статьи 

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Комментариев: 6

  • Елисей

    Директор продукта , менеджер продукта, владелец продукта — один с сошкой семеро с ложкой...

    twitter.com/kupol66/statu...10004992/photo/1

  • Елисей, замечание забавное. Но!

    Если подумать о перечисленных сущностях как о ролях (которые решают опредлеённые задачи, отвечают на определённые вопросы), то от решения каких задач, на Ваш взгляд, можно/стоило было бы отказаться? И почему?

  • Мне кажется, или Brian de Haaff использует терминологию несоклько непривычным образом?

    Product Owner не отвечает за стратегию и за roadmap продукта? Например, в Scrum Guide утверждается обратное.

    Из текста (я на всякий случай и оригинал просканировал) вырисовывается следующая картинка Product Manager (PM) ближе к заказчику, а Product Owner (PO) к команде (delivery).

    И, несмотря на то, что, действительно, в некоторых организациях то, что описано как роль PO в том же Scrum Guide распадется на более чем одну роль (и более одного исполнителя), кажется PO всё же более логичное название для заказчика/бизнеса, чем PM.

    Владелец (Owner) — тот, кто владеет. Менеджер (Manager) всего лишь управляет.

    Accountability vs Responsibility. Governance vs Management. И вот это вот всё.

    • Всё просто. Дяденьки, которые давно-давно писали Scrum Guide, не знали про идею разделения владельца и менеджера. Идея была описана примерно в то же время, когда писали первые Скрам Гайды, но другими людьми и в других книжках. Потому они использовали словосочетание Product Owner с несколько иным смыслом, вкладываемым в слово «Owner».

      А автор заметки разделяет Owner и Manager, но перепутав их местами. Однако перепутал он не по недосмотру, а потому что в части индустрии так теперь сложилось (или складывается) — у продукта есть менеджер, повыше, и владелец, пониже.

      При этом на экзамене EXIN DevOps Master мне попался вопрос — существуют ли в природе менеджеры продукта? И правильный ответ — нет, не существуют 🙂

  • Светлана Сапегина

    Как я понимаю, Brian de Haaff описывает ситуацию, характерную для немелкого энтерпрайза со сложным управленческим контуром в бизнесе и крупными ИТ-продуктами, которые обслуживает сразу несколько продуктовых команд разработки. И особого противоречия со Scrum Guide и подмены в терминах я не вижу.

    Владелец продукта несет ответственность за развитие конкретного продукта, а менеджер продукта отвечает за среду, в которой развивается продукт.

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

    Brian de Haaff показывает нам, как может быть организовано взаимодействие на уровень выше. И в этой истории PO владеет продуктом во вполне скрамовском смысле — несет ответственность за развитие продукта нужными темпами и в верном направлении (по дорожной карте), и он же обеспечивает обратную связь с заказчиками. Сам он заказчиком/бизнесом не является, не хватало ему еще придумывать как доставить счастье пользователям и как строить бизнес-модель, т.е. придумывать бизнес-гипотезы и ставить самому себе новые требования)))

    Что касается дорожной карты, то вообще-то в гайде она вовсе не упоминается. Там есть Цель продукта, нужная для фокусировки команды и ответов на вопросы почему мы делаем то, что делаем? чего ждать в будущем? что важно сделать прямо сейчас?

    Владелец продукта может разрабатывать Цель продукта исходя из личного видения прекрасного или опираясь на ДК(так явно лучше!)). Будет ли он эту карту рисовать сам, или только пользоваться, а создавать PM — вариант дизайна производственной системы. Гайд четко говорит — может делегировать разработку Product Goal, но несет ответственность за то, чтобы эта работа была проделана.

    Тоже самое касается стратегии: PO с точки зрения Scrum Guide должен приземлить ее в повседневную деятельность команды, донести, сфокусировать и применять для оперативного планирования. Но будет ли он сам придумывать эту стратегию или доверится PM, для скрам-команды без разницы.

    Вот и получается, что в сложном и динамичном бизнесе вполне можно отдать стратегические решения Менеджеру продукта, в то время как Владелец продукта будет фокусироваться вокруг оперативного управления развитием, используя инструменты (вижн, стратегию, дорожную карту и т.п), которые подготовил для него менеджер продукта.

    По крайне мере как-то так я поняла ​Brian de Haaff, и мне эта история очень нравится!))

    • Замечание Игоря — не про Scrum Guide. Оно про то, кто над кем стоит по отношению к объекту управления. Автор заметки ставит менеджера выше, владельца ниже. Так, конечно, можно рассуждать, и так в продуктовом управлении и рассуждают. Но с точки зрения «классического» ИТ-менеджмента это бред, должно быть наоборот. Это ещё в начале 2000-х всем объяснили на примере владельца услуги и менеджера услуги, владельца процесса и менеджера процесса. Стройно, красиво, непротиворечиво.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT