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

Идеальное ТЗ — утопия, но многие болезненные моменты и конфликты на стадии приемки ��ожно предсказать и минимизировать. Часто они возникают не из-за злого умысла, а из-за слепых зон в документе.

1. НСИ (Справочники): «А мы думали, тут всё просто…»

Абстрактные требования вида «реализовать справочник контрагентов» или «систему классификации товаров».

В ТЗ необходимо требовать к каждому справочнику отдельную мини-спецификацию: цель, атрибуты (поля), правила заполнения, ответственная роль, связи с другими объектами системы.

Каталог товаров, работ, услуг (КТРУ)

В закупочных системах справочник ТРУ — это критически важный элемент, и его реализация кардинально различается для 44-ФЗ и 223-ФЗ. Непонимание этой разницы — частая причина проблем при разработке ТЗ.

Для 44-ФЗ используется единый обязательный Каталог ТРУ (КТРУ), который ведется в Единой информационной системе (ЕИС) и содержит строгие описания товаров.

Для 223-ФЗ нет единого каталога. Каждый заказчик формирует собственный Перечень ТРУ и публикует его в ЕИС в составе Положения о закупках.

Это фундаментальное различие определяет все остальные требования к системе.

Эти правовые различия формируют конкретные технические требования.

 Для системы по 44-ФЗ:

- Необходим механизм загрузки и синхронизации актуальных позиций КТРУ, так как он постоянно пополняется (интеграция с ЕИС).

- При создании технического задания (ТЗ) в системе поля для характеристик товара должны соответствовать структуре КТРУ и позволять формировать структурированную заявку, требуемую законом.

- Система должна препятствовать нарушению правил (например, изменению единицы измерения или названия из каталога). Должна быть функция прикрепления обоснования для любых дополнительных характеристик. 

Для системы по 223-ФЗ:

- Нужен инструмент, позволяющий Заказчику самостоятельно создавать, редактировать и структурировать свой перечень ТРУ без участия разработчика.

- Система должна готовить данные в формате, пригодном для публикации в ЕИС, как часть пакета документов.

- Логика работы модуля закупок (способы, лимиты) должна гибко настраиваться под конкретное Положение Заказчика.

Типовые проблемы в ТЗ на примере КТРУ

В ТЗ часто пишут просто «реализовать справочник ТРУ», не уточняя, о каком законе идет речь. Это фундаментальная ошибка, ведущая к неверной архитектуре.

Для 44-ФЗ интеграция с ЕИС для подгрузки КТРУ — обязательное условие. Её отсутствие или неполная реализация (без учёта дат обязательного применения позиций) сделает систему неработоспособной.

Если в одной системе пытаются объединить работу и по 44-ФЗ, и по 223-ФЗ, используя единый м��дуль справочников, то архитектурно это неверно. Логичнее создать разные подсистемы или четко изолированные модули.

 «Система должна содержать справочник товаров с возможностью их классификации». - Пример некорректного ТЗ.

«Для работы по 223-ФЗ система должна предоставлять интерфейс для создания иерархического перечня ТРУ с произвольными атрибутами. Для работы по 44-ФЗ система должна обеспечивать автоматическую ежедневную синхронизацию справочника ТРУ из раздела ЕИС с учётом даты начала обязательного применения каждой позиции». - Как должно быть.

Справочник ТРУ — это не техническая, а в первую очередь юридическая сущность. Разработка его в отрыве от норм конкретного закона гарантированно приведёт к переделкам.

2. Связанность модулей и дублирующий функционал: «Почему здесь не как там?»

Система разрастается, и похожие процессы появляются в разных модулях для разных пользователей (например, заявка на отпуск для офиса и для склада; создание карточки товара в CRM и в личном кабинете).

В ТЗ необходимо:

- Выделить сквозные би��нес-сущности (например, «Документ», «Заявка», «Задача») и описать их общую модель данных и жизненный цикл.

- Требовать явного описания различий. Если для «Менеджера по продажам» и «Кладовщика» процесс создания заявки должен отличаться — это должно быть четко прописано: какие поля/шаги/правила скрыты, добавлены или изменены.

3. Интеграции: «Мы же договорились, что они уже всё сделали!»

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

В ТЗ необходимо:

- На каждую интеграцию прописать цели, данные (что, куда, когда), частота, протокол (REST, SOAP, файлы), ответственные с обеих сторон.

- Обязательно прописать поведение системы при недоступности контура (сценарии ошибок).

- Четко определить, интеграция на каком объеме данных считается успешно завершенной (этапность).

4. Инфраструктура и развертывание: «А на чём это будет работать?»

ТЗ описывает функционал, требования к железу и среде, но молчит о замене оборудования.

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

В ТЗ необходимо прописать обязательный нефункциональный раздел: требования к производительности (нагрузка, время отклика), инфраструктуре (версии ПО, ОС, наличие интернета), отказоустойчивости, процедурам развертывания и отката.

5. Эволюция системы: «А можно на React переписать?»

Отсутствие описания текущей архитектуры и требований к технологиям.

Невозможность оценки. Непонятно, дорабатываем мы монолит или пишем модуль для микросервиса.

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

Решение «сделать пока так» закладывает проблемы на будущее. Возникает технический долг.

В ТЗ (ЧТЗ) необходимо прописать:

- Контекст и ограничения. Раздел с описанием текущей системы (если это доработка) — основные технологии, базы данных, точки интеграции.

- Требования к стеку. Если есть явные требования (например, «использовать только контейнеризацию Docker»), их нужно зафиксировать. Если их нет — зафиксировать свободу выбора исполнителем.

- Стратегия развития. Понятно ли, что это разовая доработка или первый шаг к постепенному обновлению всей системы?

Инструменты для фиксации процесса: ЧТЗ и протоколы

Идеального ТЗ не бывает, но его цель — минимизировать неопределенность.

Лучшее ТЗ — это не просто документ, а процесс.

Обязательны этапы уточнения (workshops), прототипирования интерфейсов (Figma, Sketch) и, самое главное, фиксация всех допущений и открытых вопросов хотя бы в виде частных технических заданий и/или официальных протоколов встреч Заказчика и Исполнителя, если работы уже стартанули.

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

Частное техническое задание (ЧТЗ) используется для детализации крупных, но еще не до конца ясных модулей до начала их разработки.

Например, Интеграция с 1С. В основном ТЗ — только цель.

ЧТЗ описывает методы API, форматы данных (XML/JSON), сценарии ошибок, объем тестовых данных, график совместного тестирования.

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

Например, на совещании 01 декабря 2025 года согласовано: для поля «Тип проекта» в справочнике добавить значение «Экспериментальный». Изменение вносится в текущий спринт и не влияет на сроки.

Практические шаблоны и стандарты

Для структурирования этого процесса можно опираться на существующие frameworks, помня об их гибкости.