Тест в одно предложение
Может ли реальный пользователь пройти самый важный сценарий от начала до конца без этой функции? Если да — это не ядро, можно подождать. Один этот тест закрывает большинство споров об объёме.
Что почти всегда входит
- Один ключевой сценарий, полностью работающий от начала до конца
- Базовая аутентификация (даже с одной ролью)
- Достаточно постоянного хранения данных, чтобы ключевой сценарий был реальным, а не имитацией
Что почти всегда откладывается
- Инфраструктура биллинга/подписок
- Несколько ролей пользователей и админ-инструменты
- Обработка редких пограничных сценариев
- Полностью отшлифованный, брендированный интерфейс (для проверки гипотезы достаточно функционального и понятного)
Прототип, proof of concept или MVP
Эти три вещи отвечают на разные вопросы. Прототип отвечает, понимают ли люди идею и станут ли ей пользоваться, и показывает, как это выглядит. Proof of concept отвечает, возможно ли что-то технически в принципе, — например, подключение к системе или обработка определённого типа данных. MVP отвечает, приносит ли продукт реальную пользу реальным пользователям в реальном использовании, с минимально возможным набором функций.
Решите, какой вопрос стоит перед вами на самом деле. Если вы уже знаете, что идея востребована, а технология проверена, — пропустите первые два и переходите к MVP. См. SaaS MVP development, а если непонятно, для клиентов продукт или для собственной команды — SaaS MVP vs internal tool (на английском).
Почему эта дисциплина важна
Каждая функция, добавленная до проверки гипотезы, — это ставка, сделанная без данных о реальных пользователях. См. How Much Does a SaaS MVP Cost (на английском) о том, насколько напрямую эта дисциплина в объёме влияет на цену.
Частые вопросы
Что если я уже знаю, что биллинг понадобится рано или поздно?+
Знать, что понадобится рано или поздно, — не то же самое, что нуждаться в этом в первой версии: это можно заложить архитектурно, не строя прямо сейчас.
Разве узкий MVP не производит худшее первое впечатление?+
Для реальной проверки на реальных пользователях работающий узкий продукт лучше широкого, но недоделанного — см. What Happens When an AI Automation Fails о том же общем принципе: работающий узкий объём лучше широкого, но хрупкого.
Кто решает, что считать «ядром»?+
То, каким бы ни было самое важное действие пользователя, — решается совместно при скоупинге, а не берётся из общего шаблона.
Сайт и форма заявки — на русском, проект ведётся на английском. Русский как язык проекта мы не обещаем.