Само понятие «владелец продукта» пришло из опыта IT-компаний, которые в разработке используют, как правило, Scrum. Для других сфер бизнеса оно может быть интуитивно понятным, либо наоборот - окажется совершенно новым, поэтому есть смысл подробнее рассказать о том, кто такой владелец продукта и почему его роль очень важна. Наш эксперт Дарья Касперова, заместитель директора по развитию бизнеса Invento Labs, назвала пять причин, почему у каждого продукта должен быть свой владелец.
Причина первая. Без драйвера далеко не уедешь
Владелец продукта – драйвер всей команды, который ведет за собой. Он точно знает, что должно получиться в итоге и как этого добиться. Именно этот человек расставляет приоритеты, на каждом этапе сопровождает разработку, корректирует курс и отвечает за качество готового решения. Результат работы владельца продукта можно измерить, например, сроком возврата инвестиций, индексом инноваций, ценностью и востребованностью продукта. Безусловно, важны набор функций, их сложность, количество потраченных денег, но для владельца продукта первостепенны функциональная ценность и время доставки на рынок.
Ключевая задача владельца продукта – наращивание ценности готового продукта. Воплотить эту задачу в жизнь может только по-настоящему преданный идее профессионал.
Как правило, владелец продукта работает на стороне заказчика. Важно быть в деле на всех этапах – это рождение идеи, её проработка, обоснование, сопровождение и развитие, вывод продукта на рынок. Самый заинтересованный человек в компании – собственник – идеально подошел бы на роль владельца продукта, располагай он временем. Если нет временного ресурса, полноценным владельцем продукта стать не получится.
– Владелец продукта, помимо обязанностей, должен обладать набором соответствующих полномочий для воплощения своих идей в жизнь. Он может подбирать команду, определять функционал, распределять бюджет. К этому человеку прислушиваются и ему доверяют. Сам драйвер верит в идею, знает пользователей и конкурентов, просчитывает выгоды и преимущества. Он задает темп и настрой всей команде, – рассказывает Дарья Касперова.
Причина вторая. Нужен носитель «сакральных» знаний
Владелец продукта – это визионер. Независимо от размеров бизнеса должен быть человек, который видит целостную картину, понимает продукт в контексте бизнеса и рынка. Нужно уметь учитывать все внутренние и внешние факторы, которые могут повлиять на жизнеспособность решения. Должна быть готовность нести ответственность за то, как продукт развивается, в каком направлении и с какой скоростью, своевременно ли доставляется конечным пользователям. Все это важно, когда речь идет и о разработке ERP-системы для внутреннего пользования. Там тоже обязателен владелец продукта, несмотря на то, что не придется строить маркетинговую стратегию и изучать внешние рынки.
Если посмотреть на процессы со стороны клиента, то там объем работы владельца продукта внушительный: участие в разработке маркетинговой стратегии, анализ рынка и конкурентов, формирование фокус-групп. Также разработка стратегии выхода на новые рынки, анализ потребностей пользователей, наполнение функционального бэклога продукта.
Согласно концепции Scrum-подхода, владелец продукта – это человек, который пропускает через призму своего видения всевозможные идеи и предложения, пожелания и комментарии. Он формирует и транслирует агрегированную точку зрения, ставит задачи и несет за это ответственность. Это всегда один человек.
Если объединить все требования к портрету идеального владельца продукта, получается на самом деле носитель «сакральных» знаний. Как правило, эта роль достается опытным сотрудникам, которые давно в бизнесе и реализовали не один подобный проект. Все это применимо и к той ситуации, когда разрабатывается ERP-система для внутреннего пользования. Там тоже обязателен владелец продукта. Несмотря на то, что не придется строить маркетинговую стратегию и изучать внешние рынки, его знания о компании и процессах должны быть всеобъемлющими.
Причина третья. Каждому IT-проекту нужен коммуникатор
Еще одна ипостась владельца продукта – эффективный переговорщик и дипломат. Он работает на две аудитории – это инвесторы и команда проекта. Перед первыми отвечает за результат, перед вторыми – за задачи, которые ставит.
– Если владелец продукта справляется и с этой ролью, то на полпути проекта вряд ли возникнет ситуация, когда инвесторы недовольны результатом и хотят видеть совсем другой продукт, а IT-команда растерянно мечется между несогласованными требованиями и приоритетами.Такие истории сильно демотивируют команду разработчиков. Уровень доверия падает, когда неожиданно становится известно, что сделанное не годится. Может пострадать и качество работы. Таких ситуаций удастся избежать, если владелец продукта умеет объединить интересы разных сторон: инвесторов, пользователей, разработчиков, отдела продаж, маркетологов и рядовых сотрудников, – говорит Дарья Касперова, заместитель директора по развитию бизнеса.
Причина четвертая. Лучше всех понимает, какое предназначение ждет продукт
«Что? Зачем? Когда?» – ответы на эти три вопроса владелец продукта точно должен знать. К примеру, готовое решение планируется выводить на зарубежный рынок, поэтому его локальные особенности важно понимать еще на старте. Владелец продукта агрегирует мнение и опыт с разных сторон и доносит команде разработчиков задачи: что мы делаем, зачем и почему, каковы приоритеты, когда решение должно быть доставлено пользователям.
Владелец продукта стратегически важен. Он собирает всю информацию о продукте и транслирует ее всем участникам процесса.
Причина пятая. Находит баланс между IT и бизнесом
Стоит избегать крайностей. Если владелец продукта имеет техническую специальность, он может начать вмешиваться в работу команды разработки. Если владелец продукта более вовлечен в вопросы бизнеса, то он будет часто оперировать фразами: «Нам надо заработать, достичь определенных показателей рентабельности». При этом он будет избегать указаний конкретных действия. Нужен баланс.
Хороший владелец продукта стремится понять техническую сторону и интересы бизнеса. От его умения балансировать зависит эффективность и прозрачность хода проекта, перекос в одну из сторон может тормозить процесс.
Если владельца продукта нет
Вам предстоят трудности. Только без наличия соответствующих полномочий у владельца продукта процесс затягивается на 30%, что говорить про его отсутствие. Проект может встать на паузу или пробуксовывать, если команда тратит время на то, чтобы найти человека, который все согласует, ответит на вопросы или откроет доступ к нужным артефактам и системам. Любые проволочки сбивают с ритма. На выходе получаем неэффективное планирование, сорванные сроки, бюджеты и самое страшное – невостребованный продукт или систему .
Хорошая новость: ответственная команда разработчиков не стартует процесс, пока в уставе проекта напротив графы «владелец продукта» не появится конкретное имя.
Сложность в том, что каноническая роль владельца продукта характерна исключительно для продуктовых IT-компаний. В бизнесе, как правило, нет отдельно выделенного человека под эти задачи. В этом случае профессиональная IT-команда, которая берется за автоматизацию в вашей компании, поддержит того, кто возьмет на себя ответственность выполнять роль владельца продукта.
Подытожим, почему важен владелец продукта в любом процессе автоматизации:
