MVP проекта: где проверка идеи, а где урезанный релиз

Команда неделями собирает «минимальную версию», выпускает её, и никто не может сказать, проверили они идею или просто выпустили сырой продукт. Чтобы с вами так не вышло, сначала выясним, что такое MVP.

На вопрос «mvp проекта что это» обычно отвечают расшифровкой: минимально жизнеспособный продукт. Марти Каган в книге «Вдохновлённые. Всё, что нужно знать продакт-менеджеру» ставит на первое место цель: до выпуска цифрового продукта проверить риск с помощью простого прототипа.

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

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

MVP проекта: что это по Кагану

Для Кагана MVP проекта — способ как можно раньше узнать что-то важное о будущем цифровом продукте. Команда делает прототип под конкретный вопрос, наблюдает за людьми или проверяет техническое условие и решает, стоит ли развивать идею. Такой прототип может быть одноразовым: его задача заканчивается вместе с проверкой. Минимальность здесь означает ровно столько работы, сколько нужно для ответа на выбранный вопрос.

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

MVP продукта: чем прототип отличается от урезанного релиза

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

Прототип делают ради знания. У него может быть временный интерфейс, ручная работа за экраном или одноразовый код. Релизом люди будут пользоваться всерьёз: им нужны работающий сервис, понятный статус заказа и помощь, если что-то сломалось. Небольшая первая версия вполне уместна после исследования; её размер не снимает обязанностей перед пользователями.

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

Минимальный продукт MVP: восемь ситуаций для самопроверки

Минимальный продукт MVP проще узнать по цели проверки, чем по виду экрана или объёму кода. Перед ответами попробуйте для каждой ситуации назвать риск и действие, по которому команда о нём узнает.

1. Команда размещает страницу с описанием будущего сервиса и предлагает оставить заявку. После отправки человеку сообщают, что сервис ещё разрабатывают.

2. Команда долго собирает половину задуманных функций, а затем открывает работающую версию всем желающим.

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

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

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

6. Во время интервью людей спрашивают, купили бы они будущий сервис. Вежливые ответы принимают за подтверждение спроса.

7. Ограниченный прототип обрабатывает реальные данные, и команда наблюдает, используют ли люди его результат.

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

Ответы: что проверяет каждый пример

Восемь ответов показывают, какой риск проверяет действие команды и где вывод выходит за пределы наблюдения.

1. Страница с заявкой может показать интерес к предложению: человек совершил действие и узнал статус сервиса. Контакт ещё не означает будущую покупку.

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

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

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

5. Временный код проверяет техническую реализуемость алгоритма. Если он справился с условием, это ещё ничего не говорит об интересе пользователей.

6. Ответы в интервью помогают лучше понять проблему человека, но обещание купить остаётся словами. Для вывода о спросе нужно наблюдать поведение.

7. Реальные данные показывают, используют ли люди результат прототипа. Ограниченный опыт пока не описывает работу полноценного сервиса для всех.

8. Сырой сервис перекладывает сбои на пользователей. Для исследовательского прототипа стоило бы назвать вопрос и провести проверку, не выдавая выпуск без поддержки за эксперимент.

Для Кагана лендинг, макет и временный код ценны ровно тем знанием, которое способны дать. Слово «MVP» на обложке проекта не превращает любой из них в ответ на все вопросы сразу.

Какой риск мешает вашей идее

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

Риск ценности: нужно ли людям предложенное решение и готовы ли они им пользоваться? Риск удобства: поймут ли люди, как получить результат? Риск реализуемости: сможет ли команда построить то, что задумала? Риск жизнеспособности: согласуется ли решение с условиями бизнеса и его обязательствами?

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

Начать можно с вопроса, который держит команду в ожидании.

Ответ должен быть достаточно точным, чтобы под него удалось подобрать проверку. «Понравится ли всем?» слишком расплывчато, а «сможет ли человек найти нужное действие в макете?» уже можно наблюдать.

Чем проверить риск: короткая карта прототипов

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

Строка о жизнеспособности описывает разговор и проверку условий, а не ещё один вид прототипа. Как согласовать интересы людей, от которых зависит решение, рассказано в статье «Стейкхолдеры». Здесь достаточно помнить: удачный пользовательский опыт не отвечает за правовые и финансовые условия проекта.

Что результат проверки пока не доказывает

Результат проверки отвечает на поставленный вопрос в пределах выбранного способа. Если люди без подсказок проходят кликабельный макет, команда узнала что-то об удобстве пути. Вопрос о ценности остаётся открытым: понятным интерфейсом можно пользоваться для дела, которое человеку не нужно.

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

Заявка, клик или ограниченное использование тоже требуют аккуратного чтения. Контакт показывает интерес к описанному предложению, но не обещает покупку; ограниченное использование не закрывает вопросы бизнеса.

Первая проверка для своей идеи

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

1. Назовите человека и его проблему. Запишите, кому предназначено решение и как человек справляется сейчас. Текущий обходной путь помогает увидеть, с чем будет сравниваться ваша идея.

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

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

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

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

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

Вопросы об MVP и запрос для тренажёра

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

Я хочу проверить идею [кратко опишите свой продукт], но пока не знаю, какой риск главный. Помоги по «Вдохновлённым» отличить проверку гипотезы от урезанного релиза: задай мне вопросы о пользователе и идее, затем помоги выбрать один риск — ценность, удобство, реализуемость или жизнеспособность — и подходящий одноразовый прототип для его проверки.

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