Как написать техническое задание на разработку программы

Зачем писать, если и так всё понятно

Понятно — но каждому по-своему. В этом и проблема.

Типичная история: заказчик говорит «нужен учёт заказов», разработчик кивает. Через три месяца выясняется, что заказчик имел в виду ещё и взаиморасчёты с поставщиками, а разработчик — нет. Оба правы, потому что никто не записал.

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

Что должно быть внутри: чек-лист

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

Роли и права. Кто работает в системе и что каждому доступно. Отдельно — что человек НЕ должен видеть: закупочные цены, чужие сделки, зарплаты.

Функции и экраны. Перечень того, что программа делает. Не «удобный интерфейс», а «список заказов с фильтром по статусу и дате».

Интеграции. С чем обменивается данными, в какую сторону, как часто и что происходит, если вторая система недоступна.

Данные на старте. Что переносим, откуда и в каком объёме.

Смета и этапы. Сколько стоит и в каком порядке делается.

Критерии приёмки. Как понять, что этап сдан. Без этого сдача превращается в спор о вкусах.

Три ошибки, которые встречаются чаще всего

Писать ТЗ силами одного руководителя. Детали процесса живут у тех, кто им занимается ежедневно. Без двух-трёх встреч с ними документ описывает идеальную компанию, а не вашу.

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

Считать ТЗ бюрократией. Документ на 20-40 страниц стоит долю процента от проекта и убирает самый дорогой класс сюрпризов. При этом он ваш: с ним можно пойти к любому подрядчику и получить сравнимые предложения.