Как составить понятное техническое задание для подрядчика: структура, критерии и проверка качества

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

Главный принцип: ТЗ должно отвечать на вопрос «как мы поймём, что работа сделана правильно?» без устных догооворённостей. Если критерий приёмки не записан — его нет. Ниже разберём структуру, наполнение каждого раздела и способы проверить документ перед отправкой исполнителю.

Зачем вообще нужно формальное описание задачи

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

• Синхронизация образа результата. Заказчик и подрядчик видят одну и ту же цель.
• Объективная приёмка. Есть чёткие метрики: «страница загружается за 1.5 секунды» вместо «работает быстро».
• Защита от scope creep. Любое новое требование за пределами ТЗ — это отдельный заказ с новой оценкой сроков и бюджета.

Даже для небольших задач (верстка лендинга, настройка CRM, написание статьи) минимальное ТЗ на одной странице экономит часы переписки. Для сложных проектов — недели переделок.

Обязательная структура технического задания

Универсальный шаблон под любой тип работ содержит семь блоков. Порядок важен: от контекста к деталям реализации.

1. Контекст и цель

Почему задача возникла и какой бизнес-проблемы решает. Это даёт подрядчику понимание приоритетов и позволяет предлагать лучшие решения, чем просто исполнение инструкций.

• Текущая ситуация (что есть сейчас).
• Желаемое состояние (что должно стать).
• Ключевой показатель успеха (KPI): конверсия, время обработки, трафик, ошибки и т.д.

2. Объём работ (Scope)

Чёткий перечень deliverables — артефактов, которые подрядчик должен передать. Не процессы («настроить»), а результаты («готовый конфигурационный файл с документацией»).

• Список конкретных артефактов с форматами файлов.
• Что НЕ входит в задачу (exclusions) — критично для границ.
• Зависимости от третьих сторон (доступы, API, согласования).

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

Что система/продукт должна делать. Пишутся пользовательскими сценариями или правилами.

• User stories: «Как [роль], я хочу [действие], чтобы [ценность]».
• Бизнес-правила и ограничения (например, «скидка не более 15%», «доступ только для подтверждённых email»).
• Краевые случаи: пустые состояния, ошибки сети, некорректный ввод.

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

Качественные атрибуты результата. Часто упускаются, а потом становятся причиной споров.

• Производительность: время отклика, пропускная способность, нагрузка.
• Безопасность: авторизация, шифрование, соответствие стандартам (ГОСТ, PCI DSS, 152-ФЗ).
• Доступность: WCAG 2.1 AA, поддержка скринридеров, кросбраузерность.
• Масштабируемость и расширяемость.
• Совместимость: версии браузеров, ОС, устройств, интеграций.

5. Критерии приёмки (Definition of Done)

Самый важный раздел. Каждый пункт — проверяемое утверждение «да/нет».

• Функциональные чек-листы: «При нажатии кнопки «Купить» открывается модалка с формой заказа».
• Автоматизированные тесты: покрытие кода, прохождение CI/CD пайплайна.
• Ручные сценарии: пошаговые инструкции для QA.
• Документация: README, API docs, инструкция пользователя, диаграммы.
• Деплой: инструкция по развёртыванию, переменные окружения, миграции БД.

6. Сроки, этапы и контрольные точки

Календарный план с привязкой к deliverables, а не к активностям.

• Дата старта и дедлайн каждого этапа.
• Демонстрации/приёмки промежуточных результатов.
• Сроки на правки после приёмки (обычно 1–2 итерации входят в стоимость).
• Штрафные санкции или бонусы за сроки — если предусмотрено договором.

7. Организационные условия

• Каналы связи: чат, почта, трекер задач, регулярные созвоны.
• Ответственные лица с обеих сторон (Product Owner, Tech Lead, PM).
• Порядок изменений: как оформляется Change Request, кто согласует, как влияет на сроки/бюджет.
• Инструменты: доступы к репозиторию, CI/CD, тестовым стендам, аналитике.
• Требования к отчётности: ежедневные стендапы, еженедельные статусы, тайм-логи.

Как детализировать требования без перегруза

Частая ошибка — либо «сделайте красиво», либо 100-страничный документ, который никто не читает. Баланс находится через уровни детализации:

Уровень	Когда подходит	Пример формулировки
Высокий (Outcome-based)	Экспертный подрядчик, инновационная задача, гибкие сроки	«Увеличить конверсию корзины на 15% за счёт UX-доработок. Метрика: GA4 purchase rate. Бюджет: 200к руб. Срок: 1.5 мес.»
Средний (Feature-based)	Типовая разработка, известный стек, чёткий Scope	«Реализовать модуль подписок: CRUD тарифов, привязка к Stripe, вебхуки подтверждения, админка модерации. API по OpenAPI 3.0 spec (приложение 1).»
Низкий (Spec-based)	Регламентированные работы, миграция, интеграция по фиксированному протоколу	«Перенести 12 отчётов с Crystal Reports на Power BI. Соответствие пиксель-в-пиксель по макетам в Figma (ссылка). Источник данных: MS SQL, схемы в приложении 2.»

Правило: чем выше неопределённость, тем выше должен быть уровень описания (фокус на результате). Чем чётче образ результата — тем ниже уровень (фокус на спецификации).

Типичные ошибки и как их избежать

Скрытые предположения

Ошибка: «Интеграция с 1С».

Проблема: Какая 1С (УТ, ERP, КА)? Какой обмен (REST, OData, файловый)? Реальное время или батч? Кто даёт доступы?

Правильно: «Интеграция заказов из интернет-магазина в 1С:ERP 2.5 через OData. Обновление статусов каждые 15 минут. Доступы к тестовому контуру предоставим к старту. Спецификация обмена — приложение 3».

Отсутствие критериев приёмки для нефункционалок

Ошибка: «Сайт должен быть быстрым».

Правильно: «LCP < 2.5с, TBT < 200мс, CLS < 0.1 на мобильном 3G (эмуляция Chrome DevTools) для главной, каталога, карточки товара. Проверка через Lighthouse CI в пайплайне».

Незакрытые зависимости

Ошибка: Подрядчик готов к работе, но доступы к продакшн-БД дадут через две недели согласований с безопасностью.

Правильно: В ТЗ отдельный раздел «Зависимости и риски» с ответственными, сроками и планом Б (тестовый стенд, моки, параллельная разработка).

Размытые границы правок

Ошибка: «Небольшие правки в рамках задачи».

Правильно: «До 2 итераций правок по каждому этапу приёмки без переоценки. Новые требования, не описанные в ТЗ — через Change Request с оценкой трудозатрат. Дизайн-правки после утверждения макетов — отдельный таск».

Игнорирование поддержки и передачи знаний

ТЗ часто заканчивается на «передать исходники». А нужен: репозиторий с историей, инструкция по развёртыванию, контакты вендоров сторонних сервисов, runbook для инцидентов, обучение команды заказчика.

Чек-лист проверки ТЗ перед отправкой подрядчику

1. Есть ли однозначный ответ на вопрос «как проверить, что задача сделана?» для каждого требования.
2. Указаны ли форматы файлов, протоколы, версии библиотек, стандарты кода.
3. Чётко ли разделено: что делает подрядчик, что предоставляет заказчик (доступы, контент, дизайн, данные).
4. Есть ли список исключений (out of scope) — что точно НЕ входит в работу.
5. Описаны ли краевые случаи и обработка ошибок.
6. Зафиксированы ли нефункциональные требования с измеримыми метриками.
7. Понятен ли процесс изменений: кто инициирует, кто оценивает, кто согласует бюджет/сроки.
8. Есть ли контрольные точки приёмки с датами и ответственными.
9. Подключены ли все заинтересованные стороны (безопасность, юристы, маркетинг, поддержка) на этапе согласования ТЗ, а не после.
10. Версия ТЗ пронумерована, датирована, подписана ответственными лицами.

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

Разработка ПО / веб-сервиса

Фокус на API-контрактах, схеме БД, CI/CD, тестовом покрытии, документации для разработчиков. Обязательно: схема развёртывания, переменные окружения, стратегия миграций, мониторинг и алерты.

Дизайн и UX

Фокус на дизайн-системе, токенах (цвета, шрифты, отступы), адаптивных брейкпоинтах, состояниях компонентов (hover, focus, error, loading, empty), передаче в Figma/Zeplin с доступом для разработчиков. Критерии приёмки — pixel-perfect по ключевым экранами + соответствие дизайн-системе.

Контент и SEO

Фокус на ТЗ для копирайтера: целевые ключи (частотность, интент), структура статьи (H2/H3), тон голосовой, длина, требования к E-E-A-T, экспертность, факты для проверки, внутренние ссылки, мета-теги. Приёмка — чек-лист редактора + проверка уникальности/спамности.

Настройка и внедрение SaaS / CRM / ERP

Фокус на бизнес-процессах: карта текущего процесса (AS-IS), целевой (TO-BE), роли и права, воронки, автоматизации, интеграции, миграция исторических данных (объём, чистота, маппинг полей), обучение пользователей, UAT-сценарии.

Маркетинговые кампании / контекстная реклама

Фокус на KPI (CPA, ROAS, лиды), структуре аккаунта, минус-словах, гео/времени показа, креативах (форматы, требования модерации), подключении аналитики (UTM, цели, e-commerce), бюджете и лимитах суточных трат.

Как работать с изменениями в процессе

Никакой проект не идёт строго по плану. Процесс управления изменениями (Change Management) должен быть прописан в ТЗ или приложении к договору:

• Инициация: любая сторона пишет Change Request (CR) — что меняется, почему, влияние на сроки/бюджет/качество.
• Оценка: подрядчик даёт трудоёмкость в часах/днях и влияние на критические даты.
• Согласование: заказчик подтверждает или отказывает. Без подписанного CR работа не начинается.
• Версионирование: ТЗ обновляется, номер версии увеличивается, история изменений ведётся в конце документа.

Это защищает обе стороны: подрядчик не делает «маленькие правки» за свой счёт, заказчик не получает сюрпризы в счёте.

Практический следующий шаг

Перед стартом следующего проекта:

1. Возьмите шаблон выше и заполните его под вашу задачу за 30–60 минут.
2. Пройдитесь по чек-листу из 10 пунктов — уберите пробелы.
3. Согласуйте с заинтересованными сторонами (техлид, юрист, безопасность, маркетинг) — 1–2 дня.
4. Передайте подрядчику с дедлайном по вопросам (обычно 1–2 рабочих дня).
5. Проводите kick-off созвон: пройдитесь по ТЗ вслух, зафиксируйте уточнения сразу в документе.

Хорошее ТЗ — это не идеальный документ, а живой артефакт, который снижает неопределённость до уровня, когда подрядчик может начать работать, а не гадать.

FAQ: частые вопросы о подготовке задания

Нужно ли ТЗ для мелких задач на 2–4 часа?

Да, но в сокращённом виде: цель, результат, критерий приёмки, дедлайн, что предоставляет заказчик. Наполняет 1 экран в трекере или письме. Экономит время на уточняющих вопросах.

Кто должен писать ТЗ — заказчик или подрядчик?

Ответственность за бизнес-требования (зачем, какой результат) — у заказчика. Техническая спецификация (как реализовать) — у подрядчика, но заказчик должен её утвердить. Лучший формат: заказчик пишет черновик по структуре выше, подрядчик дополняет техническими деталями на этапе оценки.

Что делать, если заказчик не знает, чего хочет?

Это ситуация Discovery, а не исполнения. Оформите отдельный этап: аудит, прототипирование, исследование пользователей, техническое обследование. Результат Discovery — это и есть входное ТЗ для основного этапа. Не начинайте разработку без понимания цели.

Как защититься от бесконечных правок дизайна/текста?

В ТЗ пропишите: количество итераций правок в стоимости (обычно 2), формат правок (собранные в одном документе, не по одному правке в чате), критерий «утверждено» (подпись ответственного лица). Всё за пределами — Change Request.

Стоит ли включать в ТЗ стек технологий?

Если стек критичен (интеграция с легаси, компетенции команды заказчика, требования безопасности) — да, жёстко. Если подрядчик нанимается за экспертизу — лучше задать нефункциональные требования (производительность, поддержка, лицензии) и дать выбрать стек, обосновав выбор.

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