В последнее время мы все чаще начали слышать о Product Operating Model. Это не новый фреймворк, а организационная модель управления компанией, которая определяет, как создаются и развиваются продукты, принимаются продуктовые решения, распределяется ответственность между командами и оцениваются результаты их работы. Исчезнет ли традиционный Scrum, всем ли нужно переходить на POM, почему вообще появился этот подход и какие роли он выделяет - в статье.

Откуда взялась Product Operating Model?

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

Во многом появлению этого термина в профессиональной среде способствовали работы Марти Кагана (SVPG), а также исследования Thoughtworks и Gartner, посвященные продуктовым организациям. Многие воспринимают POM как очередную методологию, которая должна прийти на смену Scrum. Однако это не совсем верное представление.

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

POM определяет, как в компании:

  • распределяют ответственность;

  • принимают решения;

  • выстроены процессы финансирования;

  • взаимодействует бизнес и ИТ;

  • оценивают эффективность.

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

Почему компании отходят от Scrum

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

Команды научились соблюдать Scrum-процессы, но это далеко не всегда означало, что они стали быстрее достигать бизнес-результата для клиента. На это обращают внимание и исследователи продуктового менеджмента, включая Silicon Valley Product Group (консалтинговая компания Марти Кагана, одного из наиболее известных специалистов в области продуктового менеджмента). Марти неоднократно подчеркивал, что зрелость процессов сама по себе не гарантирует успешность продукта.

Роли как главный источник сопротивления

Это все понятно, но как перейти к новой модели безболезненно?

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

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

В рамках Scrum эта система была достаточно понятной и устойчивой. Каждая роль имела четко определенную зону ответственности:

  • Scrum Master отвечал за эффективность процесса, помогал команде соблюдать принципы Scrum и устранял организационные препятствия.

  • Product Owner формировал и приоритизировал бэклог, принимая решения о том, какую ценность команда должна создавать в первую очередь.

  • Команда разработки самостоятельно реализовывала поставленные задачи и отвечала за качество результата.

  • Agile Coach помогал масштабировать Agile-практики, развивал команды и сопровождал организационные изменения.

С приходом Product Operating Model принципы меняются, на первый план выходит конечный результат - способность быстро и непрерывно развивать продукт для клиента. Командам дают больше автономии и ответственности.

Вот небольшая сравнительная таблица:

Scrum

Product Operating Model

Основной фокус на соблюдении процесса

Основной фокус на создании ценности для клиента

Product Owner отвечает за бэклог

Product Manager ответственен за развитие продукта и достижение бизнес-результатов*

Scrum Master во многих продуктовых организациях отвечает за эффективность процесса

Функции развития команды часто распределяются между Engineering Manager, Delivery Manager, лидерами и самой командой*

Основные показатели – Velocity, выполнение Sprint Goal

Основные показатели – продуктовые и бизнес-метрики (Outcome)

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

Команда отвечает за развитие продукта на всем его жизненном цикле

*Конкретный набор ролей зависит от структуры компании и выбранной операционной модели.

Здесь нужно запомнить главное: переход к Product Operating Model означает изменение операционной модели, а не переименование ролей. Для сотрудников это вопрос собственной профессиональной идентичности. Человек начинает задавать вполне закономерные вопросы:

  • Будет ли востребована моя экспертиза?

  • Какие задачи останутся за мной?

  • Что изменится в моей зоне ответственности?

  • Как теперь будут оценивать мою эффективность?

  • Есть ли место моей роли в новой модели управления?

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

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

Несколько рекомендаций

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

Поэтому при переходе к Product Operating Model стоит учитывать несколько принципов:

  • Не переименовывайте роли без изменения ответственности. Если Product Owner становится Product Manager, но продолжает только управлять бэклогом, организационно почти ничего не изменилось.

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

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

  • Не стремитесь отказаться от Scrum любой ценой. Для многих команд он остается эффективным способом организации работы и вполне совместим с Product Operating Model.

  • Не меняйте систему оценки последней. Пока сотрудников продолжают оценивать по срокам, количеству задач или Velocity, ожидать продуктового мышления практически невозможно.

А вы уже работаете по POM? С какими сложностями сталкивались?