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

Иван Корнев·27.05.2026·⏱5 мин

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

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

Коротко о главном: Хорошее ТЗ отвечает на три вопроса: «Что делаем?», «Как это должно работать?» и «Как поймем, что работа принята?». Если хотя бы один пункт упущен, проект рискует уйти в бесконечные правки.

Зачем нужно техническое задание

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

Юридическая защита. Фиксирует объем работ. Если исполнитель сделал всё по пунктам ТЗ, заказчик не может потребовать бесплатных доработок «потому что я так представлял».
Оценка стоимости и сроков. Без четкого списка задач подрядчик закладывает риски в цену или срывает дедлайны.
Управление ожиданиями. Позволяет увидеть противоречия в требованиях еще на этапе планирования, а не после сдачи проекта.

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

Структура технического задания

Структура ТЗ зависит от сферы. Для госконтрактов и крупных инженерных систем часто используют ГОСТ 19.201-78 или ГОСТ 34.602-89. Для коммерческой веб-разработки, дизайна и маркетинга эти стандарты избыточны.

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

Основные разделы ТЗ

Раздел	Содержание
1. Термины и определения	Расшифровка специфических понятий, чтобы избежать разночтений.
2. Общие сведения	Название проекта, заказчик, исполнитель, основание для работ (договор, заявка).
3. Назначение и цели	Какую бизнес-задачу решает продукт (например, «увеличить конверсию заявок на 15%»).
4. Требования к продукту	Самый объемный блок. Включает функциональные, технические и дизайнерские требования.
5. Состав и содержание работ	Поэтапный план: прототипирование, дизайн, верстка, тестирование.
6. Порядок контроля и приемки	Как сдаются этапы, какие тесты проводятся, кто подписывает акты.
7. Требования к документации	Какие инструкции, исходники или отчеты передаются заказчику.

Разделяйте требования на «Must have» (критично важно) и «Nice to have» (желательно, но можно отложить). Это поможет уложиться в бюджет, если ресурсы ограничены.

Пример заполнения ТЗ (для сайта)

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

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

Заказчик: ООО «Мебель-Офис».
Исполнитель: Веб-студия «WebPro».
Цель проекта: Запуск сайта для презентации каталога и сбора лидов (заявок на расчет стоимости).

2. Требования к функционалу

Каталог товаров: Фильтрация по цене, материалу, цвету. Карточка товара с галереей, характеристиками и кнопкой «Заказать расчет».
Формы захвата: «Обратный звонок» в шапке, форма под каждым товаром, форма в футере. Данные должны падать в CRM (Bitrix24) и на email менеджера.
Адаптивность: Корректное отображение на мобильных (iOS/Android), планшетах и десктопах (разрешения от 320px до 1920px).

3. Технические требования

CMS: WordPress или Tilda (на выбор исполнителя, согласовать на этапе брифа).
Браузеры: Chrome, Safari, Firefox, Edge (последние 2 версии).
Скорость загрузки: Green Zone в Google PageSpeed Insights (не менее 85 баллов для мобильных).
SEO-база: Автоматическая генерация sitemap.xml, robots.txt, микроразметка Schema.org для товаров.

4. Дизайн и контент

Стиль: Минимализм, деловой стиль.
Цвета: Основной — #0056B3 (синий), фон — #FFFFFF (белый), текст — #333333.
Материалы: Заказчик предоставляет логотип в векторе и фото 10 топовых товаров. Остальные фото — стоковые (лицензионные).

5. Этапы и сроки

Прототипирование (Wireframes) — 5 рабочих дней.
Дизайн-макет главной и внутренней страницы — 7 рабочих дней.
Верстка и натяжка на CMS — 10 рабочих дней.
Наполнение контентом (10 товаров) — 2 рабочих дня.
Тестирование и исправление багов — 3 рабочих дня.

6. Критерии приемки

Все ссылки кликабельны и ведут на правильные страницы.
Формы отправляют данные в CRM без ошибок.
Сайт открывается быстрее 2 секунд при 3G соединении.
Отсутствие визуальных дефектов (съехавшие блоки, перекрытый текст) на указанных устройствах.

Частые ошибки при составлении ТЗ

Даже опытные менеджеры допускают ошибки, которые удорожают проект. Вот чего стоит избегать:

Субъективные формулировки.
- Плохо: «Сделать красивый современный дизайн».
- Хорошо: «Использовать референсы [ссылка 1] и [ссылка 2]. Цветовая гамма — пастельные тона. Шрифты — без засечек».
Отсутствие ограничений. Если не указать, что сайт должен работать в старых браузерах или поддерживать IE11, исполнитель будет оптимизировать его только под современные стандарты, что может стать проблемой для части аудитории.
Размытые критерии приемки. Фраза «сайт должен работать стабильно» ничего не значит. Используйте метрики: «время отклика сервера не более 200 мс», «ошибки 404 отсутствуют».
Игнорирование этапа тестирования. В ТЗ всегда нужно закладывать время и бюджет на правки после первого показа результата. Идеально с первого раза бывает редко.

Никогда не начинайте работу, если в ТЗ есть фраза «сделаем как у Apple» или «хочу вау-эффект». Требуйте конкретные примеры сайтов-конкурентов или референсы, которые вам нравятся.

Универсальный шаблон ТЗ

Вы можете скопировать этот шаблон и заполнить его под свою задачу.

# Техническое задание на [Название проекта]

## 1. Общая информация
- **Заказчик:** [Название/Контакты]
- **Исполнитель:** [Название/Контакты]
- **Срок реализации:** [Дата начала] – [Дата окончания]

## 2. Цели и задачи
- **Главная цель:** [Зачем нужен проект?]
- **Целевая аудитория:** [Кто будет пользоваться?]

## 3. Требования к результату
### 3.1. Функциональные требования
- [Функция 1]
- [Функция 2]

### 3.2. Технические требования
- [Платформа/Язык/Инструменты]
- [Требования к хостингу/серверу]
- [Требования к безопасности]

### 3.3. Дизайн и UX
- [Референсы/Примеры]
- [Требования к адаптивности]
- [Фирменный стиль/Брендбук]

## 4. Этапы работ
1. [Этап 1] — [Срок]
2. [Этап 2] — [Срок]
3. [Этап 3] — [Срок]

## 5. Порядок сдачи и приемки
- [Формат сдачи: ссылка на репозиторий, файл, доступ к админке]
- [Количество итераций правок, включенных в стоимость]
- [Критерии успешной приемки]

## 6. Приложения
- [Ссылки на макеты]
- [Текстовые материалы]
- [Логотипы и медиафайлы]

FAQ

Можно ли менять ТЗ в процессе работы? Да, но через процедуру дополнения соглашения (Change Request). Любое изменение требований должно фиксироваться письменно с пересчетом сроков и бюджета.

Кто должен писать ТЗ: заказчик или исполнитель? В идеале — совместно. Заказчик формулирует бизнес-требования («что нужно»), а исполнитель переводит их на технический язык («как это реализовать»). Часто исполнители предлагают услугу «написание ТЗ» как отдельный платный этап.

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