MVP против прототипа: кому нужен…

Фраза minimum viable product vs prototype может звучать как Ð·Ð°Ð¿Ñ€Ð¾Ñ Ñ‚ÐµÑ…Ð½Ð¾Ð»Ð¾Ð³Ð¸Ð¸ или раÑценки. Однако Ð´Ð»Ñ Ñ„Ð°ÑƒÐ½Ð´ÐµÑ€Ð° Ñто в первую очередь продуктовое решение: понÑÑ‚ÑŒ Ñ‚Ñ€ÐµÐ±Ð¾Ð²Ð°Ð½Ð¸Ñ Ðº качеÑтву инженерии. КачеÑтво Ñтого Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð¾Ð¿Ñ€ÐµÐ´ÐµÐ»Ñет, даÑÑ‚ ли разработка полезные доказательÑтва или проÑто ещё больше кода.

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

Ðачните С РешениÑ, Ð Ðе С Технологии

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

Полезный первый релиз завершает один путь клиента. Он не пытаетÑÑ Ð¿Ñ€ÐµÐ´Ñтавить будущий продукт в миниатюре. Это различие важно, потому что два продукта, опиÑанные одним ключевым Ñловом, могут требовать Ñовершенно разной работы. ПроÑтой внутренний рабочий процеÑÑ, клиентÑкий подпиÑной продукт и продукт, обрабатывающий конфиденциальные данные, не должны получать одинаковые планы.

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

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

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

Ð”Ð»Ñ minimum viable product vs prototype опишите результат одним предложением: «Конкретный пользователь может выполнить конкретную задачу и получить конкретный результат при извеÑтных уÑловиÑх». Затем перечиÑлите, что намеренно иÑключено из Ñтой границы. Это отделÑет необходимую работу от привлекательных будущих идей.

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

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

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

СоотнеÑите Ðртефакт С ÐеопределённоÑтью

Прототип иÑÑледует опыт, proof of concept изучает оÑущеÑтвимоÑÑ‚ÑŒ, а MVP проверÑет ценноÑÑ‚ÑŒ на реальных пользователÑÑ…. Границы могут перекрыватьÑÑ, но Ð²Ð¾Ð¿Ñ€Ð¾Ñ Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð´Ð¾Ð»Ð¶ÐµÐ½ оÑтаватьÑÑ ÑÑным. Ðе превращайте ÑкÑпериментальный код в Ñтабильный только потому, что демонÑÑ‚Ñ€Ð°Ñ†Ð¸Ñ Ð²Ñ‹Ð³Ð»Ñдела убедительно.

Определите критерии Ð·Ð°Ð²ÐµÑ€ÑˆÐµÐ½Ð¸Ñ Ð¿ÐµÑ€ÐµÐ´ началом. Прототипу могут понадобитьÑÑ Ñ€ÐµÐ°Ð»Ð¸Ñтичные Ñкраны и Ð¾Ð±Ñ€Ð°Ñ‚Ð½Ð°Ñ ÑвÑзь по задачам; POC может понадобитьÑÑ Ð²Ð¾ÑÐ¿Ñ€Ð¾Ð¸Ð·Ð²Ð¾Ð´Ð¸Ð¼Ð°Ñ Ð¿Ñ€Ð¾Ð¸Ð·Ð²Ð¾Ð´Ð¸Ñ‚ÐµÐ»ÑŒÐ½Ð¾ÑÑ‚ÑŒ на репрезентативных данных; MVP нужен надёжный Ñквозной путь, ÑкÑплуатациÑ, поддержка и измерение.

При движении вперёд оцените, что можно Ñохранить. Ð—Ð½Ð°Ð½Ð¸Ñ Ð¸ теÑтовые Ñлучаи обычно переноÑÑÑ‚ÑÑ. Код, архитектура, обработка данных и детали интерфейÑа могут потребовать Ñознательной переÑтройки.

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

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

РаÑпроÑтранённые риÑки по Ñтой теме включают:

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

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

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

Превратите План Ð’ ПроверÑемые Вехи

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

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

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

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

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

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

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

Эффективно Работайте С Командой Разработки

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

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

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

ПрактичеÑкий Чек-ЛиÑÑ‚ Следующего Шага

Прежде чем вкладывать больше бюджета в minimum viable product vs prototype, убедитеÑÑŒ, что можете ответить на Ñледующее:

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

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

Возьмите Ðа Ð¡ÐµÐ±Ñ Ðаименьшее Оправданное ОбÑзательÑтво

Лучший план Ð´Ð»Ñ minimum viable product vs prototype не обÑзательно Ñамый быÑтрый или техничеÑки Ñамый амбициозный. Это наименьшее оправданное обÑзательÑтво, которое даёт реальный результат, ответÑтвенно управлÑет извеÑтными риÑками и Ñоздаёт доказательÑтва Ð´Ð»Ñ Ñледующего решениÑ.

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

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

Каков первый шаг в minimum viable product vs prototype?

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

Как нетехничеÑкому фаундеру управлÑÑ‚ÑŒ minimum viable product vs prototype?

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

Как Ñохранить Ñ„Ð¾ÐºÑƒÑ Ð² minimum viable product vs prototype?

Определите один полный путь клиента и зафикÑируйте Ñвные иÑключениÑ. Включайте только ту работу, ÐºÐ¾Ñ‚Ð¾Ñ€Ð°Ñ Ð½ÑƒÐ¶Ð½Ð° Ð´Ð»Ñ Ñ†ÐµÐ½Ð½Ð¾Ñти клиента, ответÑтвенной ÑкÑплуатации, ÑÐ½Ð¸Ð¶ÐµÐ½Ð¸Ñ Ñ€Ð¸Ñка или Ð¿Ð¾Ð»ÑƒÑ‡ÐµÐ½Ð¸Ñ Ð·Ð½Ð°Ð½Ð¸Ð¹.

Как понÑÑ‚ÑŒ, уÑпешен ли minimum viable product vs prototype?

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