Где граница между продакт-менеджментом и проджект-менеджментом?

Привет! Меня зовут Саша, я — Product Lead в Prisma Labs. Мы развиваем фоторедакторы Prisma и Lensa, работаем над другими нашими идеями, а ещё постоянно расширяем команду. Хочу рассказать, как вследствие бурного роста мы пришли к проблеме переосмысления ролей, и как пытались структурно её решить.

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

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

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

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

И вот, наконец-то, я попала в такую команду.

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

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

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

Возник замкнутый круг:

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

Стали возникать ситуации, когда никто не может сказать текущий статус задачи, потому что непонятно, кто на данном этапе за неё отвечает. Начало страдать качество продукта.

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

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

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

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

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

Но достаточно быстро выяснилось, что у нас расходятся ожидания по UI/UX. Либо в процессе проработки возникала необходимость сделать дополнительный рисёч или проработать ивенты с аналитиком, а проджектам на это не хватало экспертизы и времени. К тому же, начало стрелять по основным обязанностям проджектов из-за недостатка времени.

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

Мы решили делить между собой не задачи, а этапы работы над задачами.

Мы нарисовали воркфлоу, который схематично отражает, через какие шаги проходит любая фича, и разделили их на Discovery (работа с гипотезой, исследования и аналитика, дизайн, копирайтинг) и Delivery (планирование и сопровождение разработки, тестирование, релиз-менеджмент). Промежуточным шагом перед передачей в разработку было написание спеки и финализация всех аспектов задачи.

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

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

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

Но появились новые:

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

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

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

Ну и чтобы всем было совсем комфортно, мы проговорили не только, что нужно делать, но и что не нужно:

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

У проджектов повысилась вовлечённость. Они стали чувствовать своё влияние на продукт и говорить "наша фича" вместо "твоя фича".

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

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

Мы поняли, что недостаточно просто поделиться на Discovery и Delivery. Слаженной работы не получится, если продакт только фонтанирует идеями и далёк от разработки, или если проджект сосредоточен на том, чтобы зарелизить в срок, но не интересуется, что и зачем.

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

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

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

#productmanagement #projectmanagement #prisma