Product Operating Model: что происходит с ролями при переходе к продуктовой модели управления

В последнее время мы все чаще начали слышать о 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 принципы меняются, на первый план выходит конечный результат — способность быстро и непрерывно развивать продукт для клиента. Командам дают больше автономии и ответственности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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