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

Я работаю продакт-менеджером и бываю по обе стороны: сам ставлю задачи подрядчикам и сам разбираю чужие брифы, когда к нам приходят с запросом на автоматизацию. Ниже я написал, что нужно дать подрядчику в качестве требований, чтобы получить честную оценку, сравнимые предложения и проект, который доедет до работы. Технического бэкграунда для этого не нужно.

Желание это еще не задача

Типичный первый запрос выглядит так: «Хотим бота, который сам разбирает голосовые отчеты сотрудников и заполняет данные в CRM». Звучит конкретно и казалось бы понятно, но это желание, а не задача. В таком задании нет ответов на вопросы, от которых зависит цена и сложность проекта в целом:

• сколько таких отчетов в день и сколько людей их присылают;

• в каком виде они приходят — голос, текст, фото, все вперемешку;

• что именно нужно заполнить в CRM и по каким правилам;

• что происходит сейчас, когда отчет не пришел или пришел с ошибкой;

• кто проверяет результат и что будет, если система ошибется.

Один подрядчик прочитает этот запрос как «распознать голос и положить текст в комментарий» и оценит в неделю работы. Другой — как «разобрать отчет, сверить объемы с планом, обновить статусы и предупредить руководителя» и оценит в два месяца. Оба правы, просто это две разные задачи.

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

Опишите процесс, а не решение

Самая частая ошибка, прийти с готовым решением: «нужен чат-бот», «нужна нейросеть для документов». Решение — это работа подрядчика. Ваша работа — честно описать, как процесс устроен сейчас и где в нем теряются время и деньги.

Достаточно ответить на пять вопросов:

1. Кто участвует ? Кто запускает процесс, кто его делает, кто получает результат. Должности и количество людей.

2. Что происходит по шагам ? От первого события до итога: пришло письмо → менеджер прочитал → перенес данные в таблицу → согласовал с руководителем.

3. Как часто ? Сколько раз в день или в месяц и сколько времени занимает один раз. Приблизительных цифр достаточно.

4. Где данные ? Откуда приходит информация и куда она должна попасть: почта, мессенджер, CRM, 1С, Excel, бумага.

5. Что болит ? Где именно теряются время, деньги или качество: ручной перенос, опечатки, забытые задачи, ожидание руководителя.

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

Приятный побочный эффект (особенно приятный для малого бизнеса): когда процесс записан честно, часть проблем решается без автоматизации. Иногда проще убрать лишний шаг или договориться о едином формате, чем учить систему разбирать хаос.

Покажите живые примеры, включая плохие

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

Главное правило: не выбирайте лучшие. Системе будут приходить все документы подряд, поэтому в наборе должны быть:

• типичные случаи — то, что приходит чаще всего;

• трудные — скан со складкой, голосовое с шумом стройки, счет нестандартной формы;

• ошибочные — где сотрудник перепутал проект, забыл цифру, написал не по форме;

• пример правильного результата — как этот документ сейчас оформляет человек.

Идеальная пара — «что пришло» и «что из этого сделал сотрудник». По таким парам подрядчик за час понимает больше, чем за неделю созвонов. А вы потом принимаете работу на тех же примерах, а не на красивом демо.

!!! Если примеров собрать не удается, это тоже сигнал. Возможно, процесс еще не сложился, и автоматизировать пока нечего.

Договоритесь, что считать результатом

Фраза «чтобы работало» не поможет ни при оценке, ни при приемке. До старта нужно записать, что именно изменится и как вы это проверите.

Начните с точки «до». Сколько часов в неделю уходит на процесс, сколько ошибок в месяц, как долго документ идет от получения до обработки. Без этих цифр через три месяца не понять, окупился ли проект. А собрать их задним числом уже не получится.

Затем опишите критерий приемки на языке бизнеса:

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

Отдельно про точность. Сто процентов ИИ-система не даст, как и сотрудник, который делает эту работу сейчас. Полезнее сравнивать с текущим уровнем ошибок людей, а не с идеалом.

Опишите исключения и цену ошибки

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

Для каждого шага процесса ответьте на два вопроса.

Сколько стоит ошибка ? Неверно разложенное по папкам фото — мелочь. Неверная сумма в документе для клиента — это деньги и репутация.

Что делать, когда система не уверена. Вариантов обычно три:

• уточнить у сотрудника, который прислал данные;

• передать ответственному человеку с пометкой «на проверку»;

• ничего не делать и записать случай в отчет.

Это и есть «человек в контуре» (он же man in loop), только словами бизнеса. На старте лучше перестраховаться: пусть система чаще спрашивает. Когда появятся данные о том, как часто она права, самостоятельность можно расширять.

Чего в задаче быть не должно

Хорошее ТЗ короче, чем кажется. Вот что можно смело вычеркнуть.

Выбор технологий. «Сделайте на ChatGPT» или «нужна нейросеть последнего поколения» сужает варианты и часто удорожает проект. Исключение — жесткие ограничения, которые обычно связаны с законами: «только российские сервисы» или «всё на наших серверах». Их пишите обязательно.

Список из сорока желаний. Чем длиннее список, тем труднее понять, что важно. Лучше три задачи с приоритетами. Дорогие проекты часто рождаются из пункта заодно хорошо было бы… .

Требование нуля ошибок. Честный подрядчик на него не согласится, а согласившийся должен вызвать недоверие. Вместо этого поймите и запишите допустимый уровень ошибок и понятный порядок действий, когда она случилась.

Вместо вывода

Постановка задачи — самая дешевая часть проекта и самая дорогая для исправления. Два-три часа на описание процесса и сбор примеров экономят недели переделок и делают цены разных подрядчиков сравнимыми.

Коротко:

1. Опишите процесс как есть, а не желаемое решение.

2. Приложите настоящие примеры, включая плохие.

3. Запишите метрику «до» и проверяемый критерий приемки.

4. Опишите исключения и цену ошибки.

А как вы ставите задачи подрядчикам — и на чем обжигались? Давайте обсудим в комментариях.