Роль Product Owner и зачем она нужна

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

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

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

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

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

Нанятые менеджеры управляют своими командами как менеджеры проектов, со своими KPI и целями. В результате падает не только общее развитие продукта и производительность, но и мотивация команд.

Это приводит, во-первых, к значительному увеличению времени реализации задач, или рост time2market (TTM). Во-вторых, из-за несогласованности команд, отвечающих только за свое направление, на выходе очень часто получаем либо неработающий продукт, или продукт, который не соответствует заявленным требованиям. В-третьих, к увеличению технического долга, многократным доработкам и переделкам, значительному удорожанию поддержки. Такая ситуация знакома многим организациям.

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

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

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

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

Как я говорил ранее, в облаке ИТ уже могут формироваться SCRUM команды, и скорее всего на данной этапе уже существует PMO, менеджеры которого стали Владельцами продуктов. Но слаженная работа не получается. Причины в том, что эти две области совершенно не знаю друг о друге в плане работы над продуктами. Менеджеры — Владельцы продуктов, отлично работаю с командами и ускоряют процессы производства, но они совершенно не знают рынок и не понимают что и для чего они производят, им сложно ориентироваться в быстро меняющихся условиях.

С другой, стороны, “акулы” продаж, маркетинга, которые постоянно общаются с конечными клиентами, анализируют рынки, прорабатывают стратегии развития, проводят исследования совершенно не в курсе что происходит в ИТ. Со временем, эта пропасть увеличивается, в том числе, и по причине улучшения процессов разработки за счет механического SCRUM. ИТ команды начинают довольно быстро реализовывать спускаемые им задачи, и все чаще им становится не хватать этих задач. В этой ситуации, либо Владельцы продуктов, начинают ходить в бизнес за задачами, или бизнес из разных подразделений начинают ходить в команды со своими разрозненными потребностями.

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

Научить бизнес общаться с командами проще и менее затратное, чем корректировать результаты работ команд и переделывать уже существующие продукты. В результате механический SCRUM уступают место фокусировке на проверку гипотез и поставки ценности для конечных потребителей продукта. В подразделениях появляется роль Business Owner (Product Owner), которая отвечает за трансляцию ценности от бизнеса до уровня команд.

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

И в это время появляется последняя роль или уровень развития владельцев продукта.

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

Целью данной роли является стратегическое планирование развития продукта или пакета продуктов компании. Данная роль выступает лидером коллектива Product Owner-ов, которые по отдельности занимаются своими продуктами. Она координирует их работу параллельно прорабатывая возможности развития новых продуктов или путей развития существующих. Это не только грамотный управленец, но и, в первую очередь, специалист с глубоким понимание коммерческих основ формирования рынка продуктов, формирования и образования новых рынков и ниш. Его роль — развитие компании и продуктов компании на пике развития и коммерчески интересных и привлекательных направлений развития рынков. К сожалению, на том уровне развития гибких методологий управления таких специалистов очень мало.

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

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

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

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