Что первая версия должна делать от начала до конца?
Начинайте с людей, а не с команд. Кто открывает бота, зачем он пришёл и что должно быть сделано к тому моменту, когда он закроет чат? Клиент, который записывается на визит, сотрудник, который сдаёт отчёт, и руководитель, который утверждает заявку, — это три разных пути, и каждый из них нужно описать отдельно. Клиентскими сценариями занимается разработка Telegram-ботов, а внутренними, вроде отчётов и согласований, — автоматизация бизнеса через Telegram.
Для того пути, с которого вы начнёте, запишите, откуда приходит пользователь, какие данные бот должен собрать, где сценарий разветвляется и какое сообщение человек видит в конце. Для каждого шага сразу запишите, какие ответы считаются правильными и что бот говорит, если человек ввёл что-то не то. Затем добавьте менее очевидные случаи: человек вернулся после перерыва, передумал на середине, дважды нажал одну и ту же кнопку. Такие ситуации составляют заметную часть реального использования, и именно на них первым делом натыкаются при тестировании.
Первая версия должна быть настолько компактной, чтобы весь путь можно было проверить на реалистичных примерах. Список из сорока команд без понятного результата сложнее разработать, сложнее проверить и сложнее оценить, чем один сценарий, который правильно работает от начала до конца. Когда этот сценарий заработает и им начнут пользоваться, вы будете гораздо лучше понимать, что добавлять дальше.
От каких систем и людей зависит бот?
Бот для бизнеса редко работает сам по себе. Перечислите все системы, из которых он берёт данные или в которые их записывает, — CRM, календарь записи, складскую базу, таблицу — и для каждой укажите, кто управляет доступом и какие данные нужны боту. Если какой-то системы ещё нет и данные пока ведутся вручную, так и напишите: это тоже влияет на объём работ. Здесь важны правила сопоставления: как бот узнаёт уже существующего клиента и что означает каждый статус. Обсудите эти правила с теми, кто отвечает за каждую систему, ведь именно им потом работать с результатом.
Запишите и ограничения. Какие роли есть и что разрешено каждой из них? Нужно ли согласие пользователя на получение сообщений и как от них отказаться? В какой момент разговор переходит к живому сотруднику и кто его подхватывает? Эти ответы влияют на устройство бота не меньше, чем основной сценарий.
Одно практическое правило: никогда не вписывайте в бриф пароли, ключи API или токен бота. Вместо этого укажите, что нужен доступ, к какой системе и кто его предоставит. Тогда документ можно спокойно пересылать, а все зависимости проекта видны с первого взгляда.
Как превратить бриф в критерии приёмки?
Для каждого сценария опишите, что должно происходить в обычном случае и при самых вероятных сбоях: не хватает обязательных данных, внешняя система не отвечает, одно и то же событие пришло дважды. Для каждого случая укажите две вещи: что видит пользователь и что в итоге оказывается в вашей рабочей базе. Если одно расходится с другим, это рано или поздно заметят, и обычно первым это замечает клиент. Хорошо помогают примеры: несколько настоящих, но обезличенных заявок или отчётов, на которых разработчики смогут проверить сценарий.
До начала работ решите и практические вопросы. Кто получает исходный код и доступ к серверу? Кто следит за работой бота после запуска и кто реагирует, когда он ломается? Что входит в поддержку, а что считается новой работой? Если записать это сейчас, потом не придётся вести неловкие разговоры.
У чётко очерченной первой версии есть ещё одно преимущество. Когда появляются новые идеи, а они появляются всегда, каждую можно описать, оценить и поставить в очередь как отдельную доработку. Без такой точки отсчёта дополнительные функции попадают в проект как молчаливые допущения, и уже никто не может сказать, какая работа была запланирована, а какая нет.
Чек-лист: бриф бота
- Опишите одну задачу целиком, включая возвращение пользователя и отмену.
- Перечислите интеграции, нужные данные и тех, кто отвечает за доступ к каждой системе.
- Напишите сообщения, которые пользователь увидит при ошибке или отмене.
- Укажите, что должно оказаться в рабочей базе в каждом сценарии.
- До начала разработки договоритесь о приёмке, передаче кода и дальнейшей поддержке.
Пример: отчёты выездной бригады
Выездная бригада через бота отправляет статус каждого заказа вместе с фотографией. Руководитель проверяет отчёт, и только одобренное обновление попадает в карточку заказа. Бриф описывает, что происходит, если фото не приложено, если отчёт отправлен дважды и если сервер на время недоступен, а также что в каждом из этих случаев видят мастер и руководитель.
Общий чат с клиентами и приём платежей тоже обсуждали, но сознательно оставили за рамками: они записаны как возможные решения на будущее, а не как часть первой версии.
