# MVP веб-приложения: как выбрать проверяемый минимальный объём

Источник: https://quicklanding.ru/knowledge/web-app-mvp/

Как определить минимальный объём веб-приложения: один рабочий процесс, роли, ограничения и критерии проверки. Что можно отложить, а что понадобится уже на первом запуске.

В списке будущего приложения есть кабинет, чат, платежи, отчёты и мобильная версия. Но команда ещё не проверила, готов ли клиент пользоваться новым процессом. Для первой версии выберите законченную задачу, которую можно выполнить от начала до конца. Сокращать нужно объём функций, сохраняя работоспособность выбранного сценария.

## Выберите одну потребность для проверки

![Рабочие заметки на доске для планирования продукта](/assets/images/knowledge/web-app-mvp.webp)

Опишите пользователя, момент возникновения задачи и результат. «Личный кабинет для клиентов» слишком широко. «Клиент получает подготовленный расчёт, задаёт вопрос и подтверждает выбранный вариант» уже позволяет определить экраны и действия. Укажите, какой существующий процесс вы заменяете и почему он сейчас неудобен.

Представьте сервис ремонта оборудования. Клиенты постоянно спрашивают, на каком этапе находится устройство. Первая версия может показывать согласованные состояния ремонта и давать возможность задать вопрос по заказу. Онлайн-оплата и программа лояльности не обязательны для проверки именно этой потребности. Но связь пользователя со своим заказом обязательна.

## Проведите сценарий через обе стороны

Нарисуйте путь клиента и сотрудника. Кто создаёт заказ, меняет состояние, отвечает на вопрос и исправляет ошибку? Экран пользователя не станет рабочим продуктом, если данные в него некому передавать. Включите в первый объём необходимые действия сотрудника, даже если интерфейс будет простым.

Для каждого шага запишите входные данные и результат. Откуда приходит номер заказа, как подтверждается принадлежность клиенту, что происходит при отсутствии записи? Если часть процесса пока ручная, сделайте её управляемой. Назначьте ответственного и ограничение по нагрузке вместо обещания автоматизации, которой ещё нет.

## Отложите дополнительные возможности по причине

Разделите задачи на необходимые для выбранного пути, полезные позже и пока неподтверждённые. Не исключайте восстановление доступа, проверку прав и сохранение данных ради красивой демонстрации. Их отсутствие может сделать тест невозможным или небезопасным. При этом сложные отчёты часто можно заменить простым контролируемым просмотром на первом этапе.

| Задача | Решение для первой версии |
| --- | --- |
| Клиент видит свой заказ | Включить в основной путь |
| Сотрудник обновляет состояние | Обеспечить рабочее действие |
| Подробная аналитика всех филиалов | Отложить до подтверждения потребности |
| Исправление неверных данных | Оставить понятный управляемый способ |

Записывайте причину каждого исключения и условие возвращения задачи в план. «Позже» без условия быстро превращается в спор о том, что было обещано. Для нового отчёта таким условием может стать конкретная управленческая задача, которую невозможно решить по уже доступным данным.

## Определите, что покажет результат запуска

Выберите проверяемый показатель: пользователь завершил путь, сотрудник обработал обращение, время определённого действия измерено. Не назначайте произвольную цель по росту продаж без исходных данных и связи с продуктом. Важно понять, используют ли люди выбранный процесс и где они останавливаются.

Подготовьте вопросы для тестовой группы. Попросите выполнить обычную задачу без подсказок и зафиксируйте затруднения. Не ограничивайтесь вопросом, нравится ли дизайн. Пользователь может похвалить интерфейс и всё равно продолжить писать менеджеру, потому что нужное состояние заказа непонятно.

## Согласуйте границы и следующий шаг

Зафиксируйте роли, сценарии, исключения, тестовые данные и порядок приёмки. Укажите, кто решает вопросы по процессу и какие изменения потребуют пересмотра объёма. После запуска разберите обращения и наблюдения, затем сформируйте следующую версию по подтверждённым проблемам. Минимальный продукт полезен, когда даёт материал для решения, а не просто сокращённый набор красивых экранов.

## Связанные материалы

[Роли в приложении: как описать доступ к данным и действиям](/knowledge/app-user-roles/)

[Админка приложения: какие действия нужны сотрудникам ежедневно](/knowledge/app-admin-design/)

[Запуск приложения: тестовая группа, обратная связь и порядок исправлений](/knowledge/app-release-plan/)

## Частые вопросы

### MVP можно сделать только из клиентских экранов?

Если для выбранного сценария нужны действия сотрудника, их тоже необходимо обеспечить. Иначе клиентские экраны не получат актуальные данные и процесс останется незавершённым.

### Что нельзя убрать ради быстрого первого запуска?

Проверку прав, надёжное сохранение нужных данных и возможность восстановить основной процесс. Состав остальных функций определяется задачей, которую проверяет первая версия.

### Как понять, какие функции делать следующими?

Смотрите на реальные затруднения тестовой группы и незавершённые действия. Приоритет получает проблема, которая мешает выбранному процессу, а не просто расширяет список возможностей.

Автор: Владимир Николаев