Есть надёжный способ потратить на бота вдвое больше денег и времени — объяснить задачу на словах «ну, чтобы клиенты могли записываться и всякое такое» и понадеяться, что разработчик «сам сообразит». Не сообразит. Не потому что плохой, а потому что «всякое такое» в голове у заказчика разворачивается в десяток конкретных сценариев, о которых исполнитель даже не подозревает. Он сдаёт то, что понял, заказчик говорит «это вообще не то», начинается череда переделок, бюджет ползёт вверх, сроки едут, обе стороны раздражаются.
Лечится это одной вещью — внятным описанием задачи. И вопреки страху новичка, ТЗ на бота — это не многостраничный документ с программистскими терминами. Это полторы страницы понятного человеческого текста, который опытный разработчик читает за десять минут и сразу называет честную цену, а не страхует себя завышенной из-за тумана в задании. Ниже — как собрать такое ТЗ блок за блоком: как описать сценарии, что писать про интеграции и как заранее закрыть вечную тему бесконечных правок.
Эта статья — часть раздела «Разработка ПО». Рядом полезно прочитать, сколько стоит каждый уровень бота, и сперва определиться, бот это или скрипт.
Что вы узнаете из статьи
- Из каких блоков состоит рабочее ТЗ на бота
- Как описать сценарии, даже если вы далеки от программирования
- Что обязательно прописать про интеграции и данные
- Как закрыть тему правок, чтобы не уйти в бесконечную доработку
- Что считать выполненной работой при приёмке
Шесть блоков рабочего ТЗ
Хорошее задание на бота держится на шести опорах. Пройдитесь по ним — и документ соберётся почти сам.
Задача и аудитория. Зачем нужен бот и кто им будет пользоваться. Бот для записи клиентов салона и бот для внутренней отчётности сотрудников — это разные продукты по тону, логике и требованиям к надёжности. Сначала определитесь, бот это или скрипт вообще, чтобы не описывать интерфейс там, где он не нужен.
Основные сценарии. Что именно бот умеет, по шагам. Это сердце ТЗ, ему ниже отдельная глава.
Интеграции. С какими внешними сервисами бот работает: CRM, платёжная система, таблицы, сторонние API. Каждая интеграция влияет на цену и срок, поэтому называть их нужно конкретно.
Данные и админ-панель. Что бот хранит (заявки, профили, история) и нужна ли владельцу панель, где это видно и чем можно управлять. Иногда админка не нужна, иногда без неё бот бесполезен — это стоит решить сразу.
Хостинг и поддержка. Где бот будет жить, кто платит за сервер, кто чинит баги после запуска и сколько это стоит. Пункт скучный, но именно он всплывает сюрпризом, если о нём не договориться.
Сроки и приёмка. Дедлайн, промежуточные точки (например, демо логики до интеграций) и список того, что считается готовой работой.
Сценарии решают половину дела
Здесь живёт главное недопонимание. «Я же не программист, как я опишу логику» — и ровно после этой фразы проект уходит в долгие переделки. Хорошая новость: описывать сценарий нужно не кодом, а обычным рассказом про путь пользователя. Вы же знаете, что человек должен делать, — вот это и опишите, шаг за шагом.
Возьмите главный сценарий и проговорите его как историю. «Пользователь нажимает старт — бот здоровается и показывает меню из трёх кнопок — человек выбирает "записаться" — бот спрашивает услугу, потом удобную дату — пользователь выбирает — бот подтверждает запись и присылает напоминание за день». Всё. Такой рассказ понятнее любой схемы, и по нему разработчик точно видит поведение бота.
Обязательно добавьте развилки и тупики — то, о чём новички забывают. Что бот отвечает, если свободных слотов нет? Что делает, если пользователь написал ерунду вместо нажатия кнопки? Что происходит, если человек бросил диалог на середине и вернулся через час? Эти «а если» — не придирки, а половина реальной работы. Чем больше развилок вы продумали в ТЗ, тем меньше сюрпризов на приёмке. И не забудьте про интеграции внутри сценария: если на шаге оплаты бот должен сходить в платёжную систему, а после — записать заказ в CRM, это надо проговорить отдельно. Как такие связки устроены и во что обходятся, мы разобрали в материале про интеграции с CRM и оплатой.
Технические детали и данные
Эту часть заказчики проскакивают, а потом получают сюрприз на финише. Договоритесь заранее о нескольких вещах, которые сильно влияют на результат и цену.
Первое — конкретные интеграции. Не «подключить CRM», а «подключить amoCRM, создавать сделку при новой заявке». Не «принимать оплату», а «через ЮKassa, с проверкой статуса платежа». Названия сервисов меняют оценку в разы: у разных систем разные API, разная сложность, разные подводные камни. Общая формулировка гарантирует неверную смету.
Второе — данные и доступ. Что бот хранит и кто к этому имеет доступ. Заявки клиентов — это персональные данные, и где они лежат, кто их видит, как выгружаются — вопрос не праздный. Заодно решите, нужна ли админ-панель: иногда хватает выгрузки в таблицу, иногда нужен полноценный кабинет с фильтрами и статистикой.
Третье — исходники и хостинг. Кому принадлежит код после оплаты, передаются ли исходники, где бот будет работать и кто оплачивает сервер. Это та же история, что с любым заказным ПО: договариваться задним числом всегда дороже и неприятнее, чем прописать строчку в начале.
Правки и приёмка без споров
Бесконечные правки — главная причина, по которой проекты по ботам ссорят заказчика и разработчика. И лечится это одной строчкой в задании. Пропишите конкретно: сколько кругов доработок входит в стоимость, а что считается дополнительной работой. Например, два круга правок по согласованным сценариям включены, новые сценарии и фичи сверх ТЗ — по отдельной ставке.
Это честно по отношению к обеим сторонам. Вы понимаете, за что платите и где граница, а разработчик не проваливается в бесконечное «а давайте ещё вот это» без оплаты — а именно от страха перед таким сценарием он и закладывает запас в первоначальную цену. Чёткая формулировка правок нередко сама по себе снижает смету.
И договоритесь о критериях приёмки заранее. Что считается готовым ботом: какие сценарии работают, какие интеграции подключены, передан ли код, есть ли инструкция для администратора. Полезно прописать, что приёмка идёт на тестовых данных по списку сценариев из ТЗ — прошли по списку, всё отработало, работа принята. Тогда финал проекта — спокойная передача, а не спор о том, кто что имел в виду. А чтобы дойти до этого финала с адекватным исполнителем, стоит заранее посмотреть, как проверить исполнителя.
Как платформа помогает с ТЗ
На Где.Эксперт не обязательно приносить идеальное ТЗ с первого раза. Достаточно описать задачу человеческим языком — что бот делает, для кого, какие сценарии, — и в откликах исполнители сами зададут уточняющие вопросы, которые вы упустили. Это, по сути, бесплатная вычитка задания: грамотный разработчик сразу спросит про развилки, интеграции и данные, и ваше ТЗ станет полнее ещё до старта работ.
Качество вопросов в откликах — заодно и фильтр исполнителей. Тот, кто вместо «сделаю за N» уточняет, что происходит при пустом расписании и куда писать заявки, обычно надёжнее того, кто молча называет цену. Оплата идёт по факту, а отзывы прошлых заказчиков показывают, доводит ли человек подобные проекты до рабочего результата.
Часто задаваемые вопросы
Нужно ли заказчику самому писать ТЗ на бота?
Технические детали пишет разработчик, но заказчик даёт понятное описание задачи: что бот делает, для кого, какие сценарии и интеграции. Это полторы страницы человеческого текста, не код.
Из каких блоков состоит ТЗ на бота?
Задача и аудитория, основные сценарии, интеграции, данные и админ-панель, хостинг и поддержка, сроки и приёмка. Пройдитесь по ним — документ соберётся.
Что обязательно прописать про правки?
Сколько кругов доработок входит в стоимость и что считается дополнительной работой сверх согласованных сценариев. Это снимает главный источник конфликтов.
Что писать про интеграции?
Конкретные сервисы: какая именно CRM, какая платёжка, какие API. Общая формулировка без названий приведёт к неверной оценке цены и срока.
Как описать сценарии, если я не технарь?
Опишите путь пользователя по шагам обычными словами: нажал старт, бот показал меню, выбрал запись, бот спросил дату, подтвердил, получил напоминание.
Заключение
ТЗ на бота — это не страшный технический документ, а понятный рассказ о том, что бот делает, для кого и как себя ведёт в нестандартных ситуациях. Шесть блоков — задача, сценарии, интеграции, данные, хостинг, приёмка — и пара строк про правки закрывают почти все будущие конфликты ещё до того, как написана первая строка кода.
Запомните главное: описывайте сценарии как историю про путь пользователя, называйте интеграции конкретно, продумайте развилки и «а если», и обязательно зафиксируйте число правок и критерии приёмки. Тогда первая же версия попадёт близко к цели, а не в молоко, и смета не разъедется с ожиданиями.
Опубликуйте задачу на Где.Эксперт — приложите описание сценариев, получите уточняющие вопросы от исполнителей и платите по факту выполнения.