Что такое RoadMap или дорожная карта в управлении проектами? Roadmap проекта — это графический обзор целей и результатов проекта, представленных на временной шкале. В отличие от плана проекта, где детали обрисованы, дорожная карта должна быть простой и не содержать мелочи.
Это делает дорожную карту продукта полезным инструментом для управления ожиданиями заинтересованных сторон, а также для обмена планами и координации ресурсов с другими командами.
Чтобы построить дорожную карту, учитывайте рыночные тенденции, значимые предложения и технические ограничения. Как только эти факторы достаточно хорошо поняты, отразите в дорожной карте, как инициативы со сроками исполнения. Ниже приведен очень простой план действий для команды разработчиков. Инициативы выделены цветом, а сроки обозначены вехами.
После того, как дорожная карта создана, ее необходимо передать всей команде, чтобы все понимали видение и направление. Встречается, что менеджеры продуктов создают свои дорожные карты в PowerPoint или электронных таблицах, а затем отправляют по электронной почте скриншоты команде. Несмотря на благие намерения, эта стратегия изначально ошибочна. Каждый член команды имеет свою собственную копию дорожной карты, и держать всех в курсе, когда вносятся изменения проблематично.
Так как же Продукт Менеджерам лучше информировать команду? Просто.
Разместите план на общем ресурсе или интернете и держите в курсе команду, чтобы у них был единый источник.
Большинство инструментов для совместной работы, будут автоматически уведомлять всех участников проекта, что дорожная карта изменилась.
Важно связать работу вашей команды с дорожной картой. Опробованный и надежный способ сделать это состоит в том, чтобы разбить инициативы на эпосы в незавершенных продуктах, а затем разложить их на требования и истории пользователей. Таким образом, связывая все это вместе, продукт менеджеру и команде разработчиков легче принимать краткосрочные решения, которые не ставят под угрозу будущую работу. Давайте посмотрим на пример, чтобы увидеть, как это закончится.
Скажем, например, что мы развернули обширную функцию профиля пользователя на нашем сайте. Если мы обнаружим, что наши клиенты не используют эту функцию, следует ли нам продолжать в нее инвестировать? Может быть, а может и нет. Нам нужно понять, почему вовлеченность низкая, прежде чем мы примем это решение. Поэтому вместо того, чтобы идти вперед, мы могли бы предпочесть провести некоторые А/В тесты в надежде получить представление о низкой степени вовлеченности, что может указать нам направление, которое было бы гораздо более трудным (или невозможным), если бы мы просто шли вперед, добавляя больше фичей.
Способность сделать шаг назад и исследовать, прежде чем мы примем решающее решение, является основой agile дорожной карты. Это дает команде возможность развивать функции по мере того, как они узнают больше о продукте и рынке.
Антипаттерны, которые нужно остерегаться:
Waterfall проекты требуют огромных предварительных инвестиций. В результате члены команды становятся эмоционально привязанными к дорожной карте и жертвуют тем, что принимают не правильные решение, потому что слишком болезненно отказаться от работы, которую они сделали.
Со своей стороны, agile разработка сталкивается с тремя различными рисками:
Чтобы бороться с этим, ведем дорожную карту равномерно, сосредоточенной на краткосрочной тактике и стратегических, долгосрочных целях. Отличный способ сделать это — ежеквартально просматривать дорожные карты, корректировать их по мере необходимости и делиться ими. Это хорошо работает в организации любого размера, но помните: одна дорожная карта может охватывать несколько agile групп, поэтому проверяйте, адаптируйте и взаимодействуйте со всеми командами.
Это делает дорожную карту продукта полезным инструментом для управления ожиданиями заинтересованных сторон, а также для обмена планами и координации ресурсов с другими командами.
Чтобы построить дорожную карту, учитывайте рыночные тенденции, значимые предложения и технические ограничения. Как только эти факторы достаточно хорошо поняты, отразите в дорожной карте, как инициативы со сроками исполнения. Ниже приведен очень простой план действий для команды разработчиков. Инициативы выделены цветом, а сроки обозначены вехами.
После того, как дорожная карта создана, ее необходимо передать всей команде, чтобы все понимали видение и направление. Встречается, что менеджеры продуктов создают свои дорожные карты в PowerPoint или электронных таблицах, а затем отправляют по электронной почте скриншоты команде. Несмотря на благие намерения, эта стратегия изначально ошибочна. Каждый член команды имеет свою собственную копию дорожной карты, и держать всех в курсе, когда вносятся изменения проблематично.
Так как же Продукт Менеджерам лучше информировать команду? Просто.
Разместите план на общем ресурсе или интернете и держите в курсе команду, чтобы у них был единый источник.
Большинство инструментов для совместной работы, будут автоматически уведомлять всех участников проекта, что дорожная карта изменилась.
Важно связать работу вашей команды с дорожной картой. Опробованный и надежный способ сделать это состоит в том, чтобы разбить инициативы на эпосы в незавершенных продуктах, а затем разложить их на требования и истории пользователей. Таким образом, связывая все это вместе, продукт менеджеру и команде разработчиков легче принимать краткосрочные решения, которые не ставят под угрозу будущую работу. Давайте посмотрим на пример, чтобы увидеть, как это закончится.
Скажем, например, что мы развернули обширную функцию профиля пользователя на нашем сайте. Если мы обнаружим, что наши клиенты не используют эту функцию, следует ли нам продолжать в нее инвестировать? Может быть, а может и нет. Нам нужно понять, почему вовлеченность низкая, прежде чем мы примем это решение. Поэтому вместо того, чтобы идти вперед, мы могли бы предпочесть провести некоторые А/В тесты в надежде получить представление о низкой степени вовлеченности, что может указать нам направление, которое было бы гораздо более трудным (или невозможным), если бы мы просто шли вперед, добавляя больше фичей.
Способность сделать шаг назад и исследовать, прежде чем мы примем решающее решение, является основой agile дорожной карты. Это дает команде возможность развивать функции по мере того, как они узнают больше о продукте и рынке.
Антипаттерны, которые нужно остерегаться:
- Будущее планирование полностью игнорируется!
- «Остальная часть бизнеса» остается в неведении относительно того, чем занимается команда.
- Дорожная карта постоянно обновляется (или никогда не обновляется).
- Подробные требования отягощают дорожную карту.
Waterfall проекты требуют огромных предварительных инвестиций. В результате члены команды становятся эмоционально привязанными к дорожной карте и жертвуют тем, что принимают не правильные решение, потому что слишком болезненно отказаться от работы, которую они сделали.
Со своей стороны, agile разработка сталкивается с тремя различными рисками:
- Команда может потерять уверенность в способности руководства принимать стратегические решения, если дорожная карта обновляется слишком часто.
- Продукт может поступить на рынок слишком поздно и пропустить отложенный спрос, если дорожная карта обновляется недостаточно часто.
- Долгосрочные усилия могут показаться «слишком большими и слишком сложными» для более коротких итераций. Команда, разбивая работу на мелкозернистые задачи, и в конечном итоге слишком сильно фокусируется на краткосрочных результатах.
Чтобы бороться с этим, ведем дорожную карту равномерно, сосредоточенной на краткосрочной тактике и стратегических, долгосрочных целях. Отличный способ сделать это — ежеквартально просматривать дорожные карты, корректировать их по мере необходимости и делиться ими. Это хорошо работает в организации любого размера, но помните: одна дорожная карта может охватывать несколько agile групп, поэтому проверяйте, адаптируйте и взаимодействуйте со всеми командами.