Product manager и product owner в чем разница

Чем отличаются Product Manager и Product Owner?

Как только речь заходит об обязанностях менеджера продуктов, мы попадаем в зону большой неопределенности. Разные компании по-разному называют одну и ту же роль, поэтому термины Product Manager и Product Owner постоянно путают, особенно начинающие продакт-менеджеры.

На рынке встречается 2 противоположных мнения.

Я придерживаюсь второй позиции: Product Manager — это профессия и должность, а Product Owner — роль в Scrum. Это не значит, что если у вас в трудовой книжке написано «Владелец продукта», нужно срочно бежать и требовать, чтобы запись исправили на «Менеджера продукта». Вы можете называться как угодно, главное — обязанности, которые вы выполняете, и ответственность, которую несете.

Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.

Чтобы разобраться подробнее, давайте обратимся к «Руководству по Скраму» Кена Швабера и Джеффа Сазерленда.

Владелец Продукта — единственное лицо, спектр компетенций которого позволяет управлять Бэклогом Продукта. Управление Бэклогом Продукта включает:

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

И это мне кажется важным. В Scrum основная роль Product Owner — наполнять (идеи могут исходить не от него), приоритизировать и доносить до команды бэклог продукта. Из этого будут вытекать его обязанности и инструментарий.

Примерно этого же требуют от Junior Product Manager в большинстве компаний.

Говоря о менеджере продуктов (не Junior уровня), мы не ограничиваемся бэклогом. Наша главная задача — исследование рынка, выявление потребностей аудитории, понимание, как работает бизнес и как наш продукт может помочь ему заработать. Подробнее о задачах и инструментах читайте в нашей статье про три грейда в развитии менеджера продуктов.

Подводя итоги

Стандарты профессии менеджера продуктов еще сильно размыты, поэтому по должности сложно определить, чем именно занимается человек. В одной компании CPO может быть менее квалифицированным, чем Middle Product в другой. Product Owner может быть как единоличным владельцем, определяющим направление развития продукта, так и «передатчиком» задач от стейкхолдеров команде.

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

Источник

Product owner: разбор профессии и отличия от product manager

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

В Scrum-команде может быть множество ролей. Одна из них – продакт оунер. В ряде IT-структур он единственный руководитель команды, а иногда его даже сопоставляют с директором. Причем эту должность часто путают с похожей – продакт-менеджер, хотя между ними разница довольно существенная. Давайте разберемся детально. Product owner – кто это, чем занимается, какую зарплату получает, и в чем его отличие от других руководителей в проекте.

Product owner включается в работу, когда видение продукта уже сформировано, и нужно решить как он будет работать. Этот человек отвечает на вопросы:

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

Product owner и product manager: разница

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

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

Но задает траекторию движения именно владелец продукта product owner. На нем же ответственность за промежуточные и конечный результат.

Обязанности product owner

Круг задач такого специалиста достаточно широк. Однако можно выделить несколько ключевых:

Вот за что отвечает product owner. Без такого человека в гибкой разработке мог бы царить реальный хаос. Взаимодействие с заказчиком, стратегия, координация действий команды, финальный результат – все это сфера ответственности продакт оунера. Ни одна современная IT-компаний в Agile-разработке и скрам-методологии не должна обходиться без него.

Product owner: зарплата в Москве и по России

Широкая зона ответственности и круг задач не могут не сказаться на размере заработной платы такого специалиста. Так, согласно hh.ru, в столице продакт оунеры получают в среднем 150-200 тыс. руб. Эта цифра может колебаться в обе стороны в зависимости от компании и опыта претендента.

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

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

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

Кадровое агентство «BGStaff» может найти опытного и перспективного владельца продукта для вашего проекта. В нашей базе есть резюме product owner. Кто это, какие у него обязанности и зарплата, мы рассказали в статье.

Успешен тот бизнес, который всегда на шаг впереди конкурентов. Будьте среди первых!

По всем вопросам свяжитесь с нами любым удобным способом:

Источник

Менеджер Проекта vs Менеджер Продукта: у кого на плечах груз тяжелее?

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

Как часто ваши коллеги путают обязанности обоих менеджеров? Если вы один из PM, то должны были хоть раз в жизни слышать вопрос: «Есть ли вообще разница?»

Итак, Product Manager и Project Manager — совершенно разные роли. Попробуем рассмотреть, в чем разница между двумя стратегическими позициями в ИТ-компаниях, чтобы это больше не вызывало путаницы.

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

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

Чья ноша тяжелее? И что случится, если один из Атлантов опустит руки?

Product Manager vs Project Manager

Продукт — это конечный результат, который вы предоставляете своим пользователям или клиентам. Это может быть физически осязаемый продукт, программная платформа, сервис, приложение или услуга.

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

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

Основные обязанности менеджера продукта и менеджера проекта

Product Manager

Менеджеры по продуктам обычно отвечают за глобальную стратегию продукта, приоритизацию функций и окончательную версию продукта. Управленцы-продуктовики создают идеи и инициативы, чтобы помочь достигать стратегии и целей с использованием дорожных карт (product roadmaps) и управлять бэклогом (product backlog).

Если еще раз вспомнить про ассоциацию с Атлантом, то ценным грузом на плечах менеджера продукта будет следующее:

Project Manager

Менеджер проекта обычно меньше ориентируются на конкретные цели продукта. Его главная ответственность — это сам проект. Project manager получает инициативы и функции продукта для разработки и утверждения таймлайна. В его ответственности — риски, потенциальные ограничения, ресурсы и масштаб задач.

Руководители проектов отвечают за:

Кто важнее в иерархии компании?

Оба. И это иллюстрирует картинка с Атлантами. Если в вашей компании есть обе позиции, то у вас полный порядок с организационной структурой. Как понять, кто из менеджеров важнее?
Задайте себе два вопроса:

Инструменты и сервисы для менеджеров продуктов и менеджеров проектов

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

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

ПО для управления продуктами

Программное обеспечение для управления продуктами служит для отслеживания требований, документирования видения продукта, стратегии, определения приоритетов.

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

В Hygger.io вы можете поделиться своей «дорожной картой» и расшарить перспективу того, что произойдет в продукте со временем, указав релизы, проекты и инициативы. Эта опция смотрится весьма конкурентоспособной, потому что многие другие сильные игроки рынка часто не могут предложить такой вариант. Например, используя Jira, вам придется заплатить за «Portfolio for Jira».

Управление бэклогом — еще одны функция, которую должен предлагать инструмент для управления продуктом. Визуализировать приоритетные задачи можно, например, с помощью графического отображения Backlog priority chart. Инструмент помогает оптимизировать приоритеты продуктов, определяя важные и менее важные задачи.

ПО для управления проектами

Профессиональные сервисы для руководителей проектов — это стратегический инструмент, который используется для отслеживания и управления всеми деталями проекта.

После того, как вы получите “зеленый свет”, чтобы начать проект, вы можете планировать все свои действия по разработке с помощью любой платформы для управления проектами.
PM-сервисы помогают фиксировать и совместно использовать задачи и подзадачи, сроки, необходимые активы и взаимодействие между членами команды.

Hygger предлагает полноценные возможности для менеджеров проектов от удобных Kanban и Scrum досок до отслеживания времени и отчетности по проектам.

Заключение

Подводя итоги, подчеркнем еще раз самое главное:

Источник

Business Analyst, Requirement Specialist, Product Owner и другие. Чем отличаются схожие на первый взгляд роли?

В 2021 наметился тренд: повышенный спрос на бизнес-аналитиков. Практически каждый проект стремится заполучить в свои ряды специалиста с такой ролью. При этом вакансии с примерно одинаковым описанием должностных обязанностей поражают многообразием названий: requirement specialist, business analyst, system analyst, (proxy) product owner, product manager. Меня зовут Святослав Щербатюк, я сотрудничаю с ЕРАМ в роли ведущего бизнес-аналитика. В этом материале предлагаю порассуждать, почему сложилась такая ситуация, отличаются ли эти роли между собой и если да, то чем.

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

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

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

Requirement Specialist (также иногда встречается requirement engineer, requirement analyst) vs Business Analyst

В первую очередь необходимо отметить, что границы и отличия между этими ролями достаточно размыты. Часто компании по-разному называют роли с одинаковым набором функций. Но все же основной особенностью requirement инженера является фокус на имплементации конкретного функционала, потому он держит под контролем сбор и документирование требований, которые связаны с процессом. Requirement инжиниринг в отличии от бизнес-анализа не предусматривает анализ и улучшение бизнес-процессов, описание бизнес-кейсов. В нем нет фокуса на доставку business value клиенту. Поэтому любые решения и документация являются инженерно-обоснованными (engineering driven), но не обоснованными бизнесом (business driven). А большинство действий requirement специалиста направлены на три активности, связанные с функциональными и нефункциональными требованиями:

Активности эти, безусловно, связаны с менеджментом заинтересованных лиц и потенциальных конфликтов между ними, умением правильно выявить и задокументировать требования, донести их команде. Однако характерной особенностью все же является то, что requirement инжиниринг не предусматривает необходимость работать с бизнес-требованиями, требованиями пользователей. Такой специалист не будет преломлять контекст на функциональные и нефункциональные требования, которые выявит, он не обязан анализировать, насколько они позволяют достигнуть поставленных бизнес-задач. Круг его стейкхолдеров (или заинтересованных лиц) обычно ограничен subject matter экспертами, у которых он и выявляет требования.

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

Повторюсь: граница между этими ролями достаточно условна. Пожалуй, единственным характерным признаком, по которому роль специалиста можно отнести к бизнес-анализу, является наличие «бизнес-компонента» в его ежедневных активностях, фокус на конкретных бизнес-результатах той или иной функциональности. То есть роль бизнес-аналитика включает в себя задачи реквайремент специалиста, как показано на графике.

Подробнее о разнице этих ролей написано здесь, здесь, и здесь.

Business Analyst vs (Proxy) Product Owner

Все характеристики бизнес-аналитика, которые я перечислил выше, очень похожи на описание другой распространенной роли – Product Owner. В чем же все-таки отличия?

Начнем с того, что такой популярный фреймворк как Scrum изначально не предусматривает роли ВА, вместо нее существует роль Product Owner-а. Но так как в реальном мире вряд ли существует проект, который на 100% соответствует всем канонам, роль бизнес-аналитика все-таки появилась в проектах, работающих по Scrum-like фреймворкам.

Разграничения между ролями бизнес-аналитика и Product Owner-а, как и в случае с requirement специалистом весьма нечеткое. Если коротко, то Product Owner:

выступает представителем бизнеса для команды разработки;

отвечает за определение порядка выполнения задач бэклога на пути к бизнес-цели;

отвечает за бизнес-ценность, которую должна доставить команда.

Исходя из этого есть несколько способов взаимодействия ролей бизнес-аналитика и Product Owner-а:

1. Бизнес-аналитик выполняет роль Product Owner-а.

Источник картинки https://www.romanpichler.com/blog/business-analysts-in-scrum/

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

2. Бизнес-аналитик является частью команды разработки.

Источник картинки https://www.romanpichler.com/blog/business-analysts-in-scrum/

В такой конфигурации ВА работает в команде разработки на ежедневной основе. Он транслирует бизнес-контекст требований, полученный от Product Owner-а инженерам. Все решения утверждает представитель бизнеса – Product Owner.

3. Бизнес-аналитик является посредником между Product Owner-ом и командой разработки.

Источник картинки https://www.romanpichler.com/blog/business-analysts-in-scrum/

По сути, в данном подходе бизнес-аналитик дублирует функции ProductOwner-а для команды разработки.

Последние два подхода весьма распространены в аутсорсе, где на стороне заказчика контактом, транслирующим бизнес-контекст, является Product Owner, а на стороне исполнителя – бизнес-аналитик.

Если кратко охарактеризовать отличие этих двух ролей, то Product Owner предоставляет, транслирует видение продукта и финальные бизнес-цели, не беспокоясь о том, как это реализовать технически. Он – точка контакта с клиентом, которая помогает соотнести ожидания бизнеса с возможностями команды разработки, выяснить открытые вопросы и принять решения.

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

Business Analyst vs System Analyst

Системный аналитик – еще одна роль, которую часто путают с ВА. В чем же отличие? Упрощенно говоря, бизнес-аналитик работает со сбором и документированием требований, которые связаны с достижениями бизнес-задач, а системный аналитик описывает, как система должна работать технически. Бизнес-аналитик не учитывает платформы реализации и технологии, а стремится максимально учесть все пожелания и цели заказчика, обеспечить полноту, корректность и непротиворечивость требований. Системному аналитику не важен фокус на бизнес-ценности и цели бизнеса, его задача – принять во внимание все особенности работы с определенной технологией и платформой, выбрать оптимальный способ реализации всех заявленных функционально-технических требований, определить платформу реализации, способы интеграции. Главный фокус системного аналитика – нефункциональные требования.

Детальнее о системных аналитиках можно почитать тут и тут.

Business Analyst vs Product Manager

Упомянув разграничение роли бизнес-аналитика с ролью ProductOwner-a, следует также рассмотреть разграничение этой роли с ролью Product менеджера. В целом, то, что отличает бизнес-аналитика от ProductOwner-a применимо и для разграничения сфер ответственности между бизнес-аналитиком и Product менеджером. Разница в том, ProductOwner оперирует тактическими целями и задачами, а Product менеджер занимается развитием продукта на уровне стратегии. В задачи последнего входит:

определением видения и миссии продукта;

создание продуктовых дорожных карт и KPI;

создание стратегии вывода продукта на рынок и его монетизации.

Кроме того, если Product Owner ориентирован на команду и взаимодействие с ней, то продакт менеджер – на конечного пользователя продукта и требования рынка.

Рассмотрев все многообразие похожих ролей (requirement specialist, business analyst, system analyst, (proxy) product owner, product manager) можно резюмировать, что основная разница между этими ролями – в предмете фокуса:

requirement специалист фокусируется преимущественно на сборе и менеджменте требований;

системный аналитик – на технической стороне проекта;

бизнес-аналитик – на соответствии требований целям бизнеса, доставке бизнес-ценности заказчику;

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

Product менеджер фокусируется на стратегических целях продукта и успех продукта на рынке.

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

Потому, несмотря на определенную банальность и оскомину от вопроса «В чем, по-вашему, состоит роль бизнес-аналитика?», который мы часто слышим на собеседованиях, он нескоро потеряет свою актуальность.

В качестве послесловия. Business Analyst vs Data Analyst (and others)

Бывают ли еще какие-либо виды аналитиков, работа которых может функционально пересекаться с ВА? Да, например, data-аналитики, которые работают с массивами информации, извлекая из них сведения, ценные для бизнеса с точки зрения принятия оптимальных управленческих решений, ищут закономерности, визуализируют анализируемую информацию и формулируют гипотезы по повышению KPI бизнеса за счет оптимизации бизнес-процессов.

С бизнес-аналитиками их объединяет то, что и те, и другие анализируют бизнес-процессы и участвуют в их оптимизации, могут формулировать, собирать и документировать требования к ПО. Однако data-аналитики используют для этого специфическую технику – настройку, сбор и анализ больших наборов данных.

Прочитать более детально о вышерассмотренных и других видах аналитиков можно тут и тут.

Святослав Щербатюк, Lead Business Analyst, EPAM

Источник