Давайте посмотрим на уроки, которые я усвоил за эти годы, в надежде, что они помогут вам и вашей команде разработчиков.
Управление продуктом — сложная функция, оказывающая огромное влияние на многие части организации. Для менеджера по продукту нет фиксированной квалификации, но требуется разностороннее сочетание опыта и знаний в конкретной области.
Часто люди переходят от своей технической роли к профилю менеджера по продукту. Вот где переход немного труден в начале. Наличие технического образования может быть преимуществом для одних вещей, а для других может стать проблемой.
Я начал свою карьеру в качестве инженера-программиста и, в конце концов, провел много лет в профессии, которая совмещала разработку и управление продуктом. Я получил свою долю знаний в процессе работы с несколькими командами, в которых были как неудачи, так и успехи.
Я также учился, наблюдая за многими другими коллегами, которые прошли через эту трансформацию и в конечном итоге стали успешными менеджерами по продуктам. Здесь я перечисляю некоторые из своих многолетних знаний в надежде, что они помогут некоторым читателям.
1. Не управлять бэклогом продукта
Это может показаться очевидным, но я видел несколько организаций, игнорирующих этот первый шаг создания команды продукта. Часто это происходит, когда компания либо новичок, либо еще не полностью приняла идею управления жизненным циклом продукта. Менеджеры по продукту создают список функций или задач, которые необходимо выполнить в течение следующих нескольких спринтов, и называют его бэклогом.
Однако бэклог, о котором я говорю, — это дорожная карта продукта, обеспечивающая долгосрочное видение. Список всех целевых функций и требований продукта в порядке приоритета. Это должно быть достаточно глубоко, чтобы выходить за рамки спринтов и четвертей. Бэклог, который следует регулярно обрабатывать, расставлять приоритеты, а все требования время от времени перепроверять с заинтересованными сторонами.
Хорошо управляемый бэклог работает как инструмент для связи с инженерной командой в качестве совместной ответственности за дорожную карту продукта.
2. Настройка продукта
Это проблема, часто встречающаяся у малых и средних продуктовых компаний. В попытке увеличить свою клиентскую базу менеджеры по продуктам часто соглашаются на настройку или обходные пути в соответствии с конкретными потребностями клиента. Именно здесь менеджеры по продукту должны сопротивляться искушению краткосрочной выгоды.
Поддержание индивидуального решения в долгосрочной перспективе требует огромных затрат и может перевесить выгоду от добавления новых клиентов. Очень скоро это станет шаблоном, и у вас может получиться своя версия вашего продукта для каждого клиента. С этим чрезвычайно сложно справиться, и в конечном итоге он превращается в хрупкий код, который ломается с каждым новым обновлением.
Каждое требование клиента должно быть оценено по достоинству, прежде чем включать его в бэклог продукта. Если у одного клиента есть очень конкретный запрос, который не соответствует видению продукта, тогда менеджеры по продукту должны работать с клиентом, чтобы найти альтернативы или убедить клиента в ограничениях продукта.
3. Игнорирование прошлого
В зависимости от типа вашего программного продукта может применяться одна из двух разновидностей этой ошибки.
Игнорирование старого продукта
У вас есть размещенный продукт и выпущено новое поколение сервисов на новейших технологиях, но у более старой версии или «устаревшей платформы» много живых клиентов. Часто менеджеры по продукту сосредотачиваются на продаже новых услуг новым клиентам, а продукты старшего поколения забываются. Сейчас у компании работают два похожих продукта с похожим функционалом, и оба приносят доход.
Однако игнорируется то, что компания также тратит в два раза больше денег на поддержку двух похожих решений, когда у нее может быть только одно. Поддержка двух решений требует огромных затрат на разработку, поддержку, эксплуатацию и инфраструктуру. Помимо затрат, существующие клиенты также упускают преимущества программного обеспечения следующего поколения и могут стать мишенью для конкурентов.
Игнорирование старых версий
У вас есть продукт/решение, которое выпускается раз в несколько недель, месяцев или лет (нежелательно, но случается). Клиенты обновляются в соответствии со своим графиком, и несколько клиентов работают на версиях, которые отстают на несколько лет. Если у менеджеров по продукту нет хорошего плана или политики для обновлений, это может продолжаться годами.
Для каждого выявленного дефекта или уязвимости в системе безопасности команде инженеров, возможно, придется вернуться и исправить все старые версии. Все эти дополнительные усилия можно сохранить и использовать для разработки новых функций. Это еще одна статья расходов, которая часто игнорируется и в долгосрочной перспективе даже увеличивает неудовлетворенность клиентов.
Обе вышеупомянутые ситуации требуют, чтобы менеджеры по продуктам смотрели на общую картину и гарантировали, что дорожные карты для каждого продукта также включают их цели в конце поддержки и в конце срока службы. Более высокие доходы не принесут пользы, если старые продукты снижают прибыль.
Apple всегда заставляла пользователей обновляться со старых версий iPhone. Вместо того, чтобы жаловаться, пользователи ждут выпуска новых функций, и продажи продолжают расти.
4. Не инвестировать в развитие навыков
В большинстве компаний, производящих продукты, часто возникают споры между инженерами и менеджерами по продукту из-за имеющихся возможностей для разработки. Существует постоянное стремление предоставлять все больше и больше функций как можно скорее. Это распространенный сценарий, когда команда настолько растянута, что у нее нет времени на планирование мероприятий по развитию навыков.
Помимо создания напряженной рабочей среды, это также создает пробел в знаниях в команде, поскольку никто не может накопить достаточный опыт работы с продуктом. В таких командах высок процент отсева, который через какое-то время может привести к тому, что в команде не останется никого, кто будет поддерживать старые продукты.
С другой стороны, новая разработка также может пострадать, поскольку у команды никогда не будет возможности узнать о новых технологиях. Такое неадекватное использование технологии может привести к разработке некачественной продукции.
Именно здесь менеджеры по продукту должны иметь видение и готовность инвестировать в развитие навыков инженерной команды. Им необходимо сбалансировать приоритеты и сотрудничать с командой инженеров, чтобы выделить время для распространения знаний о существующих решениях, а также для повышения квалификации по новым технологиям. Если это вовремя не спланировать, результат в той или иной форме будет очевиден. Это может быть выход низкокачественного кода, увеличение количества упущенных дефектов, сокращение команды или увеличение времени выполнения работ по устранению неполадок клиента.
5. Агрессивные обязательства по дате
"Должны ли мы уложиться в сроки или достичь цели по качеству?"
Я слышал этот вопрос много раз, но на самом деле эта дилемма никогда не должна возникать. Выпуск нестандартного продукта для выполнения каких-то обязательств клиента никому не принесет пользы. Во-первых, менеджеры по продукту не должны брать на себя никаких обязательств по срокам без надлежащего сотрудничества с командой инженеров.
Во-вторых, если команда инженеров не уверена в выпуске продукта, им нужно либо сократить объем, либо продлить сроки. Оказание давления на команду инженеров с целью создания продукта путем пропуска необходимых этапов обеспечения качества или продолжительной работы может привести к снижению качества выпускаемой продукции. Они могут быть в состоянии достичь целей для некоторых произвольных дат, но это приведет к большому объему работы по поддержке после выпуска и, в конечном итоге, к неудовлетворенности клиентов.
В идеале команда разработчиков должна работать только над приоритетным списком функций, уделяя особое внимание соответствию требуемым стандартам качества, и выпускать их через регулярные промежутки времени по мере завершения работы. Команды, работающие над проектом в соответствии с датами, в конечном итоге придут к некоторым компромиссам, которые повлияют на качество продукта.
6. Выбор технологии вместо функциональности
Это может показаться не очень распространенным, но часто происходит в командах, где менеджеры по продукту менее технически подкованы. Влиятельные инженеры могут попытаться повлиять на технологические решения в соответствии со своими навыками или стремлениями. К технологиям всегда следует относиться как к средству для достижения цели. Он не должен определять функциональные решения или варианты использования, влияющие на конечных пользователей.
В свое время я заметил, что одна команда запланировала несколько спринтов работы по конвертации кода с одного языка программирования на другой (без новых функций). Причина заключалась в том, что технический руководитель чувствовал, что он не слишком хорошо знаком с языком, используемым в существующем решении, хотя оно лучше подходило.
Это неправильно по нескольким направлениям, и менеджер по продукту никогда не должен был этого допускать. Это пример полной траты мощностей, ресурсов и времени нескольких человек не только в команде разработчиков, но и в других командах, таких как эксплуатация и поддержка.
Ирония ситуации заключалась в том, что техлид покинул компанию через несколько месяцев после перекодировки. Усвоенный урок: лучше приобрести набор навыков, необходимых для удовлетворения потребностей продукта, чем искажать продукт, чтобы он соответствовал набору навыков команды.
Вы выбираете технологию, которая помогает вам приносить пользу клиенту, а не наоборот. Менеджер по продукту должен не пропускать технологические решения, а задавать правильные вопросы не для того, чтобы повлиять, а для того, чтобы утвердить решение.
7. Недостаточное вовлечение заинтересованных сторон
Это снова может показаться очевидным, но самоуверенные продакт-менеджеры часто упускают его из виду. Они несут ответственность за работу с заинтересованными сторонами и сбор требований. Это основной вклад в невыполненную работу, который приводит к спецификациям новых функций. Однако важно поддерживать постоянное участие заинтересованных сторон на протяжении всего процесса.
В ходе разработки некоторые варианты использования могут измениться, и спецификации могут потребовать обновления. Команда может быстро адаптироваться к этим изменениям и избежать серьезных последствий, если требования будут постоянно проверяться заинтересованными сторонами на каждом этапе. Менеджер по продукту несет ответственность за то, чтобы вся работа оставалась актуальной для конечных пользователей и чтобы влияние любых изменений было минимальным на усилия по разработке.
Я видел, как некоторые продакт-менеджеры склонны избегать обсуждения незавершенной работы и предпочитают показывать заинтересованным сторонам только окончательный отшлифованный продукт. Однако такой каскадный подход часто может приводить к разочарованию, поскольку со временем все может измениться, поэтому ключом к успеху является постоянное общение с заинтересованными сторонами о незавершенной работе.
Я лично видел такую ситуацию, когда команда месяцами работала над предоставлением потребителям новых API, но в конце концов им сказали, что они больше не нужны им из-за меняющихся потребностей бизнеса. Этого можно было бы избежать, если бы потребители были вовлечены в цикл разработки.
8. Игнорирование технического долга
Разработка новых функций всегда считается более приоритетной, чем любой технический долг. Когда я говорю о техническом долге, я имею в виду любой рефакторинг или изменения, необходимые для устранения обходных путей, оптимизации кода, повышения производительности или решения проблем поддержки, таких как улучшенный мониторинг и т. д.
Еще одна категория, которую часто упускают из виду, — это обновления технических валют. Менеджеры по продукту часто сосредотачиваются на функциональных аспектах продукта и игнорируют технические аспекты. Технический долг, накопленный с течением времени, может стать настолько огромным, что поддерживать код будет невозможно. Это может привести к огромным затратам на доработку и поддержку кода.
Точно так же продукты, работающие на устаревших версиях базовой технологии, лишены всех улучшений с точки зрения безопасности, стабильности и производительности. Это может напрямую влиять на надежность продукта. Большинство этих технических требований собраны при непосредственном участии команды инженеров. Еще одна причина для налаживания тесного сотрудничества с инженерной командой для совместного владения бэклогом.
Коммуникация и сотрудничество
Менеджеры по продукту часто превращаются в профессионалов по продажам для достижения своих краткосрочных целей, но их роль намного шире. У них должно быть долгосрочное видение своего продукта, и они должны сотрудничать с инженерами, чтобы инвестировать в создание более сильной команды, способной создавать качественный продукт.
Иногда это означало бы снижение количества функций, поставляемых на рынок, или увеличение сроков для достижения целей разработки. Однако все это окупается в долгосрочной перспективе, когда у вас есть отличный продукт и команда, способная быстро внедрять качественные функции.
Стремитесь к совместной собственности
Часто мы используем термин два в коробке для управления продуктом и разработки, поскольку они оба должны сотрудничать вместе, чтобы приносить пользу клиентам. Менеджеры по продукту не могут работать изолированно и должны работать как часть команды с тесным сотрудничеством и открытым общением. Большинство перечисленных выше проблем не возникло бы в такой команде, где управление продуктом и команда инженеров разделяют ответственность.
Если у вас есть отзывы обо мне или другие жизненные уроки по этой теме, не стесняйтесь делиться ими в комментариях. Спасибо за прочтение!
Если вам понравилась эта статья, вы можете получать мои последние работы в свой почтовый ящик, подписавшись здесь. Если вы планируете присоединиться к Medium, поддержите меня, используя мою реферальную ссылку.
Выражаем особую благодарность Тремис Скит, исполнительный редактор Product Coalition за ценный вклад в редактирование этой статьи.
