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