Должность product owner что это

Опубликовано: 30.06.2024

В Scrum-команде есть "владелец продукта", или "product owner". Эта специфическая роль не всегда ясно понимается начинающими командами. Объясняем, кто такое владелец продукта, почему он так необходим и правда ли, что владельцем может стать не только акционер компании?

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

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

Владелец в Scrum знает:

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

Он же отвечает за масштабирование или закрытие проекта.

В Scrum есть правило: product owner — это один человек, который отвечает за один продукт. Но вполне возможно, что ему придется взять дополнительные роли в команде или в бизнесе. Зависит от масштаба продукта и других обстоятельств.

Если вы впервые узнали про Scrum и не представляете, как все работает в одной системе, это видео поможет:

Как стать владельцем продукта?

У компаний, которые начинают работать по фреймворку Scrum, возникает такой вопрос. В этой должности важен опыт и гибкие навыки. Не хочется превращать статью в объявление о вакансии, но Product Owner действительно должен быть ответственным, активным и заинтересованным. К тому же, претендент на эту роль должен разделять принципы Agile. А вот если команде можно доверять, то навыки программирования не нужны: неплохо знать, чтобы ориентироваться в сроках, но докторская по информатике не поможет делать продукт сама по себе.

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

На роль может претендовать разработчик, если достаточно изучит бизнес. Нередко активные scrum-мастера получают новый проект в свое руководство.

Кажется, подобрать кандидата сложно. Может команда обойтись без него? Тогда она столкнется с несколькими проблемами:

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

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

Личность — главное, что требуется

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

Опорная точка — личностные качества.

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

Успешному владельцу продукта необходимы такие качества:

Все коммуникативные навыки, которые только известны, так как значительная часть его работы — это общение.
Умение говорить "НЕТ", когда запрос выходит за рамки проекта, и "ДА", когда он улучшает работу. Владелец не просто принимает заказы и пытается удовлетворить все запросы, он должен отделять шум и ставить приоритеты. В противном случае, без фильтра требований, команда или будет перегружена, или очередь разработки забьется на месяцы (что не делает проект гибким).
Дальновидность, которая не превращается в паранойю: стратегия и план действий необходим, его нужно обсуждать с заказчиками и выгодно презентовать. Но пытаться запланировать детальную дорожную карту — прямое противоречие философии Agile. Предполагается умение быстро ориентироваться и реагировать.

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

Тем не менее, есть обучение и сертификация на эту роль. Проводят несколько организаций:

Certified Scrum Product Owner® в Scrum Alliance,
Professional Scrum Product Owner™ в Scrum.org ,
Certified Scrum Product Owner Training от Scrum Inc.,
онлайн-курс от 280group,
в России тренинги предоставляет ScrumTrek и несколько других площадок.

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

Что еще важно учесть?

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

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

Для продукт-оунера губительны две проблемы (в череде прочих):

отсутствие полномочий, когда нет поддержки со стороны руководства и команда не может быть эффективной: владелец не может принимать реальных решений;

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

Роман Пихлер, ведущий эксперт по Scrum и Agile, так говорит про владельца продукта:

Меня зовут Дмитрий Котенко, я – генеральный директор студии по разработке приложений InfoShell. Так как этот журнал читают не только специалисты и бизнесмены, но и молодое поколение, которому, возможно, будет интересна работа над созданием диджитал-продуктов, я решил поделиться информацией о профессии продакт оунера. Приятного чтения!

Пара вступительных слов

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

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

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

Итак, 7 основных обязанностей продакт оунера:

Определение видения продукта

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

Наличие продакт-оунера на проекте гарантирует заказчику, что agile-команда будет придерживаться того видения, которое установлено заказчиком. Для этого продакт-оунер составляет дорожную карту продукта (roadmap) – краткосрочный или долгосрочный план выполнения, изменения и развития проекта.

Управление бэклогом продукта

Еще одна обязанность продакт оунера – управлять бэклогом. Бэклог – это список задач для команды разработчиков, который может меняться в зависимости от потребностей проекта. Изменять бэклог может как продакт оунер, так и разработчик. Здесь обязанность продакт оунера состоит в том, чтобы составить список задач и определить их приоритетность выполнения в соответствии с бизнес-задачами заказчика.

Приоритезация потребностей продукта

Приоритезация потребностей – неотъемлемая часть agile-процесса. Она также зависит от бизнес-задач заказчика и сроков выпуска проекта. Например, если разрабатываемый продукт должен быть запущен в течение 6 месяцев, продакт оунер должен определить, какие главные функции должен включать его MVP (minimum viable product) – минимально жизнеспособный продукт, и, исходя из этого, решить, длительность каких итераций можно изменить. Приоритезация потребностей также зависит от бизнес-задач заказчика.

Контроль на всех этапах разработки

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

Выработка продуктовой стратегии совместно с заказчиком

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

Эффективная коммуникация с заказчиком и разработчиками

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

Оценка прогресса продукта

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

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

Product Owner является неким связующим звеном между заказчиком и командой разработки. Окончательная инстанция по принятию решений в Scrum Team – это как раз и есть Product Owner.

Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

Определение элементов бэклога продукта;
Правильное расположение элементов для оптимизации достижения цели;
Обеспечение понятности и прозрачности Product Backlog;
Обеспечение прозрачности и понятности требований, над которыми предстоит работать всей Scrum Team;
Общая оптимизация для достижения наибольшей ценности работы Development Team;
Ответственность за понимание бэклога командой разработки.

Стоит отметить, что Product Owner может сам выполнять все вышеперечисленные обязанности, а может отдать их на исполнение Development Team, однако всегда остается ответственным.

Решения Product Owner по реализации тех или иных задач должны исполняться. Все свои решения владелец продукта транслирует через тот Product Backlog, который получается. Важно при этом помнить, что влиять на саму работу Development Team он не может и порой даже не присутствует на планированиях, например, на Scrum Planning Meeting, однако он всегда должен находиться рядом, чтобы в случае возникновения вопросов их можно было оперативно решить.

Жизнь Product Owner внутри Scrum Team

Для Product Owner важно писать задачи не со стороны того же программирования, а со стороны требований заказчика – «хотелок». Например, система выборки журнала работает медленно, хотелось бы быстрее. Если Product Owner напишет: «Произвести оптимизацию базы данных», то это неправильный подход. Проблема ведь может быть и не в базе данных, или не только в ней. Поэтому описание всех задач идет на простом языке, например: «Ускорить выдачу журнала». Для идей решения проблем Product Owner (да и любой другой) есть поле «Примечание» в Product Backlog.

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

Возвращаясь к тому же Planning Meeting, можно часто заметить, что как бы ни старался Product Owner в заполнении Product Backlog, всегда появляются спорные моменты. Самая основная проблема – переоценка Story Points. Product Owner порой не может предусмотреть всех технических аспектов того или иного действия (да и не должен), и, давая задачу, он может не предусмотреть каких-то дальних сложных взаимосвязей, которые увеличивают срок выполнения работы в несколько раз. В таком случае происходит пересмотр оценок этой задачи, а это может повлиять на выход общего количества Story Points за пределы возможностей команды, оцененные по Velocity.

Подробнее о данной проблеме написано в статье про Sprint Backlog.

Product Owner нужен не только на начальном этапе, как может показаться, но и на протяжении всего Sprint. Взаимосвязь с командой правда проходит только односторонняя – команда, по мере возникновения вопросов, вправе привлекать Product Owner. Чаще происходит так, что время, необходимое для привлечения Product Owner, зависит от общего времени, проведенного с командой. Про такое говорят: «Команда созревает для вопросов к Product Owner».

Также важной обязанностью Product Owner является остановка спринта. В статье Abnormal Termination / Остановка спринта подробно описано это действие.

Scrum Team

Главный действующий единый организм, который всеми силами пытается не допустить появления такой неприятной ситуации как Остановка спринта / Abnormal Termination и выполняющий всю работу.

Product Backlog

Основной список всех задач, в котором собрано всё, что предстоит сделать команде на протяжении нескольких спринтов. Из него задачи переносятся в Sprint Backlog.

Development Team

Двигатель Scrum Team. Команда разработчиков работает как слаженная футбольная или любая другая команда. На их поле игры (битвы) - им никогда никто не мешает, а лишь помогает. Основной их помощник - Scrum Master.

Sprint Planning Meeting

Очень важно и ответственное мероприятие в методологии Scrum, которое напрямую будет влиять на всю работу в будущем. Stakeholders могут посещать данное мероприятие.

Story Points

Чтобы отчетливо понимать как формируется Velocity в Scrum, нужно понимать как грамотно оценивать Story Points. Данное понимание приводит к развитию максимально продуктивной команды.

Velocity

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

Sprint Backlog

То что попало из Product Backlog в Sprint Backlog и будет набором задач на текущий Sprint. Sprint Backlog - крайне продуманная вещь, которая позволяет выполнить именно те задачи за итерацию, которые создадут рабочий продукт.

Scrum Sprint

Пожалуй основной процесс в методологии Scrum, остановка которого и может произойти. Во время Sprint происходит вся работа Development Team, Scrum Master и Product Owner.

В своей предыдущей статье я рассказывала о роли Product Manager и том, чем она отличается от роли Project Manager. Стоить отметить, что понимание этих позиций разнится не то что в разных странах, а в разных компаниях в пределах одного города. Одни их противопоставляют, другие считают, что эти должности взаимозаменяемы, третьи - что функции продакт-менеджера входят в функции проджекта.

Кто прав? Единого ответа нет. Сфера ИТ стремительно развивается, компании расширяются, создаются новые проекты, которые требуют новых подходов. Появляются “многостаночники”: девопсы, фулстек-разработчики, технические проджект-менеджеры. Все это зачастую приводит к путанице, когда HR-команда не может четко сформулировать, кто же им собственно нужен, и появляются вакансии, которые включают в себя набор обязанностей “от всех по чуть-чуть”.

Сделав сравнение Project Manager и Product Manager, я получила вопрос:

“А в чем тогда разница между Product Owner (владелец продукта) и Product Manager (менеджер продукта)?”

Давайте разбираться вместе!

Product Manager не привязан к какой-то определенной модели, методологии или фреймворку.

Product Owner - это понятие из Scrum. У того, кого так назвали в команде проекта, есть набор своих функций и обязанностей.

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

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

Продакт-менеджер - стратег. Он дает направление, куда мы будем идти и что мы будем там делать.

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

Главный KPI продакт-менеджера - продукт, приносящий прибыль компании.

Главный KPI продакт-оунера - продукт, максимально соответствующий требованиям на момент его реализации.

На этапе зарождения продакт-менеджмента скорость развития рынка и выпуска продуктов была совсем другой. Продакт-менеджер разрабатывал видение продукта и передавал его на реализацию проджект-менеджеру. В 1980-х, когда рынок стал меняться быстрее, продукты к моменту их выхода могли потерять свою актуальность. Появился Scrum со своей ролью владельца продукта, который чувствует, “куда ветер дует” относительно его бизнеса, и вносит необходимые изменения в беклог, постоянно держа руку на пульсе и корректируя приоритеты.

Написанное выше - это скорее из серии “как задумывалось”. Как же дело обстоит на рынке труда? Есть ли запросы на эти должности и что входит в круг их обязанностей? К примеру, на DOU мы получаем 100+ вакансий для Product Manager (средняя зарплата от $1800 при опыте 2+ лет) и 30+ при запросе “Product Owner”. Rabota.ua нам показывает 300+ вакансий для продакт-менеджера и 70+ для продакт-оунера. Headhunter по запросу для России и Украины выводит более 2000 вакансий для Product manager и 600+ для Product Owner.

Как дело обстоит с релевантностью? Написав запрос “Product Manager” на dou.ua, мы получили 113 результатов. Однако вакансий с точно таким же названием оказалось 76, еще 26 подтянулось в виде “Product Owner”, остальные включали в себя Support Representative, Game Producer, Business Analyst, Project Manager или Brand manager. Что получилось, когда мы поставили запрос на “Product Owner”? 28 оказались релевантными, 3 были написаны - Product Owner/Product Manager. Картина с запросом “Product Owner” на rabota.ua показала, что эта роль тоже не до конца понята.

Давайте еще взглянем на эти должности в разрезе Facebook, Amazon и Google. Поискав их в списке вакансий, мы нашли запросы на менеджера продуктов - от Intern до Senior. Facebook описывает эту должность как

“визионера, который ведет идеи новых продуктов от первоначального концепта до запуска “созревшего” продукта”.

Примеры вакансий и более подробное их описание можно посмотреть FB Product Manager и Sr. Product Manager от Amazon. В Google помимо более 600+ запросов на эту должность, есть своя обучающая программа “Google Associate Product Manager Program”.

А что же с требованиями к этим должностям? Какими эти позиции видят рекрутеры?

Требования к Product Manager:

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

Понимание, как превращать потребности клиента в готовый продукт.

Опыт в проведении тестов (к примеру, A/B, A/A) и навыки анализа больших объемов информации.

Знание принципов UX/UI дизайна и инструментов для прототипирования.

Опыт в создании плана развития продукта или отдельных функций и отслеживание его выполнения.

Умение работать в постоянно-меняющейся окружающей среде и сбор необходимых аналитических данных для “процветания” продукта в этих условиях.

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

Знание английского языка - не ниже Upper Intermediate.

Требования к Product Owner

Опыт работы в Scrum и понимание гибких методологий и фреймворков в целом.

Организационные, аналитические и коммуникационные навыки.

Умение находить ключевые проблемы и возможности разрабатываемого продукта.

Способность правильно приоритизировать деятельность (как свою, так и команды) для успешной работы над проектом.

Умение анализировать, КАК думают потенциальные пользователи, ЧЕГО они хотят, КАК себя ведут с целью дальнейшего “превращения” этой информации в функции и услуги.

Способность “предсказывать” тренды в будущем, основываясь на имеющихся данных.

Опыт в оптимизации продукта через А/В тестирование.

Умение разбивать весь объем работы на отдельные задачи для дальнейшей презентации их стейкхолдерам и членам команды.

Знание английского языка - не ниже Upper Intermediate.

Опыт написания технической документации.

И если требования более-менее отличаются, то обязанности очень подобны.

Обязанности Product Manager:

Находить и анализировать возможности рынка и потребности ЦА для создания концепта продукта и стратегии его разработки.

Общение с клиентами напрямую.

Создание плана разработки, контроль его выполнения и написание документации.

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

Написание high-view требований и детализация их с командой.

Создание пути клиента “от А до Я”, чтобы впечатления пользователей были максимально положительными на всех этапах взаимодействия с продуктом.

Мониторинг метрик, создание и проверка гипотез.

Помощь при выведении продукта на рынок и дальнейшая его поддержка.

Обязанности Product Owner:

Анализировать рынок и потребности клиентов, понимать их ожидания и психологию.

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

Быть “клеем” для команд аналитиков, дизайнеров, разработчиков и поддержки, чтобы происходила эффективная коллаборация между ними.

Определять объем работ для разработчиков и формировать беклог.

Управлять релизами, ставить задачи команде.

Участвовать в демонстрациях и ретроспективах.

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

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

Формировать дорожную карту продукта.

Контролировать создание продукта от идеи до поставки заказчику.

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

Какой вывод? В компаниях, особенно продуктовых или с продуктовой моделью работы, должность менеджера продуктов - это must-have, ведь именно он должен разрабатывать продукт, который будет приносить прибыль.

Если компания работает по Scrum, SAFe и т.д., то появится владелец продукта - человек, отвечающий как минимум за постоянную приоритизацию требований к разрабатываемому продукту и дающий быструю обратную связь команде разработки.

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

Когда мы говорим о менеджерах в IT, то, как правило, в первую очередь упоминаем менеджеров проектов и продуктов. Но чуть реже среди вакансий встречается и такая позиция, как product owner — владелец продукта. И если границы зон ответственности между продактом и проджектом всё ещё обсуждаются, то владелец продукта — даже более дискуссионная роль.

Product owner? Это как product manager?

Основных интерпретаций здесь две. Первый вариант объяснения, чем отличается продакт-оунер от продакт- и прочих менеджеров, — методологический. В этой версии продакт- и проджект-менеджер — это специальности или должности сотрудников, а product owner — это роль в скрам-методологии. Таким образом, если команда работает не по Scrum, то и product owner’а там быть не может.

Другое толкование — более практическое и гораздо чаще встречается в реальной жизни, хотя не имеет методологического обоснования. Здесь роль product owner’а понимается буквально — владелец продукта. Схоже с продакт-менеджером, но ответственность за продукт более широкая и задач больше. Зачастую product owner совмещает роли продакта, проджекта и даже иногда аккаунт-менеджера и маркетолога.

В ряде структур он может быть единственным руководителем всех членов своей команды и иногда по статусу сопоставим с директором. То есть не «первый среди равных», как у продакт-менеджеров, а именно начальник — так бывает в организациях, где эта роль толкуется именно таким образом. Причём если в компании есть product owner, то это совершенно не исключает того, что в команде могут быть и продакт-, и проджект-менеджеры. Распределение задач и ответственности между ними может быть очень разным — всё зависит от компании.

Продакт-оунер на примере Sifox

Компания Sifox, где я сейчас работаю, создаёт и внедряет продукты для мобильных операторов. Наши заказчики — очень крупные компании по всему миру, а наши продукты — это технически серьёзные платформы с высокими требованиями по нагрузке и отказоустойчивости. Это не те вещи, которые можно сделать за неделю: каждая доработка занимает много времени, а каждое новое внедрение продукта у оператора требует значительных кастомизаций продукта, настроек и согласования деталей с заказчиками. Так что мы пришли к роли product owner’а (во втором значении) почти сразу. Расскажу, как она эволюционировала по мере роста компании.

Как это выглядело раньше? Когда продукты только создавались, а клиентов было не так много, во главе команды стоял product owner. Он определял стратегию развития продукта, руководил командой в процессе его разработки, курировал внедрения и взаимоотношения с заказчиками. По сути, он выполнял роли продакт-, проджект- и аккаунт-менеджера.

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

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

Чем занимается product owner теперь

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

Продукт на этапе идеи или гипотезы

В этом случае продукта как такового ещё нет — есть только предположение о том, что можно было бы сделать: чтобы это было реально технически и востребовано на рынке. Эдакий стартап внутри компании. Product owner в этой истории эквивалентен классическому продакт-менеджеру. Его задача — разобраться с имеющимся набором идей и гипотез и проработать их, изучая рынок, потенциальных заказчиков и пользователей. А ещё обговорить с технической командой возможности реализации, спрогнозировать бюджет продукта и сформировать план его создания — и здесь в первую очередь должны быть представлены способы верификации предположений.

Иногда для подтверждения гипотезы нужен прототип

По мере готовности продакт презентует результаты исследования и план действий перед «инвесторами» — руководителями компании. А они решают, стоит ли выделять ресурсы команды и продолжать работу над гипотезой. Здесь есть ещё одна особенность: продукты Sifox ориентированы на абонентов мобильных операторов, поэтому мы не можем просто так взять и разработать что-то новое, пока не продали это оператору. Так что недостаточно того, что продукт интересен компании, — нужно ещё убедить в его перспективности хотя бы одного клиента.

Продукт на этапе разработки

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

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

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

Согласования внутри оператора иногда принимают абсурдный оборот

Продукт нужно будет внедрить — то есть установить разработанное ПО в контуре оператора, интегрировать с множеством других систем, убедиться, что никакая логика не ломается, а система выдерживает нагрузку.

Ну и, чтобы было что внедрять, продукт всё-таки понадобится разработать — это отдельный важный процесс.

На ранних этапах (при создании MVP, например) или если продукт несложный, всё это может делать product owner — в Sifox именно так и было долгое время. Но в одиночку выполнять на высоком уровне все эти обязанности может оказаться непосильной задачей, поэтому некоторые из них владелец продукта может делегировать менеджерам. У нас обычно привлекается проджект для управления внедрением и разработкой, а продакт-оунер занимается остальными задачами. С проджекта спрашивает только результат, то есть является для него внутренним заказчиком.

Примерно так выглядит product owner, который пытается выполнить все задачи самостоятельно

Продукт на этапе развития

Когда первое внедрение продукта пройдено, а все гипотезы о его жизнеспособности и нужности подтверждены, продакт-оунер получает ещё обязанностей на свою голову.

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

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

Каждое новое внедрение пополняет копилку клиентской базы продукта. И за каждым оператором, где установлен наш продукт, нужно следить: проверять отчётность, выставлять счета, предлагать дополнения и расширения, своевременно отбиваться от сравнений с конкурентами. Чем больше клиентов, тем больше такой работы.

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

Помимо бизнес-развития есть ещё и техническая сторона решения: продукт нужно постоянно поддерживать, вовремя расширять инфраструктуру и реагировать на обращения операторов и аварии. Со временем может потребоваться переработка модулей, может остаться какой-то техдолг. Продакт должен быть в курсе происходящего.

Вот так выглядит продукт, product owner которого пытался выполнить все задачи самостоятельно

В Sifox для продуктов на этом этапе сложилась следующая конфигурация:

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

При этом роль product owner’а по-прежнему сохранилась у нас в компании. Он главный по продукту, в развитии которого участвуют менеджеры. Фактически продакт-оунер руководит всей этой командой.

Какие компетенции важны для продакт-оунера

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

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

Всё это можно воспитать в себе, хоть и потребуется немало времени. Лучше всего эти навыки нарабатываются с опытом — а чтобы его получить, начать можно с ролей попроще. Дерзайте!

Читайте также: