Техническое задание на автоматизацию: что описать заказчику

Фраза «нужен удобный кабинет» задаёт направление, но не объясняет, какую работу он должен поддерживать. Для оценки полезнее описать, что происходит с обращением от поступления до завершения и кто принимает решения по пути.

Подготовьте описание бизнес‑процесса

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

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

Если цель сформулирована как конкретное изменение работы, проще отделить нужные функции от пожеланий на будущее.

Подготовьте ответы на семь вопросов

1. Кто начинает процесс и в каком месте?
2. Какие сведения поступают на входе?
3. Кто проверяет данные и принимает решение?
4. Какие этапы проходит задача?
5. Что считается завершением?
6. Куда нужно передать результат?
7. Что происходит при ошибке или исключении?

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

Скриншоты существующих инструментов полезны как пояснение, но не заменяют описание ожидаемого действия.

Разделите роли и доступы

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

Не ограничивайтесь названиями ролей. Для каждой перечислите видимые записи и разрешённые действия. Общий подход описан в статье о доступах в кабинете.

При передаче файлов необходимо определить, кто видит вложения и сохраняется ли доступ после завершения работы.

Опишите данные и границы подключения

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

Зафиксируйте, входит ли перенос истории, настройка уведомлений и работа с нестандартными объектами. Если требуется ИИ, укажите, какой черновик он готовит и кто подтверждает результат. Наличие модели не решает автоматически вопрос о доступности рабочих данных.

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

Согласуйте критерии приёмки

Для каждого важного действия нужен пример проверки. Например: после создания обращения оно появляется у ответственного; после отказа автор видит причину; повторная отправка не создаёт вторую такую же заявку.

Добавьте ситуации без ответа внешней системы и с недостаточными правами. Исполнитель должен понимать ожидаемую реакцию, а заказчик иметь возможность проверить её без чтения кода.

Полезно отдельно перечислить дальнейшие идеи. Они сохранятся, но не будут незаметно расширять первую оценку.

Пример задания, которое уже можно обсуждать

«Нужен реестр хозяйственных заявок одного офиса. Сотрудник указывает проблему и кабинет, администратор назначает исполнителя, автор видит результат. Заявка без кабинета остаётся на уточнении. При повторном нажатии “Отправить” не появляется второй экземпляр. В первой версии нет закупок, оплат и переноса архива».

К этому описанию добавьте действующую систему, доступные способы выгрузки и три реальных обезличенных примера. Если хочется ИИ, сформулируйте отдельно: «предложить категорию по тексту, показать исходник, дать администратору подтвердить». Так функция модели становится проверяемой частью процесса.

Возможности готовых платформ стоит выяснить до оценки. Например, 1С предоставляет механизмы REST‑обмена, но для задания важнее конкретная база, доступные объекты и ответственный за её обслуживание. Исполнитель проверяет эти условия до того, как обещать подключение.

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

Где хранить открытые вопросы и изменения

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

При изменении задания фиксируйте новое правило и затронутую проверку. Например, добавление заместителя меняет доступы и уведомления, а требование работать без интернета меняет сценарий сохранения. Одна короткая просьба может затронуть несколько частей продукта.

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

Кто готовит итоговый документ

Владелец процесса подтверждает правила бизнеса. Исполнитель уточняет технические возможности, ограничения и способ проверки. Это совместная работа: от заказчика не требуется заранее выбирать устройство базы или способ передачи запросов.

В TRIKE можно прийти с описанием одного процесса и примерами. Посмотрите согласование заявок или интеграцию. До реализации логику полезно проверить на прототипе.

Смежные разборы: Подготовка данных к автоматизации: справочники без путаницы; Внедрение ИИ в бизнес: как проверить одну задачу на пилоте.