Как составить техническое задание на Telegram-бота

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

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

1. Кто пользуется ботом

Опишите типы пользователей и что каждому нужно. Это определяет, будут ли вообще роли и админ-раздел.

Пример: «Клиент — оставляет заявку на замер. Менеджер — получает уведомление и отвечает. Администратор — меняет список услуг и смотрит выгрузку».

2. Первый сценарий

Что происходит, когда человек открывает бота впервые. Опишите пошагово, включая тексты приветствия и набор кнопок стартового меню.

Отдельно проговорите, что видит человек, который вернулся: то же самое приветствие или другой экран. Это разные ветки, и их нужно заложить.

3. Какие вопросы задаёт бот

Самый важный раздел. Для каждого вопроса укажите четыре вещи:

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

Вопрос:        Ваш телефон для связи
Тип:           текст
Обязательный:  да
Проверка:      российский номер, 11 цифр,
               допускаются пробелы, скобки и дефисы
Если неверно:  «Похоже, номер введён не полностью.
               Пример: +7 900 000-00-00»

4. Какие данные сохраняются

Перечислите поля, которые остаются в системе после диалога. Это определяет структуру хранения и попадает в политику обработки персональных данных.

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

Если бот собирает персональные данные, это влечёт требования к их обработке — согласие, срок хранения, порядок удаления. Решить эти вопросы нужно до запуска, а не после.

5. Куда уходит заявка

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

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

6. Нужны ли роли

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

Отдельно: что происходит, когда сотрудник увольняется. Механизм отзыва доступа нужно заложить сразу — дописывать его потом всегда дороже.

7. Нужна ли админ-панель

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

Панель может быть отдельным веб-интерфейсом или разделом внутри самого бота. Второй вариант дешевле и часто достаточен, если изменения простые.

8. Нужны ли платежи

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

• оплата внутри Telegram или переходом на платёжную страницу;
• какая платёжная система и подключена ли она уже;
• нужен ли чек и кто его формирует;
• возможны ли возвраты и по какой процедуре;
• работаете ли с юрлицами и нужны ли счета;
• что происходит при неуспешной оплате и может ли человек попробовать снова.

9. Какие интеграции

Для каждой внешней системы укажите: что передаём, что получаем обратно, есть ли документированный API и у кого доступы.

10. Как обрабатываются ошибки

Раздел, который пропускают чаще всего, а потом получают бота, зависающего на первом нестандартном действии. Опишите поведение хотя бы для этих ситуаций:

11. Какие отчёты нужны

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

Последний пункт особенно полезен: он показывает, какой вопрос анкеты отпугивает людей, и часто окупает разработку отчёта за первую же неделю.

Шаблон целиком

1.  Пользователи и их задачи
2.  Первый сценарий (и сценарий возврата)
3.  Вопросы анкеты: формулировка, тип, обязательность, проверка
4.  Сохраняемые данные, срок и порядок хранения
5.  Куда уходит заявка и кто её обрабатывает
6.  Роли, права, назначение и отзыв доступа
7.  Админ-панель: что можно менять без разработчика
8.  Платежи: способ, чек, возвраты, юрлица
9.  Интеграции: что передаём, что получаем, есть ли API
10. Обработка ошибок и нестандартных действий
11. Отчёты и метрики

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

• Только список экранов. Экраны не описывают, что происходит при ошибке или возврате.
• Формулировки «удобно», «красиво», «быстро». Их нельзя проверить при приёмке.
• «Как у конкурента». Вы не знаете, что у него внутри и почему сделано так.
• «Остальное на ваше усмотрение». Это означает, что решение примут за вас, и не факт, что так, как вы ожидали.

Коротко

• ТЗ на бота — это перечень принятых решений, а не список кнопок.
• Самое важное — вопросы анкеты с правилами проверки и обработка ошибок.
• Решение о том, куда уходит заявка, определяет пользу от бота больше всего остального.
• Доступ к чужим API проверяется до подписания.
• Отчёт о том, на каком шаге бросают анкету, окупается быстрее прочего.

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