Три недостатка Roadmap, которые могут привести к провалу проекта
В оригинале: INSPIRED. How to Create Tech Products Customers Love.
Возможно, самая популярная и полезная книга для менеджеров в ИТ-сфере, которая учит создавать технологичные продукты, основываясь на истинных потребностях пользователей, а не слепых пожеланиях заинтересованных лиц.
В книге много применимых идей, но я расскажу об одной, которая запомнилась мне больше всего.
Руководители часто хотят видеть план работы, который состоит из требуемых функций и сроков их реализации (Roadmap). Это логично, ведь им важно понимать над чем работает команда и каким-то образом контролировать процесс. Но в этом методе есть несколько упущений, которые могут привести к провалу проекта:
- На разработку ценной функции требуется несколько итераций, поэтому просто сделать ее мало. Нужно протестировать решение, собрать обратную связь и внести улучшения. А если бы вы остановились на первой версии, она могла не принести пользователю дополнительной ценности, из-за чего он мог перестать использовать продукт. Получилось бы, что функция есть, но смысла в ней нет.
- Задача продукта — не создание новых функций, а достижение бизнес-результатов. Поэтому нужно, чтобы каждая функция приносила результат, который можно измерить с помощью метрик. Вот пример: добавление возможности зарегистрироваться через Facebook (функция) должно повысить конверсию на X% (метрика).
- Составлять Roadmap продукта из функций — не лучшая идея, ведь пользователи ждут другого — решения своих проблем. На основе этого и нужно планировать работу. Функция — один из вариантов решения проблемы и не факт, что самый лучший. Нужно всегда опускаться на уровень ниже и пытаться найти другие решения.
Загрузка...
