ТЗ на пилот автоматизации: чеклист приёмки

ТЗ на пилот автоматизации отвечает на вопрос «как примем работу», а не «как заполнить все разделы по стандарту». ГОСТ 34.602 описывает техзадание на автоматизированную систему: около десяти обязательных блоков, язык закупок и сдачи АС. Для SMB-пилота с одним потоком заявок это перегруз: вы тратите неделю на оформление, а критерий «5 заявок без потерь за неделю» так и не появляется.

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

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

Я не продаю ГОСТ как зло. Для госзаказа и крупной АС форма нужна. Для пилота автоматизации заявок достаточно короткого документа: сценарий, данные, границы, критерий, rollback. Проверяемость важнее толщины папки.

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

До первой строки кода я фиксирую:

1. 01

   Контекст процесса - кто владелец, где сейчас теряются заявки.

2. 02

   Один сценарий end-to-end - не три параллельных потока.

3. 03

   Входы: откуда приходит событие, какие поля обязательны.

4. 04

   Выходы: куда пишется запись, кто получает уведомление.

5. 05

   Исключения: что делать при дубле, пустом поле, ночном режиме.

6. 06

   Anti-scope - что сознательно не входит в пилот.

7. 07

   Критерий приёмки с числом и сроком.

8. 08

   Rollback: как откатить, если критерий не выполнен.

Тз на разработку проекта в стиле «сделайте CRM + бот + аналитику» не проходит проверку на завершённость. Подрядчик закономерно расширит scope. Я сжимаю формулировку до одного операционного цикла, как в интеграции Telegram и CRM: сообщение → квалификация → карточка → уведомление.

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

Кто пишет и кто подписывает

Владелец процесса формулирует «что должно измениться в работе». Исполнитель (я, подрядчик или внутренний dev) переводит это в проверяемые шаги и ограничения. Подпись владельца на критерии приёмки важнее подписи на 40 страницах общих слов.

Чеклист приёмки пилота - четыре поля, которые я заполняю до старта работ. Это рабочий инструмент, не отчёт для инвестора. Если поле пустое - пилот ещё не готов к коду.

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

Гипотеза и сценарий

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

Исключения и human-fallback

В ТЗ на разработку явно перечисляю исключения: дубль телефона, пустое имя, сообщение вне рабочих часов, сбой API CRM. Для каждого - действие: отложить в очередь, запросить уточнение, уведомить дежурного. Агент без fallback на человека не принимается: при сбое заявка не должна исчезнуть.

Anti-scope

Без anti-scope пилот раздувается за две недели. Типичный список: онлайн-оплата, личный кабинет, отчёты, синхронизация с 1С, WhatsApp и VK. Если заказчик настаивает на пункте из anti-scope - это другой проект, не текущий пилот.

Порядок приёмки, который я прохожу с заказчиком:

1. 01

   Сверить сценарий на бумаге с реальным потоком заявок за последнюю неделю.

2. 02

   Прогнать тестовую заявку через песочницу - не через прод.

3. 03

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

4. 04

   Набрать N реальных заявок в согласованный срок.

5. 05

   Сверить критерий: потери, дубли, задержки.

6. 06

   Подписать приёмку или зафиксировать доработки с новым сроком.

Тз для ии в теле статьи - не про заголовок ChatGPT, а про границы автоматизации до продакшена. Когда агент получает доступ к CRM, таблицам и чатам, в ТЗ фиксирую песочницу: отдельный стенд, тестовые карточки, запрет на запись в боевые сущности до приёмки.

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

В разделе «границы агента» перечисляю:

• Какие API и таблицы доступны агенту.
• Какие действия запрещены (удаление, массовое обновление, экспорт).
• Где хранятся секреты и кто их ротирует.
• Какой режим Cursor используем: Ask для аудита, Agent - только в ограниченной папке.

Cursor Rules - аналогия «ТЗ в rules»: файл в .cursor/rules задаёт рамку до того, как Agent начнёт править код. Это не замена ТЗ для заказчика, но страховка от раздувания scope на стороне разработки.

Фрагмент rules для пилота Telegram → CRM:

---
description: Границы пилота - заявки Telegram в CRM
globs: ["src/bot/", "src/integrations/crm/"]
alwaysApply: true
---

# Пилот: Telegram → CRM

- Один сценарий: входящее сообщение → квалификация (2 поля) → create_lead → notify manager.
- Не добавлять: оплату, ЛК, отчёты, интеграцию с 1С.
- CRM: только sandbox-организация до приёмки; prod ID в .env.example без значений.
- Логировать каждый Update; при ошибке API - очередь retry + алерт в рабочий чат.
- Human-fallback: если CRM недоступна 2 минуты - переслать заявку в Telegram-чат дежурного.
- Критерий приёмки: 5 реальных заявок без потерь за 7 дней (см. acceptance-checklist.json).

Документация Cursor по Rules описывает тот же принцип: контекст до генерации кода. Я связываю rules с YAML-ТЗ, чтобы Agent не «додумывал» фичи из anti-scope.

Ошибки в ТЗ на разработку я вижу на каждом втором разборе. Ниже - симптом, почему ломается приёмка и конкретный фикс.

Весь продукт в одном ТЗ

Симптом: 30 страниц про бота, CRM, аналитику, мобильное приложение и «ИИ-ассистента». Приёмка превращается в бесконечный список «ещё чуть-чуть». Фикс: один сценарий, один критерий, anti-scope на отдельном листе. Остальное - backlog после успешной приёмки пилота.

Демо без реальных заявок

Симптом: «бот отвечает в тестовом чате, принимаем». Через неделю в проде теряются ночные обращения - полей не хватало. Фикс: критерий только на реальных заявках с согласованным порогом N за срок T. Тестовый чат - для отладки, не для подписи акта.

Агент без метрики

Симптом: «ИИ квалифицирует лиды» без коридора ошибок. Заказчик не знает, сколько ложных срабатываний допустимо. Фикс: метрика или ручная выборочная проверка - например, 20 заявок, не более 1 ошибки классификации. Приёмка LLM - не «2-3 красивых демо», а проверяемый коридор.

Копипаст ГОСТ или чужого техзадания

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

«ChatGPT напишет ТЗ за вечер»

Симптом: черновик выглядит убедительно, но в тексте - несуществующие поля CRM и выдуманные webhook. Фикс: использовать ИИ для черновика структуры, затем сверить каждую интеграцию с документацией API и реальным процессом заказчика. Промпт-ТЗ ускоряет старт, не заменяет фактчек.

Устная договорённость вместо критерия

Симптом: «мы в Telegram обсудили, что главное - скорость». После пилота скорость оказалась нормой, а потери - нет. Фикс: один измеримый критерий в документе до оплаты работ. Goalposts после старта - признак слабого ТЗ.

Пример тз на разработку для пилота - не ГОСТ и не обещание «системы под ключ». Ниже шаблон разделов, который я отдаю после согласования сценария. Техническое задание образец здесь - YAML для копирования, не PDF на 50 страниц.

pilot_tz:
  title: "Пилот: Telegram → квалификация → CRM → уведомление"
  owner: "Владелец салона (подпись на критерии)"
  executor: "Разработчик / интегратор"

  scenario:
    trigger: "Клиент пишет в Telegram-бот"
    steps:
      - "Бот запрашивает услугу и удобное время"
      - "create_lead в CRM (sandbox) с полями: name, phone, service, source=tg"
      - "Уведомление менеджеру в рабочий чат со ссылкой на карточку"
    sink: "AmoCRM sandbox / Google Sheets - согласовано до старта"

  inputs:
    required: ["telegram_user_id", "message_text", "phone"]
    optional: ["preferred_time"]

  outputs:
    crm_record: "lead status=new, created_at=ISO8601"
    notification: "Telegram message to @manager_chat"

  sandbox:
    crm_org: "sandbox-only до приёмки"
    test_data: "не использовать prod контакты"
    secrets: ".env.local, не в репозитории"

  anti_scope:
    - "Онлайн-оплата"
    - "Личный кабинет"
    - "Интеграция с 1С"
    - "WhatsApp, VK"

  acceptance_criterion:
    metric: "5 реальных заявок без потерь за 7 календарных дней"
    definition_no_loss: "каждая заявка имеет запись в CRM и ответственного"
    rollback: "отключить webhook, вернуть ручную пересылку в чат"

  exceptions:
    duplicate_phone: "обновить существующую карточку, не создавать дубль"
    crm_timeout: "очередь + алерт дежурному через 2 минуты"
    after_hours: "записать заявку, уведомление с пометкой «ночь»"

Тот же пример тз на разработку в JSON - для хранения рядом с репозиторием и автоматической сверки на приёмке:

{
  "acceptance_checklist": {
    "scenario": "Telegram → qualify → CRM → notify",
    "inputs": ["telegram_user_id", "phone", "service"],
    "outputs": ["crm_lead_id", "manager_notification_sent"],
    "criterion": "5 real leads, 0 lost, 7 days",
    "anti_scope": ["payment", "lk", "1c", "analytics"],
    "checks": [
      {"id": "log_every_update", "pass": null},
      {"id": "sandbox_only_writes", "pass": null},
      {"id": "human_fallback_on_crm_fail", "pass": null},
      {"id": "no_duplicate_leads_same_phone", "pass": null},
      {"id": "criterion_met_real_leads", "pass": null}
    ]
  }
}

Перед передачей в разработку проектов я прохожу checklist с заказчиком: каждый pass - галочка после проверки, не «вроде работает». Тз на разработку сайта или мобильного приложения строится по той же логике, но сценарий и критерий другие - не копируйте YAML один в один без замены полей.

Если пилот уже прошёл стадию MVP из материала про MVP, в ТЗ переношу подтверждённую гипотезу и anti-scope из scorecard. Повторно спорить о «нужен ли бот» на этапе ТЗ - признак, что MVP пропустили.

Разбор ТЗ и пилота - не скачивание шаблона и не переписывание ГОСТ. Я смотрю ваш черновик или переписку: один сценарий, критерий приёмки, песочница, anti-scope. Если чего-то нет - скажу прямо, до оплаты разработки.

На наставничестве разбираем процесс до ТЗ: где теряются заявки, что проверять руками. На разработке проектов - пилот после согласованного документа. Не смешивайте этапы: сначала проверяемый сценарий, потом код.

По теме в блоге: как проверить идею проекта, MVP до кода, автоматизация заявок, интеграция Telegram и CRM.