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