У человека, не слишком глубоко погружённого в айти, может создаться впечатление, что продакт и прожект — это как Вупсень и Пупсень, Жиган и Джиган. На самом деле, эти профессии различаются не просто сильно, они разные идеологически. В этой статье разберём, в чём разница.
А главная разница в том, что продакт управляет продуктом, а прожект — проектом или проектами. Продукт не имеет чётких ограничений по продолжительности, проект — всегда с дедлайном.
Вот иллюстрация продуктового цикла:
Жизненный цикл проекта выглядит иначе:
Проект может быть подчинённой сущностью, по отношению к продукту. Например, у нас в качестве продукта мобильное приложение по изучению иностранных языков. У этого продукта могут быть подчинённые проекты в виде добавления в приложение новых языков и новых уроков.
Ещё раз. Продукт существует весь свой жизненный цикл, который может продолжаться годами и десятилетиями. Проекты тоже бывают долгими, но они всегда имеют чёткое ограничение. То есть, языковое приложение существует, пока востребовано на рынке и приносит прибыль, добавление языка ограничивается несколькими месяцами.
Продакт в данной схеме «подаёт патроны» прожекту. То есть, формулирует, что мы будем делать. Прожект решает, как это делать.
Давайте разбираться с обязанностями.
Обязанности прожект менеджера
Кадровая работа
Пиэм обязательно должен участвовать в отборе людей в команду. Как минимум, смотреть резюме, присутствовать на каждом собеседовании, рассказывать там о проекте и формировать собственное мнение о каждом кандидате. Да, скрининг проводит рекрутер, техническую часть собеседования — технический специалист, но конечное решение в итоге за вами.
Пиэм должен следить за атмосферой в команде и разруливать конфликты, если таковые вылезут.
Кроме того, пиэм разруливает ситуацию, когда кто-то из команды хочет уволиться или ротироваться. Пытается удержать человека, если не выходит — найти замену и проконтролировать передачу дел.
Работа на пресейле
Если мы говорим о компании аутсорсной разработки, проджект менеджер организует работу на пресейле. То есть, компания получила лид, заказчик заинтересован в проекте, нужно сформировать вариант реализации и верхнеуровневую оценку. В продуктовых компаниях я пресейлы не встречал.
Планирование проекта
Прожект менеджер организует процесс планирования проекта и точной оценки. Составляет план с вехами, основные проектные документы. Формирует дизайн команды, в некоторых компаниях — ещё и финансовую модель, но это уже ближе к функциям продакта.
Я настаиваю на том, что не стоит подменять пресейлом фазу планирования. Это две разных активности и пиэм должен уметь их проводить.
Функции аналитика
Если проект небольшой и компания экономит на аналитике, пиэм выполняет его роль, снимает требования, анализирует их, согласует и фиксирует. На уровне, достаточном для того, чтобы разработчики могли понять, как именно кодить те или иные фичи. А разработчики очень любят задавать каверзные вопросы о малозначительных (на первый взгляд) деталях.
Функции тимлида
На небольшом проекте с небольшой командой руководство может не выделить ставку тимлида и его обязанности придётся выполнять пиэму и ведущему разработчику. Сюда входит планирование итераций, распределение задач на команду, решение техническо-организационных вопросов, проведение дейли и ретроспектив.
Отчётность о ходе проекта
Рекомендую освежить в памяти статью про вещи, которые нельзя делегировать. В частности, нельзя делегировать общение с руководством. Руководитель проекта изрядную часть времени тратит, чтобы рассказывать разнокалиберному начальству о том, как у него обстоят дела на проекты. По-хорошему, надо применять метод освоенного объёма, тогда доклад будет сводиться к нескольким значениям. Но на практике я такого не встречал, обычно всё же применяется традиционный текстовый доклад о ходе проекта, новых рисках, планах.
Во многих компаниях нужно раз в неделю заполнять отчёт по установленной форме.
Финансовый менеджмент
Для контроля треугольника пиэму нужно постоянно понимать, сколько уже потратили на проект, сколько ещё планируется потратить, сколько и когда заплатит заказчик. С последним может помочь аккаунт-менеджер, но вся расчётная бухгалтерия на вас. Следствие — нужно контролировать, чтобы все участники команды не забывали трекать время.
Хорошая штука для финансового менеджмента — методология Profit and Loss.
Приёмочное тестирование
Хорошо, когда у вас есть нормальное QA, налажено написание модульных тестов и автотестов, но практика показывает, что наилучший подход — когда пиэм самостоятельно протыкивает то, что сделали разработчики. Максимально быстро и дёшево понять, сделали они то, что нужно или нет. А уже потом, когда стало ясно, что в целом, ок, отдавать это на полноценное тестирование QA.
Демонстрация продукта
Убеждён, что демо продукта заказчику (контрагенту в заказной разработке, продакт-менеджеру в продуктовой) должен проводить пиэм. Но если продукт достаточно сложный, можно делегировать это кому-то из старших QA, они лучше разбираются в мелких деталях функционирования приложения.
Управление рисками
Когда я в детстве спрашивал маму: «а что будет, если…», она всегда шикала, не думай о плохом, а то накаркаешь и сбудется. Руководитель проекта должен профессионально думать о плохом, как минимум, раз в одну-две недели и держать актуальным реестр рисков, отслеживать триггеры, вовремя реагировать на риски, которые стали фактами.
Ведение проектной документации
На самом деле, существует несколько видов проектной документации:
- Основные проектные артефакты (ведёт пиэм)
- Требования (ведёт аналитик)
- Техническая документация (ведут разработчики)
- Пользовательская документация (ведёт техпис)
- Тестовая документация (ведут тестировщики)
В целом, будучи пиэмом, вы отвечаете за следующие артефакты:
- PnL проекта (если в компании используется методология P&L)
- Еженедельный отчёт пиэма (писал о нём выше)
- Паспорт или устав проекта
- Карта коммуникаций (или реестр заинтересованных лиц)
- Реестр рисков
- RACI-матрица (нужна на сложных проектах)
- Коммуникационный план (если предполагается сложноструктурированная коммуникация)
- ИСР
- Итерационный план (мне нравится доска в Миро)
- Дорожная карта (Гант)
Вот эти десять артефактов нужно вести и поддерживать самостоятельно. Ведение остальной документации нужно лишь контролировать, чтобы всё было по шаблону и актуально.
В целом, это все обязанности менеджера проекта. Хватает на одного человека с избытком.
Обязанности продакт-менеджера
Анализ рынка, конкурентов, конкурирующих продуктов
Да да, продакт может вступать в игру задолго до прожекта, когда ещё нет ни проектов, ни продукта, а есть только идея. Поэтому продакт должен обладать навыками маркетолога и уметь исследовать рынок, чтобы понять, будет ли задуманный продукт на этом рынке востребованным.
При этом, продакт может работать в связке с узкоспециализированными маркетологами и сейлзами.
К этому же пункту могу отнести различные исследования пользователей, фокус-группы, интервью.
Определение каналов сбыта и продвижения
Самая грустная вещь в нашей профессии — сделать продукт, но так и не суметь наладить его продажи. Лучше средний продукт с хорошей системой продаж, чем наоборот. Также продакт вместе с маркетологами определяет, как продукт будет рекламировать и продвигаться, как будем доносить до пользователей его ценность.
Сюда же относится формирование ценовой политики. Именно продакт решает, сколько будет стоить использование продукта в продуктовой разработке.
Формирование верхнеуровневых требований
Продакт-менеджер вырабатывает видение продукта и то, как будут работать его основные фичи с бизнесовой точки зрения. Что пользователь будет иметь возможность делать с продуктом, что не может, его границы.
Чаще всего, продакт поставляет эти требования команде в виде сформулированных и приоритизированных юзер стори, которые дальше уже прорабатывают аналитики.
Хорошо бы продакту также уметь прототипировать интерфейсы, этим он сильно облегчит работу дизайнерам.
Управление приоритетами
Приоритизация чего угодно — одна из ключевых обязанностей продакта. Он должен уметь аргументированно приоритизировать фичи, баги, требования внутри доработок и вообще, всё, что угодно. Если бы я мог выделить самую главную функцию продакта, это была бы приоритизация.
Сюда же относится ведение роадмапа продукта. Продакту зрелого продукта стоит иметь представление о том, чем будет заниматься разработка в перспективе одного-двух лет.
Верхнеуровневый контроль исполнителей
Продакт — это не про микроменеджмент, однозначно. Но раз в неделю собираться с прожектом, тимлидом, ведущим аналитиком и QA, конечно, стоит. Послушать, как у них дела, нет ли серьёзных проблем, не нужна ли помощь.
Формирование и проверка гипотез
Всё время жизненного цикла продакт формулирует гипотезы и организует их проверку. Главный инструмент в этом его нелёгком деле — А/Б-тестирование.
Работа с метриками
Продакт формулирует иерархию продуктовых метрик, чтобы получать достоверную информацию о том, как пользователи используют продукт и нравится ли он им. Тренд последнего времени — DataDriven-подход, когда решения принимаются только на основании данных.
Продакт же должен эти метрики мониторить.
Работа с обратной связью пользователей
В любом хорошем продукте есть форма обратной связи, через которую пользователи могут внести предложение, зарепортить баг или просто поделиться мнением о продукте. По мобильным приложениям пользователи часто оставляют отзывы в сторах (чаще негативные), за ними продакт тоже должен наблюдать и принимать своевременные решения.
Заключение
Продакт отвечает на вопрос «Что?» Прожект — на вопрос «Как?»
Продакт ближе к маркетологам. Прожект — к тимлидам.
Продакт точно знает, что будет представлять ценность для пользователей. Прожект — чем занят каждый из членов команды, чем был занят на прошлой неделе и чем займётся на следующей.
Продакты чаще встречаются в продуктовой разработке. Прожекты — в заказной. Это не догма, в продуктовой тоже часто встречаются прожекты. Могу представить заказную разработку с продактом.
Рынку нужны оба, но продактам зачастую платят больше. Сколько платят прожектам.
