Техническое задание на автоматизацию: что в нём должно быть, чтобы подрядчик сделал то, что нужно

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

Хорошее задание на автоматизацию отличается от плохого не объёмом, а тем, что в нём зафиксировано.

С чего начинается задание

Не со списка функций, а с решения. Первая строка задания должна отвечать на вопрос, какое решение станет возможным после внедрения и кто его принимает. Всё остальное проверяется на соответствие этой строке.

Задание, которое начинается со слов «нужен дашборд», почти всегда приводит к спору о том, что именно имелось в виду. Задание, которое начинается со слов «руководитель отдела продаж должен по понедельникам решать, кого догружать заявками», не оставляет места для разночтений.

Что обязательно фиксируется

Источники данных, по одному, с указанием доступа. Не «данные из CRM», а какая CRM, какие сущности, какие поля, кто даёт доступ и в каком объёме.

Определения показателей. Что считается лидом, что квалифицированным лидом, в какой момент сделка считается выигранной, как считается конверсия. Это самая частая причина переделок, и она же самая дешёвая для предотвращения: полчаса разговора до начала работ.

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

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

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

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

Что фиксировать не надо

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

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

Как проверять результат

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

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

Красные флаги на стороне подрядчика

Не задаёт вопросов о ваших данных. Значит, будет делать по шаблону и упрётся в первую же особенность.

Обещает срок до того, как посмотрел источники. Срок автоматизации определяется состоянием данных, а не количеством экранов.

Не спрашивает про определения показателей. Значит, посчитает по-своему, и вы узнаете об этом на приёмке.

Предлагает начать с красивого макета. Оформление это последний этап, а не первый.

Что сделать на этой неделе

Возьмите задачу, которую собираетесь отдать на автоматизацию, и напишите одну страницу: решение, источники, определения, форма выдачи, поведение при сбое, условия приёмки.

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

Как устроен процесс с моей стороны: https://ilkaev.com/uslugi/