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