Продукт-менеджер VS проект-менеджер: как выбрать профессию и не ошибиться

Продукт и проект: в чем отличия

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

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

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

Обязанности продукт-менеджера

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

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

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

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

Циклы развития продукта

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

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

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

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

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

Методы управления продуктами и проектами

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

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

Принципы бережливого производства и непрерывного совершенствования (кайдзен) актуальны и сейчас.

Джефф Сазерленд на основе японских принципов сформулировал принципы методологии SCRUM.

SCRUM (термин из регби, переводится как «схватка») — гибкая методология разработки, при которой работа делится на периоды от одной до четырех недель, в среднем это обычно две недели. Это называется спринтом — перед каждым таким интенсивным периодом выбираются наиболее актуальные задачи, над которыми команда будет работать в течение четко установленного срока. Никакие другие задачи после начала спринта не добавляются.

Для управления и контроля командами назначаются специальные роли — иногда они могут быть объединены в одних и тех же людях:

1. «product owner» — человек, обладающий видением того, что команда собирается делать, производить или достигать. Он принимает во внимание риски, выгоды,       расставляет приоритеты задач: что может быть сделано и что воодушевит команду. Эта роль совпадает с функциями продукт-менеджера.   
              
2. Команда — те люди, которым предстоит выполнить спринт. Специалисты, входящие в группу, должны владеть всеми навыками и знаниями, необходимыми, чтобы воплотить идею владельца продукта в жизнь. Команды всегда небольшие — от трех до девяти человек — это то оптимальное число людей, которые могут договориться, что и как им делать. Людей в команду обычно набирает тимлид. Каждая команда      занимается конкретным проектом или частью продукта.
              
3. SCRUM-мастер — человек, который следит за ходом проекта и помогает команде устранять мешающие им препятствия. Он координирует первичное обсуждение перед спринтом, на котором выбирают задачи для разработки. Проводит ежедневные стендап-совещания, участвует в ретроспективном обзоре спринта. Его роль не управляющая, а поддерживающая, он, скорее, фасилитатор,    то есть ответственный за коммуникацию внутри команды.

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

Главное требование к работе по методу SCRUM — прозрачность всех действий и процессов. Это обеспечивает скорейшее достижение цели. Наиболее распространенный способ добиться прозрачности — использовать scrumban – модификацию kanban специально для scrum. На доске может быть совершенно разное количество колонок — это зависит от каждой конкретной компании или команды, но всегда есть три повторяющиеся: колонка с бэклогом продукта, то есть списка всех требований к продукту, его возможных улучшений; колонка задач в работе; колонка выполненных задач.

Фото на обложке: shutterstock.com