Разработка MVP веб-сервиса

Что должна проверить первая версия

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

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

Как определить результат проверки

До разработки согласуем, какие действия пользователей будем наблюдать и как собирать обратную связь. Это могут быть завершённые сценарии, повторное использование или причины отказа. Числовой критерий выбирается для конкретной гипотезы и объёма исследования.

Техническая приёмка и проверка востребованности продукта происходят отдельно. Работающая отправка заявки подтверждает выполнение функции. Готовность людей пользоваться сервисом требует наблюдения за реальными пользователями и не гарантируется разработкой.

Что входит в первую версию

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

Учебный состав MVP

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

Многоуровневую аналитику, десятки шаблонов форм, автоматические рекомендации и несколько способов оплаты можно рассмотреть позже, если они не нужны для выбранной проверки. Такое решение не универсально: у другого продукта оплата окажется частью самого основного сценария.

На узком экране таблицу можно прокрутить вбок. С клавиатуры используйте Tab и стрелки.

Роли и источники данных

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

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

Как передаётся первая версия

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

Материалы владельцу продукта

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

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

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