Десять способов провести успешную презентацию дорожной карты продукта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нужна дополнительная помощь? Ознакомьтесь с возможностями дорожных карт в Jira Software и шаблоном дорожной карты продукта в Jira. Попробуйте продукт Jira Product Discovery, созданный для менеджеров проектов, бесплатно.