product owner и product manager чем отличаются
Есть ли на самом деле разница между Project Manager, Product Owner и Product Manager
Несмотря на рост популярности и понимание методологий управления проектами, включая Agile, многие люди часто путаются в определении кем он хочет стать или кого ищет компания себе в штат. В случае Project Manager, Product Owner и Product Manager вы, наверное, сталкивались с путаницей в понимании ролей и обязанностей сотрудников.
Итак, попробуем разобраться в чем разница и есть ли она между Project Manager, Product Owner и Product Manager?
Давайте для начала проясним, что такое “проект” и “продукт”.
Проект — временная активность, направленная на создание уникального продукта или услуги.
У проекта есть критерии успеха, по достижению которых проект считается завершенным, или когда проект прекращается в связи с тем, что его цели не будут или не могут быть достигнуты.
Продукт — товар или услуга, которую можно предложить для рынка, и которая будет удовлетворять потребности пользователей.
Продукт можно улучшать и за счет запуска и выполнения новых проектов.
В рамках одного продукта может существовать множество подпродуктов и подпроектов.
Чтобы понять роли более четко и иметь возможность различать Project Manager, Product Owner и Product Manager, давайте углубимся в набор обязанностей, которые фактически воплощает каждая роль.
Project Manager
Роль Project Manager появилась самой первой в виду необходимости иметь ответственного координатора за реализуемый проект. Изначально все проекты следовали методологии Waterfall, координируя действия команды проекта.
Project Manager берет на себя управление определенной фазой продукта или услуги, например, выпуском нового продукта, а также отвечает за удовлетворение потребностей: потребностей задач, потребности проектов и индивидуальных потребностей членов команды. Но его ответственность может быть расширена на основе дополнительных обязанностей или бизнес процессов в компании.
Основные обязанности Project Manager’a:
Product Owner
Роль Product Owner возникла после появления на свет методологии управления проектами — Agile Project Management. Обязанности Product Owner похожи на роль Project Manager, но Product Owner работает в относительно лучшей координации со всей командой Agile. Какой тип лидера будет наиболее эффективным, зависит от того, на какой философии построен проект.
Project Manager вступает в игру, когда проект использует более традиционный подход Waterfall, тогда как проект, разработанный с учетом гибкого подхода Agile, будет возглавляться Product Owner. Project Manager предпочитают диаграммы Ганта (Gantt chart), а Product Owner предпочитают Agile-инструменты.
Способ, которым Project Manager или Product Owner решает задачу, должен быть гибким, но всегда будут существовать некоторые конкретные различия в подходе. Идеи, лежащие в основе роли Product Owner и философии управления Agile, выросли и развились на основе идей, разработанных в методе Waterfall.
Product Manager
В отличие от проекта, который может иметь временные рамки, сам продукт является чем-то более долгосрочным. По сути, управление продуктом вращается вокруг продукта или услуги, то есть всего, что может быть предложено рынку для решения проблемы или удовлетворения потребности.
Product Manager отвечает за успех продукта на протяжении всего жизненного цикла продукта. Он сосредотачивает внимание больше на вопросе «что?», чем на «как?». Product Manager отвечает за верхнеуровневое планирование и отвечает за рост и развитие продукта.
Основные обязанности Product Manager:
В итоге выделим самое главное:
Роли Project Manager, Product Owner и Product Manager имеют разные обязанности и набор необходимых знаний.
Основное различие между Project Manager и Product Owner можно найти в направлении проекта, которым необходимо управлять. Если это тип проекта, который должен быть построен из надежного плана, в котором изложены все шаги в том порядке, в котором они должны быть завершены до начала следующего шага, Project Manager поможет вам туда добраться.
С другой стороны, проект, подразумевая продукт, который нуждается в гибкой разработке функционала, то для такого проекта Product Owner будет лучшим решением.
Кто такой Product Owner, чем занимается и как отличается от project-менеджера
В scrum-команде есть несколько основных ролей. Одна из них — Product Owner. Рассказываем, кто это и чем занимается.
Product Owner, или «владелец продукта» знает всё о потребностях и болях пользователя, возможностях команды, видит их точки соприкосновения на благо всего проекта.
Как не путать с менеджером проекта
Менеджер проекта и Product Owner — это не одно и то же. Менеджер проекта — руководитель: он распределяет задачи и нагрузку, проверяет и снова руководит процессом.
А владелец продукта больше про сам продукт. Он видит, каким должен быть результат, и знает, как команда будет его добиваться. Контролируя каждый этап, он корректирует курс и говорит, что делать дальше. У них похожие функции, но есть и отличия.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.
| Product Owner | Руководитель проекта |
|---|---|
| ключевая роль в гибких методологиях | должность вне зависимости от методологии |
| не управляет командой, а направляет и работает вместе с ней | по большей части руководит |
| отвечает за продукт | отвечает за продукт |
Функции Product Owner ближе к работе, которую выполняет Product Manager. Чтобы научиться и стать профессионалом в этой области, обратите внимание на практический курс «Управление продуктом» от Skillbox.
Роли продуктового менеджера и владельца продукта часто объединяют в вакансиях.
Роль Product Owner
в scrum-команде
Напомним, что Scrum — методология гибкой разработки программного обеспечения. Она основана на Agile-манифесте.
Scrum-команда — это владелец продукта, scrum-мастер и разработчики. В заказной разработке — еще клиент, пользователи и стейкхолдеры.
Чем занимается
Product Owner
Product Owner выполняет часть функций руководителя проекта, менеджера продукта и маркетолога. Он не управляет, а направляет команду, чтобы вместе прийти к желанному результату. У него есть власть и ответственность.
Product Owner отвечает за продукт на всех этапах его создания:
По Scrum владелец продукта — это роль одного человека из команды. Но компании, которые используют фреймворк, адаптируют его под свои потребности. Поэтому бывает, что один человек выполняет сразу несколько ролей. Например, менеджер проекта в заказной разработке — это и scrum-мастер, и Product Owner. Это противоречит scrum-гиду, но вполне допустимо, если система работает и приносит нужный результат.
Кто будет выполнять роль владельца продукта, зависит от проекта. Это может быть человек из команды, сотрудник заказчика или он сам, если, например, проект — сайт для его компании. Владельцев продукта часто нанимают на проект со стороны и обучают внутри команды.
Что важно для владельца продукта
Обязанности владельца продукта зависят от типа проекта. Вот что для вас важно, если вы — Product Owner.
Вы всегда представляете, как будет выглядеть продукт в итоге, и способны объяснить это другим. Важно сделать так, чтобы все в команде поняли задачи одинаково.
Вы должны убедиться, что продукт будет ценен для пользователя. Не важно, какие методы вы будете применять для этого.
Вам придется слушать предложения команды, оценивать их и заносить в общий список задач и требований. Вы отвечаете за содержание бэклога и за изменения в нем.
Только вы выбираете порядок, в котором команда будет работать. Всегда точно знаете, какие функции появятся у продукта первыми, а что можно дорабатывать потом. Задачи на каждый спринт тоже планируете вы.
Вам важно, что получается после каждой итерации. Вы проверяете качество продукта в конце спринта, и, если что-то идет не так, знаете, как это изменить. Прогресс продукта — это ваш личный прогресс.
Именно вы следите, чтобы общение команды было продуктивным. Вам важно, чтобы все, кто создаёт продукт, могли обмениваться идеями и легко понимали друг друга. От этого зависит общий результат.
Заключение
Мы рассказали, кто такой Product Owner и чем он занимается. Если у вас остались вопросы или вы хотите подробнее разобраться в Scrum и Agile, советуем почитать и посмотреть:
Чтобы быть владельцем продукта, нужно уметь работать по Agile-методологиям. Разбираться в маркетинге, юзабилити, разработке и управлении, а главное — понимать жизненный цикл продукта.
Product Owner vs. Product Manager – в чем разница
Тут на работе с коллегами на днях спорили, есть ли разница между менеджером продукта (Product Manager) и владельцем продукта (Product Owner), или это одна и та же роль, только называют ее по-разному. Из более-менее внятного по теме в русскоязычном интернете нашлась только прошлогодняя статья на vc, и, хоть я и не согласна с мнением автора, прочитать однозначно стоит. Поэтому мы пошли в гугл, поспорили еще полчаса и в итоге пришли к следующему.
Принципиальная разница между этими ролями нигде формально не описана, и чаще всего все сводится все-таки к “ну так просто назвали должность, какая разница-то”. А вот если придираться и твердо следовать идеологии, то Product Owner (владелец продукта) – это чисто скрамовская роль, предполагающая очень конкретный круг задач в рамках этого фреймворка, и не более того. А вот Product Manager (менеджер продукта) – это уже про управление продуктом как таковым без привязки к способу разработки, работа с рынком и пользователями, продвижение и проч.
Если говорить про компетенции, то:
Product Owner (владелец продукта) – больше про управление проектом или набором проектов для создания и совершенствования продукта. Product Owner плотно работает с командой проекта (и имеет минимальные технические навыки, чтобы говорить с ними на одном языке, от разработки до UI/UX), решает, каким именно будет продукт, управляет бэклогом, взаимодействует с пользователями на всех этапах (от сбора требований до тестирования и получения обратной связи), иногда – контролирует бюджет на разработку продукта.
В общем, основная обязанность Product Owner – получить работающий продукт, отвечающий ожиданиям пользователей, и, в идеале, даже их превышающий, и развивать его. В большинстве случаев этот термин используют при разработке внутренних продуктов, не ориентированных на внешний рынок.
При этом Product Owner, конечно, не равно руководитель проекта, но в отдельных случаях возможно его совмещение с этой ролью или с ролью Scrum Master.
Product Manager (менеджер продукта) – больше про маркетинг, вывод продукта на рынок и получение выгоды. Product Manager работает с рынком, анализируя потребность, наличие конкурентов и прочие факторы, отвечает за видение и направление развития продукта (как правило, не спускаясь на технический уровень), определение ценовой и ассортиментной политики, работу с клиентами и выполнение поставленных KPI.
В общем, основная обязанность Product Manager – не просто создать продукт, а сделать его успешным на рынке и обеспечить возврат инвестиций. В большинстве случаев этот термин используют при разработке продуктов, ориентированных на внешний рынок и внешнюю аудиторию.
При этом Product Manager также не выступает в качестве руководителя проекта, скорее – в качестве спонсора и внутреннего заказчика одновременно.
Забавное короткое видео в тему:
Расскажите, а как вы воспринимаете эти роли? Если у вас другое видение – расскажите в комментариях, интересно!
Product Manager vs Product Owner — кто нужен вашему бизнесу
В чем разница между двумя популярными профессиями.
Product Owner (PO) и Product Manager (PM) занимают лидерскую позицию в продуктовой команде. Они отвечают за разработку продукта, а также за результат — удалось ли предоставить решение проблемы клиента. Именно из-за того, что оба специалиста преследуют одну и ту же цель, сложно разграничить их обязанности. Если ввести запрос Product Owner на поисковой платформе вакансий Indeed, в выдаче частично окажутся результаты для Product Manager — и наоборот.
Кто же руководит процессами в отделе по разработке продукта и формирует его ценность — PM или PO? Это отдельные должности или просто разные названия для одной?
Разбираемся вместе с Андреем Хлякиным, ex-Senior Product Manager в Jobble, EVO и преподавателем онлайн-курса «Продакт-аналитик» в Laba. У Андрея 10+ лет опыта в продакт-менеджменте. Он участвовал в создании системы ProZorro и торговой площадки Zakupki.Prom.ua.
Как зарождался продакт-менеджмент
Все началось с памятки на 800 слов, которую в 1931 году написал Нейл Макэлрой, президент Procter & Gamble. В ней он определил основные принципы современного бренд-менеджмента.
Описанный в памятке Brand Man становился ответственным за бренд и продукт, причем управление продуктом должно было происходить путем экспериментов и взаимодействия с клиентами. Макэлрой реструктурировал P&G в бренд-ориентированную организацию и создал должность продакт-менеджера в сфере FMCG (рынок товаров повседневного спроса).
При этом своей теорией Макэлрой оказал влияние на двух предпринимателей — Уильяма Хьюлетта и Дэвида Паккарда. Когда они строили свою технологическую империю, применили идеологию Brand Man, решив стать как можно ближе к клиенту.
Именно Hewlett-Packard стала первой компанией, которая адаптировала методологию Just In Time (JIT) и внедрила Kanban-доску — концепт, разработанный в Toyota в Японии. Благодаря адаптации новаторских идей HP выдержала 50-летний рекорд непрерывного развития с ежегодным ростом в 20% в период с 1943 по 1993.
Андрей:
«У Product Manager много лиц и задач. Он несет ответственность за смысл, видение и стратегию продукта. Это человек-оркестр, чаще всего его задача — отвечать на вопрос “что делать дальше?”. Мне в этом плане нравится одноименная формулировка Саймона Сайнека в его книге
Let’s start with why».
Итак, изначально продакт-менеджеры в FMCG в большей степени были частью маркетинговой функции. Основная задача заключалась в определении потребностей клиентов и поиске решения, чтобы удовлетворить их. Продакты опирались на классический маркетинговый комплекс:
Хотите получать дайджест статей?
Ключевыми показателями PM-ов были продажи и прибыль, но из-за медленных процессов разработки и производства новых продуктов в FMCG они больше сосредоточились на последних трех P: Place, Price и Promotion.
Однако по мере того как роль продакт-менеджера перешла из FMCG в сферу IT, это разделение больше не оправдывало себя. Многие технологические компании изобретали совершенно новые отрасли на рынке, и к успеху их не могла привести только красивая упаковка или приемлемая цена.
По этой причине разработка продукта вернулась к корням самого Product-менеджмента, ведь необходимо было не только понимать клиентов, но и согласовывать с ними процесс разработки.
Скотт Кук, бывший Brand Man P&G, одним из первых применил продакт-менеджмент в технологической сфере — он внедрил этот концепт в своей компании Intuit.
Возникновение Agile: Product Owner выходит на сцену
Чтобы разрешить организационную дилемму между теми участниками команды, которые создают продукт, и теми, кто коммуницирует с клиентами, программисты Кен Швабер и Джефф Сазерленд разработали новую методологию — фреймворк Scrum.
Первое описание Scrum они представили в 1995 году на конференции OOPSLA. Новый фреймворк позволял правильно организовать процессы в production-команде благодаря ежедневному планированию, проведению спринтов и получению фидбека по проделанной работе.
В рамках этого фреймворка роль продакт-менеджера была пересмотрена и расширена. Она стала более приближенной к команде, клиентам и процессам. Так появилась позиция Product Owner.
Андрей:
«PO — это человек, который отвечает на вопрос, КАК мы это сделаем. Здесь больше о процессах и непосредственной работе над смыслами, которые генерирует РМ. То есть про реализацию задуманного, тесную работу с инженерами и другими заинтересованными».
Изначально Сазерленд вложил в роль PO больше ответственности за стратегию продукта и получение дохода, чем на PM, однако должность Product Owner не включает в себя непосредственно маркетинг и обеспечение продаж. В зоне ключевых обязанностей PO — организация процессов в команде разработки.
В 2001 году 17 разработчиков, среди которых был и Сазерленд, создали Agile-манифест и 12 принципов Agile-разработки. Это дало толчок для распространения Scrum в технологических компаниях и для внедрения в отделы позиции Product Owner.
Человек-оркестр и мини СЕО. Кто такой продакт-менеджер?
Главная ошибка Agile-трансформаторов: почему Product Manager и Product Owner — это не один человек
Консультант по развитию цифровых продуктов — о том, как превратить «узкое горлышко» вашей организации в конкурентное преимущество.
«Да что этот пр*д*кт себе позволяет?» — воскликнут на этот раз топ-менеджеры и цифровые трансформаторы со стажем и начнут кидаться в меня маркерами и блокнотами для флипчарта, или чего у них там в избытке осталось после процесса Agile-трансформации?
Ведь мы касаемся скользкой темы: на территории СНГ профессия менеджера по продукту считается новой, в профессиональном сообществе ещё не выработалось её чёткое определение, а функциональность «продакта» разнится от компании к компании.
Каждый специалист в рамках разумного определяет удобные для него параметры этой роли. Но я хочу поговорить о проблеме, которая вызывает очень серьёзные последствия для цифрового бизнеса — в виде потери или качества продукта или скорости разработки.
Некоторые евангелисты гибких подходов так были увлечены их идеями, что потеряли одну важную роль в компаниях в процессе трансформации — роль менеджера продукта. Точнее, спутали её с другой важной ролью — Product Owner. И жизнь менеджера продукта заиграла новыми красками.
Прежде чем говорить о текущих тенденциях, давайте вспомним о том, как производство продукта было устроено до внедрения, например, Scrum. Считается, что история современного продакт-менеджмента уходит своими корнями в сферу FMCG.
В 1931 году Нил МакЭлрой, в те годы президент Procter & Gamble, в своей записке расписал обязанности новой единицы в компании — Brand Man. Диапазон ее ответственности в значительной степени совпадал с современным представлением о функции менеджера продукта в сфере ИТ. По забавному стечению обстоятельств в этой записке МакЭлрой затрагивает проблему, близкую той, которую я решил поднять в этой статье.
Долгие годы продакт-менеджмент развивался в сфере производства товаров повседневного спроса, но позднее, в начале 1980-х годов, эта функция была применена в области производства программных продуктов выпускником P&G, бывшим «брендменом». После этого ранние технологические компании, такие как Microsoft, стали перенимать эту модель.
Менеджер продукта изучал рынок, проводил конкурентный анализ, разрабатывал стратегию, собирал и формулировал требования программного продукта, которые передавал в руки менеджера проекта. Менеджер проекта следил за сроками, качеством и бюджетом проекта в плотном взаимодействии между заказчиками (в том числе в виде менеджера продукта) и командой разработки.
Эти специалисты образовывали эффективную команду с хорошо разграниченными обязанностями, которая обеспечивала желаемый результат, пускай и в каскадной модели разработки.
У каскадной модели разработки продукта был существенный недостаток: требования и рынок могли несколько раз поменяться, прежде чем проект был сдан. Недостаток стали замечать специалисты рынка, и в середине 1980-х годов начала зарождаться идея маленьких кросс-функциональных команд и итеративной разработки, которая впоследствии, к середине 1990-х годов, сформировалась в том числе во фреймворк под названием Scrum.
С распространением последнего менеджеры продукта, иногда менеджеры проекта, во многих случаях преобразовались во «Владельцев Продукта».
Так назвали Scrum-роль, которая предполагает «ответственность за достижение максимальной ценности продукта» и управление беклогом, включая обеспечение доступности и ясности его элементов для всех.
«Ответственность за достижение максимальной ценности продукта» при «самодостаточности» кросс-функциональных команд и является тем самым камнем преткновения, в который упираются все, кто мечтает делать качественный продукт, сохраняя высокую скорость разработки.
Ведь для достижения «максимальной ценности продукта» необходимо сформировать видение на основе того, что происходит вовне организации. А «самодостаточные» кросс-функциональные команды сосредоточены на производстве внутри организации.
Когда новоиспеченному Product Owner приходится балансировать, совмещая две роли, возникают сложности. Если в организации происходит Agile-трансформация и менеджер продукта принимает на себя новые обязанности, старые чаще всего тоже остаются в его сфере ответственности.
Как владельцу продукта ему нужно донести до команды разработки видение целиком, ответить на все «Почему?», «Зачем?» и «Как?», прописать пользовательские истории, «отбиться» от стейкхолдеров, приоритезировать и почистить беклог, поучаствовать в скрам-событиях.
С другой стороны, как менеджеру продукта ему необходимо следить за рынком, соответствием продукта фокусу компании, общаться с целевой аудиторией, разрабатывать стратегию, roadmap, проводить исследования, работать в тесном сотрудничестве практически со всеми подразделениями компании, снабжая их всем необходимым.
В итоге, сложив обе стороны, мы увидим, что на самом деле это работа для двух специалистов. Но ее приходится выполнять одному.
«Но Scrum же — такой замечательный фреймворк, он позволяет оптимизировать работу, именно поэтому совмещение двух ролей возможно», — скажут некоторые. К сожалению, это не так. На практике «тактико-стратегическое» балансирование заканчивается на одной стороне. Либо «владелец продукта» увлекается исследованиями, взглядом в будущее, теряя контакт с командой разработки.
Симптомы такого выбора проявляются достаточно быстро в виде фраз наподобие «Мы практически не видим нашего продакт-оунера» и потери скорости разработки. Во втором случае такой специалист слишком сильно погружен в процесс разработки и теряет связь с рынком и аудиторией продукта.
Такой дисбаланс очень быстро выливается в недовольство команды неактуальностью или полным отсутствием видения, а также снижением качества продукта с точки зрения ценности.
В случае когда компания находится в поиске устойчивой бизнес-модели (является стартапом), у нее еще нет продаж и продакт наработал достаточно материала для понимания рынка, у него может хватать ресурсов для работы на два фронта.
Однако когда компания начинает расти, появляются новые требования и давление со стороны внутренних и внешних стейкхолдеров растет. Тогда незаметно для самого менеджера продукта и для его коллег начинает возникать ситуация, описанная выше.
Другое исключение, когда продакт-менеджер справляется с ситуацией ценой своего психологического и физического здоровья. По тем или иным причинам, в зависимости от условий работы, вы, скорее всего, уволите или потеряете такого специалиста примерно через 6–18 месяцев. Как я говорил в своей предыдущей статье, ресурс человека ограничен.
Самое интересное, что причина этой проблемы остается неочевидной и в ситуации, когда один человек взваливает на себя ответственность за двоих в корпоративной среде. Зато очевидными при этом становятся симптомы, о которых я рассказывал выше. Что делает менеджмент в такой ситуации?
Зачастую продолжает усиливать команду инженерами. В итоге вопросы «Почему ты не можешь освоить больший ресурс и увеличить скорость разработки?» или «Почему фича конкурентов проработана лучше?» повисают над владельцем продукта, который, согласно ошибочным общепринятым стандартам, отвечает за все, что касается продукта.
Как я уже сказал, во время роста компании выделяются огромные бюджеты на наем новых разработчиков, менеджеров по продажам и усиление команды маркетинга. Но для компаний несвойственно при этом увеличивать команду управления продуктами.
На продакт-менеджеров, особенно на старте компании, зачастую взваливают также роли аккаунтов, business development менеджеров, администраторов, скрам-мастеров и менеджеров проекта. Руководство компании находится в иллюзии, что один человек может иметь одно название должности, но совмещать функционал множества.
Такая иллюзия объясняется непониманием ресурсоемкости отдельного человека в организации. Каждая из совмещаемых ролей приносится в жертву ради осуществления другой, субъективно более важной.
Кроме этого, отсутствует понимание концепции фокуса отдельного индивида. Если фокус — изолирование существенного от несущественного в процессе достижения цели, то углубление в низкоуровневые задачи наносит ущерб высокоуровневым. Так устроен мозг: если вы фокусируете внимание, у вас пропадает широта взгляда. Если вы, наоборот, смотрите максимально широко, для вас стираются детали.
Это простые концепции, но руководство многих компаний не учитывает их при построении организационной структуры.
Чтобы избежать описанной проблемы, необходимо признаться себе в двух вещах: первое — для производства технологического продукта необходима тесная связь между теми, кто разрабатывает концепцию, и теми, кто ее реализует. Второе — на двух стульях усидеть невозможно. Вывод следующий: необходима прослойка. Это место и может занять Product Owner.
Владелец продукта — очень важная роль, которая будет исполняться в тесном тандеме с менеджерами продукта с одной стороны и командой разработки — с другой. Ему может быть делегировано «представительство продукта» перед разработчиками и многими стейкхолдерами, а также все активности, описанные в руководстве по Скраму, в то время как продакт-менеджер и его команда сосредоточатся на стратегии и проработке видения продукта.
Тут возникают закономерные вопросы. Не будет ли функционал этих ролей пересекаться? Как разграничить ответственность? За кем последнее слово?
Дело в том, что разделение стратегической и тактической функций существовало задолго до появления гибких методологий разработки программного обеспечения. Начиная военным делом и заканчивая строительством частных домов.
Когда архитектор разрабатывает видение проекта, он учитывает свойства ландшафта, продумывает расположение объекта относительно сторон света, проводит исследования и разрабатывает документацию, которую позже передает в руки строителей.
Работу, которую провел архитектор, строители берут за основу: для них важно, в каких местах требуется уплотнить почву и какой высоты будут стены. Но здесь уже прораб решает, что бригада будет делать сегодня и что делать в первую очередь: выровнять и поштукатурить стены или залить пол бетоном.
Можно ли сказать, что архитектор — «босс» прораба? Нет, но он вправе требовать и контролировать исполнение с целью достижения поставленной цели. Он может периодически появляться на объекте, пояснять детали проекта и интересоваться деталями процесса постройки.
Хороший архитектор может знать в деталях, как возвести дом, но он не станет учить рабочих замешивать строительные смеси. Во-первых, мы предполагаем, что строители такие же профессионалы, а во-вторых, это просто не сфера его ответственности. У бригады строителей тоже могут появляться свои соображения на тему как процесса постройки, так и проекта в целом. Порой такие идеи могут оказаться очень ценными.
При желании вам не составит труда соотнести эту аналогию со схемой «продакт-менеджер — продакт-оунер — команда разработки», которую я предлагаю.
Конечно, во многих вопросах ответственность продакт-менеджера и продакт-оунера будет пересекаться. В таких областях требуется готовность позитивной совместной работы и принятия коллегиальных решений. Однако важно учитывать: если все решения принимаются коллегиально, компания начинает пробуксовывать, терять темп изменений и развития своих продуктов, уступать конкурентам преимущество на рынке.
Это заметно в компаниях, которые ставят «демократичность» способа принятия решений на пьедестал. Несмотря на то что важные решения требуют обсуждения на многих уровнях, когда дальнейшее обсуждение проблемы не уменьшает уровень энтропии, должен быть человек, который взвалит на свои плечи ответственность. Поэтому должно существовать довольно четкое разграничение обязанностей в тех областях, в которых это возможно.
Где пройдет черта? Решать в каждом индивидуальном случае придется в рамках отдельной организации. Где-то менеджеру по продукту нравится глубже прорабатывать решения, где-то он захочет сосредоточиться на стратегии и оставить эту ответственность Scrum-команде.
Некоторые скажут: «Product Owner — это авторитет, только к нему все идут, только он решает все вопросы». Некоторые испуганно воскликнут: «А вдруг это уже и не Скрам?»
Я отвечу: «Вам шашечки или ехать?»
Для России необходимое писать, что Product Manager еще:
— не равен Project Manager
— не равен Market researcher
— не равен UI/UX designer
— не равен Data Scientist
— не равен Support
и т.п.
Мягко смузи стелет фраерок:
«
Agile-трансформация
прописать пользовательские истории
отбиться от стейкхолдеров
приоритезировать и почистить беклог
поучаствовать в скрам-событиях
»
Наверное, кто-то без этого и работать не может.
Смешаются клеточки на рубашонках овнера и менеджера, запутаются, переплетуться потоки аджайловы, да порой и не разобрать где тут чья крашеная бровь али борода нависла знаком вопроса. А бэклог то подгорает. Эх.
Методист-практик по организации бизнес-структуры и бизнес-процессов по производству востребованных на рынке программных решений должен быть четким, как удары плёткой и дерзким, как пуля резким. А тут 90% воды и экзотических дефиниций и 10% предложений.
Доверия вообще не вызывает!
Особенно заключение:
«Где пройдет черта? Решать в каждом индивидуальном случае придется в рамках отдельной организации»
«Можно ли сказать, что архитектор — „босс“ прораба? Нет, но он вправе требовать и контролировать исполнение с целью достижения поставленной цели. Он может периодически появляться на объекте, пояснять детали проекта и интересоваться деталями процесса постройки.»
Вы плохо читали статью
Вы плохо ответили на коммент
Все знают, что в России Agile это когда product manager, product owner и scrum master это один и тот же человек. Иногда этот человек ещё и тимлид, и CTO, не говоря уже о том, что он дизайнит и осуществляет техподдержку, что вполне логично для его роли
I see what you did there 😄
Не все поймут, что вы иронизируете 🙂
Похоже вы рассказываете что получили опыт, который лучше не иметь. Разруха в командах, а не в России.
Зачем отбиваться от стейкхолдеров?
Изначально там были кавычки. Я так и знал, что их не надо убирать.
Если некий «agile-трансформатор» смешивает PO (роль в скрам-фреймворке) и PM (должность в компании) то такого транформатора надо с порога спускать.
Современная реальность России: дикий аджайл. Есть скрам мастер, продакт оунер, продакт менеджер, проджект менеджер, разномастные лиды и вот эти два разработчика, один из которых на половину QA, а второй девопс. Вот из-за последних вечно сроки срываются. 🙂
Во-первых, у PO достаточно чёткая сфера ответственности. В этом смысле можно подсмотреть в руководство по Скраму.
Я не говорил, что PdM оторван от разработки, он может быть вовлечен в некоторой степени, а может быть и не вовлечен. Это уже от него зависит и от договоренностей между ролями.
Концепцию mini-CEO не стоит воспринимать буквально, иначе она приводит к тем проблемам, о которых я рассказываю. За маркетинг может и должен отвечать Product Marketing Manager, за финансы отвечают финансисты, P&L размазывается в плане ответственности неровным слоем по продажам, маркетингу, финансам и менеджерам продукта.
Суть любого бизнеса — синергия. Вместе люди могут больше, чем по отдельности. В этом смысле сваливать всю ответственность на одного человека не эффективно.
Я бы сказал, что ценность продакт-менеджера не размыта, а в некоторых случаях не осознаётся и в большинстве случаев проявляется в полной мере лишь на большой дистанции. Это долгие деньги. Российский менталитет к этому не готов. Но существуют исключения и возможна смена парадигмы.
Напридумывали новых терминов и путаются в них. ГОСТ!
Ставь лайк, если заколебали эти пространные статьи ни о чем от очередных Agile гуру.
Так вот, по определению agile заказчик/клиент должен быть частью команды проекта и принимать участие буквально в еждневной корректировке курса. Это базовое правило, потому что в agile вы размениваете определённость курса на его гибкость. Если же вы отказываетесь от определённости и не хотите постоянно следить за траекторией, то теряете контроль.
Если финальный источник требований по проекту исходит от Менеджера Продукта, то добавление промежуточного слоя здесь приведёт к тому, что контроль за курсом потеряется. По сути вы предлагаете классическую схему с Менеджером Проекта, который как бы и на стороне команды, но при этом должен следить за требованиями и контролировать проект.