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