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