MVP — самое затасканное слово в разработке продуктов. Им называют и прототип на выброс, и урезанную версию, и первую очередь большой системы. Из-за путаницы проекты стартуют с разными ожиданиями у заказчика и команды.
Полезное определение одно: MVP — это минимальная версия, которая уже создает ценность для пользователя и дает проверяемый ответ на главный вопрос о продукте.
Ключевое слово — «работающая»
Самая частая ошибка — резать продукт по слоям. Сначала нарисуем все экраны, потом сделаем логику, потом подключим данные. В таком порядке первая версия появляется в конце и проверить на ней нельзя ничего.
Какой вопрос проверяет ваш MVP
До начала работ стоит записать одну фразу: что именно станет известно после запуска. Формулировки бывают трех типов, и они требуют разного объема работ.
Нужно ли это вообще
Проверяется дешевле всего и часто без разработки: лендинг, ручная услуга под видом сервиса, продажи до продукта. Если тут ответ отрицательный, дальше идти не надо.
Будут ли этим пользоваться
Нужен работающий сценарий целиком. Мерить надо не регистрации, а повторные заходы и завершенные действия.
Сойдется ли экономика
Самый дорогой вопрос: нужны реальные деньги, реальные затраты на обслуживание и достаточный объем. Здесь MVP уже мало отличается от продукта.
Если вопрос не сформулирован, MVP превращается в «первую версию продукта» и режется по принципу «что успеем». Это не проверка гипотезы, а просто перенос срока.
Что режем, а что нет
- Режем количество сценариев. Один пользователь, один путь, один тип задачи. Все остальные роли и случаи — потом.
- Режем автоматизацию внутренних шагов. То, что делается редко, можно первое время делать руками. Пользователь не видит разницы, а разработки меньше в разы.
- Режем настройки. В первой версии параметры зашиты в код. Экран настроек — это отдельный продукт внутри продукта.
- Режем красоту второго плана. Один сценарий должен выглядеть прилично, остальное — без отделки.
- Не режем вход и безопасность. Если есть чужие данные, защита не может быть «потом».
- Не режем качество главного шага. Ради которого все затевалось — он должен работать хорошо, иначе проверка ничего не покажет.
- Не режем сбор данных о пользовании. Без него запуск не даст ответа, и все усилия уйдут в ощущения.
- Не режем структуру данных. Интерфейс переделать легко, модель данных — дорого. Здесь экономить нельзя.
Практическое правило: в MVP допустимо, чтобы что-то работало медленно, некрасиво или руками. Недопустимо, чтобы работало неправильно или теряло данные.
Что можно делать руками
Самый недооцененный прием в первой версии — не автоматизировать то, что происходит редко или требует сложной логики.
Подбор и распределение
Пользователь оставляет заявку, а распределяет ее человек за пультом. Снаружи выглядит как работающий сервис, внутри — таблица и диспетчер. Логику подбора вы поймете только после сотни реальных случаев.
Модерация и проверка
Все, что нужно проверить глазами, проверяется глазами. Автоматизировать имеет смысл, когда понятно, что именно проверять и в каких случаях.
Документы и выставление счетов
На первых десятках сделок быстрее сделать руками, чем строить генератор. Он появится, когда шаблон устоится.
Онбординг
Личное сопровождение первых пользователей дает больше информации о продукте, чем любая аналитика, и при этом требует нуля разработки.
Единственное условие: пользователь не должен страдать от того, что внутри сидит человек. Если ручная обработка означает ответ через сутки вместо минуты, проверка испорчена.
Как не превратить MVP в долгострой
- Добавление сценариев по ходу. Каждый новый «и еще бы» отодвигает запуск. Список дополнений копится в отдельном файле и разбирается после.
- Ожидание, пока станет прилично. Всегда есть что доделать. Дата запуска назначается заранее и не двигается ради отделки.
- Проектирование на будущий масштаб. Первая версия не должна выдерживать миллион пользователей. Она должна выдержать первых пятьдесят и не потерять их данные.
- Отсутствие решения, что считать успехом. Без записанного заранее критерия обсуждение результата превратится в спор интерпретаций.
Что мерить после запуска
Регистрации, установки и просмотры сюда не входят. Они показывают, что сработала реклама, а не продукт.
Где здесь ИИ
У моделей в разработке MVP две роли, и обе снижают цену проверки.
Скорость сборки. Типовые части первой версии — формы, списки, вход, выгрузки — собираются в разы быстрее, чем раньше. Это сдвинуло экономику: проверить гипотезу работающим продуктом стало дешевле, чем несколько лет назад, и во многих случаях дешевле, чем городить имитацию.
Замена ненаписанной логики. Там, где в будущем будет сложный алгоритм, в первой версии часто достаточно модели. Разбор заявки, подбор похожего, черновик ответа — все это работает сразу и позволяет проверить сценарий целиком, не строя алгоритм заранее.
При этом сам по себе ИИ внутри продукта не делает его нужным. Если сценарий не востребован, он не станет востребованным от того, что внутри модель.
Частые вопросы
Сколько занимает MVP
Один сценарий через все слои — обычно от трех недель до двух месяцев. Больше двух месяцев — это, скорее всего, уже не MVP, а первая очередь продукта, и стоит пересмотреть границы.
Что делать с MVP дальше
Возможны три исхода: развивать, переписывать или закрывать. Третий — тоже успех, если он случился через месяц, а не через год. Переписывание с нуля нужно реже, чем кажется, при условии, что модель данных изначально была нормальной.
Можно ли сделать MVP на конструкторе
Часто да, и это правильный ход для проверки первого вопроса. Упирается в две вещи: нестандартную логику и перенос данных потом. Если гипотеза подтвердится, переезд с конструктора будет отдельным проектом — это нормальная цена быстрой проверки.
Определим границы MVP по вашему вопросу
Расскажите про идею и что именно надо проверить. В ответ — какой сценарий достаточно сделать, что можно первое время делать руками, что нельзя резать ни в каком случае, и оценка по срокам.
Если гипотезу можно проверить без разработки, скажем об этом сразу.