MVP не спас бизнес. Он лишь зафиксировал ошибку за миллион
В исходном кейсе MVP подаётся как спасение бюджета: 4 недели, ~900 тыс. ₽ — и стало ясно, что «ключевая фича» никому не нужна. Проект якобы сэкономил клиенту миллионы.
Как бизнес-аналитик, я не могу пройти мимо этого вывода молча.
Потому что в этой истории MVP выполнил роль бизнес-анализа — но в самой дорогой, медленной и рискованной форме.
Что здесь на самом деле произошло
Если убрать маркетинговую обертку, кейс звучит так:
- была гипотеза о ценности функции;
- ее не проверяли до разработки;
- вместо аналитики сразу пошли в код;
- через месяц и почти миллион рублей узнали, что пользователи ей не пользуются.
Это не «успех MVP». Это позднее обнаружение неверного предположения.
Почему это принципиально важно
MVP — это инструмент проверки решений. Бизнес-анализ — инструмент снижения вероятности ошибки.
В этом кейсе:
- не показано анализа процессов (или хотя бы упоминания об этом!);
- нет упоминания об описании реальные сценариев принятия решений менеджеров;
- не видно работы с болями и ограничениями пользователей;
- гипотеза о «ключевой фиче» взялась, судя по всему, из убежденности, а не из данных.
Именно поэтому MVP пришлось использовать как замену аналитики.
Что можно было сделать раньше и дешевле
До MVP, без строчки кода, можно было ответить на ключевые вопросы:
- В каких моментах менеджеры реально принимают решения?
- Какие данные они используют сейчас и как именно?
- Что они делают вручную и почему?
- Какие решения откладывают и по какой причине?
- Что для них сигнал, а что — шум?
Это классическая аналитическая работа:
- интервью;
- разбор AS-IS процессов;
- картирование решений;
- выявление точек ценности.
Стоимость — на порядок ниже, чем 900 тыс. Результат — понимание, какие гипотезы вообще стоит проверять в MVP.
В чем подмена понятий
В тексте звучит мысль:
«Мы сэкономили деньги, потому что не зафиксировали гипотезу как истину»
На самом деле деньги сэкономили потому что вовремя остановились. Но это не отменяет факта: гипотеза была слишком грубой, и ее можно было уточнить до начала разработки.
MVP здесь не «умный ход». Это финальная страховка от отсутствия аналитики.
Опасный вывод, который могут унести читатели
Самый рискованный месседж этого кейса:
«Не надо анализировать — давайте быстрее делать MVP»
Это прямой путь к тому, чтобы проверять очевидные вещи через код, тратить сотни тысяч на то, что видно из разговоров и превращать MVP в замену мышления.
Корректная модель выглядит иначе
Правильная связка не «аналитика или MVP», а:
- Бизнес-анализ — снижает неопределенность, отсекает слабые гипотезы, формирует поле решений.
- MVP — проверяет оставшиеся гипотезы, минимизирует стоимость ошибки, дает данные для масштабирования.
Когда MVP делают вместо аналитики, он становится самым дорогим способом подумать.
Итог
Этот кейс — полезный. Но не как доказательство силы MVP.
А как напоминание: если вы узнали, что «ключевая фича не нужна», уже после разработки MVP — значит, аналитика в проекте началась слишком поздно.
MVP снижает стоимость ошибки в разработке. Бизнес-анализ снижает вероятность самой ошибки.
И путать эти роли — дорого.