Советы по предоставлению дорожных карт продукта

Завоюйте всех своей дорожной картой

Шпаргалка: 10 лучших советов для получения выкупа от вашей технической команды

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

Вы могли бы утверждать, что проблема, вероятно, заключалась в том, что я страдаю от NIH (синдром не изобретен здесь), и вы можете быть правы. Как разработчик, у меня было очень твердое мнение о том, что нужно делать. Но теперь, как менеджер по продукту, я вижу, что вызвало это разъединение, и что менеджеры по продуктам общего обучения могут извлечь из этого разъединения, чтобы вызвать успех с вашей следующей презентацией. В конце концов, если техническая команда согласна и понимает общую картину, ежедневные решения по проектированию и внедрению будут приниматься в правильном контексте, и вы получите продукт, который представляете себе.

  1. Выберите вещество над модными словечками

Хотя такие модные слова, как «анализ больших данных», «машинное обучение» или «инициатива Интернета вещей» (IoT), могут найти отклик у деловых кругов в качестве опорных точек высокого уровня, они не являются полезными и действенными элементами для технических групп. Инжиниринг должен точно знать, что именно он создает, как он связан с текущими продуктами, как он должен поставляться, и кто будет его использовать в конце и для каких целей.

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

  1. Установите правильный контекст

Техническим группам нужен контекст, чтобы понять, почему вы строите что-то по дорожной карте. Ни одна техническая команда не скажет: «Просто скажи мне, чего ты хочешь, и я сделаю это».

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

  1. Внимательно рассмотрите обязательства

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

  1. Составьте реалистичные планы

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

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

  1. Думайте масштабно, начинайте с малого

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

  1. Создайте бизнес-кейс

Бизнес кейс? Да. Технические команды заботятся о бизнес-кейсах. Может быть, не в такой степени, как высшее руководство, но вся команда разработчиков заботится о том, почему что-то имеет отношение к бизнесу, если оно дает реальные результаты, и как это будет измеряться.

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

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

  1. Баланс обыденного с мотивацией

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

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

  1. Думайте не только о MVP и v1

Создание минимально жизнеспособного продукта, а затем версия 1 - это одно, но есть также все, что происходит после запуска: операции, обслуживание, запросы функций от пользователей, постоянные улучшения и новые версии других продуктов и / или интегрированных платформ. Если вы быстро подумаете о том, какие вызывы и препятствия могут возникнуть после запуска, вы сможете легко их обнаружить, то инженеры будут благодарны, что вы не проигнорировали эти реалии. По приблизительным оценкам, первоначальные усилия по созданию новой функции часто составляют лишь треть или половину от общих усилий, затраченных на нее в течение всего срока ее службы. Другими словами: последствия дороже, чем первоначальная сборка, а некоторые «быстрые мелочи» становятся очень дорогими в долгосрочной перспективе.

  1. Закатывание с ударами

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

  1. Будьте открыты и честны

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

Суть? (Линия дна)

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

По материалам Agile Coach "Tips for presenting product roadmaps"