Что включить в MVP: один полный сценарий вместо урезанной копии

Что первый релиз должен помочь вам решить?

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

Когда вопрос записан, расставлять приоритеты становится гораздо проще. Функция попадает в MVP, если без неё невозможен ключевой сценарий или если она делает его достаточно безопасным и измеримым, чтобы его можно было оценить. Всё остальное, каким бы привлекательным оно ни казалось, — удобства на будущее. С этого правила начинается разработка MVP.

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

Что входит в полный путь пользователя?

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

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

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

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

Как сохранить список задач честным?

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

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

Ещё до начала работ договоритесь и о том, что будет передано по итогам MVP: исходный код, документация и порядок поддержки. MVP — это начало, и следующему этапу или новой команде не придётся начинать с нуля.

Частые ошибки

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

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