Провалы в управлении: 5 распространённых ошибок продакт-менеджера

О типичных ошибках в управлении продуктом рассказала

Ольга Антипова

Ex-product owner клиентского приложения Flowwow. Более 16 лет работает в области управления и выстраивания процессов, шесть из которых — в IT-сфере.

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

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

• Создание «узкого горлышка»
• Обсуждение всех деталей продукта
• Разрозненность релизов
• Пренебрежение техническим заданием
• Страх личной ответственности

Ошибка 1

Создание «узкого горлышка»

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

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

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

Вот пять ключевых признаков «узкого горлышка» — наличие даже одного из них может привести к остановке работы команды:

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

«Узкое горлышко» может создать продакт, который сам «завязал» все процессы на себе — часто неосознанно. Также оно может образоваться органически, в процессе развития компании. Важно это вовремя заметить и исключить.

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

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

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

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

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

Ошибка 2

Обсуждение всех деталей

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

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

Как это исправить? Определите целевые задачи для каждого члена команды и исходя из этого спланируйте загрузку — в том числе и участие в созвонах.

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

При таком подходе основное время разработчиков занято целевой работой, а звонки занимают порядка 3–4 часов в неделю, включая дейли, ретро и другие регулярные созвоны команды. Например, мы во Flowwow таким образом сократили затраты времени разработчиков в 1,5–2 раза.

Ошибка 3

Разрозненность релизов

Эта ошибка касается продактов, чьи команды выпускают мобильные приложения одновременно для iOS и Android.

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

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

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

Ошибка 4

Пренебрежение техническим заданием

Технические задания (ТЗ) нужны для того, чтобы зафиксировать, что и как нужно сделать. Они помогают всем членам команды понять свои задачи при разработке продукта.

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

Почему это ошибка? Технические задания — инструкции для разработчиков и других участников команды продукта. То есть именно эти сотрудники — целевая аудитория ТЗ. Поэтому его формат должен быть удобен им, а не только продакту. В противном случае возникает много вопросов, обсуждений — работа замедляется, релизы выходят с опозданиями.

Как это исправить? Формировать технические задания нужно так, чтобы они были понятны команде, которая будет с ними работать. Желательно уточнить у участников команды даже мелкие детали оформления, с которыми документ станет удобнее для них, — например, отступы, разбивку на абзацы, разделение на пункты и так далее.

Наиболее оптимальный формат ТЗ такой:

• Название фичи.
• Содержание документа.
• Общее описание функциональности, цель, ценность.
• Пошаговое описание требуемых действий, разделённое на пункты.
• Дизайн или прототип, полностью согласованный с пунктами ТЗ.

Также ТЗ важно вовремя обновлять — вносить информацию обо всех изменениях, которые происходят в процессе работы над продуктом. Например, обновлять скорректированные юристами формулировки.

Ошибка 5

Страх личной ответственности

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

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

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

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

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