Техническое задание на разработку системы: что должно быть внутри и что делает его рабочим

Техническое задание чаще всего пишут ради договора: чтобы было что подписать, прежде чем начинать. Рабочее ТЗ — другое: по нему можно проверить результат и объяснить, почему та или иная доработка не входит в объём. Если документ не позволяет ответить на эти два вопроса, решения всё равно будут приняты — только в коде, без вас.

Что должно быть в ТЗ

• Границы системы: что входит, а что осознанно не входит. Последнее важнее: именно здесь возникает большинство споров.
• Процессы в целевой логике: как работает заказ, заявка, документ, согласование после внедрения, а не как сейчас.
• Роли и права: кто видит, кто меняет, кто утверждает, у кого доступ внешний — с описанием интерфейса под каждую роль.
• Сущности и состояния: из чего состоит система и какие переходы между состояниями допустимы, кто их выполняет.
• Интеграции: системы, направление обмена, частота, владелец справочников, поведение при недоступности внешней системы.
• Данные: откуда переносим, что делаем с расхождениями, что храним и как долго, какие требования к защите персональных данных.
• Отчёты и выгрузки: какие цифры нужны, кому и с какой периодичностью.
• Критерии приёмки: проверяемые формулировки. Не «удобный интерфейс», а «руководитель видит данные за предыдущий день к 10:00».
• Этапы: состав первого контура и точка, в которой он считается работающим.

Чем ТЗ отличается от архитектуры и от прототипа

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

• Архитектура — решения и их причины: где источник правды, что происходит при сбое интеграции, почему выбран такой вариант.
• ТЗ — состав работ и критерии приёмки: что делаем, в каком объёме, чем докажем, что сделано.
• Прототип — сценарии и интерфейс: как человек выполняет свою задачу и что видит на экране.
• Оценка — следствие всех трёх, а не отдельный документ с одной цифрой: без объёма и критериев она превращается в спор на приёмке.

Как ТЗ делается на практике

ТЗ не пишут из головы за один вечер: источником становятся люди, которые работают в процессе. Мы начинаем с обследования — интервью, разбор данных, текущих обходных путей, — и из него собираем требования, прототипы ключевых экранов, этапы и оценку. За 7–10 рабочих дней это даёт документ, с которым можно идти к бюджету или к другому подрядчику: результат остаётся у заказчика независимо от того, кто делает разработку.

• Собираем факты, а не пожелания: какие документы, роли, системы и цифры участвуют в процессе сейчас.
• Фиксируем целевую логику и то, что меняется в работе людей после внедрения.
• Описываем роли, состояния и интеграции в объёме, достаточном для разработки и приёмки.
• Пишем критерии приёмки в проверяемых формулировках и согласуем их до начала работ.
• Отдельным разделом — допущения и открытые вопросы: их лучше назвать вслух, чем обнаружить в середине проекта.

Сколько стоит и когда окупается

Обследование, из которого получается ТЗ и оценка: 50 000 ₽ за 7 дней в базовом варианте, 75 000 ₽ за 10 дней — в расширенном, с экономическим обоснованием и материалами для защиты бюджета внутри компании. Разработка считается после: минимальный бюджет от 300 000 ₽, типичный проект около 500 000 ₽ и 3–6 месяцев, оплата по этапам 50/50.

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