Главная ошибка 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.

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

Источник: EBG Consulting

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

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

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

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

Можно ли сказать, что архитектор — «босс» прораба? Нет, но он вправе требовать и контролировать исполнение с целью достижения поставленной цели. Он может периодически появляться на объекте, пояснять детали проекта и интересоваться деталями процесса постройки.

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

При желании вам не составит труда соотнести эту аналогию со схемой «продакт-менеджер — продакт-оунер — команда разработки», которую я предлагаю.

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

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

Где пройдет черта? Решать в каждом индивидуальном случае придется в рамках отдельной организации. Где-то менеджеру по продукту нравится глубже прорабатывать решения, где-то он захочет сосредоточиться на стратегии и оставить эту ответственность Scrum-команде.

Некоторые скажут: «Product Owner — это авторитет, только к нему все идут, только он решает все вопросы». Некоторые испуганно воскликнут: «А вдруг это уже и не Скрам?»

Я отвечу: «Вам шашечки или ехать?»

Евгений Зубак — FacebookTelegram.

0
34 комментария
Написать комментарий...
Цой жив

Для России необходимое писать, что Product Manager еще:
- не равен Project Manager
- не равен Market researcher
- не равен UI/UX designer
- не равен Data Scientist
- не равен Support
и т.п.

Ответить
Развернуть ветку
Sergei Timofeyev

Злободневно. :)

Ответить
Развернуть ветку
Yantarev

Мягко смузи стелет фраерок:

«
Agile-трансформация
прописать пользовательские истории
отбиться от стейкхолдеров
приоритезировать и почистить беклог
поучаствовать в скрам-событиях
»

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

Ответить
Развернуть ветку
Yantarev

Методист-практик по организации бизнес-структуры и бизнес-процессов по производству востребованных на рынке программных решений должен быть четким, как удары плёткой и дерзким, как пуля резким. А тут 90% воды и экзотических дефиниций и 10% предложений.
Доверия вообще не вызывает!

Особенно заключение:
«Где пройдет черта? Решать в каждом индивидуальном случае придется в рамках отдельной организации»

Зашибись. А я читал этот кисель зачем? Чтобы под конец услышать, что «каждый дрочит так, как хочет»?

Молодец!

Ответить
Развернуть ветку
Artem Labutin

Слог хороший, но комментарий не по делу. "Кисель" - только если не сталкивался с этим на практике.

Ответить
Развернуть ветку
Михаил Донской

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

Ответить
Развернуть ветку
Eugene Zubak
Автор

«Можно ли сказать, что архитектор — „босс“ прораба? Нет, но он вправе требовать и контролировать исполнение с целью достижения поставленной цели. Он может периодически появляться на объекте, пояснять детали проекта и интересоваться деталями процесса постройки.»

Ответить
Развернуть ветку
Eugene Zubak
Автор

Вы плохо читали статью

Ответить
Развернуть ветку
Михаил Донской

Вы плохо ответили на коммент

Ответить
Развернуть ветку
Sergei Zotov

Все знают, что в России Agile это когда product manager, product owner и scrum master это один и тот же человек. Иногда этот человек ещё и тимлид, и CTO, не говоря уже о том, что он дизайнит и осуществляет техподдержку, что вполне логично для его роли

Ответить
Развернуть ветку
Eugene Zubak
Автор

I see what you did there 😄
Не все поймут, что вы иронизируете 🙂

Ответить
Развернуть ветку
Евгений Евдокимов

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

Ответить
Развернуть ветку
Nikolay Nikonov

Зачем отбиваться от стейкхолдеров?

Ответить
Развернуть ветку
Eugene Zubak
Автор

Изначально там были кавычки. Я так и знал, что их не надо убирать.

Ответить
Развернуть ветку
Вася Бездомный

Если некий "agile-трансформатор" смешивает PO (роль в скрам-фреймворке) и PM (должность в компании) то такого транформатора надо с порога спускать.

Ответить
Развернуть ветку
Victor Glinka

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

Ответить
Развернуть ветку
Mkha Stas

Современная реальность России: дикий аджайл. Есть скрам мастер, продакт оунер, продакт менеджер, проджект менеджер, разномастные лиды и вот эти два разработчика, один из которых на половину QA, а второй девопс. Вот из-за последних вечно сроки срываются. :)

Ответить
Развернуть ветку
Dmitry Ilyin

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

Второй момент - не очень понимаю подход к позиции менеджера продукта как оторванного от команды разработки человека.
Продакт-менеджер - это мини- генеральный директор своего продукта. Он и про стратегию, и про финансы, и про маркетинг, и про клиентов, и про производство (разработку то есть). При этом, естественно, на каждом направлении у Продакта должны быть свои исполнители, разруливающие текущие вопросы.
Но если Продакт - только про стратегию и только про клиентские потребности\ фидбек и теоретизирование, а с разработки только требует реализации - это странно. Если команда вовлечена в развитие продукта и плотную коммуникацию с продактом, продукт гораздо более эффективен.

Ответить
Развернуть ветку
Eugene Zubak
Автор

Во-первых, у PO достаточно чёткая сфера ответственности. В этом смысле можно подсмотреть в руководство по Скраму.

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

Концепцию mini-CEO не стоит воспринимать буквально, иначе она приводит к тем проблемам, о которых я рассказываю. За маркетинг может и должен отвечать Product Marketing Manager, за финансы отвечают финансисты, P&L размазывается в плане ответственности неровным слоем по продажам, маркетингу, финансам и менеджерам продукта.

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

Ответить
Развернуть ветку
Dmitry Ilyin

Погодите, разве Продакт не должен подумать про то, какая фича - сколько стоит и как повлияет на PnL и в каком периоде времени и как её продвигать, условно говоря?
Если нет, то на внедрении "важной для клиента, но дорогой и трудоёмкой фичи" вместо реализации "чуть менее важных, но нескольких и небольших фич" может и бюджет, условно говоря, закончиться, без выхлопа для бизнеса.
Уж как минимум, должен контролировать!
А это уже мини-СЕО.

Ответить
Развернуть ветку
Eugene Targarien

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

Ответить
Развернуть ветку
Eugene Zubak
Автор

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

Ответить
Развернуть ветку
Евгений Евдокимов

Напридумывали новых терминов и путаются в них. ГОСТ!

Ответить
Развернуть ветку
Danya Kryuchkov

Ставь лайк, если заколебали эти пространные статьи ни о чем от очередных Agile гуру.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Sergey Puzin

Для разрабов заказчик - тимлид, для тимлида - продакт овнер, для продакт овнера - продакт менеджер и т.д.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Yantarev

Не надо никаких итд, давайте без компромиссов пройдём всё! От репки, дедки до дошки и мышки!

Ответить
Развернуть ветку
Mkha Stas

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Ksenia Salyukova

Ну фиг знает: выглядит, как методичка, как отбиться от упрёков, почему не сделал/не успеваешь/провисает направление. «А все потому, что у нас product owner-а нет»

Ответить
Развернуть ветку
Андрей Павленко
Ответить
Развернуть ветку
Eugene Zubak
Автор

Как здорово, что мои статьи вдохновляют на подобное. Обязательно как-нибудь ознакомлюсь.

Ответить
Развернуть ветку
Пономаренко Влад

А разве во многих компаниях прорабом не является проджект? Есть ощущение что Продакт овнер, это проджект на максималках.

Ответить
Развернуть ветку
31 комментарий
Раскрывать всегда