Ставит чёткие ТЗ или умеет кодить? Спросили у разработчиков, кто для них идеальный продакт

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

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

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

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

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

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

Сложности можно условно разделить на несколько групп:

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

Как ещё бывает ↓

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

В незрелой команде часто бывают ситуации, когда приходит продакт и говорит: «Ребята, нам нужно добавить вот эту функцию». Они говорят «ок» и берут задачу в спринт. В процессе выясняется, что не изучено множество моментов, которые надо было проработать заранее. Это вина и продакта, и команды разработки. Продакт недостаточно глубоко прописал всевозможные сценарии и алгоритмы работы функции. Разработчик недостаточно хорошо погрузился в задачу и не сказал, что не готов брать её в спринт. В результате сроки затягиваются, функцию не удаётся выпустить, и команда рушит ожидания стейкхолдеров. В зрелой команде, которой мы смогли стать в Авито, достаточно долгий этап технического discovery — предразработки.

Проблемы в работе продактов и разработчиков могут возникать с обеих сторон. Если у разработчика не получается грамотно объяснить свою оценку задачи, чаще всего это проблема разработчика. За такими ситуациями должен следить тимлид, его задача — быть посредником в общении разработчика и продакта. Если разработчик не может чётко объяснить, в чём сложность реализации функции, а у продакта есть вопросы, тимлиду стоит подключиться к обсуждению.

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

Другая проблема: углубляясь в задачу, мы часто начинаем говорить на характерном для этой области сленге. И вот продакт уже не понимает, зачем разработчику «писать новую миграцию под сохранение трастов из keystone», когда задача звучит как «возобновлять резервное копирование после рестарта сервисов». Поэтому у нас есть правило — на общих встречах выбирать выражения так, чтобы «поняла моя бабушка». Если разработчик увлекается и начинает сыпать техническими терминами, никто не стесняется остановить его и попросить разъяснить, о чём идёт речь.

Есть история про продакта, с которым когда-то удалось поработать на одном зарубежном проекте. В силу недостатка навыков продакт выставил задачу без проработки. Нам тогда нужно было увеличить поток клиентов. В эпике был текст: «Ребята, будем работать над тем, чтобы привести больше трафика. Я пока создал скелет нашей задачи. Потом заполню истории». Однако из-за того, что не было понятно, как над этим работать, откуда вести клиентов, какие это клиенты, истории так никогда и не появились. Долго лежал эпик и удалился со временем.

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

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

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

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

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

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

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

Тимлид команды разработки часто даже участвует в найме продакта, чтобы с самого начала понять, говорят ли они на одном языке. Если коммуникация не клеится, работа вряд ли будет успешной. Даже если продакт разберётся с discovery-частью, с delivery начнутся проблемы.

В то время как тимлид организует процессы разработки, продакт доставляет результаты discovery до команды разработки. У нас в Нетологии тимлид иногда выполняет роль проджект-менеджера, а приоритеты разработки определяет продакт.

Выяснили, как выстроена работа в других компаниях ↓

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

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

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

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

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

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

Чаще всего я работал в связке «продакт-менеджер — проджект-менеджер — тимлид». Эта схема наиболее сбалансированная, в ней каждый отвечает за свой пул задач. Тимлид — за расширяемость, интеграцию в общие технические решения, за цену команды. Проджект — за планирование и цену проекта, а продакт — за прибыль и поиск возможностей.

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

Тимлид — неотъемлемая единица команды. Самостоятельная, самоорганизованная команда может отлично справляться с краткосрочными вызовами, но не с долгосрочными задачами. Разработчикам нужен адвокат, который не будет отнимать самостоятельность у команды, но сформулирует позицию разработки и синхронизирует её с продуктом.

Мне кажется, что базово продакт-менеджер должен:

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

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

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

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

Главное — мы вместе следуем единым целям. Это, конечно, клише, но оно работает: руководствуйся здравым смыслом, и всё получится. Команду мы строим, исходя из соображений, что лучше хороший человек, чем специалист.

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

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

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

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

Хочется, чтобы у продакта было понимание возможностей продукта, которые действительно нужны рынку, и не получалось так, что команда работала на износ, что-то выпустила, а через неделю на это всем стало всё равно. Такое очень демотивирует.

Конечно, единственно верного портрета продакт-менеджера не существует. Каждый тимлид выделяет что-то своё. А как вы считаете, что должен уметь идеальный продакт?

#нетология #продактменеджмент #productmanagement #команда