MVP и продукты
MVP и SaaS-продукты
Проверка гипотезы рабочим продуктом за ограниченный срок.
Состав работ
MVP нужен, чтобы проверить спрос рабочим продуктом, а не презентацией. До начала разработки фиксируем объём первой версии: функции, необходимые для проверки гипотезы и запуска с первыми пользователями. Всё, что не влияет на проверку, выносится за рамки первой версии — иначе срок растягивается, а гипотеза всё равно остаётся непроверенной.
Работу ведём этапами с демонстрацией результата каждую неделю; состав работ согласуется до начала этапа. Вы видите работающие части продукта, а не отчёт о ходе работ.
По завершении передаём продукт в промышленную эксплуатацию: инфраструктура, мониторинг, доступы, план развития. Архитектура закладывается с запасом, чтобы после подтверждения гипотезы продукт можно было наращивать, а не переписывать.
Чем MVP отличается от прототипа
| Прототип | MVP | |
|---|---|---|
| Что проверяет | Понятность интерфейса | Готовность платить и пользоваться |
| Кто видит | Команда и тестировщики | Реальные пользователи |
| Данные | Демонстрационные | Настоящие, с учётом ошибок |
| Что даёт | Обратную связь по дизайну | Ответ, стоит ли развивать продукт |
Прототип полезен, но он не заменяет MVP: одобрение макета не означает, что люди будут пользоваться продуктом.
Что входит в работу
- Гипотеза и объём: что проверяем и по какому показателю поймём, что получилось.
- Прототип и архитектура: пользовательские сценарии, схема данных, выбор стека.
- Разработка итерациями с регулярными демонстрациями и сборками.
- Инфраструктура: развёртывание, домен, сертификат, резервное копирование.
- Аналитика: подключение измерений, чтобы решения принимались по данным.
- Передача: документация, доступы, план дальнейшего развития.
Что влияет на срок
- Число ролей пользователей. Каждая роль — отдельный набор экранов и прав.
- Внешние интеграции. Платежи, рассылки, сторонние сервисы требуют времени на подключение и тестирование.
- Требования к безопасности. Персональные данные и платежи добавляют работу.
- Скорость обратной связи. Проект идёт быстрее, когда решения принимаются в течение дня, а не недели.
Смежные задачи
Материал по теме — MVP: как проверить гипотезу за несколько недель. Если продукт уже работает и требует сопровождения — поддержка и развитие.
Полезные материалы
Результат для заказчика
- Сжатые сроки до первого релиза
- Фиксированный объём работ этапа
- Архитектура, пригодная для развития
Этапы
-
01
Гипотеза и объём
Формулируем, что именно проверяем и по какому показателю поймём, что гипотеза работает. Из этого выводим минимальный набор функций: всё, что не влияет на проверку, выносится за рамки первой версии.
-
02
Прототип и архитектура
Проектируем пользовательские сценарии и схему данных, выбираем стек. Архитектура закладывается с запасом на развитие, чтобы после подтверждения гипотезы продукт можно было наращивать, а не переписывать.
-
03
Разработка
Реализуем итерациями с регулярными демонстрациями: вы видите работающие части продукта, а не отчёт о ходе работ. Каждая итерация заканчивается сборкой, которую можно показать пользователям.
-
04
Запуск и измерения
Разворачиваем продукт, подключаем аналитику и первые интеграции, наблюдаем за поведением пользователей. Дальше развитие идёт по фактическим данным: что используют, где отваливаются, за что готовы платить.
FAQ
Что входит в MVP?
Только то, что необходимо для проверки гипотезы: ключевой сценарий пользователя, минимально достаточный интерфейс, схема данных и способ оплаты или регистрации, если это часть проверки. Всё остальное — админские удобства, редкие сценарии, автоматизация внутренних процессов — выносится во вторую версию.
Сколько времени занимает разработка MVP?
Обычно от двух до восьми недель. Срок определяется числом пользовательских сценариев и сложностью интеграций. Мы стараемся сокращать первую версию до предела: чем быстрее продукт попадёт к пользователям, тем раньше станет ясно, нужно ли его развивать.
Можно ли развивать MVP дальше?
Да, и архитектура закладывается именно с этим расчётом. Мы не делаем одноразовых прототипов, которые приходится выбрасывать: код, схема данных и инфраструктура рассчитаны на рост нагрузки и добавление функций без переписывания с нуля.
Что делать, если гипотеза не подтвердится?
Это нормальный результат проверки — он экономит месяцы работы над ненужным продуктом. В таком случае мы разбираем данные, формулируем уточнённую гипотезу и переиспользуем то, что осталось полезным: инфраструктуру, интеграции, части интерфейса.
Кому принадлежит код и данные?
Заказчику. Мы передаём исходный код, доступы и документацию, а также разворачиваем продукт на вашей инфраструктуре или помогаем её подготовить. Никакой зависимости от нашей команды в вопросах владения продуктом нет.