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

Для начала: кое-что о проектах и продуктах

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

Проект — фиксированный список задач, которые нужно выполнить в отведенный промежуток времени, чтобы получить ожидаемый результат в виде уникального продукта или услуги (или какой-то его части). То есть у нас есть конкретный срок, в который мы планируем уложиться, конкретный перечень работ по проекту и видение того, что мы получим в итоге.

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

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

Связь между проектом и продуктом

Продукт создается в контексте проекта, а в жизненном цикле продукта может быть несколько проектов. Если ваш продукт — свадебный торт, то для его создания придется развернуть минимум три проекта (иногда — параллельно и даже силами разных команд): проект по созданию коржей, проект по созданию начинки и проект по созданию финального покрытия. Если продукт — приложение, то по ходу его жизненного цикла может быть проект по созданию MVP, проект по созданию первой версии, второй, третьей, и так до бесконечности. Напоминает спринты из Scrum? Всё верно :)

Чем отличаются продакты и проджекты

1. Временные рамки

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

2. Ключевые вопросы

Цель продакта — понять, почему. Почему продукт будет именно таким. Почему в нем будут конкретно эти фичи. Почему пользователи станут им пользоваться. Цель проджекта — понять, как. Как именно добраться из пункта А, где продукта ещё нет, в пункт Б, где он готов. Какие ресурсы использовать. Какие шаги предпринять и в какой последовательности. Как организовать работу в целом.

3. Задачи

Из-за разницы целей работы продакта и проджекта разнятся и их ежедневные задачи.

4. Навыки

Проджекты и продакты отличаются и набором навыков, хотя и могут переходить из одной роли в другую.
Навыки, которые пригодятся обоим — перечень из большого списка Soft Skills (необязательно сразу все, но очень желательно). Например:

  • Общение: хороший менеджер проекта или продукта — это эффективный коммуникатор, который представляет интересы заинтересованных сторон.

  • Требовательность: к себе, своим результатам и к команде — только так можно добиться достойных результатов вовремя.

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

  • Ответственность: проблемы с продуктом или проектом непременно будут, на любых этапах — и здесь важно не перекладывать ответственность, не откладывать их на «когда-нибудь» и делать то, что быть готовым рисковать собственной шкурой.

  • Аналитика и критическое мышление: важно понимать, как и откуда берутся данные, и уметь верно их интерпретировать.
Какие навыки жизненно необходимы на старте профессии продакта и проджекта, почему нужные именно они и как их прокачать, можно прочесть в книге «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий».

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

5. Критерии эффективности

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

Нагляднее могут быть общие метрики из Agile-разработки, которые так проще измерить и которые так нравятся всем заказчикам:
1
Velocity, или Скорость — объем проделанной командой работы за один спринт. Если менеджер уложился в планируемый объем, значит, он эффективно «науправлял».
2
Cycle time, или Время цикла — время для выполнения одной задачи.
3
Cumulative flow, или Совокупный поток — количество разных типов задач на каждой стадии проекта. Показывает, насколько эффективно задачи продвигаются по разным стадия проекта.
4
Flow efficiency, или Эффективность потока — соотношение времени работы и времени ожидания.
Менеджер продукта
Для оценки работы продакта пригодятся метрики, которые показывают успешность самого продукта:
1
Набор метрик под аббревиатурой AAARRR — Awareness (осведомленность потенциальных клиентов), Acquisition (количество покупок или установок), Activation (активация), Revenue (ежемесячный доход или выручка), Retention (удержание), Referral (рекомендации), которые определяют успех продукта.
2
Индекс NPS — соотношение лояльных пользователей, которые будут советовать продукт, и тех, кому продукт не зашел.
3
Трафик пользователей — общее количество пользователей, которые нашли и использовали продукт.

2 в 1: проджект и продакт в одном лице — бывает ли?

Бывает, и часто. Как правило, роли стараются развести в крупных компаниях или больших командах, и тогда получается, что каждый занимается своим делом: продакт — изучает рынок и пользователей, генерирует идеи и формирует видение продукта, а проджект — превращает большие фичи и «хотелки» продакта в понятный список задач для команды. Вроде бы, все довольны, но есть свои минусы:
1
Дисконнект по обратной связи: например, продакт описал задачи, передал их проджекту, тот спланировал спринт. Но когда разработчик принялся за дело, у того появились вопросы по бизнес-логике, и он пошел сразу к продакту. Проджект при этом не в курсе, что там вообще у них происходит, или же узнаёт об этом последним.
2
Меньшая осведомленность проджектов: когда проджект получает задачи от продакта, то не знает всего контекста, поскольку не так глубоко знает продукт — от этого и результат работы команды может быть не тем, что ожидал получить продакт. Команде при этом придется вносить правки в то, что сделано, вроде бы, по ТЗ.
3
Недостаток экспертизы и несоответствие ожиданий: например, для выполнения задачи нужно уточнить вводные, а для их уточнения нужен рисерч предпочтений пользователей — и это уже ответственность продакта. Тогда проджекту приходится останавливать процесс разработки и идти к продакту за этими данными. А ещё у продактов и проджектов могут расходиться мнение: например, об UI/UX или пользовательских предпочтениях.
Как решить эти проблемы? Есть пара вариантов.

1. Четко обозначить границы ответственности двух ролей

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

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

Любые вопросы команда сначала задает проджекту, и только если тот не может ответить, он идёт к продакту. А все уточнения фиксируются в описании задачи.

2. Слить роли в одну

Если позволяют компетенции менеджера и размер команды, можно отдать обе роли одному человеку. Это решит сразу несколько проблем и добавит предсказуемости и управляемости:
1
Общая картина по продукту: продуктом управлять легче, если ты отвечаешь и за видение, и за его реализацию командой на практике — знаешь о нюансах разработки, пользовательских ожиданиях и проблемах и можешь планировать работу команды с учетом всех этих данных.
2
Никаких размытых границ и потерь при передаче данных: ты в курсе всей аналитики, прогрессов и списка нужных фич, и можешь ответить на любой вопрос команды (а команда точно знает, к кому с таким вопросом обратиться).
3
Четкая ответственность: когда обязанности поделены между продактом и проджектом, границы ответственности размываются, и их постоянно нужно контролировать. Когда ты один отвечаешь за весь процесс — увильнуть от чего-то уже не получится.
Один из главных минусов слияния ролей — у менеджера остается меньше времени на типично продуктовые задачи: вместо кропотливого изучения рынка, пользователей и самого продукта нужно ставить задачи команде, контролировать их выполнение и следить за процессом.

Команда «Академии Яндекса» узнала у своих менеджеров, как они относятся к совмещению ролей продакта и проджекта:
“
Совмещать это в одном человеке можно. Но начинается тяжёлый внутренний диалог, возникают зачатки раздвоения личности. Ты такой придумал что-то из разряда «прямо вау», а потом внутренний голос говорит тебе, что команда устала и в сроки не уложимся.
— Андрей Гевак, руководитель Яндекс.Музыки и Яндекс.Радио
“
Хорошо бы, чтобы у продакта были скиллы проджекта. Проджект у нас занимается процессами в разработке, отвечает за то, чтобы были выполнены требования к релизу, чтобы всё было вовремя, ведёт дашборды в Трекере, ставит таски, собирает API от смежников и т. д. Он должен быть суперкоммуникабельным, готовым со всеми договориться, понимать, что кто-то что-то не хочет делать, уметь с ним поговорить об этом, следить за сроками, быть очень ответственным, самодвижущимся, аккуратным. И не умирать от рутины.
— Елизавета Семяновская, руководитель Яндекс.Транспорта
В «Сибирикс» клиентские проекты ведут проджект-менеджеры. Но собственным продуктом SingularityApp управляет директор по продукту, который совмещает функции руководителя проекта с функциями руководителя продукта.

Екатерина Мамонтова
Директор по продукту SingularityApp
— К тому моменту, когда стартовали разработку продукта SingularityApp, я работала проджектом в заказной веб-разработке 8 лет. Сначала думала, что значительной разницы в управлении проектом с позиции продуктовой разработки не будет — тоже проект, тоже нужно делать задачи, планировать время и ресурсы, работать с постановками.

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

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

Отдельный контур — это маркетинг и его показатели. И вот уже приходится разбираться в новых тонкостях — границы расширяются. Начинаешь разбираться в SEO, ASO, маркетинговых показателях, каналах продвижения. Это не говоря о том, что контур технической разработки тоже остается. SingularityApp — кроссплатформенный продукт, и при внедрении новой функции нужно учитывать ее влияние на другие части системы и все платформы.

На вопрос, хотелось бы разделить роли проджекта и продакта в проекте — отвечу «Нет». Потому что задача управления продуктом для меня интересная и драйвовая. Да, больше ответственности, больше рисков, постоянно нужно держать руку на пульсе. Но и кайфа от результата тоже больше :)

Вопрос на засыпку: а кто тогда в этой системе Владелец Продукта?

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



Скачать полное русскоязычное руководство по Scrum бесплатно.

Что делает Владелец Продукта

  • Несет ответственность за успех продукта и окупаемость инвестиций.
  • Отвечает за видение продукта.
  • Предоставляет ресурсы для создания продукта и отвечает за бюджет.
  • Отвечает за постоянную поддержку и развитие продукта.
  • Максимизирует ценность и пользу продукта для его пользователей и компании.
  • Управляет Бэклогом Продукта (перечнем всех необходимых фич): упорядочивает его элементы и делает бэклог понятным и прозрачным для всех участников команды.
  • Общается со стейкхолдерами: объединяет их видение с целями и задачами продукта.

Чего он точно не делает — не превращается в мальчика на побегушках у стейкхолдеров: он не собирает их видение, чтобы объединить все мнения во что-то невнятное и похожее на Франкенштейна. Вместо этого он корректирует своё видение продукта с учетом пожеланий стейкхолдеров.

Также Владалец Продукта не планирует процесс его создания — это задача менеджера проекта. Так же как и управление ресурсами команды, качеством и рисками.

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

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

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

Разница примерно такая:
Так что, если вы вдруг и Владелец Продукта, и продакт в одном лице — нестрашно. Просто придется сочетать все эти задачи в своем расписании дел :)

Из проджекта — в продакты, или наоборот?

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

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

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

Проджекты, как и продакты, в своей работе обычно ориентируются на пользователей конечного продукта. Но продакты в этой теме обычно более «прошаренные»: им важно знать, что думает, чувствует и хочет пользователь от продукта. Почему он ведет себя так, а не иначе. Что им движет и когда. Какие потребности у него есть и какие функции нужны, чтобы их закрыть. Так что, если решили быть продактом, велкам в глубинные исследования потребностей пользователей, методы вроде MVP, RAT, JTBD, CJM, CustDev, Data Driven и прочие интересности — прилагаются. Ну и книжку нашу всё-таки советуем почитать, скоро выйдет :)

Закрепить

Чтобы точно-точно разобраться в разнице продактов и проджектов, прделагаем пройти тест:
Тест
Продакт или проджект?
Проверим, хорошо ли вы запомнили отличия проджекта и продакта
Начать
Какое утверждение верно?
Продукты, конечно, тоже стартуют, но их дедлайн всегда хочется отложить в далекое будущее.
Всё верно!
Отчасти инвестиции тут тоже играют роль, но верный ответ всё-таки 2.
Увы, нет.
Дальше
Проверить
Результаты
Какое утверждение верно?
Всё так.
Увы, нет.
Увы, нет.
А вот и есть!
Дальше
Проверить
Результаты
На какие вопросы отвечают продакты и проджекты?
Напутали, увы.
Напутали, увы.
Наоборот же :)
Верно!
Дальше
Проверить
Результаты
Исследование аудитории, рынка, потребностей, пользовательских сценариев и конкурентов — задача…
Верно!
Нет.
Дальше
Проверить
Результаты
Планирование объема проекта — задача:
А вот и нет.
Верно!
Дальше
Проверить
Результаты
Кому больше пригодится стратегическое мышление?
Верно, ему же за путь продукта отвечать.
Пригодится, но необязательно.
Дальше
Проверить
Результаты
Velocity — критерий оценки работы…
Нет, у продакта свои показатели
Верно!
Дальше
Проверить
Результаты
Главный минус слияния ролей проджекта и продакта в одном человеке:
Если он в крусе всего, как это нет? :)
Наоборот, всё чётко
Да, увы.
Нет, с этим никаких проблем.
Дальше
Проверить
Результаты
Главная задача Владельца Продукта — …
Нет, это задача продакта
Всё так, кто ж ещё это сделает.
Ошибочка, это проджект.
Ошибочка, это проджект.
Дальше
Проверить
Результаты
Кто управляет бэклогом продукта, а кто бэклогом — проекта?
Вас не проведёшь, верно!
Мы-таки вас запутали.
Мы-таки вас запутали.
Мы-таки вас запутали.
Дальше
Проверить
Результаты
«Я просто посмотреть»
Ну вы просто любите тыкать опросы, мы поняли:)
Ещё раз!
Перечитаете, может быть? :)
Кое-что про разницу усвоили, но можно бы пробежаться по тексту снова.
Ещё раз!
Несите зачётку, пять!
Один раз прочитали — и уже всё знаете :) Браво!
Ещё раз!