Что такое MVP? Как решить, что оставить за рамками первой версии

MVP — один из самых употребляемых и самых неверно понимаемых терминов в мире разработки. Это не дешёвый продукт и не недоделанный продукт. Это минимальная конструкция, созданная для того, чтобы ответить на один вопрос. В этой статье мы разбираем, как выбрать этот вопрос и как решить, что оставить за рамками первой версии.

Что такое MVP и как расшифровывается? MVP — сокращение от английского minimum viable product; по-русски это минимально жизнеспособный продукт. Это самая маленькая, но работающая версия продукта, достаточная для проверки его ключевой гипотезы на реальных пользователях. Цель — не выпустить неполный продукт, а с минимальными затратами на разработку получить подтверждённый данными ответ на вопрос «будут ли люди этим действительно пользоваться?».

Что такое MVP и чем он не является?

MVP (minimum viable product / минимально жизнеспособный продукт) — это минимальная версия вашего продукта, достаточная для проверки одной гипотезы. Ключевое слово здесь — «жизнеспособный»: он действительно делает свою работу, просто делает её немного.

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

Сначала запишите: какую гипотезу вы проверяете?

MVP — это эксперимент, а у каждого эксперимента есть гипотеза. Прежде чем сокращать объём, закончите предложение: «Я верю, что люди будут …; я пойму это, глядя на показатель …».

Примеры:

• «Я верю, что владельцы небольших магазинов будут вести учёт товара с телефона; я пойму это, если из 20 зарегистрировавшихся компаний не менее 8 будут заходить три раза в неделю в течение двух недель».
• «Я верю, что клиенты будут записываться через приложение, а не по телефону; я пойму это, если к концу месяца не менее четверти записей будет приходить из приложения».

Если вы не можете написать это предложение, значит, вы не знаете, по какому критерию будете оценивать MVP. «Людям понравилось» — не результат; пользовались ли, вернулись ли, заплатили ли — критерием должно быть одно из этого.

Метод сокращения объёма

Список можно сократить с помощью трёх вопросов:

• Один тип пользователя: если сторон несколько (покупатель – продавец, клиент – бизнес), решите, чью проблему вы решаете в первой версии. Работу другой стороны вы можете временно выполнять вручную сами.
• Один сценарий: одна операция, которая является стержнем приложения. Если есть «оформление заказа», то в первой версии нет акций, избранного и системы рекомендаций.
• Один результат: что остаётся у пользователя после использования продукта? Всё, что не производит этот результат, — за рамками первой версии.

Посмотрите на список функций и спросите: «Если это убрать, продукт перестанет работать?» Если ответ «всё равно будет работать» — убирайте.

Три вещи, на которых в MVP нельзя экономить

Сокращается объём, а не качество. Эти три пункта должны быть полноценными и в первой версии:

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

Способы проверки без написания кода

Некоторые гипотезы можно проверить и без разработки ПО, и это самый дешёвый путь:

• Одностраничная презентация: страница с описанием продукта и форма регистрации. Сколько человек оставляют данные? Это первый сигнал спроса.
• Ручная работа за кулисами: то, что для пользователя выглядит автоматическим, вы выполняете вручную в фоновом режиме. Подбор записи, подготовку рекомендаций, передачу заказа дальше поначалу можно делать руками. Так вы узнаёте, какие правила действительно нужны.
• Сборка на готовых инструментах: соберите сценарий из форм, таблиц и мессенджеров и опробуйте его с несколькими реальными пользователями.
• Кликабельный прототип: неработающий, но доступный для навигации интерфейс, в котором вы просите пользователя «сделайте вот это» и наблюдаете, где он застревает.

Информация, полученная этими методами, напрямую определяет объём, когда вы начнёте разработку.

Как читать результат?

MVP даёт один из трёх результатов, и все три ценны:

• Сработало: использование достигло заданного критерия. Следующие функции вы выбираете уже не по догадкам, а глядя на то, где пользователи застревают.
• Сработало частично: продуктом пользовалась не та аудитория, которую вы ожидали, или на первый план вышла неожиданная функция. Обычно это самый поучительный результат; у вас появляется основание сменить направление.
• Не сработало: больно, но дёшево. Если бы вы заказали ту же идею в полном объёме, тот же результат обошёлся бы вам намного дороже.

Способность заранее принять третий результат — главная польза подхода MVP.

Частые ошибки

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

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

Сколько времени занимает создание MVP?

Зависит от узости объёма и готовности контента; называть срок заранее было бы неправильно. Главное, что сокращает срок, — сокращение списка функций. Когда объём прояснится, мы предоставим график в письменном виде.

Можно ли потом расширить MVP или его придётся переписывать с нуля?

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

Достаточно ли MVP для инвестора?

Инвестор обычно ищет не идею, а доказательства: пользующиеся люди, повторное использование, оплата. MVP — это способ получить такие доказательства, но доказательством служит не сам MVP, а собранные им данные об использовании.

У конкурента полнофункциональный продукт, как мне конкурировать с неполным?

Вы не конкурируете — вы решаете одну проблему узкой группы лучше, чем они. Цель MVP — не весь рынок, а первая группа пользователей.

MVP — значит дёшево?

Дешевле — не значит дёшево. Объём уменьшается, но качество работы — нет; сервер, безопасность и тестирование по-прежнему нужны.

Давайте вместе выпустим первую версию вашей идеи

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