Главная ошибка 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 — это авторитет, только к нему все идут, только он решает все вопросы». Некоторые испуганно воскликнут: «А вдруг это уже и не Скрам?»

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

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

#hr #продукт #менеджмент