ТЗ на Telegram-бота: что включить и проверить

ТЗ на бота — это не формальность, а способ договориться о результате. Хорошее ТЗ закрывает 80% последующих споров: что входит в обязанности подрядчика, какие сценарии должны работать, что считается приёмкой. Разберём структуру, которая работает на проектах от микро-ботов до сложных Mini Apps, антипаттерны, которые ломают сроки, и приведём шаблон, который можно скопировать в Notion и заполнить за один день.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

5. UX/UI

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

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

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

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

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

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

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

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

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

• Языки и фреймворки (рекомендуемые или обязательные).
• БД и кеши.
• Инфраструктура: VPS, Yandex Cloud, Selectel, on-premise.
• Деплой: Docker Compose, Kubernetes, ручной.
• Резервное копирование и DR.

8. Аналитика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 4. Функциональные требования
FR-01 Бот хранит ответы пользователя на каждом шаге.
FR-02 При повторном /start предлагается продолжить с места остановки.
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 разговоров с реальными или потенциальными клиентами. Ищем, какую работу они нанимают сделать и в каком контексте.
• Аудит существующих систем. Если уже есть сайт, CRM, чат-бот — смотрим, как они устроены, чтобы не ломать процессы.
• Прототип в Figma. Кликабельный low-fi прототип ключевых экранов до того, как написана первая страница ТЗ. Прототип проверяет логику быстрее любого текста.

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

User story mapping для бота

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

Этапы:    Знакомство  Регистрация  Первый сценарий  Повторное использование  Поддержка
MVP:      /start +    Согласие     Запись на        Просмотр своих           FAQ +
          приветствие на ПДн       консультацию     записей                  оператор
v1.1:     Видео-      Импорт       Перенос          Напоминания              Чат с
          приветствие из календаря записи           за день                  историей
v2.0:     Геймификация Соцсети     Mini App         Программа                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. Подходит для проектов с высокой неопределённостью (новые интеграции, экспериментальные фичи).

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

Кто пишет ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 7. Архитектура
- Стек:
- Инфраструктура:
- Деплой и резервное копирование:

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

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

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

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

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

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

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

Итого

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

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

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

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

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

Универсальный костяк из 12 разделов: бизнес-цели и KPI; целевая аудитория и user stories; функциональные требования с уникальными ID; нефункциональные требования (нагрузка, доступность 99.5%, время отклика P95 ниже 2 секунд, безопасность, локализация); UX и тексты всех сообщений или дизайн Mini App; интеграции с 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-ревью.

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

Pre-discovery: короткий этап исследования, который сильно снижает риск переделок. Включает интервью со стейкхолдерами по 30–60 минут с каждым — владелец бизнеса, маркетинг, продажи, поддержка, IT, чтобы зафиксировать боли и ожидания и обнаружить расхождение во взглядах внутри команды. JTBD-интервью с 5–8 реальными или потенциальными клиентами: какую работу они нанимают сделать и в каком контексте. Аудит существующих систем (сайт, 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», подрядчик теряет инженерную свободу, а заказчик — гарантию работающего результата. Граница простая: «что должно произойти с точки зрения пользователя или бизнеса» — в ТЗ; «как именно это реализовано в коде» — в техническом дизайне команды разработки. Не лезьте в micromanagement.