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

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

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

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

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

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

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

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

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

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

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

• Продакт описывает задачи и готовит их к передаче в разработку.
• Проджект планирует спринт и получает эстимейты по задачам от команды.
• Разработчик принимается за задачу и у него возникают вопросы по бизнес-логике или эдж-кейсам, он обращается с ними к продакту. Часто это происходит в личной переписке или 1-1 созвонах, и проджект не в курсе последних договорённостей или узнаёт о них постфактум и поверхностно.
• Кулуарные разговоры раздувают задачу, она перестаёт укладываться в озвученные эстимейты, сдвигается таргет-релиз по ней.
• План-факт по спринту не сходится, фича не выходит вовремя, недовольны и проджект, и продакт. Команда расстроена.

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

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

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

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

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

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

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

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

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

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

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

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

• Продакт верхнеуровнево описывает, что и зачем нужно сделать, и ставит соответствующие подзадачи в Discovery-команды (на проработку дизайна/ копирайтинга/ивентов). Это важно сделать продакту, чтобы передать своё видение реализации и сихронизироваться в ожиданиях. Он проводит первичные обсуждения по подзадачам и доводит их до стадии, когда начинает вырисовываться каркас фичи.
• Проджект перехватывает этот каркас, погружается в задачу и дорабатывает детали. Таким образом, он оказывается в курсе всего скоупа работ, а спека обогащается новыми эдж-кейсами и доходит до разработки в более качественном виде. Также проджект помогает допушить задачу: если дизайн или аналитика готовы на 80-90%, но застряли на последней итерации правок. Проджект присматривает, чтобы все дыры были закрыты до попадания задачи в разработку.

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

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

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

• Как и в прошлый раз, проджекты стали зашиваться, что сказалось на качестве планирования и релиз-менеджемента.
• Получив помощь с проработкой эдж-кейсов, продакты уделяли им всё меньше внимания. То, что кейс обыгран не так, как хотелось бы, порой выяснялось перед самым релизом.
• Как следствие, увеличилось количество реопенов и время на тестирование. Команда негодовала, что приходится переделывать задачи, сделанные по ТЗ.
• Трактовка ролей получилась очень пространной, её было сложно объяснять команде и новым ребятам, и периодически мы сами путались, на чьей стороне мяч.

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

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

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

• Качество продукта — ответственность продакт-менеджера. Но оно не ограничивается выполнением целей по метрикам и новыми фичами. Впечатление пользователей о продукте складывается и из мелочей, вроде текста в сообщении об ошибке при отвалившемся интернете, или дизайнерских решений, в которых учтены платформенные особенности или маленькие экраны. И круто, если проджект или кто-то из команды заметил упущенный кейс и даже предложил решение для него, но продакт должен быть в курсе всех деталей, и окончательное решение за ним.
• Качество планирования — ответственность проджект-менеджера. Это ответ на вопрос "Когда будет готово?" с высокой долей вероятности, что так и произойдёт. Но для того, чтобы отвечать на этот вопрос осмысленно, нужно быть в курсе подробностей задачи, держать по ней коммуникацию с командой, знать о возможных затыках и помогать преодолевать их.
• Отдельно про спеку. Чтобы усилить качество продуктовой спеки, мы настроили шаблон, подходящий для почти любой нашей задачи. Внутри него мы сделали чеклист, помогающий продакту проверить, что он ничего не упустил при проработке. Ответственность продакта — написать качественную спеку, но ответственность проджекта — подстраховать и провалидировать её. Сырые задачи, ушедшие в разработку, невыгодны никому.
• И про кулуарные обсуждения. Команда разработки задаёт вопросы проджекту, если у проджекта нет ответов — он задаёт их продакту. Все возникшие в ходе дополнительных обсуждений моменты фиксируются в описании задачи. Так в любой момент кто угодно может увидеть, какими нюансами обросла задача в процессе реализации.

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

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

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

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

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

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

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

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

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

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

#productmanagement #projectmanagement #prisma