Фраза «MVP за две недели» вызывает у заказчиков два противоположных опасения. Первое: за две недели сделают что-то настолько сырое, что показывать клиентам будет стыдно. Второе: под словом MVP продадут полноценную разработку по цене полноценной разработки. Оба опасения обоснованы, потому что термином злоупотребляют. Разберём честно, что помещается в две недели работы небольшой команды, что сознательно выносится за скобки и по каким признакам понять, что срок нереален для вашей задачи.
Что такое MVP и чем он не является
MVP — минимальная версия продукта, которой уже можно пользоваться для решения одной реальной задачи. Ключевое слово — пользоваться: реальные клиенты или сотрудники, реальные данные, реальный результат. Не прототип для презентации, не кликабельный макет, не демонстрация «посмотрите, как будет».
При этом MVP — не урезанный до неузнаваемости продукт. Если бот для записи клиентов записывает, но не присылает подтверждения, им нельзя пользоваться — администратор всё равно будет звонить. Значит, подтверждение входит в минимум. А вот выбор мастера по фотографии, история посещений и бонусная программа — нет.
Граница проходит по вопросу: без чего продукт не выполняет свою единственную задачу? Всё, что отвечает «без этого можно», откладывается.
Что входит в первую версию обязательно
Независимо от типа продукта — бот, Mini App, агент, дашборд — в две недели входят пять слоёв.
Одна ключевая функция, доведённая до конца
Не три функции на 70%, а одна на 100%. Для бота обработки заявок — принять, квалифицировать, передать менеджеру. Для дашборда — показать пять согласованных метрик по данным из реальных систем. Для Mini App записи — выбрать время, записаться, получить подтверждение и напоминание.
Интеграции с реальными системами
Данные приходят из настоящей CRM, а не из тестовой таблицы. Заявки уходят живому менеджеру. Если интеграции нет, это демо, а не MVP. Обычно в первую версию входят одна-две интеграции, не больше.
Обработка ошибок и крайних случаев
Что происходит, когда клиент пишет не по сценарию, CRM недоступна, модель вернула неожиданный ответ. Для каждой ситуации — предсказуемое поведение, чаще всего передача человеку. Этот слой невидим, но именно он отличает рабочий продукт от прототипа.
Минимальная аналитика
Сколько людей воспользовались, сколько дошли до конца, где отвалились. Без этого через месяц невозможно решить, что делать дальше. Достаточно простого журнала событий и таблицы или сводки в Telegram.
Передача и инструкция
Доступы, короткая инструкция для команды, понимание, кто и как меняет настройки — например, тексты ответов или расписание. Если после запуска любое изменение требует разработчика, продукт не передан.
Что сознательно откладываем
Список того, что чаще всего просят включить в первую версию, и почему мы предлагаем подождать.
- Личные кабинеты и роли. Администратор, менеджер, руководитель с разными правами. В первой версии один тип пользователя, остальным хватит сводки в Telegram.
- Второй и третий канал. Telegram и WhatsApp и виджет на сайте одновременно. Начинаем с канала, где больше всего клиентов, остальные — после проверки сценария.
- Мультиязычность. Один язык, тот, на котором говорит основная аудитория. Второй язык добавляется за дни, когда сценарий устоялся, а не переписывается трижды вместе с ним.
- Фирменный дизайн. Аккуратный, понятный интерфейс на стандартных компонентах — да. Уникальная дизайн-система с анимациями — после того, как понятно, какие экраны вообще останутся.
- Оплата внутри продукта. Если можно первые недели выставлять счёт вручную или через ссылку — так и делаем. Платёжная интеграция тянет за собой возвраты, чеки и поддержку.
- Масштабирование. Архитектура под тысячу одновременных пользователей, когда их будет двадцать. Проектируем так, чтобы масштабирование было возможно, но не реализуем его заранее.
- Редкие сценарии. Всё, что случается реже раза в неделю, в первой версии обрабатывает человек.
- Сложная ИИ-логика. Мультиагентные схемы, долгосрочная память, самообучение. Один агент с понятными инструкциями закрывает большинство задач малого бизнеса.
Каждый из этих пунктов можно добавить позже, и почти всегда он добавляется в другом виде, чем представлялось в начале, — потому что две недели реальной работы продукта меняют понимание задачи.
Как выглядят две недели по дням
Ориентировочный ритм для проекта с одной ключевой функцией и одной-двумя интеграциями:
- Дни 1–2. Разбор задачи, фиксация границ: что входит, что нет. Доступы к системам клиента. Согласование сценария на бумаге — буквально текстом, кто что пишет и что происходит.
- Дни 3–4. Каркас: сервер, база, подключение к CRM или учётной системе, первый сквозной прогон «от входа до выхода» на тестовых данных.
- Дни 5–9. Основная функция, обработка ошибок, настройка ИИ-части, если она есть: инструкции модели, база знаний, проверка на реальных примерах.
- Дни 10–11. Тестирование с участием клиента на реальных кейсах. Правки по результатам — их всегда много, и это нормально.
- Дни 12–13. Аналитика, инструкция, передача доступов, обучение команды.
- День 14. Запуск на ограниченную аудиторию: одна точка, одна группа клиентов, один менеджер.
Главный риск для сроков — не разработка, а ожидание: доступов, ответов, решений по сценарию. Если клиент отвечает раз в три дня, две недели превращаются в пять.
Три MVP, которые помещаются в срок
Бот для обработки заявок. Принимает сообщения в Telegram, задаёт два-три уточняющих вопроса, определяет, целевой ли запрос, создаёт сделку в amoCRM с резюме и уведомляет менеджера. Не входит: WhatsApp, интеграция с календарём, автоматические ответы на вопросы о ценах по базе знаний.
Mini App для записи. Выбор услуги и времени из реального расписания, запись, подтверждение, напоминание за день. Не входит: выбор мастера, оплата, история, отзывы, бонусы. Как решить, нужно ли здесь вообще нативное приложение, разобрано в статье про выбор между приложением и Mini App.
Дашборд собственника. Пять метрик из CRM и учётной системы, обновляемые раз в сутки, со сводкой в Telegram каждое утро. Не входит: детализация до сотрудников, прогнозы, вопросы на естественном языке, подключение рекламы.
Во всех трёх случаях вторая версия — ещё две-три недели — добавляет то, что реально оказалось нужным по данным первых недель, а не по изначальному списку пожеланий.
Что нужно от заказчика
Срок держится только при участии клиента, и это участие стоит оценить заранее.
- Один человек, который принимает решения по сценарию и доступен ежедневно хотя бы на короткий созвон или ответ в чате.
- Доступы к системам в первые два дня, а не на второй неделе.
- Реальные примеры: десять-двадцать настоящих заявок, диалогов, документов для настройки и проверки.
- Готовность запуститься на ограниченной аудитории с несовершенным продуктом и смотреть на данные.
- Чёткое техническое задание, пусть короткое. Как его написать, не упустив главного, — в статье про ТЗ на AI-агента.
Где двух недель не хватит
Честный список признаков, при которых срок стоит сразу закладывать больше:
- Интеграция с «коробочной» 1С или самописной учётной системой без документированного API.
- Платежи с чеками и возвратами как обязательная часть первой версии.
- Нативное приложение под две платформы с публикацией в магазинах — одна только модерация может занять до недели.
- Требования к безопасности, при которых модель должна работать на вашем сервере, а инфраструктуры для этого нет.
- Процесс, который в компании ещё не устоялся: сначала нужно договориться, как он работает без автоматизации.
В таких случаях лучше сказать «четыре недели» и уложиться, чем обещать две и сорвать. Какие ещё ловушки поджидают при запуске, собрано в статье про ошибки автоматизации.
Итог
MVP за две недели — это не компромисс по качеству, а компромисс по объёму. Одна функция, работающая с реальными данными и реальными людьми, с обработкой ошибок и минимальной аналитикой, переданная команде. Всё остальное — осознанно позже и в том виде, который подскажут первые недели использования.
Мы в AiKrok работаем по этому принципу не из любви к коротким срокам, а потому что видели достаточно продуктов, полгода разрабатывавшихся «со всеми функциями» и оказавшихся ненужными в половине из них. Две недели — это цена ответа на вопрос, нужна ли вообще эта вещь вашим клиентам.