MVP за 14 дней позволяет проверить один рабочий сценарий до того, как компания вложится в большую систему. За две недели можно собрать функциональный срез процесса, развернуть его в согласованной инфраструктуре и дать реальным пользователям. Такой формат отвечает на практический вопрос: помогает ли решение выполнять работу быстрее, надёжнее или прозрачнее.
В эти сроки не помещается полная CRM, ERP или мобильная платформа со всеми интеграциями. Смысл подхода как раз в ограничении объёма. Команда выбирает один путь от входного события до результата, фиксирует критерий успеха и на четырнадцатый день принимает решение о дальнейшем развитии.
Как проходит двухнедельный пилот
Сценарий и критерий → Сборка и деплой → Работа пользователей → Решение о развитии
Для каких задач подходит MVP за 14 дней
Хороший кандидат уже существует в работе компании. Это может быть обработка заявки, бронь объекта, подготовка черновика документа, регистрация обращения поддержки или приём заказа на ограниченную группу товаров. Пользователи сейчас выполняют этот сценарий вручную или в неудобной системе, поэтому результат пилота можно сравнить с понятной исходной точкой.
Формат требует владельца процесса. Он отвечает на вопросы, выбирает пилотных пользователей и решает, какие исключения можно отложить. Если у задачи нет хозяина, разработчики будут угадывать правила, а две недели уйдут на согласование терминов.
- Есть один повторяемый процесс с понятным началом и результатом.
- Два-три пользователя готовы работать в пилоте на реальных данных.
- Можно сформулировать наблюдаемый критерий успеха.
- Основные доступы и источники данных доступны до старта.
- Заказчик готов отложить второстепенные роли и интеграции.
Стартап без пользователей и подтверждённого процесса тоже может сделать прототип, но такой проект проверяет скорее интерфейс или техническую возможность. Он не доказывает наличие спроса сам по себе.
Что не следует обещать за две недели
Полноценная CRM для отдела из 25 человек с аналитикой, финансами, Avito, ЦИАН и мобильным клиентом не является двухнедельным MVP. В кейсе «Мегаполис-Недвижимость» такая система разрабатывалась четыре месяца и сократила время на сделку на 30%. За 14 дней можно было бы проверить, например, единый статус объекта и запрет двойной брони. Подробнее: кейс CRM для недвижимости.
Производственную ERP также нельзя честно свести к короткому пилоту целиком. Склад, заказы, роли и интеграции затрагивают несколько участков. Первой проверкой может стать один тип заказа или отдельная складская операция, но результат нельзя выдавать за готовую систему предприятия.
В срок не стоит одновременно включать несколько платформ, сложный офлайн, полный дизайн, миграцию всех архивов и обучение всей компании. Каждое из этих направлений может быть нужно позже. В пилоте они мешают получить ответ на главный вопрос.
Готовый продукт иногда полезнее MVP
Проверка гипотезы не всегда требует нового кода. Если задача уже решена готовым продуктом и его модель подходит процессу, быстрее провести внедрение. Например, КонтрактПРО формирует договоры, счета и акты из шаблонов и единого источника реквизитов. Договор занимает 2–5 минут вместо 20–40, пакет 5–15 минут вместо 1–2 часов.
Коробка также выигрывает, когда процесс типовой и команда согласна с её правилами. Заказная разработка нужна, если готовые поля вынуждают сотрудников возвращаться к таблицам. Принцип выбора подробнее разобран в материале о разработке ПО на заказ.
Для селлера пилот может заключаться в запуске собственной витрины рядом с Ozon, Wildberries и Яндекс Маркетом. Площадки не требуется отключать в первый день. Сценарий прямых продаж и обмена с учётной системой описан на странице ecommerce.
Как распределяются четырнадцать дней
В начале команда фиксирует сценарий, роли, данные и критерий результата. Формулировка должна быть проверяемой: заявка получает ответственного, бронь не дублируется, документ создаётся из утверждённых реквизитов. Субъективное «стало удобнее» полезно как обратная связь, но его недостаточно для решения об инвестициях.
Основная часть срока уходит на разработку и ранний деплой. Пользователь должен увидеть рабочую версию до последнего дня, чтобы успеть пройти сценарий и обнаружить неверные предположения. Headline включает в цикл серверную часть и мониторинг, поскольку пилот на ноутбуке разработчика не показывает реальную эксплуатацию.
- Дни 1–2: границы сценария, роли, критерий и доступы.
- Дни 3–9: сборка основной логики и развёртывание.
- Дни 10–13: работа пилотной группы, наблюдения и обязательные исправления.
- День 14: разбор результата и письменная развилка.
Если данные нельзя передавать внешнему облаку, среду готовят On-Premise. Это решение принимают до старта, чтобы не переносить пилот сразу после проверки. Инфраструктурные требования и обслуживание серверов входят в обсуждение вместе с приложением.
Каким должен быть критерий успеха
Критерий связан с фактом работы, а не с количеством экранов. Для внутренней поддержки это может быть доля заявок, которые получили ответственного и не потерялись в чате. Для CRM: прохождение сделки без дублирования карточки. Для документов: создание корректного черновика из утверждённого шаблона.
Полезно заранее определить и отрицательный результат. Если пользователи обходят систему, данные недоступны или экономия не подтверждается, проект можно остановить либо изменить подход. Честная остановка после двух недель также является ценным результатом: компания не тратит месяцы на неверную гипотезу.
После успешной проверки формируется очередь развития. В неё входят новые роли, интеграции, отчёты и требования к надёжности. На этом этапе пилот становится обычным проектом, которому нужны приоритеты, резервные копии и сопровождение после запуска.
Частые ошибки короткого пилота
Первая ошибка состоит в попытке спрятать большой проект под названием MVP. Слишком широкий объём приводит либо к срыву срока, либо к демонстрационному макету, который нельзя использовать. Вторая ошибка связана с тестовыми данными: на них легко показать красивый путь, но невозможно проверить реальные исключения.
Третья ошибка возникает, когда пользователи подключаются только к финальной демонстрации. В таком случае команда узнаёт о неверных правилах слишком поздно. Четвёртая ошибка: отсутствие решения на пятнадцатый день. Если пилот остаётся без владельца и очереди работ, он быстро теряет актуальность.
Наконец, MVP не заменяет организационные изменения. Программа не назначит владельца процесса, не создаст спрос и не заставит отдел соблюдать статусы. Она даёт инструмент и проверяемые данные для управленческого решения.
Частые вопросы
Что считается функциональным MVP?
Рабочий срез одного процесса, который пользователи могут пройти на реальных данных от начала до результата.
Можно ли сделать CRM за 14 дней?
Можно проверить узкую воронку или один тип сделки. Полная CRM с несколькими интеграциями и аналитикой требует отдельного проекта.
Кто участвует со стороны заказчика?
Владелец процесса и два-три будущих пользователя. Они дают правила, данные и обратную связь во время пилота.
Можно ли разместить пилот на своих серверах?
Да. Возможен On-Premise-деплой, если данные должны оставаться в инфраструктуре компании.
Что происходит на пятнадцатый день?
Заказчик получает результат проверки и выбирает развитие, изменение подхода, готовый продукт или остановку проекта.
Чтобы обсудить пилот, напишите на welcome@headln.ru. Опишите один сценарий, его пользователей, источник данных и вопрос, на который нужно ответить через 14 дней.