Как проверить идею цифрового проекта до разработки

Код - пассив с обслуживанием: его нужно деплоить, чинить, защищать и объяснять команде. Проверка идеи до разработки отвечает на один вопрос: есть ли боль в конкретном процессе и готов ли кто-то платить временем или деньгами за её закрытие. Я не про «генерацию идей» и не про стартап-питч - про одну операционную дыру: заявка из Telegram, запись клиента, перенос в CRM.

На разборе чаще всего приходит запрос «соберите бота за выходные». Открываю переписку - заявки живут в личном чате владельца, менеджер копирует их в таблицу вечером, ночные сообщения висят до утра. Идея «бот + CRM» звучит логично, но без проверки непонятно, что считать успехом: скорость ответа, отсутствие дублей или запись в учёт за N минут. Пока критерий не записан, любой прототип - демо ради демо.

CustDev, как описывает Kokoc со ссылкой на Стив Бланка, идёт в порядке: сначала проблема, потом как решают сейчас, и только потом продукт. Для ИП и малого бизнеса это не венчурная история - та же логика при падении конверсии или новом сегменте, как пишут в ADPASS про проблемные интервью.

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

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

1. 01

   Выбрать один операционный сценарий (не «весь бизнес»).

2. 02

   Сформулировать гипотезу и метрику «сработало/нет».

3. 03

   Провести 5-10 problem-solution интервью с людьми из сегмента.

4. 04

   Заполнить Lean canvas на этот сценарий и обновить после интервью.

5. 05

   Выбрать эксперимент: concierge-ручной шаг, лендинг, прототип или узкий пилот.

Ниже - разбор шагов 2-4 с шаблонами. Шаг 5 пересекается с блоком про тестирование гипотез и готовность к пилоту.

Сформулировать гипотезу и метрику успеха

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

Шаблон, который я фиксирую в начале разбора:

{
  "hypothesis": "Владелец салона теряет записи, когда клиент пишет в личный Telegram после 21:00",
  "metric": "доля заявок с меткой «ночь», попавших в учёт до 10:00 следующего дня",
  "threshold": "≥ 90% за 7 дней пилота при ≥ 20 заявках",
  "segment": "салон 2-4 мастера, заявки в Telegram + звонки",
  "experiment": "concierge: админ пересылает в общий чат + строка в таблице по шаблону"
}

Порог threshold согласую заранее. Без него пилот превращается в «вроде работает».

Problem-solution interview: шаблон на 5 вопросов

Интервью - не опрос «понравилось бы». Mom Test (Prime IT) требует спрашивать о прошлом опыте: что уже делали, сколько времени ушло, чем пользовались. На узкую гипотезу - 5-7 разговоров, на сегмент - до 12-15 до насыщения (Kokoc); для SMB по одному сценарию часто хватает 5-10 (ADPASS).

Не спрашиваю: «Вам было бы интересно, если бот…» - это ломает валидацию.

MVP canvas без полноценной разработки

Lean Canvas (Prime IT) - девять блоков на одной странице. Заполняю в порядке: проблема, сегмент, уникальная ценность, решение - ближе к концу. Каждый блок - гипотеза, канвас обновляю после интервью.

1. Проблема (топ-3): заявки теряются в личном Telegram; нет единого статуса; дубли в таблице
2. Сегмент: ИП услуги, 1-3 человека принимают заявки
3. Уникальная ценность: заявка в учёте за 3 мин без копипаста
4. Решение (гипотеза): бот-квалификатор + webhook в таблицу (после проверки)
5. Каналы: текущий Telegram, сарафан
6. Потоки дохода: удержание клиентов, не новый продукт
7. Структура затрат: время админа, позже - разработка пилота
8. Ключевые метрики: % заявок в учёте за 3 мин; время первого ответа
9. Несправедливое преимущество: знание своего процесса (пока слабое - честно)

Решение в пункте 4 - гипотеза, не заказ разработке. Сначала concierge или таблица, потом код.

Тестирование гипотезы продукта - это не статистика A/B на миллионе пользователей. Для малого бизнеса я выбираю метод по риску гипотезы, как в цепочке Prime IT: canvas → custdev → landing → MVP.

Для B2B с высоким чеком чаще уместен concierge: процесс делают вручную или в таблице, пока не подтверждён сценарий. Для заявок из мессенджеров ближе пилот одного потока - как в автоматизации заявок, но только после интервью.

Критерии остановки записываю до эксперимента. Пример: «если из 8 интервью меньше 4 описали потерю заявки за последний месяц - гипотеза слабая, меняем сегмент или формулировку». Это дисциплина, а не пессимизм.

ИИ в тестировании гипотез помогает оформить вопросы и канвас, но не подтверждает спрос. Habr про вайбкодинг в проде напоминает: ускорение кода не снимает ответственность за безопасность. PADEZHNOV добавляет: happy path в прототипе не равен бизнес-валидности - валидация ввода и авторизация не появятся без явного требования.

На одном разборе заказчик уже собрал «рабочий» бот в конструкторе. Спросил про последнюю заявку - оказалось, менеджер по-прежнему переписывает данные в Excel, потому что в боте нет поля «услуга». Тест гипотезы провалился не из-за кода, а из-за поля в сценарии.

Как проверить идею бизнеса без фантазий о «рынке в целом»: найти плательщика и единицу ценности. Плательщик - не всегда конечный клиент; иногда это владелец, который платит своим временем администратора.

Четыре индикатора реальной потребности из custdev-практики (Prime IT):

• Уже тратит время или деньги на обходной путь (таблица, напоминания, второй телефон).
• Описывает последствия: потерянный клиент, штраф, срыв записи, конфликт в чате.
• Сам поднимает проблему до того, как вы предложили решение.
• Готов на тестовый шаг: дать доступ к чату, вести учёт неделю по вашему шаблону.

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

Эпизод из практики: студия маникюра, идея «бот записи». В интервью с администратором выяснилось, что 70% записей - переносы и уточнения, а не новые клиенты. Гипотеза сместилась: не «бот записи», а «единый статус переноса в учёте». Плательщик - владелец, который платит зарплатой времени на переписку. Без этого разговора ушли бы в разработку неверного сценария.

Валидация идеи здесь - не слайд для инвестора. Это ответ: «за что конкретно готовы отдать деньги или неделю пилота». Связка с картой AI-автоматизации: если процесс не описан и цена ошибки неясна, автоматизация рано даже при горячем желании «сделать бота».

Ошибки при проверке идеи проекта обычно не в методологии, а в спешке к коду. Ниже - что ломает пилот и как чинить.

Друзья вместо целевой аудитории

Симптом: пять восторженных отзывов от знакомых, ни одного разговора с теми, кто реально ведёт заявки. Фикс: список из 10 людей в сегменте (конкуренты не нужны - коллеги по нише, клиенты смежных услуг), cold outreach с просьбой о 20 минутах про последний эпизод.

Фичи до подтверждённой боли

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

Пилот без метрик

Симптом: «запустили бота, клиенты довольны» без цифр. Фикс: критерий приёмки текстом до пилота:

Пилот принят, если:
- заявка из Telegram попадает в таблицу или CRM за ≤ 3 минут без потерь;
- ответственный получает уведомление в тот же канал;
- за 7 дней ≥ 20 реальных заявок, ручной перенос ≤ 2 из 20;
- исключения (звонок, нестандарт) описаны и не ломают учёт.

Сразу в код с ИИ без требований

Симптом: прототип за вечер, в проде нет валидации телефона, ролей и логов. Фикс: список нефункциональных требований до генерации кода - кто видит заявку, где хранятся ПДн, что делать при сбое webhook. Иначе получаем красивый happy path без эксплуатации.

Если узнаёте две и более строки - вернитесь к пяти шагам, не к репозиторию.

Идея готова к пилоту, когда совпали четыре условия: боль подтверждена интервью, плательщик или владелец процесса назван, канвас обновлён после разговоров, критерий приёмки пилота записан и согласован. Не раньше.

Чеклист перед переходом к разработке проектов:

• Один сценарий, не «платформа на всё»
• Гипотеза в JSON или таблице с metric и threshold
• Минимум 5 интервью с эпизодами из практики
• Lean canvas: проблема и сегмент заполнены фактами, не догадками
• Concierge или ручной прогон сценария хотя бы 3-5 дней
• Список того, что сознательно не делаем в v1
• Понятно, кто принимает пилот по метрике

Пилот - не «запуск продукта». Это проверка цепочки на реальных заявках с правом откатиться к таблице. На одном проекте CRM подключили до согласования полей: карточки пустые, менеджеры вернулись к Telegram. Откат стоил дороже, чем неделя concierge в Google Sheets.

Когда критерий выполнен, имеет смысл переходить к узкой разработке - бот, интеграция, автоматизация заявок как следующий слой. Если критерий не выполнен - упрощаем сценарий, а не добавляем фичи.

Проверить идею стартапа теми же шагами можно, но угол у владельца ИП другой: не pitch deck, а одна дыра в операционке. Стартап-лексика не обязательна; обязателен измеримый исход до кода.

Если хотите пройти те же шаги на своём процессе - пришлите один сценарий: откуда приходит заявка, кто отвечает, где учёт сейчас. На разборе зафиксируем гипотезу, метрику и решим, нужен ли пилот или достаточно ручного шага.

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