ТЗ на бота в MAX: что включить и как защититься от рисков

ТЗ на бота в MAX — это не «формальность для галочки», а способ договориться о результате между заказчиком и подрядчиком. Хорошее ТЗ снимает 80% споров на этапе сдачи и позволяет точно прогнозировать сроки и стоимость. Разберём, какие разделы обязательны для бота в российском мессенджере MAX, какие антипаттерны ломают сроки, как выглядит хороший шаблон и что должно остаться за пределами документа.

Зачем вообще писать ТЗ

Соблазн «сделать на словах» возникает почти в каждом небольшом проекте: бот в MAX же простой, что там обсуждать. Через две недели выясняется, что заказчик ждал интеграцию с amoCRM и Mini App с личным кабинетом, а подрядчик предполагал текстовые сценарии и ручной экспорт в CSV. Ещё через неделю появляется «маленький» модуль рассылок с сегментацией. Бюджет уплывает, обе стороны злятся.

ТЗ решает четыре задачи одновременно:

• Юридическая основа договора. Без приложения с описанием работ договор подряда — это бумажка, которая не защищает ни одну из сторон. Спор о том, входил ли модуль рассылок в стоимость, разбирается за минуту, если ТЗ есть, и неделями — если его нет.
• Фиксация скоупа. Перечень сценариев и фич — это «забор», за который нельзя выходить без отдельного допсоглашения. Без забора подрядчик соглашается на всё, чтобы не ссориться, а потом не успевает к сроку.
• Защита от scope creep. Ползучее расширение требований — главный убийца дедлайнов. С ТЗ любая новая идея превращается в честный разговор: «это change request, плюс N дней и K рублей».
• Оценка сроков и бюджета. По размытому описанию оценка делается «с потолка» с запасом 2–3×. По детальному ТЗ можно собрать оценку по компонентам с погрешностью 20–30%.

Скрытая пятая задача — выровнять ожидания внутри команды заказчика. Часто маркетинг хочет одно, продажи — другое, директор — третье. ТЗ заставляет их договориться до того, как разработчик начал писать код для MAX Bot API.

Антипаттерны, которые видно сразу

Перед тем как разбирать структуру хорошего ТЗ, проще показать, как выглядит плохое. Если в документе есть хотя бы один из этих признаков, его придётся переписывать.

• «Сделайте как у X». Скрин конкурента из Telegram или WhatsApp и подпись «нам нужно так же, только в MAX» — это не ТЗ, а мудборд. Внутреннее устройство чужого бота снаружи не видно: как считается остаток, как обрабатывается возврат, как хранится корзина, как ведётся история.
• Простыня без структуры. Десять страниц текста подряд без заголовков и списков. Ни найти, ни сослаться, ни оценить.
• «Всё обсудим в процессе». Признание, что договариваться будут на ходу. На практике это означает, что разработчик будет угадывать, а заказчик — переделывать.
• Только текст без диаграмм и экранов. Сценарий «пользователь оформляет заказ» из четырёх слов превращается в десять разных реализаций.
• Смешение требований и реализации. «Нужен бот на Python с Redis и Celery» — это не требование, это решение. Сначала зафиксируйте, что бот должен делать, потом обсуждайте стек.
• Отсутствие нефункциональных требований. Нагрузка, доступность, время отклика, безопасность не упомянуты. Подрядчик закладывает минимум, через полгода всё ложится при первом всплеске трафика.
• Нет критериев приёмки. Непонятно, в какой момент проект считается сданным. Сдача растягивается на месяцы «ещё одной правки».
• Игнорирование специфики MAX. Документ скопирован из проекта по Telegram-боту без учёта особенностей платформы: возможности Mini App MAX, лимиты MAX Bot API, политика модерации, региональные требования VK Tech.

Структура хорошего ТЗ

Универсальный костяк, который покрывает 90% проектов на платформе MAX. Размер — 15–40 страниц для типичного бота. Меньше 10 — наверняка чего-то не хватает; больше 50 — никто не дочитает.

1. Бизнес-цели

Что бот должен изменить в бизнесе и как мы поймём, что получилось. Минимум:

• Бизнес-задача в одном предложении: «уменьшить нагрузку на поддержку на 30% за счёт автоматизации первичных обращений в MAX».
• KPI с числами: целевая конверсия из старта в заявку, среднее время до первого отклика, доля обращений, которые бот закрывает автономно.
• Горизонт измерения: «первые 90 дней после запуска».
• Что не входит в задачи бота — пункт, который сильно экономит нервы.

2. Целевая аудитория и сценарии

Для каждого типа пользователя — короткое описание и набор JTBD (jobs to be done). Дальше — user stories в одном формате:

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

User stories группируются в сценарии — пути от триггера до результата:

Запись на консультацию. Пользователь нажимает «Старт» → бот спрашивает имя → пользователь вводит имя → бот предлагает выбрать услугу из 4 вариантов → пользователь выбирает → бот показывает свободные слоты на ближайшие 7 дней → пользователь выбирает слот → бот просит телефон → пользователь отправляет → бот подтверждает запись и присылает напоминание за день.

Сценариев обычно 5–15. Каждый — максимум на полстраницы. Если не помещается, сценарий слишком сложный и его надо разбить. На этом же этапе проектируется FSM (конечный автомат): набор состояний, переходов между ними и условий перехода. Чем подробнее карта, тем меньше переделок.

3. Функциональные требования

Перечень модулей и фич в формате «пользователь может …» или «система должна …». Каждое требование — атомарное, проверяемое, с уникальным ID (FR-001, FR-002 …), чтобы на него можно было ссылаться из тестов и из чата.

Пример:

• FR-014 Пользователь может посмотреть историю своих записей за последние 90 дней.
• FR-015 Администратор может отменить запись пользователя из веб-кабинета. Пользователь получает уведомление в боте MAX.
• FR-016 Бот не принимает запись на слот менее чем за 2 часа до его начала.

4. Нефункциональные требования

То, что не видно в сценариях, но без чего проект разваливается на проде.

• Нагрузка. Ожидаемое количество активных пользователей в день и в пиковую минуту, объём базы за полгода и год.
• Доступность. SLA по доступности — типично 99.5% в месяц (около 3.6 часа простоя), для критичных систем — 99.9%.
• Производительность. Время отклика бота: P50 меньше 800 мс, P95 меньше 2 секунд на webhook от MAX.
• Безопасность. Шифрование чувствительных полей, ротация токенов MAX Bot API, разделение прав в админке.
• Локализация. Русский по умолчанию, готовность к добавлению второго языка без переписывания кода.
• Совместимость. Десктоп и мобильный MAX, последние две версии клиента.

5. UX/UI

Для текстовых ботов — таблица всех сообщений с текстами, кнопками, условиями показа и действиями при нажатии. Для Mini App MAX — Figma-макет с прототипом. По каждому экрану:

• Текст сообщения (включая Markdown-разметку, поддерживаемую MAX).
• Кнопки (inline, reply, web_app для Mini App), их подписи и callback.
• Условия показа (например, только в рабочее время).
• Действие при нажатии каждой кнопки.

Удобный формат — таблица в Notion или Google Docs. Главное, чтобы тексты лежали в одном месте и не дублировались между ТЗ, дизайн-макетами и кодом.

6. Интеграции

Любая интеграция — отдельный пункт. По каждой:

• Внешний сервис (название, URL документации).
• Метод подключения (REST, webhook, GraphQL, очередь).
• Авторизация (OAuth2, API-key, JWT, basic auth).
• Какие данные туда уходят и оттуда приходят (поля, типы).
• Лимиты (запросов в секунду, размер payload, окна).
• Кто отвечает за доступы (логины, токены, тестовые аккаунты).

Типичный набор для бота в MAX: CRM (Bitrix24, amoCRM), платежи (ЮKassa, СБП), календарь (Yandex, Google), таблицы, рассылки, складские системы, 1С.

7. Архитектура

Здесь два варианта: либо стек жёстко зафиксирован заказчиком (есть свой DevOps, и всё должно быть на Python+PostgreSQL), либо «открытый» — подрядчик выбирает сам в рамках ограничений. Зафиксируйте:

• Языки и фреймворки (рекомендуемые или обязательные).
• БД и кеши (PostgreSQL, Redis).
• Инфраструктура: VPS, Yandex Cloud, Selectel, on-premise — для российского мессенджера MAX обычно нужны российские площадки.
• Деплой: Docker Compose, Kubernetes, ручной.
• Резервное копирование и DR.
• Способ подключения к MAX: webhook (с публичным HTTPS-доменом и валидным SSL) или long polling.

8. Аналитика

Какие события трекаем и через что:

• События в боте: старт, переход между шагами сценария, отправка заявки, отказ.
• Воронка: старт → шаг 1 → шаг 2 → конверсия.
• Дашборды: где смотрим (Metabase, DataLens, Excel), кто их собирает, с какой частотой обновляются.
• Хранение сырых событий: в собственной БД или в ClickHouse для последующего анализа.

9. Безопасность и compliance

Юридический минимум для российского рынка и платформы MAX:

• 152-ФЗ. Согласие на обработку персональных данных, политика конфиденциальности, уведомление в РКН для оператора ПДн. Хранение ПДн на территории РФ.
• 54-ФЗ. Чеки через ОФД при приёме оплаты.
• Статья 18 закона о рекламе. Возможность отписки от рассылок одной кнопкой, маркировка рекламных сообщений (ОРД).
• Хранение токенов. Только в защищённом хранилище (Vault, Yandex Lockbox, секреты CI), не в Git, не в логах.
• Логи. Без чувствительных данных в plain text, срок хранения зафиксирован.
• Антибот и капча. Для рассылок и форм с публичным доступом.

10. Этапы и сроки

План работ по этапам с длительностью и результатом каждого:

1. Дискавери и финализация ТЗ — 1 неделя.
2. Дизайн макетов и текстов — 1–2 недели.
3. Разработка ядра — 2–3 недели.
4. Интеграции — параллельно, 1–2 недели.
5. Внутреннее тестирование — 1 неделя.
6. UAT (приёмочное тестирование заказчиком) — 3–5 дней.
7. Запуск и стабилизация — 1 неделя.

Реалистичные сроки для среднего бота в MAX — 4–8 недель. Сжатие до «14 дней» работает только для очень простых сценариев или для команд с готовыми шаблонами.

11. Критерии приёмки и тестирование

Проверяемый список того, что должно работать:

• Все сценарии проходят на тестовом боте MAX без ошибок.
• Боты развёрнуты в обоих окружениях (test, prod).
• Документация на админ-панель.
• Код в репозитории заказчика, README с инструкцией по запуску.
• Покрытие критичных модулей автотестами (например, оплата и резерв).
• Прохождение нагрузочного теста на расчётный пик.
• 30 дней гарантии на доработки по багам.

12. SLA на поддержку

Что входит в постгарантийную поддержку, время реакции на инциденты разной критичности, окно работ, канал связи. Без этого после запуска начинаются те же споры, что и без ТЗ.

Хорошее vs плохое требование

Любое требование можно переписать так, чтобы его можно было проверить. Сравните:

Простой тест: можно ли написать тест-кейс по требованию? Если нет — переформулируйте.

Пример мини-ТЗ на квиз-бот в MAX

Короткий пример того, как выглядит сжатое ТЗ для простого бота. Целевой объём — 3–5 страниц.

# ТЗ: квиз-бот в MAX для подбора курса английского

## 1. Цель
Подобрать пользователю курс по результатам квиза и собрать
контакт для отдела продаж. KPI первых 60 дней: 500 завершённых
квизов, конверсия в заявку >= 35%.

## 2. Аудитория
Взрослые 25–45, изучали английский в школе/вузе, работают
в найме, планируют карьерный рост. Канал трафика: таргет
ВКонтакте и посевы в сообществах MAX.

## 3. Сценарий
Старт → приветствие + кнопка «Пройти тест» →
8 вопросов с inline-кнопками →
расчёт уровня (A1–C1) →
рекомендация курса (3 варианта) →
запрос телефона →
подтверждение + передача в amoCRM.

## 4. Функциональные требования
FR-01 Бот хранит ответы пользователя на каждом шаге.
FR-02 При повторном старте предлагается продолжить с места остановки.
FR-03 Администратор может выгрузить результаты за период в CSV.
FR-04 Бот не присылает рекламные сообщения без согласия (ст. 18 ФЗ «О рекламе»).

## 5. Нефункциональные
- Нагрузка: до 200 одновременных квизов, 5000 в сутки.
- Доступность: 99.5% в месяц.
- Время отклика: P95 < 1.5 с.

## 6. Интеграции
- amoCRM v4: создание сделки в воронке «Лиды из квиза».
- Yandex Metrika: цели quiz_started, quiz_finished, lead_sent.

## 7. Этапы
Дизайн — 3 дня; разработка — 10 дней; тест — 3 дня; запуск — 1 день.

## 8. Приёмка
Все 8 вопросов проходятся, сделка появляется в amoCRM,
выгрузка CSV открывается в Excel без артефактов кодировки.

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

В каком инструменте писать ТЗ

Универсального ответа нет. У каждого формата свои сильные и слабые стороны.

• Notion. Удобно для совместной работы, поиск, история версий, шаблоны. Минус — для подписания договора нужен экспорт в PDF, и форматирование иногда «плывёт».
• Markdown в Git. Идеально для технических команд: версионирование, code review через PR, легко связать с issue в Jira или Linear. Минус — нетехнический заказчик не зайдёт.
• Google Docs. Самый низкий порог входа, комментарии, режим предложений. Минус — структура расползается, на 30+ страницах документ становится неуправляемым.
• Confluence. Корпоративный стандарт, хорошо для крупных компаний с общей вики. Минус — медленный, дорогой, плохо работает офлайн.

Практический выбор: для проектов до 1 млн рублей — Notion или Google Docs; для крупных корпоративных — Confluence; для проектов с серьёзной технической глубиной (микросервисы, сложные интеграции) — Markdown в Git с PR-ревью.

Версионирование и согласования

ТЗ — живой документ. Пока проект идёт, появляются уточнения, change requests, новые требования. Без версионирования через две недели никто не помнит, какая версия согласована.

Минимум:

• В шапке документа — номер версии и дата.
• В конце — changelog с датой, автором и сутью изменения.
• Каждое значимое изменение — отдельное согласование с заказчиком (письмо, чат, подпись).
• Финальная версия фиксируется как приложение к договору, дальнейшие правки оформляются допсоглашением.

Простой шаблон changelog:

## История изменений
- 2026-02-01 v1.3 — добавлен модуль рассылок (по запросу заказчика, +5 дней)
- 2026-01-25 v1.2 — уточнены лимиты amoCRM, изменён формат экспорта
- 2026-01-20 v1.1 — добавлены критерии приёмки
- 2026-01-15 v1.0 — начальная версия

Что делать до ТЗ: pre-discovery

Самая частая ошибка — садиться писать ТЗ сразу после первого звонка. Получается документ, отвечающий на неправильные вопросы. Перед ТЗ нужен короткий этап исследования.

• Интервью со стейкхолдерами. 30–60 минут с каждым: владелец бизнеса, маркетинг, продажи, поддержка, IT. Фиксируем боли, ожидания, ограничения. Часто всплывает, что у разных людей в команде разное видение проекта.
• JTBD-интервью с пользователями. 5–8 разговоров с реальными или потенциальными клиентами. Ищем, какую работу они нанимают сделать и в каком контексте, и почему именно через бота в MAX, а не через сайт или звонок.
• Аудит существующих систем. Если уже есть сайт, CRM, чат-бот в другом мессенджере — смотрим, как они устроены, чтобы не ломать процессы.
• Прототип в Figma. Кликабельный low-fi прототип ключевых экранов до того, как написана первая страница ТЗ. Прототип проверяет логику быстрее любого текста, особенно для Mini App MAX.

Pre-discovery занимает 3–10 дней и сильно снижает риск переделок на этапе разработки.

User story mapping для бота

Чтобы не утонуть в плоском списке user stories, удобно собирать story map: горизонтально — этапы пути пользователя, вертикально — сценарии разной приоритетности.

Этапы:    Знакомство   Регистрация   Первый сценарий   Повторное использование   Поддержка
MVP:      Старт +      Согласие      Запись на         Просмотр своих            FAQ +
          приветствие  на ПДн        консультацию      записей                   оператор
v1.1:     Видео-       Импорт из     Перенос           Напоминания               Чат с
          приветствие  календаря     записи            за день                   историей
v2.0:     Геймификация Соцсети       Mini App MAX      Программа                 AI-
                                     с календарём      лояльности                ассистент

Story map даёт две вещи сразу: понимание полного пути и возможность быстро договориться, что входит в MVP, а что переезжает в следующие итерации.

Оценка проекта по ТЗ

Когда ТЗ готово, его нужно оценить — иначе договор не подписать. Три рабочих подхода, которые не противоречат друг другу.

• T-shirt sizing (XS/S/M/L/XL). Каждый сценарий или модуль получает размер. XS — несколько часов, S — день, M — 2–3 дня, L — неделя, XL — две и больше. Подходит для быстрой оценки и приоритизации до детальной проработки.
• Story Points. Относительная оценка в пунктах через planning poker. Команда сравнивает задачи между собой, не привязываясь к часам. Хорошо работает на длинных проектах, где важна стабильная скорость.
• Three-point estimate. Для каждого пункта — оптимистичная (O), пессимистичная (P) и наиболее вероятная (M) оценка. Финальная: (O + 4M + P) / 6. Подходит для проектов с высокой неопределённостью (новые интеграции, экспериментальные фичи в MAX).

На практике эти подходы комбинируются: T-shirt на старте для договора, Story Points в спринтах, three-point — для рискованных задач.

Кто пишет ТЗ

Минимальная команда для нормального ТЗ — три роли. В маленьких проектах их может закрывать один человек, но роли не исчезают.

• Продакт. Отвечает за бизнес-цели, аудиторию, сценарии, приоритизацию. Защищает ценность для пользователя.
• Системный аналитик. Превращает сценарии в функциональные требования с уникальными ID, описывает интеграции, форматы данных, граничные случаи. Именно он держит документ в порядке.
• Тех-лид. Отвечает за нефункциональные требования, архитектурные ограничения, реалистичность сроков, выбор стека и способа подключения к MAX Bot API.

Заказчик в этой команде — обязательный участник, а не «дам исходные данные и подожду». Без вовлечения заказчика ТЗ получается академическим.

Что не должно быть в ТЗ

Граница между ТЗ и реализацией размыта, и это часто приводит к перегруженным документам. Хорошее ТЗ отвечает на «что» и «зачем», а не на «как именно».

В ТЗ не нужно включать:

• Конкретные имена классов, структуру таблиц БД, SQL-запросы.
• Алгоритмы реализации функций (если они не часть бизнес-логики).
• Внутренние API между микросервисами.
• Решения о том, какую конкретно очередь сообщений использовать (если архитектура открыта).
• Детальные сценарии тестирования (это отдельный документ — тест-план).

Если в ТЗ начинают описывать «как считать остаток в Redis», подрядчик теряет инженерную свободу, а заказчик — гарантию работающего результата. Граница простая: «что должно произойти с точки зрения пользователя или бизнеса» — в ТЗ; «как именно это реализовано в коде» — в техническом дизайне команды разработки.

Чек-лист готовности ТЗ

Перед тем как подписывать ТЗ как приложение к договору, прогоните его по списку.

• Бизнес-цели зафиксированы с числовыми KPI и горизонтом измерения.
• Указано, что не входит в задачи бота.
• Описаны 1–3 типа пользователей и для каждого — JTBD.
• Сценариев 5–15, каждый помещается на полстраницы.
• У каждого функционального требования есть уникальный ID.
• Зафиксированы нагрузка, доступность, время отклика.
• Тексты всех сообщений лежат в одном месте.
• По каждой интеграции — auth, лимиты, формат данных, ответственный за доступы.
• Архитектурные ограничения прописаны (стек, инфраструктура, деплой, способ подключения к MAX).
• Перечислены события для аналитики и инструменты дашбордов.
• Закрыты юридические аспекты: 152-ФЗ, 54-ФЗ (если есть оплата), ст. 18 закона о рекламе.
• План работ разбит на этапы с длительностью и результатами.
• Прописаны критерии приёмки в виде проверяемого списка.
• Указан SLA на постгарантийную поддержку.
• У документа есть номер версии, дата и changelog.
• ТЗ согласовано всеми ключевыми стейкхолдерами заказчика, не только инициатором.

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

Шаблон ТЗ для копирования

Скелет, который можно скопировать в Notion или Google Docs и заполнить под свой проект:

# ТЗ: <название проекта> в MAX
Версия 1.0 от <дата>

## 1. Бизнес-цели
- Задача:
- KPI:
- Горизонт измерения:
- Что не входит в задачи:

## 2. Целевая аудитория и сценарии
- Сегменты и JTBD:
- User stories:
- Сценарии (5–15):

## 3. Функциональные требования
- FR-001 …
- FR-002 …

## 4. Нефункциональные требования
- Нагрузка:
- Доступность:
- Производительность:
- Безопасность:
- Локализация:

## 5. UX/UI
- Тексты сообщений:
- Кнопки и действия:
- Макеты Mini App MAX (ссылка на Figma):

## 6. Интеграции
- Сервис 1: auth, лимиты, поля, ответственный
- Сервис 2: …

## 7. Архитектура
- Стек:
- Инфраструктура:
- Способ подключения к MAX (webhook/long polling):
- Деплой и резервное копирование:

## 8. Аналитика
- События:
- Дашборды:
- Хранение сырых данных:

## 9. Безопасность и compliance
- 152-ФЗ:
- 54-ФЗ:
- Реклама и отписка:
- Хранение токенов и логов:

## 10. Этапы и сроки
- Этап 1 (… дней):
- Этап 2 (… дней):

## 11. Критерии приёмки
- [ ] …
- [ ] …

## 12. SLA на поддержку
- Часы работы:
- Время реакции по приоритетам:
- Канал связи:

## История изменений
- <дата> v1.0 — начальная версия

Заполнение этого шаблона занимает 1–3 дня при условии, что pre-discovery уже сделан.

Итого

Хорошее ТЗ — это страховка для обеих сторон, а не бюрократия. Структура «бизнес-цели → аудитория → функциональные требования → нефункциональные → UX → интеграции → архитектура → аналитика → закон → сроки → приёмка → SLA» закрывает большинство проектов на платформе MAX. Длина — 15–40 страниц для типичного бота. Слишком длинное ТЗ никто не читает, слишком короткое — порождает споры. Прогоняйте ТЗ через двух-трёх человек со стороны заказчика и одного со стороны разработки, фиксируйте версии и changelog — и идите в работу с уверенностью, что приёмка не превратится в бесконечные правки.

Частые вопросы

Зачем писать ТЗ на бота в MAX, если проект небольшой?+

ТЗ решает четыре задачи. Юридическая основа договора: без приложения с описанием работ договор подряда не защищает ни одну из сторон. Фиксация скоупа: перечень сценариев и фич — это «забор», за который нельзя выходить без допсоглашения. Защита от scope creep: с ТЗ любая новая идея превращается в честный change request с оценкой времени и денег. Оценка сроков и бюджета: по детальному ТЗ можно собрать оценку с погрешностью 20–30%, по размытому — с запасом 2–3×. Скрытая пятая задача — выровнять ожидания внутри команды заказчика, где маркетинг, продажи и руководство часто видят проект по-разному.

Какая структура у хорошего ТЗ на бота в MAX?+

Универсальный костяк из 12 разделов: бизнес-цели и KPI; целевая аудитория и user stories; функциональные требования с уникальными ID; нефункциональные требования (нагрузка, доступность 99.5%, время отклика P95 ниже 2 секунд, безопасность, локализация); UX и тексты всех сообщений или дизайн Mini App MAX; интеграции с auth и лимитами; архитектура и стек; аналитика и дашборды; безопасность и compliance (152-ФЗ, 54-ФЗ, статья 18 закона о рекламе); этапы и сроки; критерии приёмки и тестирование; SLA на поддержку. Размер — 15–40 страниц для типичного бота. Меньше 10 страниц — наверняка чего-то не хватает; больше 50 — никто не дочитает.

Чем отличается хорошее требование от плохого?+

Хорошее требование можно проверить. «Бот должен быстро отвечать» — плохое; «P95 времени отклика бота меньше 2 секунд при нагрузке до 100 RPS» — хорошее. «Удобный интерфейс» — плохое; «любой сценарий укладывается в 5 экранов, кнопка Назад доступна везде, кроме экрана оплаты» — хорошее. «Интеграция с CRM» — плохое; «создание сделки в amoCRM v4 при отправке заявки с полями имя, телефон, услуга, источник, обработка ответа за 3 секунды, при ошибке повтор через 5 минут» — хорошее. Простой тест: можно ли написать тест-кейс по требованию? Если нет, переформулируйте.

В каком инструменте лучше писать ТЗ — Notion, Google Docs, Markdown в Git или Confluence?+

Универсального ответа нет. Notion удобен для совместной работы, поиска и шаблонов, минус — для договора нужен экспорт в PDF. Markdown в Git идеален для технических команд: версионирование, code review через PR, привязка к issue, минус — нетехнический заказчик не зайдёт. Google Docs — самый низкий порог входа, комментарии, режим предложений, минус — структура расползается на 30+ страницах. Confluence — корпоративный стандарт для крупных компаний с общей вики. Практический выбор: проекты до миллиона рублей — Notion или Google Docs; крупные корпоративные — Confluence; технически сложные с микросервисами и серьёзными интеграциями — Markdown в Git с PR-ревью.

Что нужно сделать ДО написания ТЗ на бота в MAX?+

Pre-discovery: короткий этап исследования, который сильно снижает риск переделок. Включает интервью со стейкхолдерами по 30–60 минут с каждым — владелец бизнеса, маркетинг, продажи, поддержка, IT, чтобы зафиксировать боли и ожидания и обнаружить расхождение во взглядах внутри команды. JTBD-интервью с 5–8 реальными или потенциальными клиентами: какую работу они нанимают сделать и почему именно через бота в MAX. Аудит существующих систем (сайт, CRM, чат-бот в другом мессенджере), чтобы не ломать процессы. И кликабельный low-fi прототип ключевых экранов в Figma до того, как написана первая страница ТЗ — прототип проверяет логику быстрее любого текста. Pre-discovery занимает 3–10 дней.

Как оценить проект по ТЗ — какие подходы работают?+

Три подхода, которые комбинируются. T-shirt sizing (XS/S/M/L/XL) — каждый сценарий или модуль получает размер: XS — несколько часов, S — день, M — 2–3 дня, L — неделя, XL — две и больше; подходит для быстрой оценки на старте. Story Points — относительная оценка через planning poker, команда сравнивает задачи между собой, хорошо работает в спринтах на длинных проектах. Three-point estimate — для каждого пункта берутся оптимистичная, пессимистичная и наиболее вероятная оценки, итог считается по формуле (O + 4M + P) / 6, подходит для задач с высокой неопределённостью (новые интеграции, экспериментальные фичи). На практике T-shirt используется на старте для договора, Story Points — в спринтах, three-point — для рискованных задач.

Что не должно попадать в ТЗ?+

ТЗ отвечает на «что» и «зачем», а не на «как именно». В ТЗ не нужно включать конкретные имена классов и структуру таблиц БД, SQL-запросы, алгоритмы реализации функций (если они не часть бизнес-логики), внутренние API между микросервисами, решения о конкретной очереди сообщений (если архитектура открыта), детальные тест-кейсы (это отдельный тест-план). Если в ТЗ описывают «как считать остаток в Redis», подрядчик теряет инженерную свободу, а заказчик — гарантию работающего результата. Граница простая: «что должно произойти с точки зрения пользователя или бизнеса» — в ТЗ; «как именно это реализовано в коде» — в техническом дизайне команды разработки.