MVP, прототип и Proof of Concept: в чём разница
Основы3 минРедакция Innovialabs
Коротко
PoC проверяет, возможно ли это технически, прототип — понятно ли и удобно ли это пользователю, а MVP — готовы ли люди реально пользоваться продуктом и платить за него.
Короткий ответ
Все три формата нужны, чтобы снизить риск до больших вложений, но отвечают они на разные вопросы:
- Proof of Concept (PoC) — «Можно ли это вообще сделать технически?»
- Прототип — «Как это будет выглядеть и понятно ли пользователю?»
- MVP — «Будут ли люди этим пользоваться и платить?»
Путать их опасно: можно потратить бюджет на красивый прототип, когда главный риск был технический, или собрать MVP, не проверив, что ключевая технология вообще работает.
Сравнение в одной таблице
| Proof of Concept | Прототип | MVP | |
|---|---|---|---|
| Главный вопрос | Реализуемо ли? | Удобно ли? | Нужно ли рынку? |
| Аудитория | Команда, технический директор, инвестор | Пользователи на тестах, заказчик | Реальные пользователи |
| Что это физически | Кусок кода, скрипт, эксперимент | Кликабельный макет или упрощённая сборка | Работающий продукт |
| Можно ли пользоваться | Нет | Только в сценарии теста | Да |
| Относительная стоимость | Обычно низкая | Низкая или средняя | Самая высокая из трёх |
| Что остаётся после | Вывод «да/нет» и знание | Утверждённый UX и дизайн | Продукт и данные о пользователях |
Стоимость и сроки каждого формата зависят от сложности задачи, поэтому сравнивать их корректно только относительно друг друга.
Proof of Concept: когда главный риск — технология
PoC — это небольшой эксперимент, который доказывает, что идея технически осуществима. Интерфейса обычно нет, красоты тоже.
Когда нужен:
- вы хотите использовать новую технологию, например распознавание документов или LLM, и не уверены в качестве результата;
- нужно интегрироваться с внешней системой, у которой неясное или закрытое API;
- есть сомнения в производительности: выдержит ли решение нужный объём данных.
Пример. Компания хочет автоматически вытаскивать данные из сканов накладных. Прежде чем делать сервис, команда за короткое время проверяет на реальных сканах, насколько точно это получается.
Прототип: когда главный риск — пользователь
Прототип показывает, как продукт будет работать для человека. Чаще всего это кликабельный макет в Figma, по которому можно пройти основные сценарии.
Когда нужен:
- сложный пользовательский путь: оформление заказа, онбординг, личный кабинет;
- нужно согласовать видение между заказчиком, дизайнером и разработчиками;
- хочется показать идею инвестору или первым клиентам до разработки.
Пример. Сервис записи к врачу: на прототипе пользователи проходят путь «выбрать врача — выбрать время — подтвердить», а команда видит, где люди путаются.
MVP: когда главный риск — рынок
MVP — это уже настоящий продукт с минимальным набором функций. Им пользуются реальные люди в реальных условиях.
Когда нужен:
- технология понятна, интерфейс проверен;
- осталось выяснить, будут ли люди возвращаться и платить;
- нужны данные для решений о развитии или для привлечения инвестиций.
Пример. Тот же сервис записи запускается для нескольких клиник, и команда измеряет, сколько записей проходит через него и сколько пользователей возвращается.
Как выбрать: короткий чек-лист
- Есть сомнения, что это технически возможно? Начните с PoC.
- Технология понятна, но сложный интерфейс? Сделайте прототип.
- И то и другое понятно? Переходите к MVP.
- Проект простой и типовой (например, интернет-магазин)? PoC обычно не нужен, а прототип можно сделать облегчённым.
Форматы часто идут последовательно: PoC снимает технический риск, прототип — риск удобства, MVP — рыночный.
Частые ошибки
- Выдавать прототип за MVP. Красивый макет показывает интерес, но не доказывает, что люди будут пользоваться продуктом.
- Превращать PoC в продакшн. Код эксперимента пишется быстро и без расчёта на нагрузку и безопасность.
- Пропускать прототип в сложных продуктах. Переделывать интерфейс в готовом коде заметно дороже, чем в макете.