Хорошее техническое задание на внедрение ИИ отвечает на семь вопросов: какой процесс меняем и как он идёт сейчас, как выглядит «сделано», откуда берутся данные, что система делать не должна, кто и что утверждает, как проверяется выполнение действия и что происходит при ошибке. Больше ничего не нужно, а меньше - опасно.
Документ не обязан быть длинным. Две страницы, отвечающие на семь вопросов, работают лучше двадцати страниц с описанием возможностей искусственного интеллекта. Ниже - разбор каждого вопроса, пары формулировок «плохо и хорошо» и готовый пример.
Зачем вообще писать ТЗ, если подрядчик обещал разобраться
Разобраться он действительно может, и хороший исполнитель половину этой работы сделает сам. Проблема не в его квалификации, а в том, что без записанного документа у вас нет общей картины того, о чём договорились.
Проверяется это одним признаком: если в конце проекта возможен спор «мы ждали другого», значит ТЗ не хватало. Спор такой почти всегда возникает вокруг двух вещей - что считается готовым и что система делать не должна.
Второе назначение документа сугубо практическое. С одинаковым ТЗ можно пойти к трём подрядчикам и получить три сравнимых предложения. Без него вы получите три разных описания разных работ и не сможете сравнить даже цены.
Семь вопросов, на которые отвечает ТЗ
| Плохая формулировка | Хорошая формулировка |
|---|---|
| «Внедрить ИИ в отдел продаж» | «Разбирать входящие заявки с сайта и почты: определять тему, срочность и источник, заводить карточку в CRM» |
| «Сделать так, чтобы работало хорошо» | «85% заявок разбираются без правки менеджером, замер на 200 заявках за две недели» |
| «Использовать наши данные» | «Источники: выгрузка из CRM за год (csv), 40 регламентов в docx, почтовый ящик sales@. Часть регламентов устарела, актуальные помечены» |
| «Система не должна ошибаться» | «Система не меняет сумму сделки, не пишет клиенту напрямую и не меняет статус на "оплачено"» |
| «Согласовать с руководством» | «Приёмку подписывает руководитель отдела продаж, спорные случаи решает коммерческий директор» |
| «Проверить, что всё работает» | «После записи в CRM система перечитывает карточку и сверяет поля; расхождение - три попытки, потом задача Ивану» |
| «Обеспечить поддержку» | «Ошибки уходят в очередь, её разбирает Иван, 30 минут в день; критичные сбои - подрядчик в течение рабочего дня» |
Какой процесс меняем и как он работает сейчас
Описывается не идеальный процесс из регламента, а фактический: кто начинает, куда передаёт, где застревает, что делают при отклонении. Обязательно с цифрами: сколько таких задач в неделю. От объёма зависит, окупится ли работа вообще.
Как выглядит «сделано»
Самый важный пункт документа. Критерий должен быть измеримым и проверяемым на конкретном наборе: «столько-то процентов на выборке из стольких-то случаев за такой-то период». Формулировка «работает корректно» приёмкой быть не может, потому что её нельзя ни подтвердить, ни опровергнуть.
Откуда система берёт данные и в каком они состоянии
Перечисляются источники с форматами и честной оценкой качества. Если половина документов - сканы, а инструкции существуют в трёх версиях, это пишется прямо. Скрытый бардак всё равно всплывёт, но уже внутри проекта и за ваш счёт по срокам.
Что система делать не должна
Список запретов конкретнее списка возможностей. Обычно сюда попадают операции с деньгами, прямая переписка с клиентами и изменение статусов, за которыми стоят обязательства. Эти запреты потом живут в правах доступа, а не в инструкции для модели.
Кто и что утверждает
Имя человека, который подписывает приёмку, и имя того, кто решает спорные случаи. Без этого приёмка растягивается на недели согласований между отделами.
Как проверяется, что действие выполнено
Отдельный пункт, потому что это самая тихая поломка интеграций: сервер отвечает «принято», а данные не изменились. В ТЗ пишется, что после действия состояние перечитывается и сверяется с ожидаемым. Подробнее об этом - в разборе того, почему проекты не доходят до результата.
Что происходит, когда система ошибётся
Маршрут ошибки: куда уходит задача, кто её разбирает, сколько времени на это выделено. Плюс поведение в первый месяц, когда каждое действие подтверждает человек.
Что в ТЗ писать не нужно
Названия моделей, фреймворков и баз данных. Это выбор исполнителя, и, зафиксировав его, вы берёте на себя ответственность за чужое решение, ничего не выигрывая.
Описание того, что такое искусственный интеллект и почему он полезен. Подрядчик это знает, а документ становится длиннее и хуже читается.
Требования вида «современный интерфейс» и «высокая производительность» без чисел. Они не проверяются, а значит не работают.
Полную схему архитектуры, если вы не архитектор. Достаточно ограничений: где могут лежать данные, с какими системами обязательна интеграция, что нельзя выносить наружу.
Шаблон ТЗ
Скелет из семи блоков. Каждый пункт - несколько предложений, весь документ помещается на две страницы.
1. Процесс
Что за задача, кто её выполняет сейчас, сколько раз в неделю, где застревает. Что происходит при отклонении от обычного хода.
2. Результат
Что считается сделанным. Измеримый критерий, набор для проверки, срок замера.
3. Данные
Источники с форматами, объём, честная оценка состояния. Кто отвечает за их актуальность после запуска.
4. Запреты
Что система не делает ни при каких условиях. Отдельно - что делает только с подтверждением человека.
5. Роли
Кто подписывает приёмку, кто решает спорные случаи, кто разбирает очередь ошибок после запуска и сколько времени на это выделено.
6. Проверка выполнения
Как система убеждается, что действие прошло. Сколько повторных попыток и что происходит после них.
7. Эксплуатация
Кто платит за вызовы модели и хостинг, кому принадлежат исходники и доступы, что происходит при расторжении договора.
Документ пишется в свободной форме, шапка и нумерация разделов значения не имеют. Важно, чтобы каждый из семи блоков содержал утверждение, которое можно проверить: не «данные в CRM», а «выгрузка за год в csv, 12 тысяч строк, поле "источник" заполнено у трети записей».
Если процессы в компании не разобраны и первый блок написать нечем, начинать стоит с аудита процессов: его результат - как раз материал для этого документа.
Как понять реакцию подрядчика на ваше ТЗ
| Что отвечает подрядчик | Что это значит |
|---|---|
| Задаёт вопросы про исключения и редкие случаи | Работал с реальной эксплуатацией, а не только с демо |
| Просит показать реальные данные до оценки | Понимает, что состояние данных двигает сроки сильнее сложности задачи |
| Спорит с критерием приёмки и предлагает свой, тоже измеримый | Хороший знак: значит, будет по нему отвечать |
| «Всё понятно, сделаем» без единого вопроса | Либо не читал, либо считает, что разберётся по ходу за ваш счёт |
| «ТЗ не нужно, мы работаем гибко» | Гибкость закончится на этапе приёмки, когда сравнивать будет не с чем |
Правило простое: чем больше уточняющих вопросов на этапе ТЗ, тем меньше сюрпризов на этапе сдачи. Восемь вопросов, которые стоит задать в ответ, собраны в материале про то, как выбрать подрядчика.
Частые вопросы
Нужно ли ТЗ, если проект небольшой?
Нужно, но короткое. Для пилота на одной задаче хватает половины страницы: что за процесс, что считается успехом, откуда данные и что система делать не должна. Остальные три блока при коротком проекте обсуждаются устно и записываются одной строкой в переписке. Полностью обойтись без документа плохо даже на маленькой работе: спор «мы ждали другого» возникает независимо от размера бюджета.
Нужно ли оформлять ТЗ по ГОСТ 34?
Для внедрения ИИ в малом и среднем бизнесе - нет. ГОСТ разрабатывался под автоматизированные системы совсем другого масштаба и порядка согласования, и его применение здесь добавит недели работы, не улучшив результат. Исключение - если вы государственная организация или работаете по требованиям заказчика, где формат задан обязательными правилами. Тогда содержание из семи блоков просто раскладывается по разделам стандарта.
Подрядчик говорит, что ТЗ не нужно. Это нормально?
Наполовину. Подрядчик действительно может написать документ сам, и это нормальная практика: он делает это быстрее и точнее. Ненормально, если он утверждает, что документ не нужен вовсе. Тогда стоит спросить, чем будет измеряться приёмка и что вы сравните с обещанным. Внятного ответа обычно не следует.
Кто должен писать ТЗ - заказчик или подрядчик?
Обычно оба. Заказчик описывает процесс, ограничения и то, что считается успехом: этого никто, кроме него, не знает. Подрядчик переводит это в проверяемые формулировки и добавляет техническую часть: как проверяется выполнение, что происходит при отказе, кто платит за эксплуатацию. Документ, написанный одной стороной без второй, почти всегда оказывается неполным в своей половине.
Что делать, если процесс в компании не описан вообще?
Это обычная ситуация и не повод откладывать. Порядок такой: сначала неделя наблюдения за тем, как работа идёт на самом деле, потом карта процесса, потом ТЗ. Наблюдение обязательно, потому что описание «сверху» и фактический ход расходятся почти всегда. Такую работу можно взять отдельно как аудит процессов, а можно провести внутри пилота: как проходит пилот, разобрано отдельно.
Если писать ТЗ некому
Могу написать его вместе с вами. Тридцать минут по видео: разбираем процесс, я задаю недостающие вопросы и показываю, как формулировки из левой колонки превращаются в правую. Документ после этого остаётся у вас, и с ним можно идти к любому подрядчику.
Написать можно в Telegram или на почту hi@za-ai.ru.