Техническое задание (ТЗ) — это не просто приложение к договору авторского заказа, а его «сердце». Именно в этом документе фиксируются все требования к создаваемому результату: от объема текста и цветовой гаммы дизайна до архитектуры программного кода и прав на интеллектуальную собственность. Согласно ст. 1288 ГК РФ и судебной практике, отсутствие детально проработанного ТЗ является главной причиной споров между Заказчиком и Автором (Исполнителем);

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

Правовая природа ТЗ в договоре авторского заказа

В отличие от договора подряда (ГПХ), где ТЗ часто заменяется сметой или чертежами, в авторском заказе (гл. 70 ГК РФ) ТЗ выполняет уникальную функцию — оно индивидуализирует объект исключительного права. До момента создания произведения авторского права на него не существует, поэтому стороны должны максимально точно описать «будущий объект».

• Статус: ТЗ является неотъемлемым приложением к договору (п. 2 ст. 1288 ГК РФ). Ссылка на него в теле договора обязательна.
• Юридическая сила: Условия ТЗ имеют приоритет над общими формулировками договора при приемке работы.
• Форма: Письменная (электронный документ с ЭЦП или скан с «живой» подписью). Устные договоренности в суде доказать практически невозможно.

Важно: Если ТЗ отсутствует или сформулировано размыто («сделать красивый сайт», «написать хорошую статью»), суд, скорее всего, встанет на сторону Автора при отказе Заказчика принимать работу, так как критерий «качества» не определен.

Стандартная структура ТЗ (универсальный шаблон)

Независимо от вида творчества (текст, дизайн, код, фото), грамотное ТЗ состоит из следующих блоков:

1. Преамбула / Общие сведения: Название проекта, номера договора, даты, ФИО/наименования сторон (Заказчик / Автор).
2. Предмет и назначение произведения: Что создается (роман, логотип, модуль CRM, серия фото), для каких целей (коммерческая публикация, внутреннее использование, перепродажа).
3. Детальное описание требований к результату (Спецификация): Основной технический блок (см. ниже по видам работ).
4. Этапы выполнения и календарный план: Декомпозиция настоуны (Milestones) с датами сдачи промежуточных результатов.
5. Порядок приемки-сдачи (Критерии приемки): Чек-лист или сценарии тестирования, по которым Заказчик подписывает Акт приема-передачи.
6. Порядок внесения изменений (Редакции/Итерации): Количество бесплатных правок, стоимость дополнительных, сроки согласования правок.
7. Требования к оформлению и формату сдачи: Расширения файлов (.psd, .fig, .docx, .py, .raw), кодировки, цветовые профили (sRGB/AdobeRGB/CMYK), репозитории (GitHub/GitLab).
8. Права интеллектуальной собственности (Ключевой пункт): Режим отчуждения исключительных прав или предоставления лицензии, территориальность, срок, способы использования. Указание на сохранение личного неимущественного права авторства (ст. 1265 ГК РФ).
9. Конфиденциальность и NDA: Запрет на публикацию в портфолио до релиза, защита ноу-хау.
10. Ответственность сторон: Штрафы за просрочку, за некачественную работу, за утечку ТЗ.

Специфика ТЗ для популярных видов работ

Содержание пункта 3 (Спецификация) кардинально отличается в зависимости от объекта авторского права.

ТЗ для текстов (Копирайтинг, Редактирование, Писательство)

• Объем: Знаки с пробелами / слова / страницы (формат А4, шрифт, кегль, интервал).
• Структура: Оглавление, обязательные заголовки H1-H3, список ключевых слов (SEO), плотность вхождения.
• Стиль и Тон (Tone of Voice): Примеры референсов, запрещенные слова/клише, обращение к читателю (Вы/ты);
• Фактура/Экспертиза: Требования к уникальности (Antiplagiat, Advego — %), достоверности фактов, наличию ссылок на источники.
• Иллюстрации: Кто подбирает фото/скриншоты, требования к alt-тегам, авторство изображений.

ТЗ для дизайна (Логотип, Брендбук, UI/UX, Иллюстрации)

• Референсы и Мудборд: Ссылки на работы-бенчмарки (что нравится/не нравится).
• Технические параметры: Вектор/Растр, разрешение (DPI), цветовые модели (Pantone, CMYK, RGB, HEX), безопасные зоны для логотипа.
• Комплектация исходников: Слои (Layers), шрифты (лицензии на них!), библиотека компонентов (UI Kit), дизайн-система (Figma/Sketch).
• Адаптивность/Версии: Логотип: основной, монохромный, фавикон, аватарка для соцсетей. UI: Desktop, Tablet, Mobile, состояния элементов (hover, active, error, disabled).
• Гайдлайн по использованию: Нужен ли брендбук/гайдлайн как отдельный артефакт?

ТЗ для разработки ПО (Сайты, Приложения, Скрипты, Боты)

Здесь ТЗ часто вынесен в отдельный документ — SRS (Software Requirements Specification) или формируется через User Stories в бэклоге (Jira/YouTrack).

• Функциональные требования: User Stories (As a [role], I want to [action], so that [benefit]), Use Cases, схемы БД (ER-диаграммы), API-спецификация (Swagger/OpenAPI).
• Нефункциональные требования: Нагрузка (RPS), время отклика (SLA), доступность (WCAG), безопасность (OWASP Top 10), поддержка браузеров/ОС.
• Стек технологий: Языки, фреймворки, версии библиотек, инфраструктура (Docker, K8s, CI/CD), требования к коду (Code Style, Линтеры, Покрытие тестами %).
• Архитектура: Монолит / Микросервисы, паттерны, интеграции с внешними системами (1С, CRM, Платежные шлюзы).
• Приемка: Demo-сессия, прогон автотестов, ручное тестирование по чек-листу, передача доступов к репозиторию (Git), документация (README, ADR).

ТЗ для фото/видео съемки

• Концепция и Референсы: Мудборд, примеры поз, света, локаций.
• Техника и настройки: Камера/оптика, формат (RAW / ProRes / LOG), разрешение (4K/8K), частота кадров, профиль цвета.
• Объем выдачи: Количество отретушированных кадров / минут готового видео. Количество «сырых» исходников (передаются ли они?).
• Ретушь/Постпродакшн: Уровень ретуши (базовая / high-end / beauty), цветокоррекция (LUT/стиль), монтаж (музыка, титры, анимация).
• Модельный релиз / Property Release: Кто собирает подписи моделей/владельцев локаций? Это критично для коммерческого использования.

Критически важные юридические нюансы в ТЗ

Отчуждение исключительного права vs Лицензия

В ТЗ (или в основном договоре со ссылкой на ТЗ) должно быть четко прописано:

• Отчуждение (Полная передача прав): Автор теряет все права на использование произведения. Заказчик становится полноправным владельцем. Обязательно указывать: способы использования (все известные или перечень), территория (мир / РФ), срок (весь срок охраны / конкретные годы), вознаграждение (одноразовое / процентное).
• Лицензия (Простое / Исключительная): Автор сохраняет право использовать работу сам и/или давать другим. В ТЗ прописываются ограничения: «Только для сайта заказчика», «Запрет на доработку третьими лицами без согласия автора».

Право авторства (Личное неимущественное)

Согласно ст. 1265 ГК РФ, право авторства неотчуждаемо. Даже при полном отчуждении исключительных прав Автор имеет право требовать указания своего имени на произведении (или псевдониме/анонимности). В ТЗ стоит зафиксировать: «Заказчик обязуется указывать имя Автора в формате: [ФИО / Псевдоним] при любом публичном использовании».

Противопоставление «Результату» и «Процессу»

Авторский заказ оплачивает Результат (готовое произведение), а не часы работы. ТЗ должно описывать именно признаки готового результата. Фразы вроде «Автор работает 8 часов в день» в ТЗ авторского заказа неуместны (это признаки трудового договора) и могут привести к реквалификации отношений в трудовые (Налоговая, Суды).

Этапы и Акты приема-передачи

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

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

Пример структуры приложения «Техническое задание» (для вставки в договор)

ПРИЛОЖЕНИЕ № 1
К ДОГОВОРУ АВТОРСКОГО ЗАКАЗА № * от ..2026 г.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ
НА СОЗДАНИЕ ПРОИЗВЕДЕНИЯ: [Название, например: «Разработка дизайн-системы для мобильного приложения»]

ОБЩИЕ ПОЛОЖЕНИЯ
Настоящее ТЗ определяет требования к Результату работы Автора [ФИО Автора / Название ИП ], передаваемому Заказчику [Название ООО ] по Договору авторского заказа.
Вид произведения: Комплексное произведение дизайна (UI Kit, Компоненты, Иконки, Гайдлайн).
Цель создания: Использование в коммерческом продукте Заказчика (iOS / Android приложение).

ТРЕБОВАНИЯ К РЕЗУЛЬТАТУ (СПЕЦИФИКАЦИЯ)
Инструмент: Figma (файл-библиотека, опубликованная в Community/Organization Заказчика).
Комплектация (Минимально необходимый набор):
 ⸺ Foundations: Color Tokens (Light/Dark), Typography Scale, Spacing System, Border Radius, Shadows.
 ⸺ Components (Min 30 шт.): Button, Input, Select, Checkbox, Radio, Modal, Toast, Navigation Bar, Tab Bar, Card, List Item, Avatar, Badge, Tooltip, Accordion. Все компоненты — Variants (State: Default, Hover, Focus, Disabled, Loading, Error; Size: Sm, Md, Lg).
 ⎯ Icons: Набор 100 иконок 24x24px, Outline style, SVG, компоненты Figma с True/False stroke.
 ⸺ Documentation Page: Гайдлайн по использованию токенов и компонентов внутри файла.
Технические ограничения: Auto Layout 4.0, Variables (Tokens), без плагинов для генерации кода. Шрифты: Inter (Google Fonts, SIL OFL) — разрешены для коммерции.

ЭТАПЫ РАБОТЫ И СРОКИ
Этап 1: Foundations & Icons — до ..2026 (Акт приема-передачи №1).
Этап 2: Core Components (Buttons, Inputs, Navigation) — до *..2026 (Акт №2).
КРИТЕРИИ ПРИЕМКИ (DEFINITION OF DONE)
Работа считается принятой по Этапу, если:
- Файл Figma передан в команду Заказчика с правами Editor.
- Все компоненты соответствуют п. 2.2.
- Пройден ревью Tech Lead Заказчика (чек-лист из 50 пунктов, приложение 2).
- Нет критических багов (компоненты ломаются при ресайзе, токены не применяются).

ПРАВА ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТИ
Автор сохраняет право авторства (п. 1 ст. 1265 ГК РФ). Заказчик вправе не указывать имя Автора в интерфейсе продукта, но обязан сохранить атрибуцию в внутренней документации/crediits.
Автор гарантирует, что Результат не нарушает права третьих лиц (шрифты, иконки, код библиотек).

ПОРЯДОК ВНЕСЕНИЯ ИЗМЕНЕНИЙ
В рамках каждого Этапа Автор вносит до 2-х раундов правок по письменным замечаниям Заказчика в течение 3 (трех) рабочих дней.
Правки, меняющие архитектуру токенов или структуру компонентов после Этапа 1, оплачиваются отдельно по ставке * руб/час (Доп. соглашение).

ОТВЕТСТВЕННОСТЬ
За просрочку сдачи Этапа — пена 0.5% от стоимости Этапа за каждый день просрочки, но не более 50% стоимости Этапа.
За несоответствие ТЗ, выявленное при приемке — безвозмездное устранение несоответствий в срок 5 раб. дней.

ПОДПИСИ СТОРОН:
ЗАКАЗЧИК: _____________ / [ФИО Директора ] / М.П.
АВТОР: _____________ / [ФИО Автора ] / Дата: ..2026

Практический совет: Как работать с ТЗ на этапе переговоров

1. Начинайте с «Brief / Брифа»: Не пишите ТЗ сразу. Соберите вводные: цели бизнеса, референсы, бюджет, дедлайн. Бриф, это вводные для ТЗ.
2. Итеративное согласование: Присылайте черновик ТЗ Автору до подписания договора. Обсудите риски: «Ты сможешь сделать этот анимационный переход на чистом CSS за 4 часа или нужен Lottie/GSAP?». Это спасет от срывов сроков.
3. Версионирование: ТЗ v1.0 (подписано с договором). Любые изменения — только через Дополнительное соглашение к ТЗ (v1.1, v1.2) с подписями двух сторон. Не ведите переговоры по изменению требований только в мессенджерах — в суде это не докажете.
4. Приложения к ТЗ: Выносите тяжелые спецификации (таблицы API, списки экранов, семантические ядра) в отдельные файлы (Excel, PDF, Confluence/Notion), на которые даеться ссылка в ТЗ. Это делает основной документ читаемым.

Резюме

Грамотное Техническое задание к договору авторского заказа — это инструмент управления ожиданиями и рисками. Оно защищает Заказчика от получения «кота в мешке» и бесконечных доработок, а Автора — от «размывания» границ задачи (Scope Creep) и неоплачиваемой работы.

Главные правила:

• ТЗ — обязательное приложение к договору (ст. 1288 ГК РФ).
• Описывайте Результат (признаки готового произведения), а не процесс труда.
• Детализируйте критерии приемки (как именно вы будете проверять работу).
• Явно пропишите режим передачи прав (отчуждение / лицензия) и судьбу исходников.
• Ограничьте количество бесплатных правок.

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