Покорите всех своей дорожной картой

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

Martin Suntinger Martin Suntinger
Просмотр тем

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

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

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

1. Не нужно громких слов — старайтесь передать сущность

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

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

2. Задайте правильный контекст

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

3. Будьте осторожны с обязательствами

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

4. Создавайте реалистичные планы

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

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

Презентация дорожных карт продуктов | Atlassian — тренер по agile

5. Мыслите масштабно, но начинайте с малого

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

6. Создайте бизнес-сценарий

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

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

7. Найдите баланс между рутиной и мотивирующими задачами

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

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

8. Не забывайте думать, что последует за продуктом с минимальным функционалом и выпуском первой версии

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

9. Держите удар

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

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

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

Общий итог?

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

продолжение темы
Requirements