От задачи к прототипу: разбор процесса без маркетинговых обещаний

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

На разборе типичный запрос звучит широко: «нужен бот, CRM и отчёты». Открываю переписку - 80% боли в одном месте. Ночные заявки в личном Telegram владельца до утра никто не переносит в учёт. Остальное откладываю в anti-scope: аналитика, round-robin между менеджерами, интеграция с 1С. Так я сужаю разработку нового прототипа до проверяемой гипотезы, а не до презентации «мы всё автоматизировали».

До кода фиксирую четыре вещи:

• владелец процесса - кто отвечает за строку в учёте;
• бюджет на узкий этап, без «потом доплатим за всё»;
• какие данные нельзя светить агенту в Cursor;
• anti-scope - что сознательно не делаем в этом цикле.

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

Когда заказчик говорит «у конкурента за неделю», я не спорю про календарь. Спрашиваю: какой критерий они сдавали и что осталось за кадром. Неделя без чек-листа - это срок на показ, не на приёмку. Мой порядок тот же: ограничения, один поток, критерий, потом вилки решений.

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

Три вилки, которые я предлагаю чаще всего:

1. 01

   Concierge - ручной шаг за кулисами: админ пересылает заявку в рабочий чат и вносит строку в таблицу.

2. 02

   Таблица плюс уведомление - бот или webhook пишет в Google Sheets и пушит менеджеру без полноценного backend.

3. 03

   Код в репозитории - handler в Cursor, лог каждого Update, human-fallback при сбое.

Выбор не «как моднее», а где дешевле ошибиться. Если гипотеза про потери ночных заявок, concierge на три дня может дать сигнал быстрее, чем неделя настройки webhook. Если сигнал есть, но ручной шаг не масштабируется - переходим к вилке 2 или 3.

Перед Agent я включаю Plan Mode в документации Cursor: план до кода, уточняющие вопросы, откат к плану вместо бесконечного «долечивания» diff. Scope файлов согласую заранее: handler, конфиг staging, тестовые данные - не весь монорепозиторий. Промежуточная проверка - не «понравилось демо», а staging URL, diff в git, лог последних заявок.

Обезличенный разбор: ночные заявки в Telegram

Задача: услуги, команда 2-4 человека. Заявки приходят в личный Telegram владельца после 21:00 и до утра не попадают в учёт. Ограничения: дисциплины CRM нет, бюджет только на узкий пилот, прод-данные клиентов в чат агента не отдаём.

Вилка 1 - concierge три вечера: админ по шаблону пересылает в рабочий чат и ставит строку в таблицу. Проверяем, исчезают ли «утренние сюрпризы». Вилка 2 - бот пишет в Sheets и шлёт push дежурному. Вилка 3 - handler с логом Update и ручным fallback, если webhook молчит.

Критерий до старта - шаблон, не выдуманная статистика: N заявок подряд без потери записи за T дней. N и T согласуем с владельцем процесса. Я не пишу «у клиента было пять» - это был бы обман читателя.

Не закрыто на этом этапе: round-robin между менеджерами, 1С, оплата, SLA мониторинг, vault для секретов. Список хвостов фиксирую в конце - иначе заказчик думает, что «раз бот есть, всё готово».

После выбора вилки «код в репо» собираю минимальный handler. Токен - плейсхолдер, данные - тестовые:

import logging
from telegram import Update
from telegram.ext import Application, MessageHandler, filters

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("night_lead_proto")

YOUR_BOT_TOKEN = "REPLACE_ME"  # staging only, not in chat prompt

async def on_message(update: Update, context) -> None:
    msg = update.effective_message
    if not msg or not msg.text:
        return
    payload = {
        "chat_id": msg.chat_id,
        "text": msg.text[:500],
        "user": msg.from_user.username if msg.from_user else None,
    }
    logger.info("lead_captured %s", payload)
    # TODO: append row to Sheets / notify manager chat

def main() -> None:
    app = Application.builder().token(YOUR_BOT_TOKEN).build()
    app.add_handler(MessageHandler(filters.TEXT & ~filters.COMMAND, on_message))
    app.run_polling()

if __name__ == "__main__":
    main()

Перед merge смотрю diff: нет ли реального токена, нет ли прод-таблицы в конфиге. Verify через terminal в Agent - да, но только на тестовом боте.

Разработка прототипов продукта для меня - это проверяемый контур, а не красивая оболочка. Три опоры: среда, данные, критерий. Среда - staging или изоляция, не «у разработчика на ноутбуке». Данные - тестовые или маскированные; прод-клиенты в промпт не кладу. Критерий - scorecard до кода, не «в целом ок» на демо.

В ленте недавно мелькнул заголовок про LangChain и продакшен-агентов с песочницей - я не копирую чужие тексты, но факт полезен: LangSmith Sandboxes выделяют microVM, auth proxy, lifecycle. Смысл для моего разбора простой: агент в Cursor на локальной машине доказывает сценарий; продакшен-контур начинается, когда среда и секреты отделены от ноутбука. Параллель уже есть в MVP с ИИ: агент в ноутбуке без прод-метрики не равен готовому продукту.

Разработка прототипа системы - тоже про один поток. «Система» не значит «вся CRM». Это цепочка: канал входа, правило записи, уведомление ответственному, статус. Если любое звено вне scope - честно пишу в anti-scope.

Перед кодом заполняю scorecard приёмки - четыре поля, как в проверке идеи и ТЗ пилота:

scenario: "Ночная заявка из Telegram попадает в учёт без потери"
acceptance_criterion: "N заявок подряд за T дней - порог согласуем с владельцем"
anti_scope: "1С, оплата, round-robin, прод-секреты в чате агента"
rollback: "Отключить webhook; заявки снова вручную в рабочий чат"

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

Для разработки и создания прототипов в связке с Cursor держу короткий цикл: Plan Mode на список файлов, Agent на реализацию, checkpoint перед рискованным Apply, verify через лог или тестовую заявку. Режимы Ask и Debug подключаю, когда нужно понять чужой handler, а не писать с нуля вслепую.

Вопрос «mvp прототип - это одно и то же?» я слышу на каждом втором разборе. Нет. Прототип - один сценарий с приёмкой на ограниченном контуре. MVP - устойчивый минимум под эксплуатацию: логи, права, rollback, понятный владелец инцидента. Пилот - следующий шаг, когда критерий прототипа пройден, а хвосты записаны.

Чем прототип отличается от mvp в моей практике - прототип может жить на staging и тестовом боте. MVP уже отвечает на вопрос «что будет в понедельник утром, если webhook упал». Прототип mvp продукт в поисковых статьях часто смешивают в одну кучу; я развожу по таблице выше, чтобы не обещать прод после первого демо.

Отстройка от agency-чеклистов вроде «12-15 фич за 30 дней» простая: чужие формулировки не переношу как свои факты. У меня нет универсального «N фич за M дней» - есть один сценарий и порог приёмки. Если заказчик приносит чужой список фич, возвращаю к as-is: где заявка теряется сейчас, и что из списка к этому относится.

Подробнее про границу с кодом - в MVP с ИИ. Здесь добавлю только правило: не называю прототип MVP, пока нет rollback и владельца сопровождения.

Ниже - рабочий чеклист, который я прохожу с заказчиком на разработке проектов. Восемь пунктов, не пять одинаковых карточек. Можно копировать в переписку и отмечать галочками.

1. 01

   Зафиксировать одну задачу и владельца процесса.

2. 02

   Записать ограничения: бюджет этапа, данные, anti-scope.

3. 03

   Нарисовать as-is: где заявка теряется сейчас.

4. 04

   Сформулировать критерий «готово» с порогом (до кода).

5. 05

   Выбрать вилку: ручной шаг / таблица+бот / код в репо.

6. 06

   Собрать прототип в согласованном контуре (staging, без прод-секретов в чате).

7. 07

   Промежуточная проверка: показ + diff/логи/тест по scope.

8. 08

   Зафиксировать открытые хвосты и решение: пилот / доработка / стоп.

Пункт 4 - самый частый пропуск. Без порога любая вилка из пункта 5 «сработает» в глазах того, кто показывал демо. Пункт 8 защищает от иллюзии, что прототип закрыл CRM, оплату и отчёты. Я явно пишу: round-robin, 1С, vault - в хвостах, не в обещаниях.

Если после пункта 7 критерий не выполнен, не перескакиваю к пилоту. Возврат к вилке или к concierge - нормальный исход. Честный стоп дешевле, чем месяц поддержки «почти готового» бота.

Три сбоя вижу чаще остальных. У каждого - симптом, фикс и короткая проверка. Это не абстрактные советы, а то, что всплывает на приёмке прототипов.

Прототип без критерия готовности

Симптом: на демо всё красиво, на сдаче спор - «я думал, CRM уже полная». Фикс: scorecard до кода с полями scenario, acceptance_criterion, anti_scope, rollback - как в блоке выше и в ТЗ для пилота. Verify: владелец проходит пункты приёмки вслух, без «в целом норм».

Я не начинаю Agent, пока acceptance_criterion не согласован. Иначе агент оптимизирует happy path, а не вашу операцию.

Секрет или прод-данные в чате агента

Симптом: токен бота или API-ключ оказался в промпте; агент прочитал .env через terminal. Фикс: .cursorignore, в задаче только имена переменных без значений, git diff на SECRET и TOKEN перед коммитом, ротация ключа если утёк. Практики - в git и Cursor безопасно.

Redact runtime secrets в документации Cursor относится к Cloud Agent - не переношу это на локальную установку как «само скроет». Локально отвечаю за ignore, diff и тестовые данные. Прототип собираю на staging-боте, не на проде.

«Сделаем как в чужом кейсе» без ваших ограничений

Симптом: скопировали чужой webhook и стек; на ваших полях и канале всё ломается. Фикс: as-is карта одного потока, anti-scope, потом прототип. Concierge на таблице иногда заменяет код - если заявки уже не теряются, репозиторий не нужен. Подход ближе к проверке идеи: сначала ваш канал, не клон чужого репо.

Verify: 2-3 реальные заявки через ваш Telegram или форму, не тестовый аккаунт из туториала. Если concierge держит поток - честно фиксируем «код не обязателен», а не делаем бота ради бота.

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

По теме в блоге: ТЗ для пилота, MVP с ИИ, как проверить идею.