Roadmap - это отличный инструмент управления продуктом. Но при неправильном использовании она может вызвать серьезные проблемы. В этой статье рассматриваются десять ошибок при составлении дорожной карты продукта, которых следует избегать, чтобы в полной мере использовать свою дорожную карту.
Roadmap - это план, основанный на характеристиках
Традиционные дорожные карты продукта - это, как правило, планы, ориентированные на результат, в которых список функций, таких как регистрация, поиск и отчетность, наносится на временную шкалу. В такой дорожной карте, по сути, указывается, когда будет предоставлена та или иная функциональность. Это может быть обнадеживающим для клиентов и заинтересованных сторон.
Но у него есть следующие три недостатка:
- Дорожная карта, основанная на функциях, может породить и укрепить мышление "фабрики функций", когда добавление функций важнее, чем создание ценности и положительное влияние на жизнь людей и бизнес.
- Сосредоточение на функциях рискует превратить дорожную карту в тактический план, дублирующий бэклог продукта, особенно при использовании мелкомасштабных функций. Это затрудняет понимание дорожной карты и увеличивает усилия по ее обновлению.
- Дорожную карту продукта, основанную на функциях, легко принять за обязательство, а не за высокоуровневый план, который может измениться. Это приведет не только к разочарованию заинтересованных сторон. Это также ограничит вашу способность экспериментировать и учиться, проводить спринты и находить наилучшие способы удовлетворения потребностей пользователей и клиентов и создания ценности для бизнеса.
Вы можете избежать этих недостатков, используя другой тип дорожной карты: дорожная карта продукта, ориентированная на цель или результат.
Как следует из названия, эта дорожная карта фокусируется на целях и результатах продукта, таких как привлечение клиентов, повышение вовлеченности и защита продукта на будущее путем устранения технического долга. Отдельные крупнозернистые функции могут по-прежнему использоваться, но теперь они зависят от целей:
Каждая функция должна служить цели и быть необходимой для достижения определенного результата.
Цели дорожной карты - это замаскированные возможности
Хотя ориентированные на цели дорожные карты могут быть очень полезны, они не всегда применяются эффективно. Распространенная ошибка, которую я вижу у специалистов по продуктам, заключается в использовании целей продукта, которые являются замаскированными функциями. Допустим, я собираюсь создать дорожную карту продукта для продукта здорового питания. Будут ли два утверждения "измерять количество потребляемых калорий" и "определять уровень сахара в крови" считаться целями продукта? Я так не думаю. На мой взгляд, они описывают возможности или особенности продукта и характеризуют решение. В них не говорится о том, почему стоит продвигать продукт.
Поэтому будьте осторожны и не путайте цели и возможности.
Убедитесь, что цели вашего продукта всегда отражают желаемый результат, который продукт должен создать, а не выход. Хороший тест, чтобы понять, описывает ли цель продукта результат, - это задать вопрос "почему". Например, я могу спросить себя, почему было бы полезно измерять количество потребляемых калорий. Ответ покажет истинную цель, например, "помочь пользователям улучшить свои привычки в питании".
Заинтересованные стороны определяют содержание дорожной карты
Просят ли вас заинтересованные стороны добавить определенные функции в дорожную карту продукта? Если это так, то вы не одиноки. Нередко "дорожные карты" продуктов определяются запросами заинтересованных сторон, и отдельные заинтересованные стороны хотят, чтобы в них были включены "их" функции.
Хотя важно активно слушать заинтересованные стороны, вы не должны позволять им диктовать содержание дорожной карты. Ваша задача заключается не в том, чтобы угодить заинтересованным сторонам, а в том, чтобы добиться успеха продукта.
Если вы будете говорить "да" на каждую просьбу, вы рискуете создать продукт Франкенштейна - продукт, представляющий собой набор не связанных между собой функций, предлагающий слабое ценностное предложение и создающий плохой пользовательский опыт.
Отклоняйте запросы заинтересованных сторон, если они не соответствуют стратегии продукта. Если они соответствуют, то найдите цель продукта, которую поддерживает функция. Если таковой нет, то либо скорректируйте план, изменив существующую цель или введя новую, либо отклоните запрос на функцию. Это, конечно, предполагает, что вы наделены достаточными полномочиями и что за вами остается последнее слово в принятии стратегических решений по продукту.
Человек, отвечающий за продукт, создает дорожную карту самостоятельно
Еще одна распространенная ошибка в составлении дорожной карты, которую я наблюдаю, противоположна только что описанной:
человек, отвечающий за продукт, создает дорожную карту самостоятельно, без участия заинтересованных сторон и команды разработчиков.
Такой подход проблематичен по следующим трем причинам:
- Он не использует творческий потенциал и знания заинтересованных сторон и команд разработчиков. Это может привести к тому, что дорожная карта продукта будет неоптимальной или неправильной.
- Существует риск создания плана, который не ясен заинтересованным сторонам и членам команды разработчиков, не имеет общего понимания и вызывает рассогласование.
- Люди с меньшей вероятностью поддержат дорожную карту продукта, если у них не было возможности внести в нее свой вклад. В худшем случае заинтересованные стороны и команды разработчиков лишь на словах поддерживают план, расходятся в разные стороны и следуют своим собственным целям.
Поэтому вам следует использовать подход, основанный на сотрудничестве, когда вы привлекаете ключевых заинтересованных лиц и членов команды разработчиков к созданию, пересмотру и обновлению дорожной карты продукта, предпочтительно в форме совместных семинаров. Стремитесь разработать план, который поможет максимизировать ценность вашего продукта и в то же время привлечет как можно больше поддержки.
Дорожная карта не связана систематически со стратегией и бэклогом
Хотя дорожная карта продукта является самостоятельным планом, было бы ошибкой создавать и управлять ею изолированно. Это приведет к тому, что дорожная карта не будет согласована с ценностным предложением продукта и бизнес-целями, а бэклог продукта не будет связан с дорожной картой. Это, в свою очередь, может привести к непоследовательным и неверным решениям по продукту:
Стратегические решения не направляют тактические, а выводы, полученные в ходе разработки, не помогают продвижению дорожной карты.
Моя модель стратегии продукта, показанная ниже, размещает дорожную карту продукта между стратегией и бэклогом: Дорожная карта определяет, как стратегия будет реализована в ближайшие месяцы, и направляет бэклог продукта.
Первое достигается путем перевода потребностей и бизнес-целей, указанных в стратегии продукта, в цели продукта.
Второе достигается путем использования следующей цели продукта для фокусировки бэклога продукта.
Дорожная карта - это фиксированный план
Некоторые люди принимают дорожную карту продукта за жесткий план, который должен быть выполнен. Но любая дорожная карта основана на том, что известно на данный момент. По мере того, как вы начнете ее реализовывать и узнаете больше о том, как наилучшим образом удовлетворить потребности пользователей, клиентов и бизнеса, дорожная карта продукта, скорее всего, будет меняться.
Это хорошо: это поможет вам максимизировать ценность продукта и предложить лучший из возможных продуктов - вместо того, чтобы слепо следовать плану, который может оказаться устаревшим.
Поэтому вам следует регулярно пересматривать и адаптировать дорожную карту.
Для этого учитывайте любые изменения в стратегии продукта, достигнутый прогресс в разработке и более крупные корректировки бэклога продукта, которые могут повлиять на дорожную карту.
Как правило, оценивайте дорожную карту продукта вместе с ключевыми заинтересованными сторонами и членами команды разработчиков не реже одного раза в три месяца.
Рассмотрите возможность объединения обзоров стратегии и дорожной карты, чтобы обеспечить тесную согласованность этих двух планов и минимизировать время, затрачиваемое на совещания, о чем я подробно рассказываю в книге "Стратегия".
Дорожная карта носит спекулятивный характер
Какой бы полезной ни была дорожная карта продукта, нет смысла создавать умозрительный план, основанный на желаемом, а не на эмпирических данных. Это, скорее всего, приведет к разочарованию и неудаче. Чтобы максимально увеличить шансы на создание реалистичной, осуществимой дорожной карты, необходимо сначала создать и утвердить стратегию продукта, как показано на рисунке ниже. Это включает в себя систематическое рассмотрение ключевых предположений и рисков, содержащихся в стратегии, и сбор данных, которые покажут, что вы выбрали правильную целевую группу, потребности, отличительные особенности и бизнес-цель. Другими словами, не создавайте дорожную карту продукта, если у вас нет утвержденной стратегии продукта.
Кроме того, заглядывайте в будущее только настолько далеко, насколько это реально возможно. Не используйте дорожную карту, если вы не можете заглянуть дальше следующей цели продукта - что может произойти, когда вы работаете над совершенно новым, инновационным продуктом. В этом случае используйте только одну цель продукта, которую вы определили. По мере работы над достижением этой цели вы, надеюсь, лучше поймете, как вы можете развивать свой продукт в будущем, и сможете создать реалистичную дорожную карту продукта.
Дорожная карта слишком амбициозна
Может быть заманчиво создать амбициозный план, который произведет впечатление на заинтересованные стороны и обеспечит поддержку и финансирование. Но дорожная карта продукта с нереалистичными целями может превратить процесс разработки в "марш смерти". Члены команды разработчиков регулярно работают сверхурочно, испытывают постоянный стресс и в итоге оказываются измотанными.
Как следствие, снижается творческий потенциал, мотивация и производительность, ухудшается самочувствие и здоровье людей. Кроме того, возникает больше ошибок и оплошностей, а качество программного обеспечения часто снижается, что усложняет и удорожает обновление продукта в будущем. Поэтому вы должны сделать все возможное, чтобы ваша дорожная карта была реалистичной и поддерживала устойчивые темпы - чтобы члены команды могли реализовать ее без переутомления, потери мотивации и болезней.
Лучший способ разработать такую дорожную карту продукта - вовлечь членов команды разработчиков в работу по составлению дорожной карты, предпочтительно в форме совместных семинаров, как упоминалось выше. Выслушайте их мнения непредвзято и не давите на них, чтобы они согласились с содержанием дорожной карты. Наоборот, серьезно отнеситесь к их опасениям, итеративно прорабатывайте план и адаптируйте его до тех пор, пока он не станет выполнимым.
Дорожная карта ошибочно принимается за план выпуска продукции
Некоторые дорожные карты продуктов прогнозируют, как будет разрабатываться основной релиз или новая версия продукта. Но это, на мой взгляд, ошибка, поскольку дорожная карта - неправильный инструмент для этой работы. Лучше всего управлять процессом разработки с помощью плана релизов, например, с помощью диаграммы выгрузки релизов.
Временная диаграмма помогает вам отслеживать прогресс от спринта к спринту и позволяет предвидеть, удастся ли достичь конкретной цели продукта в срок и в рамках бюджета - или сколько времени это займет и сколько будет стоить.
Это помогает вам направлять работу команды разработчиков и вносить необходимые коррективы, например, исключать функциональность из бэклога продукта. Другими словами, план выпуска помогает вам максимизировать шансы на достижение конкретной цели продукта.
Дорожная карта продукта, однако, определяет, как продукт будет развиваться в течение более длительного периода времени. Она основана не на бэклоге продукта, а на стратегии продукта, и содержит несколько целей продукта.
Правильный инструмент для составления дорожной карты продукта - вот что имеет наибольшее значение
Последняя ошибка, которую, как я вижу, совершают люди, занимающиеся продуктами, - это вера в то, что правильный инструмент решит их проблемы с составлением дорожной карты.
Некоторое время назад я работал с командой управления продуктами в крупной издательской компании. У команды не было эффективного подхода к составлению дорожной карты продукта. Но вместо того, чтобы приобрести соответствующие знания и открыть для себя правильные методы составления дорожной карты, команда попыталась сократить этот процесс, лицензировав мощный инструмент для составления дорожной карты. Поскольку у них не было соответствующего опыта, они не смогли настроить инструмент под свои нужды и не смогли воспользоваться его преимуществами.
Как однажды сказал Грейди Буч: "Дурак с инструментом - все равно дурак".
Поэтому я рекомендую вам разработать подход к составлению дорожной карты продукта, который работает для вас, прежде чем вы решите, какой специализированный инструмент для составления дорожной карты вам подходит, если таковой имеется.
Для начала выберите простой инструмент, который легко использовать и который позволяет заинтересованным сторонам и членам команды разработчиков просматривать план и вносить в него свой вклад.
Это может быть PDF-документ, электронная таблица или инструмент для совместной работы, который вы используете в своей компании.