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

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

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

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

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

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

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

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

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

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

Стратегия

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

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

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

Обязанности

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

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

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

Клиенты

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

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

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

Влияние

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

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

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

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

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

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы