MVP продукта с ИИ: как проверить один сценарий до разработки

MVP продукта отвечает на один вопрос: сработает ли конкретный поток в реальной работе, а не «понравится ли идея». Эрик Рис формулирует это как validated learning с минимальным усилием - максимум знаний о клиенте при минимальных затратах. Минимальный продукт mvp в моей практике - не урезанное ТЗ на 40 страниц, а один операционный сценарий с критерием «готово».

На разборе идеи я уже отделил боль от фич. Следующий шаг - проверить, что цепочка держится на живых заявках. Типичный запрос: «нужен бот + CRM + аналитика». Открываю переписку - 80% боли в одном месте: заявка из Telegram доходит до менеджера с задержкой или теряется. Остальное - отложенный scope. MVP фиксирует именно этот поток.

Concierge-паттерн из Lean Startup здесь уместен: первые дни процесс может идти вручную за кулисами, пока вы смотрите на поведение, а не на красоту интерфейса. Владелец салона пересылает сообщения в общий чат, админ вносит строку в таблицу - это уже MVP, если есть гипотеза и метрика потерь. Код подключите позже, когда сигнал подтвердится.

Я не смешиваю этот этап с пилотом приложения с ИИ: там разработка после согласованных критериев. Здесь - до первого заказа разработки. Если ручной процесс устраивает и заявки не теряются, честный исход - «код не нужен», и это нормально.

Этапы mvp продукта - короткая цепочка, которую я прохожу с владельцем бизнеса на наставничестве, пока не появится измеримый сигнал. Создание mvp продукта не растягиваю на квартал: один цикл на один риск.

1. 01

   Сформулировать гипотезу - что именно должно измениться в операции.

2. 02

   Описать один сценарий: кто инициирует, что происходит, где фиксируется результат.

3. 03

   Задать критерий готовности с порогом - число, срок, допустимые потери.

4. 04

   Записать anti-scope - что сознательно не делаем в этом цикле.

5. 05

   Прогнать на реальных заявках или клиентах, не на демо-аккаунтах.

6. 06

   Зафиксировать исход: масштабируем, меняем гипотезу или останавливаемся.

Разработка mvp продукта в смысле «заказать код» - шестой шаг, не первый. Пока критерий не выполнен на живых данных, ТЗ для подрядчика преждевременно: вы оплатите реализацию гипотезы, которую ещё не проверили.

Гипотеза: формулировка, которую можно опровергнуть

Плохо: «клиентам будет удобнее с ботом». Хорошо: «если заявка из Telegram попадает в таблицу ответственного за 3 минуты без ручного копирования, ночные обращения перестанут теряться до утра». Гипотеза должна иметь противоположный исход - иначе это пожелание, а не проверка.

Сценарий: один поток от входа до записи

Сценарий пишу в настоящем времени, как инструкцию для нового сотрудника. Пример для услуг: клиент пишет в бот → бот задаёт два уточняющих вопроса → менеджер получает уведомление в рабочий чат → строка появляется в Google Sheets или CRM. Всё. Без личного кабинета, без оплаты, без отчётов.

Метрика и anti-scope

Метрика привязана к потерям или задержкам, не к «удобству». Anti-scope - список того, что откладываем: интеграция с 1С, мультиязычность, админка с графиками. Без anti-scope MVP раздувается до мини-продукта за две недели.

MVP scorecard - четыре поля, которые я заполняю до любого прототипа. Это рабочий шаблон, не отчёт для инвестора. На разборе scorecard лежит в одном файле рядом с перепиской клиента - чтобы не путать «идею» и «проверку».

Критерий «5 заявок без потерь за неделю» - мой рабочий шаблон для SMB-услуг, не рыночная статистика. У вас может быть другой порог: 10 заявок, 3 минуты до ответа, ноль дублей в CRM. Главное - согласовать порог до старта, а не после «вроде работает».

Пример сценария: заявка Telegram → уведомление → CRM/таблица

Разберу поток, который чаще всего проверяю на MVP:

1. 01

   Клиент пишет в Telegram-бот (или в Business-чат, если бот ещё не готов).

2. 02

   Система или админ фиксирует имя, услугу и желаемое время.

3. 03

   Менеджер получает push в рабочий чат с ссылкой на карточку.

4. 04

   Строка появляется в таблице или CRM с меткой времени и статусом «новая».

5. 05

   Менеджер меняет статус на «в работе» в течение N минут.

На этапе concierge шаги 2-4 могут быть ручными. MVP всё равно валиден, если гипотеза про потери, а не про скорость разработки.

Критерий готовности: 5 заявок без потерь за неделю

Я использую этот порог как стартовый для салонов и студий с 20-40 заявками в неделю. «Без потерь» значит: каждая входящая заявка имеет запись в учёте и ответственного. Если из пяти две «зависли» в личке владельца - гипотеза не подтверждена, меняем сценарий, а не заказываем красивый фронт.

Что сознательно не делаем в этом цикле

Anti-scope защищает от раздувания. Типичный список для первого цикла:

• Онлайн-оплата и чеки.
• Личный кабинет клиента.
• Отчёты и дашборды для руководителя.
• Синхронизация с 1С или МойСклад.
• Мультиканальность (WhatsApp, VK, сайт) - только Telegram.

Если заказчик настаивает на пункте из anti-scope - это уже другой проект, не MVP текущей гипотезы.

Шаблон scorecard для копирования:

hypothesis: "Ночные заявки из Telegram не теряются до 10:00 следующего дня"
scenario:
  trigger: "Клиент пишет в бот после 21:00"
  steps:
    - "Бот собирает имя, услугу, желаемое время"
    - "Менеджер получает уведомление в рабочий чат"
    - "Строка появляется в Google Sheets с меткой created_at"
  owner: "Администратор салона"
done_criterion: "5 реальных заявок подряд без потерь за 7 календарных дней"
anti_scope:
  - "Онлайн-оплата"
  - "Личный кабинет"
  - "Интеграция с 1С"
  - "Аналитика и дашборды"
notes: "Критерий 5/7 - рабочий шаблон Петра, не бенчмарк рынка"

Тот же scorecard в JSON - удобно хранить рядом с репозиторием пилота:

{
  "hypothesis": "Ночные заявки из Telegram не теряются до 10:00",
  "scenario": {
    "trigger": "Сообщение клиента в бот после 21:00",
    "steps": ["сбор полей", "уведомление менеджеру", "запись в таблицу"],
    "sink": "Google Sheets / CRM"
  },
  "done_criterion": "5 реальных заявок без потерь за 7 дней",
  "anti_scope": ["оплата", "ЛК", "1С", "дашборды"]
}

Разработка mvp продукта с ИИ ускоряет черновик, но не снимает проверку сценария. Cursor, n8n и конструкторы ботов помогают собрать webhook за вечер - и это ловушка, если scorecard пустой. MVP с ии в моём понимании - когда ИИ ускоряет сборку проверяемого потока, а критерий готовности остаётся человеческим и измеримым.

NIST в профиле рисков generative AI называет confabulation - уверенно ложный контент - отдельным риском при решениях с последствиями. Агент может сгенерировать «рабочий» обработчик webhook, который теряет поля или пишет не в ту таблицу. Поэтому до продакшена я проверяю: логирование каждого входящего Update, human-fallback при сбое, ограниченный набор действий агента.

Что фиксирую до первой строки кода

• Scorecard заполнен и согласован с владельцем процесса.
• Telegram webhook: HTTPS, secret_token в заголовке X-Telegram-Bot-Api-Secret-Token, SSL на endpoint.
• setWebhook и long polling getUpdates не смешиваются - только один способ доставки.
• Таблица или CRM: какие поля обязательны, кто меняет статус.
• Лог ошибок и алерт, если запись не создалась за 60 секунд.

Минимальный псевдокод обработчика - ориентир для разработки или для Agent в Cursor:

# webhook_handler.py - псевдокод, не production
import hmac, hashlib, json
from datetime import datetime

SECRET = os.environ["TG_WEBHOOK_SECRET"]

def verify_telegram(request):
    token = request.headers.get("X-Telegram-Bot-Api-Secret-Token", "")
    return hmac.compare_digest(token, SECRET)

def handle_update(update: dict):
  msg = update.get("message") or update.get("business_message")
  if not msg or not msg.get("text"):
    return {"ok": True}
  row = {
    "telegram_id": msg["from"]["id"],
    "text": msg["text"],
    "created_at": datetime.utcnow().isoformat(),
    "status": "new"
  }
  sheet.append_row(row)          # или crm.create_lead(row)
  notify_manager(row)            # push в рабочий чат
  log.info("lead_saved", extra=row)
  return {"ok": True}

Cursor: черновик scorecard и handler, не замена проверки

В Cursor я начинаю с Ask: прошу разобрать текущий процесс по переписке и предложить поля scorecard. Потом одна задача в Agent - файл scorecard.yaml и скелет webhook_handler.py с тестовым payload. Смотрю diff, прогоняю три тестовых Update вручную, только после этого подключаю реальный бот.

Промпт, который использую на разборе:

Контекст: MVP одного сценария - заявка из Telegram в таблицу.
Есть scorecard.yaml с hypothesis, scenario, done_criterion, anti_scope.

Задача для Agent:
1. Прочитай scorecard.yaml.
2. Создай webhook_handler.py: проверка secret_token, разбор message.text,
   запись в sheets_client.append_row с полями из scenario.steps.
3. Добавь log при ошибке записи и TODO human-fallback.
Не добавляй оплату, ЛК и интеграции из anti_scope.
Покажи diff перед сохранением.

ИИ не подтверждает, что гипотеза верна - только ускоряет черновик. Подтверждение - пять реальных заявок по критерию scorecard. Подробнее про операционный поток - в материале про автоматизацию заявок.

Ошибки при создании mvp продукта обычно не в методологии Ries, а в спешке к коду и в размытом scope. Ниже - симптомы, которые вижу на разборах, и конкретные исправления.

Весь ТЗ упаковали в MVP

Симптом: в «минимальной версии» уже оплата, ЛК, три интеграции и «потом добавим ИИ-аналитику». Сроки растут, критерий готовности размыт. Фикс: вернуться к scorecard, оставить один сценарий и anti-scope на одной странице. Всё остальное - backlog после выполнения done_criterion.

Демо без реальных пользователей

Симптом: бот протестирован на аккаунтах команды, «всё работает», живых заявок нет. Фикс: неделя на реальном канале с согласованным критерием потерь. Concierge допустим - ручная пересылка в чат - но заявки должны быть настоящими.

Агент в ноутбуке без прод-метрики

Симптом: в Cursor собран красивый handler, в чате пишут «готово», в таблице пусто или дубли. Фикс: лог каждого Update, проверка secret_token, тестовый прогон + 5 живых заявок по scorecard. Песочница агента - не MVP.

Vanity-метрики вместо потерь заявок

Симптом: считают открытия бота, клики по кнопкам, «вовлечённость», а потерянные ночные сообщения не измеряют. Фикс: одна операционная метрика - время до записи в учёт, доля заявок без ответственного, число потерь за неделю. UI-метрики - после подтверждения потока.

Нет human-fallback при сбое

Симптом: webhook упал ночью, клиенты пишут в пустоту. Фикс: алерт ответственному, резервный канал (пересылка в чат админа), инструкция «если бот молчит - звоните». Guardrails для агента описаны в любом вменяемом agent MVP - ограниченные tools, логи, эскалация человеку.

MVP бизнес продукта готов к передаче в разработку, когда scorecard выполнен на реальных данных, а не когда «демо понравилось». Я смотрю на четыре сигнала.

1. 01

   done_criterion достигнут или провален осознанно - есть цифры, не ощущения.

2. 02

   Anti-scope согласован: заказчик понимает, что оплата и аналитика - следующий инкремент.

3. 03

   Сценарий описан так, что разработчик может написать ТЗ на один поток без чтения всей переписки.

4. 04

   Понятна цена ошибки: что будет, если webhook снова упадёт ночью.

Прототип mvp продукт в виде таблицы и ручных шагов - нормальный вход в разработку проектов. Mvp версия продукта с кодом - следующий слой: стабильный webhook, права доступа, резервное копирование логов. Не наоборот.

Что передаю подрядчику или в свой репозиторий:

• Файл scorecard (yaml/json) с финальными формулировками.
• Примеры реальных заявок (обезличенные) и тайминги.
• Список полей таблицы или CRM и правила статусов.
• Anti-scope и явный «следующий инкремент» после v1.
• Логи сбоев, если были - чтобы не повторить.

Если критерий не выполнен две недели подряд при достаточном потоке заявок - это тоже сигнал. Либо гипотеза слабая, либо сценарий неверный, либо сегмент не тот. Разработка минимального жизнеспособного продукта mvp не спасёт неверную гипотезу - только ускорит её похороны с инвойсом.

Если у вас заявки живут в Telegram, а учёт - в таблице или CRM, начните с одного scorecard на неделю. Я помогу сформулировать гипотезу, критерий без потерь и anti-scope до заказа кода. Разбор процесса - на наставничестве, реализация пилота - в разделе разработка проектов.

По теме в блоге: как проверить идею проекта - шаг до MVP; создание приложения с помощью ИИ - пилот после валидации; автоматизация заявок - разбор операционного потока.