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

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

Почему проверку нельзя заменить просто чтением

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

Обязательная структура ТЗ: что должно быть в любом документе

Независимо от отрасли (IT, строительство, оборудование, НИОКР), полное ТЗ содержит семь базовых блоков. Отсутствие любого из них делает документ негодным для отправке поставщикам.

• Область применения и цели: что входит в поставку, что не входит, какие бизнес-проблемы решаются, ключевые ограничения (бюджет, сроки, нормативы).
• Функциональные требования: что система/объект должна делать — сценарии использования, пользовательские роли, бизнес-процессы, алгоритмы расчетов.
• Нефункциональные требования: производительность, надежность, безопасность, удобство использования, масштабируемость, совместимость, требования к среде эксплуатации.
• Интерфейсы и интеграция: точки сопряжения с внешними системами, протоколы, форматы данных, API, механические/электрические стыки, версии сопрягаемых систем.
• Требования к данным и миграции: состав переносимых данных, правила очистки, маппинг полей, допустимые потери, процедура отката.
• Критерии приемки и тестирование: конкретные тест-кейсы, пороговые значения метрик, порядок проведения ПСИ/ОСИ, состав приемо-сдаточной документации.
• Коммерческие и организационные условия: этапы поставки, график платежей, штрафы, гарантии, обучение, документация, сервисная поддержка (SLA), права на ИП.

В государственных закупках (ФЗ-44, ФЗ-223) к этому добавляются обязательные реквизиты по приказам Минэкономразвития и технические регламенты. В коммерческих закупках структура свободнее, но логика полноты остается той же.

Чек-лист проверки каждого раздела: на что смотреть при аудите

Функциональные требования

• Каждый сценарий описан в формате «Как <роль>, я хочу <действие>, чтобы <результат>» или через Use Case / User Story с критериями готовности (Definition of Done).
• Исключены формулировки «система должна быть удобной/быстрой/современной» без измеримых параметров.
• Обработаны альтернативные и ошибочные сценарии (что происходит при обрыве связи, неверном вводе, отказе подсистемы).
• Есть перечень отчетов/выгрузок с полями, частотами, получателями и форматами.

Нефункциональные требования (качество)

• Производительность: время отклика (перцентили p95/p99), пропускная способность (TPS/RPS), объемы данных, пиковые нагрузки.
• Доступность: SLA (например, 99,9%), окна обслуживания, RTO/RPO для DR-сценариев.
• Безопасность: класс защиты (ФСТЭК/ФСБ для ГосТЗ), требования к шифрованию, аудиту, управлению доступом (RBAC/ABAC), защите от OWASP Top 10.
• Совместимость: браузеры/ОС/мобильные платформы с версиями, версии сопрягаемых систем (1С, SAP, СБИС и т.д.).

Интерфейсы и интеграция

• Для каждого интеграционного контура: схема взаимодействия, протокол (REST, SOAP, MQ, Kafka, файловый обмен), формат (JSON, XML, EDIFACT), схема валидации (XSD, JSON Schema).
• Версии API внешних систем и гарантии обратной совместимости.
• Обработка ошибок интеграции: ретраи, DLQ, ручное вмешательство, SLA внешней стороны.
• Тестовые контуры (sandbox) у поставщиков интеграции — есть или нужно разворачивать моки.

Критерии приемки — самый критичный блок

• Для каждого функционального требования есть хотя бы один проверяемый тест-кейс.
• Метрики нефункциональных требований имеют пороговые значения: «время отклика < 200 мс при нагрузке 100 RPS», а не «быстро».
• Описан порядок проведения приемо-сдаточных испытаний: кто, где, на каком стенде, с какими данными, состав протокола.
• Критерии входа/выхода в приемку (Entry/Exit criteria) — например, «все блокер-баги закрыты, критических < 3, прошло нагрузочное тестирование».

Алгоритм валидации ТЗ: три уровня проверки

Не пытайтесь проверить всё за один проход. Разделите процесс на уровни с разными участниками и целями.

1. Уровень 1 — Структурная полнота (автор ТЗ / бизнес-аналитик). Сверка по чек-листу разделов выше. Поиск пустых заголовков, ссылок на «приложение, которое будет позже», требований без владельца. Результат: список пробелов для доработки.
2. Уровень 2 — Качество требований (кросc-функциональная команда: архитектор, безопасник, тестировщик, юрист, закупщик). Каждое требование проверяется по критериям INVEST/ SMART и ISO/IEC/IEEE 29148: необходимо ли, однозначно ли, проверяемо ли, достижимо ли, прослеживаемо ли, непротиворечиво ли. Выявление дублей и конфликтов (например, «хранить данные 10 лет» vs «GDPR — право на удаление»).
3. Уровень 3 — Валидация приемо-сдаточных процедур (QA-лид + заказчик). Проход по тест-кейсам: можно ли их выполнить на чистом стенде без уточнений? Совпадают ли ожидаемые результаты с бизнес-целями? Есть ли тестовые данные и среда? Если тест-кейс требует «магического» действия — требование неполное.

Только после закрытия замечаний по третьему уровню ТЗ подписывается и уходит в закупку.

Матрица прослеживаемости (RTM) — главный инструмент контроля полноты

RTM (Requirements Traceability Matrix) связывает четыре уровня: Бизнес-цель → Требование ТЗ → Тест-кейс приемки → Компонент решения / Этап поставки. Если в матрице есть «висячие» узлы — ТЗ неполное.

Бизнес-цель / Стейкхолдер	ID требования в ТЗ	Тип требования	ID тест-кейса приемки	Этап поставки / Компонент	Статус проверки
Сокращение времени закрытия месяца на 30% (CFO)	FR-042	Функциональное	TC-105, TC-106	Модуль авто-сверки / Этап 2	Прошли L2, L3
Соответствие 152-ФЗ (Юрист)	NFR-SEC-012	Нефункциональное (Безопасность)	TC-SEC-040	Субсистема аудита / Этап 1	Конфликт с FR-015 (требует доработки)
Интеграция с 1С:ERP (ITD)	IF-007	Интерфейс	TC-INT-022	Адаптер 1С / Этап 1	Нет тестового контура у 1С (риск)

Строить RTM лучше в таблицах (Excel, Confluence, Jira, DOORS, Polarion) до отправки ТЗ. Это выявляет требования, к которым никто не писал тесты, и тесты, которые не покрывают ни одного требования.

Типичные пробелы, которые пропускают при чтении, но находит валидация

• Неявные зависимости от внешних систем: ТЗ требует «выгрузку в ГИС ЖКХ», но не указывает версию API ГИС, порядок получения тестового доступа, ответственность за изменения в API со стороны регулятора.
• Отсутствие требований к миграции исторических данных: «Система должна хранить историю 5 лет» — а как данные туда попадут? Кто чистит, кто мапит, какой процент потерь допустим, как откатываться.
• Скрытые требования к документации: Поставщик сдает код, а заказчик ожидает еще и архитектурную схему, ADR, инструкции администратора, пользователя, SBOM. Если это не в ТЗ — это доп. соглашение и бюджет.
• Противоречия между функционалом и безопасностью: «Любой сотрудник видит все отчеты» (функционал) vs «Доступ по ролям, принцип минимальных привилегий» (безопасность).
• Отсутствие критериев приемки для нефункционалки: Написано «система должна быть отказоустойчивой», но нет теста «отключаем один нод кластера — сервис не прерывается».
• Незакрытые права интеллектуальной собственности: Кто владеет кодом, кастомизациями, базой знаний, обученными моделями ML после завершения контракта?

Сценарии: как адаптировать проверку под тип закупки

Закупка коробочного ПО / SaaS (COTS)

Фокус на разрыве между стандартным функционалом и потребностями. Проверяйте: матрицу соответствия (Fit/Gap) — каждое требование отмечено как «из коробки», «настройка», «доработка», «нет». Для «доработки» — отдельное ТЗ на кастомизацию. Четкие SLA вендора, политика обновлений, выход из вендор-лока (экспорт данных).

Индивидуальная разработка (Custom Dev)

Полный цикл: от архитектуры до исходников. Критичны: процесс управления изменениями (Change Request), определение Definition of Ready / Done для спринтов, права на код, обязательность код-ревью и статического анализа (SAST/DAST), передача CI/CD пайплайнов.

Поставка оборудования / Комплексная автоматизация

Добавьте к базовым разделам: паспортные характеристики, допуски, климатическое исполнение, требования к пусконаладочным работам (ПНР), запасные части/комплекты (ЗЧ/ЗК), сервисные центры в регионе, сроки доставки ЗЧ, требования к фундаментам/коммуникациям (подготовка площадки заказчиком).

Государственная закупка (ФЗ-44 / 223)

Обязательна экспертиза ТЗ (внутренняя или внешняя) перед публикацией. Проверка на соответствие техническим регламентам, национальным стандартам, запрету ссылок на бренды (ст. 33 ФЗ-44), наличие обоснования максимальной цены (НМЦК) на основе ТЗ. Любое изменение ТЗ после публикации — протокол уточнений и риск обжалования.

Практический следующий шаг: внедрите гейт «Ready for Procurement»

Не отправляйте ТЗ поставщикам по готовности автора. Внедрите формальный гейт (Quality Gate) перед стартом закупки. Критерии прохождения гейта:

1. Все разделы чек-листа заполнены, нет заглушек «ТБД» (To Be Defined).
2. RTM построена, 100% требований покрыто тест-кейсами приемки.
3. Закрыты все замечания уровня 2 (качество требований) и уровня 3 (валидация тестов).
4. Юридический аудит: нет противоречий с законом, договором, политиками безопасности, нет запрещенных брендовых ссылок.
5. Финансовый аудит: НМЦК / бюджет пересчитан по итоговому ТЗ, риски заложены.
6. Подписи ответственных: Заказчик (бизнес), Архитектор, Безопасник, Юрист, Закупщик.

Если хоть один пункт не пройден — ТЗ возвращается на доработку. Это экономит месяцы споров на этапе исполнения контракта.

Часто задаваемые вопросы

Нужно ли описывать в ТЗ архитектуру решения или достаточно требований «что»?

Для закупки готового продукта (SaaS/Box) — только требования «что» и интеграционные границы. Для индивидуальной разработки — минимально необходимая архитектурная الرؤية (контекстная диаграмма, ключевые технологические решения, нефункциональные драйверы), чтобы поставщик не предложил стек, который заказчик не сможет поддерживать. Детальную архитектуру проектирует поставщик на этапе ТЭО/Проектирования.

Как проверить полноту, если заказчик не знает, чего хочет (Agile/неопределенность)?

ТЗ в таком случае формулируется на уровне Эпиков / MVP-области с фиксированными нефункционалками, интеграциями, безопасностью, SLA и коммерческой моделью (T&M или фиксированные спринты). Полноту проверяют по «Definition of Ready» для запуска первой итерации: есть ли приоритезированный бэклог на 2-3 спринта, готова ли среда, согласованы ли нефункционалки. Остальное детализируется в процессе.

Что делать, если поставщик на этапе уточнений находит пробелы, которые мы пропустили?

Это нормально для сложных систем. Заведите реестр уточнений, классифицируйте: критическое (блокирует оценку стоимости/сроков) — дорабатываете ТЗ и пересылаете всем участникам; некритическое — фиксируете в протоколе уточнений как допущение поставщика. Главное — не меняйте критерии приемки после получения коммерческих предложений без пересчета НМЦК.

Стоит ли нанимать внешнего эксперта для аудита ТЗ?

Да, если: сумма контракта высокая (риск претензий ФАС/СЧ), предмет закупки уникален (нет внутренней компетенции), есть прецедент неудачных закупок по схожим темам, требуется независимая экспертиза для обоснования НМЦК. Внутренний аудит (уровни 1-3) обязателен всегда, внешний — по решению руководства/комиссии.

Как формализовать «неформальные» пожелания руководства типа «чтобы было красиво и удобно»?

Проводите сессию стейкхолдеров: переводите каждое пожелание в измеримый нефункциональный требование или UI-гайдлайн. «Красиво» → соответствие дизайн-системе компании, проверка по чек-листу UI-ревью. «Удобно» → время выполнения типовой задачи новичком 70). Если не получается измерить — требование не попадает в ТЗ, а фиксируется как пожелание без гарантии исполнения.

Данная статья носит информационный характер и описывает общие инженерные практики подготовки технической документации. Конкретные требования к составу и форме ТЗ регламентируются отраслевыми стандартами (ГОСТ 19.xxx, ISO/IEC/IEEE 29148), нормативными правовыми актами (ФЗ-44, ФЗ-223, технические регламенты) и внутренними регламентами закупающей организации. При подготовке документа к публикации обязательно проконсультируйтесь с юристами, закупщиками и техническими экспертами профильного направления для учета актуальных законодательных требований и специфики объекта закупки.