У начинающих продакт-менеджеров, особенно без технического бэкграунда, вопрос эффективного взаимодействия с командой разработки может вызывать сложности. Как правильно ставить задачи разработке? Как оценивать необходимое для их выполнения время? Как разрешать потенциальные конфликты?
Этот материал с ответами мы подготовили совместно с бывшим разработчиком, а теперь Product Director в Ostrovok.ru (Emerging Travel Group) Вадимом Купцовым. Этот FAQ основан на вопросах, которые задавали Вадиму участники вебинара о технических навыках для продакт-менеджеров.
Q: Я не знаком с платформой разработки моего продукта. Насколько это критично? Смогу ли я быстро разобраться в этом?
Каждая платформа, будь то веб, мобайл или VR, имеет свои нюансы, и совершенно нормально, если продакт не знает про особенности каждой из них. Тем не менее эти нюансы могут накладывать отпечаток и на работу продакта: например, если ваш продукт существует в вебе, то ему нужна и мобильная версия, на которую уйдет дополнительное время команды, поэтому продакт это должен предусмотреть. Если вы никогда раньше не имели дела с платформой, с которой вам предстоит работать, стоит хотя бы минимально изучить ее специфику: для этого достаточно гугла или даже разговора с тимлидом. Это несложно.
Понимание платформы будет помогать выстроить доверие с разработкой, лучше писать требования и работать со скоупом проекта.
Q: Мне надо поставить задачу на разработку. Как корректно оценить сроки и запросить нужный ресурс у разработки?
Необходимо начать с понимания того, что разработчик не пишет код все восемь часов рабочего времени, а например, шесть или меньше: в зависимости от количества встреч и других активностей. Исходя из этого продакт может оценить, сколько часов в неделю разработчик действительно способен уделить коду, и, соответственно, планировать, сколько задач команда в состоянии закрыть за неделю или любой другой срок.
Тимлид обычно ведет учет рабочего времени разработки. Это не контроль, а необходимость для более точного понимания, на что уходит время и правильно ли команда его распределяет. Если мы не знаем стоимость задачи в часах разработки, то можем взять в работу неправильные задачи, а это в конце концов ударит по бизнесу.
На самом деле, не так важно, считаете вы в часах, днях, неделях или, например, в стори-поинтах: важнее, что задачи можно соотнести между собой, распределить приоритеты.
Q: Мне нужно поставить задачу на разработку. Стоит делать детальную инструкцию или достаточно верхнеуровневого документа?
То, насколько подробно описываются задачи, зависит от культуры команды и компании в целом. Поэтому здесь опять же нужен диалог с командой разработки. Универсального рецепта не существует, поэтому стоит подбирать тот темп и тот уровень проработки, который позволяет адекватно оценить задачу и принять правильное управленческое решение.
Q: Я ставлю задачи разработке, но раз за разом она срывает сроки. Что делать?
Точно оценить сроки довольно тяжело. Здесь всегда есть место для ошибки, и это нормально. Помните, что разработчики не срывают дедлайны специально: в здоровой команде никто не заинтересован в том, чтобы саботировать работу.
Попробуйте выяснить причины. Возможно, вашей команде не хватает ресурсов, или время, которые вы запланировали на выполнение этой задачи, было подобрано не совсем верно. Используйте историческую информацию про оценки задач и корректируйте процессы в соответствии с ней. Если проект большой — декомпозируйте его: зачастую это помогает делать более точные оценки. Чем больше итераций вы как команда срабатываетесь друг с другом, тем точнее будет ваша оценка времени.
Пройти симуляторы от GoPractice можно в группе с опытным ментором.
Что вы получите:
✅ Онлайн-встречи для обсуждения прогресса и разбора вопросов
✅ Общение в закрытом чате для постоянной обратной связи с ментором и одногруппниками
✅ Дополнительные кейсы от ментораПоддержка ментора доступна при обучении:
→ в «Симуляторе управления продуктом на основе данных»
→ в «Симуляторе управления ростом продукта»
→ в «AI/ML-симуляторе для продакт-менеджеров»
Q: Я вижу, что разработка неохотно берет мои задачи в работу. Как я могу мотивировать команду?
Разработчики по натуре своей — более системные люди, для них ближе работа, которая выстроена по типу конвейера. Именно этим руководствуются продакты, которые держат команду в неведении относительно продукта, давая конкретные задачи без погружения в общую картину.
Но все же о продукте должен думать не только продакт-менеджер. В команде разработки стоит поддерживать фокус, объяснить стратегию и донести до нее, что вы вместе делаете одно общее дело. Совсем идеально, если люди из команды разработки тоже привносят свои идеи.
Вовлекайте разработку в бизнес. Зовите тимлидов на кастдевы, делитесь с ними инсайтами. Это хороший знак, если тимлиду интересен бизнес и он начинает генерировать идеи по продукту вместе в вами.
Еще одна задача продакта — быть своеобразным щитом для команды разработки, защищать ее от негатива, который идет извне, в том числе от стейкхолдеров. Так вы можете заработать кредит доверия от разработчиков, который позднее поможет вам решать задачи более плавно и проще находить компромиссы.
Q: Команда разработки часто говорит о неких технических ограничениях. Как я могу убедиться в этом или найти решение для таких ограничений?
Есть несколько важных принципов, и один из них — ваша любознательность!
Объясните команде, что вы будете задавать очень много вопросов, но не потому что хотите их на чем-то подловить, а потому, что вы правда хотите разобраться в технической стороне вопроса. Расспрашивайте команду о рисках: что будет, если мы что-то сделаем или не сделаем. Можно ли оставить идею на потом, сможет ли команда в долгосрочной перспективе обойти техническое ограничение, о котором говорит? После многих разговоров вы заметите, как постепенно калибруетесь с разработчиками в понимании того, как ваш проект работает технически, и сами начнете лучше понимать суть тех или иных ограничений, о которых говорит команда.
Другой важный принцип — заинтересуйте команду бизнесом. Команда может быть зациклена только на коде и не иметь желания вовлекаться в бизнес-аспекты. Попробуйте объяснить ей, что вы вместе работаете над конечной ценностью для клиента и бизнеса. Если все получится, возможно, что разработка сама будет генерировать идеи, как преодолеть те или иные ограничения.
Q: Как понять, нужно ли проводить ретроспективу с командой разработки? Если да, то зачем?
Ретроспектива позволяет команде осмыслить прошлую работу, выявить успехи и области для улучшения. Она помогает команде не только оценить проделанную работу, но и наладить взаимодействие, улучшить процессы и решить внутренние проблемы. Это своего рода рефлексия, в ходе которой собираются мнения всех участников команды: от разработчиков до тестировщиков и продуктовых менеджеров. На начальных этапах работы продакт должен быть готов к тому, что он будет единственным, кто выносит темы для обсуждения на ретро, однако важно, чтобы команда разработки тоже могла и хотела что-то сказать.
Подайте пример! Неплохая идея — настроить автоматическую подгрузку в ретро тех задач, где что-то не получилось: например, неправильно оценили время выполнения.
А если вы понимаете, что ретро может стать сливом негатива, к этому нужно готовиться заранее. Стоит собрать всех информацию со всей команды, понять, где кроется зерно недопонимания. Если в команде есть какой-то конфликт, то ретро — это не то место, где нужно это обсуждать. Такие вопросы лучше выносить в отдельное кулуарное обсуждение. Поэтому продакту важно уметь фасилитировать ретро, четко определяя, что выносится на такие встречи и как это формулируется.
Если у вас есть другие вопросы о том, как продакту эффективно взаимодействовать с разработкой, напишите нам на dima@gopractice.io. Мы передадим вопросы Вадиму, дополним материал и сообщим вам об этом!
Узнайте больше
— 5 вещей о разработке, которые важно знать продактам
— Как повысить эффективность продуктовых аналитиков в разы
