Техническое задание (ТЗ) — это основной документ‚ определяющий требования к результатам работ (услуг)‚ которые должен выполнить подрядчик (исполнитель) по договору. Грамотно составленное ТЗ минимизирует риски споров‚ обеспечивает единство понимания задачи заказчиком и исполнителем и служит основой для приемки выполненных работ.

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

Нормативная правовая база

При разработке ТЗ необходимо опираться на следующие нормативные акты РФ:

• ГК РФ (ст. 702‚ 743‚ 779): общие положения о договоре подряда и возмездном оказании услуг.
• ГОСТ 19.201-78 (ЕСПД): требования к составу параметров и структуре ТЗ (базовый стандарт для документации).
• 44-ФЗ (ст. 22‚ 23‚ 65): особенности ТЗ для закупок в сфере госзаказов (обоснование максимальной цены‚ критерии оценки).
• 223-ФЗ: регулирование закупок определенными видами юридических лиц.
• Постановление Правительства РФ № 1166 (для 44-ФЗ): требования к составу и оформлению документации закупки.

Принципы составления качественного ТЗ

1. Полнота: ТЗ должно содержать все существенные условия‚ необходимые для выполнения работы без дополнительных уточнений.
2. Однозначность: Формулировки не должны допускать двоякого толкования. Избегайте слов: «качественно»‚ «быстро»‚ «современно»‚ «по современным стандартам» без конкретных метрик.
3. Измеримость: Результаты должны поддаваться проверке (количественные и качественные показатели).
4. Реалистичность: Требования должны соответствовать рыночным возможностям и уровню технологий.
5. Непротиворечивость: Разделы ТЗ не должны противоречить друг другу‚ договору и законодательству.

Стандартная структура Технического задания (по ГОСТ 19.201-78)

Рекомендуемый состав разделов ТЗ:

Общие сведения

• Наименование работы/услуги (полное и краткое).
• Основание для разработки ТЗ (номер договора‚ техническое предложение‚ решение заказчика).
• Исполнитель и заказчик (реквизиты).
• Сроки выполнения работ (календарные даты или этапы).

Назначение и цели работы

• Функциональное назначение создаваемого объекта/результата.
• Основные технико-экономические показатели.
• Область применения.

Требования к результату работы (к продукту/услуге)

Ключевой раздел. Детализируется в зависимости от вида договора:

• Функциональные требования: что должен делать продукт (алгоритмы‚ бизнес-процессы‚ функции).
• Нефункциональные требования: производительность‚ надежность‚ безопасность‚ удобство использования (usability)‚ масштабируемость.
• Требования к интерфейсам: пользовательский (UI)‚ программный (API)‚ аппаратный.
• Требования к составу параметров: точность‚ скорость‚ объемы данных‚ пропускная способность.
• Требования к материалам/компонентам: марки‚ ГОСТы‚ ТУ‚ сертификаты соответствия (для строительства‚ производства).

Требования к составу и параметрам работ (процессу)

• Этапы работ и их последовательность.
• Методы и способы выполнения (если заказчик их диктует).
• Требования к персоналу исполнителя (квалификация‚ допуски‚ сертификаты).
• Требования к оснащению (оборудование‚ ПО‚ инструменты).
• Режим работы (график смен‚ доступ к объекту‚ режим ЧС/КТ).

Требования к документации

• Перечень передаваемых документов (акт приемки‚ паспорт объекта‚ руководства‚ схемы‚ исходный код‚ отчеты).
• Формат предоставления (бумажный‚ электронный‚ ЭДО‚ портал заказчика).
• Язык документации.
• Сроки передачи документации по этапам.

Порядок контроля и приемки работ

• Виды приемки: входной контроль‚ операционный‚ приемо-сдаточные испытания (ПСИ)‚ гарантийные испытания.
• Критерии приемки (чек-листы‚ тест-кейсы‚ протоколы испытаний‚ допуски).
• Порядок устранения замечаний/дефектов (сроки‚ процедура повторной приемки).
• Условия предъявления претензий и гарантийные обязательства.

Особенности монтажа‚ пусконаладки и ввода в эксплуатацию (если применимо)

• Требования к подготовке площадки заказчиком.
• Порядок согласования проектной документации (ППР‚ ПОС).
• Участие представителей заказчика/экспертизы.

Требования к информационной безопасности и защите данных

• Классификация обрабатываемой информации (Гос. тайна‚ Перс. данные‚ Ком. тайна).
• Требования к сертифицированным СЗИ (средствам защиты информации).
• Порядок доступа исполнителя к ИС заказчика (VPN‚ бастионы‚ разграничение прав).
• Уничтожение/возврат носителей информации после завершения работ.

Экологические и санитарно-гигиенические требования

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

Образец заполнения ключевых разделов (Шаблон)

Ниже приведен пример структуры ТЗ для типового договора на разработку программного обеспечения / IT-услуги (адаптируйте под свою сферу).

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Наименование работы: Разработка веб-приложения «Личный кабинет клиента»
Номер договора: № 123/2026 от
Заказчик: ООО «Вектор»
Исполнитель: ИП Иванов И.И.

Предмет и цели работы

Разработка‚ тестирование и внедрение веб-приложения для автоматизации процесса оформления заказов клиентами и отслеживания статуса доставки;
Цель: сокращение времени обработки заявки менеджером на 40%‚ исключение ошибок ручного ввода данных.

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

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

• Производительность: Время отклика сервера (TTFB) < 200 мс при нагрузке 500 RPS. Время загрузки главной страницы (LCP) < 2.5 сек (Google PageSpeed > 90).
• Доступность (SLA): 99.9% аптайм в месяц (допуск простоя 43 мин/мес). Резервирование БД (Master-Slave).
• Безопасность: Соответствие OWASP Top 10. HTTPS (TLS 1.2+). Защита от CSRF‚ XSS‚ SQL-инъекций. Хранение паролей: bcrypt/Argon2. Соответствие 152-ФЗ (персональные данные).
• Совместимость: Последние 2 версии Chrome‚ Firefox‚ Safari‚ Edge. Адаптивная верстка (Mobile First): 320px ⸺ 1920px.
• Масштабируемость: Горизонтальное масштабирование бэкенда (Kubernetes/Docker Swarm).

Требования к технологическому стеку и архитектуре

• Backend: Python 3.11+ (FastAPI/Django) или Go 1.22+. Архитектура: микросервисы или модульный монолит.
• Frontend: TypeScript‚ React 18+ (Next.js 14+ App Router)‚ UI Kit: Ant Design / Shadcn UI.
• Database: PostgreSQL 16+ (основная)‚ Redis 7+ (кэш‚ сессии‚ очереди).
• DevOps/Infra: GitLab CI/CD‚ Docker‚ Kubernetes (k8s)‚ Helm-чарты. Мониторинг: Prometheus + Grafana + Loki. Логирование: ELK/EFK стек.
• Интеграции: REST API (OpenAPI 3.0 / Swagger)‚ Webhooks для 1С‚ API СДЭК‚ СМС-шлюз (МТС/Билайн).

Этапы работ и сроки (Календарный план)

1. Этап 1 (2 недели): Проектирование (ТЗ детализация‚ ER-диаграммы‚ API-контракты‚ UI-прототипы в Figma). Результат: Утвержденная спецификация (OpenAPI)‚ макеты всех экранов.
2. Этап 2 (6 недель): Разработка MVP (Backend API‚ Frontend‚ Админка‚ Интеграция с 1С/СДЭК). Результат: Работоспособный стенд на Dev-среде‚ пройденные Unit/Integration тесты (покрытие > 80%).
3. Этап 3 (2 недели): Тестирование (QA: функциональное‚ нагрузочное k6/JMeter‚ безопасность SAST/DAST). Исправление багов (Critical/High = 0). Результат: Отчет о тестировании‚ чек-лист приемки.
4. Этап 4 (1 неделя): Внедрение на Production‚ миграция данных‚ обучение администраторов (2 занятия по 2 часа‚ запись видео). Результат: Подписанный Акт приема-передачи работ‚ переданная документация.
5. Этап 5 (Гарантия 3 мес.): Техподдержка (SLA: реакция на Critical < 1 час‚ исправление < 4 часа). Обновления безопасности.

Требования к документации (Перечень передаваемых результатов)

• Исходный код в репозитории GitLab (доступ заказчику‚ лицензия MIT/проприетарная по договору).
• Техническая документация (Markdown/Confluence): Архитектура (C4 model)‚ ER-диаграммы‚ Описание API (Swagger)‚ Инструкция по развертыванию (Runbook).
• Отчеты о тестировании (Test Report)‚ протоколы нагрузочного тестирования.
• Ключи доступа к инфраструктуре (k8s‚ БД‚ мониторинг‚ DNS‚ SSL сертификаты) — в защищенном хранилище (Vault/KeePass).

Порядок приемки и оплаты

• Приемка по этапам (промежуточная) и итоговая (после Этапа 4).
• Основание для приемки: подписанный двусторонний Акт приема-передачи выполненных работ (КС-11 / УПД) и соответствующий этапу артефакт (код‚ отчет‚ доступы).
• Критерии отказа в приемке: наличие багов Critical/High‚ несоответствие API-контракту‚ падение нагрузки ниже пороговых значений‚ отсутствие документации.
• Срок устранения замечаний: 5 рабочих дней после получения претензии.
• Оплата: поэтапная (аванс 30%‚ этап 2 — 40%‚ этап 4 — 30%) в течение 10 банковских дней после подписания Акта.

Ответственность сторон и гарантии

• Исполнитель гарантирует отсутствие в коде вредоносного ПО‚ «закладок»‚ недокументированных возможностей.
• Гарантийный период: 12 месяцев с момента итоговой приемки (на исправление дефектов‚ не связанных с изменением требований заказчиком).
• Штрафные санкции за просрочку этапов: 0.5% от стоимости этапа за каждый день просрочки (не более 10% от стоимости этапа).
• Интеллектуальная собственность: Исключительное право на результат переходит к Заказчику с момента полной оплаты (п. 4 ст. 1295 ГК РФ).

Типичные ошибки при составлении ТЗ (Чек-лист «Чего избегать»)

• Отсутствие критериев приемки: «Сделать удобный интерфейс», плохо. «Интерфейс соответствует макетам Figma v;12‚ проходит чек-лист usability из 50 пунктов», хорошо.
• Ссылаться на внешние документы без версионирования: «Сделать как в ТЗ от 2020 года». Правильно: «Сделать согласно Приложению № 1 (Версия 1.0 от )».
• Игнорирование нефункциональных требований: Работа сдана функционально‚ но «тормозит» или «падает под нагрузкой».
• Незакрытые интеграции: Не описаны форматы обмена‚ SLA внешних систем‚ ответственность за доступы к тестовым контурам партнеров.
• Отсутствие процедуры управления изменениями: Как согласовывать правки в ТЗ в процессе работы (Change Request)‚ как они влияют на сроки и бюджет.

Особенности ТЗ для закупок по 44-ФЗ и 223-ФЗ

Если ТЗ готовится для электронного аукциона/конкурса‚ к вышеуказанной структуре добавляются жесткие требования:

• Запрет ссылок на конкретные товары/производителей (п. 10 ст. 22 44-ФЗ)‚ если только это не обосновано уникальными свойствами (тогда нужна ссылка на «или эквивалент» с описанием свойств).
• Обоснование Максимальной цены контракта (МЦК): ТЗ должно позволять рассчитать стоимость работ (объемы‚ нормы расхода‚ сложность).
• Критерии оценки заявок (для конкурса/РПЦ): ТЗ должно содержать параметры‚ по которым будет проводиться сравнение предложений (качественные показатели‚ сроки‚ жизненный цикл).
• Единая форма ТЗ (для отдельных видов закупок): Использование форм‚ утвержденных Минэкономразвития (например‚ для капитального ремонта‚ ИТ-закупок определенного типа).

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

Рекомендация: Всегда согласовывайте ТЗ с юристом (юридическая экспертиза условий) и техническим экспертом (техническая экспертиза реализуемости) перед подписанием договора или публикацией закупки. Храните историю версий ТЗ (систему контроля версий или нумерацию редакций)‚ чтобы избежать путаницы при дополнительных соглашениях.