Создание дорожной карты функций MVP…

Фраза Ð´Ð¾Ñ€Ð¾Ð¶Ð½Ð°Ñ ÐºÐ°Ñ€Ñ‚Ð° функций mvp может звучать как Ð·Ð°Ð¿Ñ€Ð¾Ñ Ð½Ð° технологию или Ñмету на поÑтавку. Однако Ð´Ð»Ñ Ñ„Ð°ÑƒÐ½Ð´ÐµÑ€Ð° Ñто прежде вÑего продуктовое решение: Ñеквенирование приоритетных функций. КачеÑтво Ñтого Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð¾Ð¿Ñ€ÐµÐ´ÐµÐ»Ñет, даÑÑ‚ ли разработка полезные доказательÑтва или проÑто ещё больше кода.

Это руководÑтво объÑÑнÑет на практике, как Ñоздать дорожную карту функций MVP поÑле приоритизации. Оно напиÑано Ð´Ð»Ñ Ñ„Ð°ÑƒÐ½Ð´ÐµÑ€Ð¾Ð², которым нужно принимать чёткие решениÑ, не ÑтановÑÑÑŒ инженерами. ЕÑли более широкий процеÑÑ MVP пока незнаком, начните Ñ Ñтого практичеÑкого руководÑтва по разработке MVP и иÑпользуйте Ñхему ниже, чтобы Ñделать Ñто конкретное решение Ñвным.

Ðачните Ñ Ñ€ÐµÑˆÐµÐ½Ð¸Ñ, а не Ñ Ñ‚ÐµÑ…Ð½Ð¾Ð»Ð¾Ð³Ð¸Ð¸

Ðачните Ñ Ð¾Ð´Ð½Ð¾Ð³Ð¾ вопроÑа: что должен обеÑпечить первый пригодный к иÑпользованию релиз? ИнÑтрумент, архитектура, модель, агентÑтво или ÑпиÑок функций не могут ответить на Ñтот Ð²Ð¾Ð¿Ñ€Ð¾Ñ Ð·Ð° ваÑ. Фаундер должен определить клиента, проблему, важный рабочий процеÑÑ Ð¸ доказательÑтва, которые оправдали бы продолжение.

Полезный первый релиз завершает один путь клиента. Он не пытаетÑÑ Ð±Ñ‹Ñ‚ÑŒ уменьшенной копией конечного продукта. Это различие важно, потому что два продукта, опиÑанные одним и тем же ключевым Ñловом, могут требовать Ñовершенно разной работы. ПроÑтой внутренний процеÑÑ, клиентÑкий подпиÑной продукт и продукт Ñ Ñ‡ÑƒÐ²Ñтвительными данными не должны получать одинаковые планы.

Ðапишите одноÑтраничную запиÑку о решении перед обÑуждением реализации. Включите целевого клиента, текущий обходной путь, желаемый результат, оÑновной путь, предположениÑ, ограничениÑ, иÑÐºÐ»ÑŽÑ‡ÐµÐ½Ð¸Ñ Ð¸ Ñигналы уÑпеха. Это ÑтановитÑÑ Ñ‚Ð¾Ñ‡ÐºÐ¾Ð¹ отÑчёта, когда поÑвлÑÑŽÑ‚ÑÑ Ð½Ð¾Ð²Ñ‹Ðµ идеи или раÑходÑÑ‚ÑÑ Ð¾Ñ†ÐµÐ½ÐºÐ¸.

Определите узкий, но полный результат

«Минимальный» не должно означать «незавершённый». Клиент должен иметь возможноÑÑ‚ÑŒ войти в продукт, выполнить важную задачу, получить полезный результат и понÑÑ‚ÑŒ, что произойдёт дальше. Ð’Ñпомогательные операции — проверка, поддержка, иÑправлениÑ, ÑƒÐ²ÐµÐ´Ð¾Ð¼Ð»ÐµÐ½Ð¸Ñ Ð¸ управление аккаунтом — тоже нуждаютÑÑ Ð² ответÑтвенном, даже еÑли некоторые оÑтаютÑÑ Ñ€ÑƒÑ‡Ð½Ñ‹Ð¼Ð¸.

Ð”Ð»Ñ Ð´Ð¾Ñ€Ð¾Ð¶Ð½Ð¾Ð¹ карты функций mvp опишите результат одной фразой: «Конкретный пользователь может выполнить конкретную задачу и получить конкретный результат при извеÑтных уÑловиÑх». Затем перечиÑлите, что намеренно оÑтаётÑÑ Ð·Ð° Ñтой границей. Это отделÑет необходимую работу от привлекательных будущих идей.

ИÑпользуйте Ñту компактную карточку решений:

ОблаÑÑ‚ÑŒ решениÑ	Что документировать
Результат	Одно доÑтижение первого клиента
Граница	Явно отложенные функции
ДоказательÑтво	Поведение, подтверждающее Ñледующую инвеÑтицию
ОтветÑтвенный	Человек, отвечающий за каждое открытое решение

Эта карточка полезнее длинного ÑпиÑка пожеланий, потому что каждый пункт можно проверить вопроÑом: обеÑпечивает ли он оÑновной путь, Ñнижает ли ÑущеÑтвенный риÑк или Ñобирает ли необходимые доказательÑтва? ЕÑли нет — вероÑтно, Ñто отноÑитÑÑ Ðº периоду поÑле MVP.

Стройте объём вокруг пути

Пошагово ÑоÑтавьте карту первого полезного пути. Включите дейÑÑ‚Ð²Ð¸Ñ ÐºÐ»Ð¸ÐµÐ½Ñ‚Ð°, реакции ÑиÑтемы, задачи оператора, иÑÐºÐ»ÑŽÑ‡ÐµÐ½Ð¸Ñ Ð¸ итоговый результат. Функции легче оценивать, когда они ÑвÑзаны Ñ Ñтим потоком, а не перечиÑлены отдельно.

КлаÑÑифицируйте каждую предложенную возможноÑÑ‚ÑŒ как необходимую Ð´Ð»Ñ Ñ†ÐµÐ½Ð½Ð¾Ñти, необходимую Ð´Ð»Ñ Ð±ÐµÐ·Ð¾Ð¿Ð°ÑноÑти или ÑкÑплуатации, необходимую Ð´Ð»Ñ Ð¾Ð±ÑƒÑ‡ÐµÐ½Ð¸Ñ, или отложенную. ЕÑли пункт не подходит ни под одну из Ñтих групп, отложите его. ФикÑируйте завиÑимоÑти, поÑкольку Ð½ÐµÐ±Ð¾Ð»ÑŒÑˆÐ°Ñ Ð²Ð¸Ð´Ð¸Ð¼Ð°Ñ Ñ„ÑƒÐ½ÐºÑ†Ð¸Ñ Ð¼Ð¾Ð¶ÐµÑ‚ потребовать значительной Ñкрытой админиÑтрации или работы Ñ Ð´Ð°Ð½Ð½Ñ‹Ð¼Ð¸.

Секвенируйте вехи как законченные Ñрезы пути. Это Ñоздаёт более ранние демонÑтрации и выÑвлÑет недопонимание до того, как будет поÑтроен каждый Ñлой.

Определите риÑки перед оценкой работы

Ранние планы проваливаютÑÑ, когда Ð²Ð°Ð¶Ð½Ð°Ñ Ð½ÐµÐ¾Ð¿Ñ€ÐµÐ´ÐµÐ»Ñ‘Ð½Ð½Ð¾ÑÑ‚ÑŒ маÑкируетÑÑ Ð¿Ð¾Ð´ фикÑированное требование. ПопроÑите команду разработки отделить извеÑтную работу от предположений, требующих иÑÑледованиÑ, Ð¿Ñ€Ð¾Ñ‚Ð¾Ñ‚Ð¸Ð¿Ð¸Ñ€Ð¾Ð²Ð°Ð½Ð¸Ñ Ð¸Ð»Ð¸ техничеÑкого анализа. Цель — не уÑтранить вÑÑŽ неопределённоÑÑ‚ÑŒ, а не дать одной Ñкрытой завиÑимоÑти управлÑÑ‚ÑŒ вÑем проектом.

Типичные риÑки Ð´Ð»Ñ Ñтой темы:

• Объём раÑширÑетÑÑ Ð´Ð¾ того, как проÑÑнитÑÑ Ñ†ÐµÐ½Ñ‚Ñ€Ð°Ð»ÑŒÐ½Ð¾Ðµ предположение. Запишите, как команда будет Ñто выÑвлÑÑ‚ÑŒ и реагировать.
• ЗавиÑимые функции обнаруживаютÑÑ Ñлишком поздно. Запишите, как команда будет Ñто выÑвлÑÑ‚ÑŒ и реагировать.
• Команда оптимизирует полировку раньше полезноÑти. Запишите, как команда будет Ñто выÑвлÑÑ‚ÑŒ и реагировать.
• У операций за интерфейÑом нет ответÑтвенного. Запишите, как команда будет Ñто выÑвлÑÑ‚ÑŒ и реагировать.

ОбÑуждайте влиÑние и реакцию, а не только вероÑтноÑÑ‚ÑŒ. Сторонний ÑÐµÑ€Ð²Ð¸Ñ Ð¼Ð¾Ð¶ÐµÑ‚ быть надёжным, но вÑÑ‘ равно требовать резервного варианта. Модель может пройти демонÑтрацию, но не ÑправитьÑÑ Ñ Ñ€Ð°Ð·Ð½Ð¾Ð¾Ð±Ñ€Ð°Ð·Ð½Ñ‹Ð¼Ð¸ клиентÑкими данными. Рабочий процеÑÑ Ð¼Ð¾Ð¶ÐµÑ‚ быть техничеÑки проÑтым, но операционно невозможным Ð´Ð»Ñ Ð¿Ð¾Ð´Ð´ÐµÑ€Ð¶ÐºÐ¸ командой. Эти Ñ€Ð°Ð·Ð»Ð¸Ñ‡Ð¸Ñ Ð²Ð»Ð¸ÑÑŽÑ‚ на объём и поÑледовательноÑÑ‚ÑŒ.

Ð¡Ñ‚Ð°Ñ‚ÑŒÑ Ð¾ приоритизации риÑков MVP предлагает полезный дополнÑющий процеÑÑ, когда за внимание конкурируют неÑколько неопределённоÑтей.

Превратите план в проверÑемые вехи

Избегайте вех вроде «бÑкенд готов» или Â«Ð¸Ð½Ñ‚ÐµÐ³Ñ€Ð°Ñ†Ð¸Ñ Ð˜Ð˜ завершена». Они Ñообщают об активноÑти, а не о пригодном к иÑпользованию прогреÑÑе. Более ÑÐ¸Ð»ÑŒÐ½Ð°Ñ Ð²ÐµÑ…Ð° заканчиваетÑÑ Ð´ÐµÐ¼Ð¾Ð½Ñтрируемым результатом Ð´Ð»Ñ ÐºÐ»Ð¸ÐµÐ½Ñ‚Ð° или оператора и пиÑьменными уÑловиÑми приёмки.

Ð”Ð»Ñ ÐºÐ°Ð¶Ð´Ð¾Ð¹ вехи определите Ñценарий, начальные данные, ожидаемый результат, поведение при Ñбое и доказательÑтва Ð´Ð»Ñ ÑохранениÑ. Фаундер должен иметь возможноÑÑ‚ÑŒ наблюдать реальный рабочий процеÑÑ Ð½Ð° демо и Ñравнивать его Ñ ÑоглаÑованным результатом. ВопроÑÑ‹ и Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð´Ð¾Ð»Ð¶Ð½Ñ‹ попадать в общий журнал, чтобы не терÑÑ‚ÑŒÑÑ Ð¼ÐµÐ¶Ð´Ñƒ вÑтречами.

ПроверÑйте доÑтупы нарÑду Ñ Ñ„ÑƒÐ½ÐºÑ†Ð¸Ñми. ÐšÐ¾Ð¼Ð¿Ð°Ð½Ð¸Ñ Ð´Ð¾Ð»Ð¶Ð½Ð° контролировать репозиторий иÑходного кода, аккаунт хоÑтинга, домены, аналитику, Ñторонние ÑервиÑÑ‹, файлы дизайна и данные продукта. Это оÑобенно важно, когда задейÑтвованы внешние ÑпециалиÑÑ‚Ñ‹ или платформы Ñ Ð¾Ð¿Ð»Ð°Ñ‚Ð¾Ð¹ по иÑпользованию.

ИзмерÑйте доказательÑтва, а не активноÑÑ‚ÑŒ

Полезные доказательÑтва Ð´Ð»Ñ Ñтого Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð²ÐºÐ»ÑŽÑ‡Ð°ÑŽÑ‚ завершение пути, повторное иÑпользование, Ð¾Ð±Ñ€Ð°Ñ‰ÐµÐ½Ð¸Ñ Ð² поддержку и подтверждение того, что рабочий процеÑÑ Ñ€ÐµÑˆÐ°ÐµÑ‚ заÑвленную проблему. Выберите небольшой набор, напрÑмую ÑвÑзанный Ñ Ð¾Ñновным предположением. Панель, Ð¿Ð¾Ð»Ð½Ð°Ñ Ð½ÐµÑвÑзанной активноÑти, может заÑтавить неопределённый продукт выглÑдеть здоровее, чем он еÑÑ‚ÑŒ.

Определите ритм проверки до запуÑка. Решите, кто анализирует результаты, как отзывы клиентов ÑочетаютÑÑ Ñ Ð¿Ð¾Ð²ÐµÐ´ÐµÐ½Ñ‡ÐµÑкими данными и какие уÑÐ»Ð¾Ð²Ð¸Ñ Ð·Ð°Ð¿ÑƒÑкают изменениÑ. ДоказательÑтва могут поддерживать продолжение, Ñужение аудитории, переÑмотр процеÑÑа, изменение техничеÑкого подхода или оÑтановку. Ð’Ñе Ñто законные иÑходы MVP.

ИÑпользуйте выводы Ð´Ð»Ñ Ð¾Ð±Ð½Ð¾Ð²Ð»ÐµÐ½Ð¸Ñ Ð¿Ñ€Ð¸Ð¾Ñ€Ð¸Ñ‚ÐµÑ‚Ð¾Ð², а не Ð´Ð»Ñ Ð°Ð²Ñ‚Ð¾Ð¼Ð°Ñ‚Ð¸Ñ‡ÐµÑкого Ð´Ð¾Ð±Ð°Ð²Ð»ÐµÐ½Ð¸Ñ Ñамой запрашиваемой функции. Сначала определите, предÑтавлÑет ли Ð·Ð°Ð¿Ñ€Ð¾Ñ Ð¿Ð¾Ð²Ñ‚Ð¾Ñ€ÑющееÑÑ Ð¿Ñ€ÐµÐ¿ÑÑ‚Ñтвие Ð´Ð»Ñ Ñ†ÐµÐ»ÐµÐ²Ð¾Ð³Ð¾ клиента или предпочтение одного человека.

Эффективно работайте Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´Ð¾Ð¹ разработки

Фаундерам не нужно диктовать детали реализации, но им нужна видимоÑÑ‚ÑŒ. ПроÑите команду объÑÑнÑÑ‚ÑŒ важные Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð¿Ñ€Ð¾Ñтым Ñзыком: требование, раÑÑмотренные варианты, компромиÑÑÑ‹, выбранный подход и уÑловиÑ, которые изменили бы Ñтот выбор.

ДоговоритеÑÑŒ о коротких циклах обратной ÑвÑзи, рабочих демонÑтрациÑÑ…, критериÑÑ… приёмки и чётком пути ÑÑкалации. ЕÑли вы Ñравниваете внешнюю помощь, руководÑтво по выбору компании Ð´Ð»Ñ Ñ€Ð°Ð·Ñ€Ð°Ð±Ð¾Ñ‚ÐºÐ¸ MVP объÑÑнÑет, как оценивать доказательÑтва поÑтавки и ответÑтвенноÑÑ‚ÑŒ, а не полагатьÑÑ Ð½Ð° качеÑтво презентации.

Здоровое ÑотрудничеÑтво ÑохранÑет разные зоны ответÑтвенноÑти. Фаундер владеет пониманием клиента, приоритетами, коммерчеÑкими ограничениÑми и продуктовыми решениÑми. ТехничеÑÐºÐ°Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´Ð° владеет качеÑтвом инженерии, вариантами реализации, теÑтированием, безопаÑноÑтью и операционными рекомендациÑми. Важные компромиÑÑÑ‹ решаютÑÑ Ð²Ð¼ÐµÑте и фикÑируютÑÑ.

Практичный чек-лиÑÑ‚ Ð´Ð»Ñ Ñледующего шага

Прежде чем вкладывать больше бюджета в дорожную карту функций mvp, убедитеÑÑŒ, что вы можете ответить на Ñледующее:

• Кто первый конкретный пользователь?
• Какой полный результат предоÑтавит продукт?
• Какое предположение проверÑет Ñтот релиз?
• Что Ñвно иÑключено?
• ÐšÐ°ÐºÐ°Ñ Ð·Ð°Ð²Ð¸ÑимоÑÑ‚ÑŒ или техничеÑкое решение неÑÑ‘Ñ‚ наибольший риÑк?
• Какие доказательÑтва будут проверены поÑле реального иÑпользованиÑ?
• Кто отвечает за ÑкÑплуатацию, поддержку, данные, аккаунты и решениÑ?
• Какой результат заÑтавит команду продолжить, переÑмотреть или оÑтановитьÑÑ?

Чёткие ответы не уÑтранÑÑŽÑ‚ неопределённоÑÑ‚ÑŒ, но делают её управлÑемой. Они также дают дизайнерам и разработчикам доÑтаточно контекÑта, чтобы предлагать более проÑтые варианты вмеÑто того, чтобы трактовать широкое ключевое Ñлово как указание поÑтроить вÑÑ‘ ÑвÑзанное Ñ Ð½Ð¸Ð¼.

Принимайте наименьшее защитимое обÑзательÑтво

Лучший план Ð´Ð»Ñ Ð´Ð¾Ñ€Ð¾Ð¶Ð½Ð¾Ð¹ карты функций mvp не обÑзательно Ñамый быÑтрый или техничеÑки амбициозный. Это наименьшее защитимое обÑзательÑтво, которое даёт реальный результат, ответÑтвенно управлÑет извеÑтными риÑками и Ñоздаёт доказательÑтва Ð´Ð»Ñ Ñледующего решениÑ.

Держите запиÑку о решении активной на протÑжении вÑей поÑтавки. ОбновлÑйте Ð¿Ñ€ÐµÐ´Ð¿Ð¾Ð»Ð¾Ð¶ÐµÐ½Ð¸Ñ Ð¿Ñ€Ð¸ изменении доказательÑтв от клиентов, фикÑируйте, почему менÑетÑÑ Ð¾Ð±ÑŠÑ‘Ð¼, и требуйте демонÑтраций отноÑительно оÑновного пути. Эта диÑциплина защищает продукт как от преждевременной ÑложноÑти, так и от Ñокращений, делающих реальное иÑпользование небезопаÑным.

Часто Задаваемые Вопросы

Каков первый шаг в дорожной карте функций mvp?

Ðачните Ñ Ð¾Ð¿Ñ€ÐµÐ´ÐµÐ»ÐµÐ½Ð¸Ñ Ñ†ÐµÐ»ÐµÐ²Ð¾Ð³Ð¾ клиента, нужного результата и неопределённого предположениÑ, которое должна проверить работа. Выбирайте технологию или партнёра по разработке только поÑле того, как Ñти моменты проÑÑнÑÑ‚ÑÑ.

Как нетехничеÑкому фаундеру управлÑÑ‚ÑŒ дорожной картой функций mvp?

Возьмите на ÑÐµÐ±Ñ Ð¿Ñ€Ð¾Ð±Ð»ÐµÐ¼Ñƒ клиента, приоритеты, Ð¾Ð³Ñ€Ð°Ð½Ð¸Ñ‡ÐµÐ½Ð¸Ñ Ð¸ меры уÑпеха. ПроÑите техничеÑкую команду объÑÑнÑÑ‚ÑŒ варианты и компромиÑÑÑ‹ проÑтым Ñзыком, а прогреÑÑ Ð¾Ñ†ÐµÐ½Ð¸Ð²Ð°Ð¹Ñ‚Ðµ по рабочим демонÑтрациÑм и доказательÑтвам.

Как Ñохранить Ñ„Ð¾ÐºÑƒÑ Ð´Ð¾Ñ€Ð¾Ð¶Ð½Ð¾Ð¹ карты функций mvp?

Определите один полный путь клиента и зафикÑируйте Ñвные иÑключениÑ. Включайте только работу, необходимую Ð´Ð»Ñ Ñ†ÐµÐ½Ð½Ð¾Ñти клиента, ответÑтвенной ÑкÑплуатации, ÑÐ½Ð¸Ð¶ÐµÐ½Ð¸Ñ Ñ€Ð¸Ñка или обучениÑ.

Как понÑÑ‚ÑŒ, уÑпешна ли Ð´Ð¾Ñ€Ð¾Ð¶Ð½Ð°Ñ ÐºÐ°Ñ€Ñ‚Ð° функций mvp?

Выберите поведенчеÑкие доказательÑтва, ÑвÑзанные Ñ Ð¾Ñновным предположением, до начала разработки. Оценивайте реальное завершение задач, повторное иÑпользование, качеÑтво, паттерны обращений в поддержку и коммерчеÑкие обÑзательÑтва, а не только мнениÑ.