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