Договор авторского заказа (ДАЗ)– это соглашение между заказчиком и автором (или исполнителем), по которому автор обязуется создать произведение (научное, литературное, художественное, программное обеспечение и т. д.) по техническому заданию (ТЗ) заказчика, а заказчик оплачивает работу.
В каких случаях ДАЗ предпочтительнее альтернатив?
1. Создание уникального произведения – если заказчику нужно конкретное произведение (например, логотип, книга, музыка, ПО).
2. Определение условий передачи прав – когда важно сразу зафиксировать, кому и в каком объеме переходят права (исключительные или неисключительные).
3. Фиксация сроков и этапов – если работа сложная и требует поэтапной сдачи.
4. Избежание споров – когда нужно четко прописать требования к результату, порядок приемки и оплаты.
Преимущества перед другими договорами
Гибкость договора авторского заказа позволяет детально прописать требования к произведению. Вкупе с предусмотренной передачей прав по умолчанию (если не указано иное, исключительные права переходят заказчику (ст. 1288 ГК РФ)) это качество защищает интересы заказчика, т.к.автор не может просто так отказаться от работы или передать произведение третьим лицам. ДАЗ дозволяет установление штрафов– за нарушение сроков или несоответствие ТЗ.
Слабые стороны ДАЗ
Сложность в детализации ТЗ – если задание слишком общее, могут возникнуть споры.
Авторские права могут остаться у исполнителя – если в договоре не указано иное, моральные права (авторство, неприкосновенность) остаются у автора.
Техническое задание – ключевой документ в договоре авторского заказа, который определяет требования к создаваемому произведению. От его детализации зависит, насколько результат удовлетворит заказчика и минимизирует риски споров.
Основные разделы ТЗ:
1.1 Общие сведения
- Название проекта / произведения.
- Цель создания (например, для коммерческого использования, рекламы, публикации).
- Сроки выполнения (этапы, дата сдачи).
1.2. Описание произведения
- Жанр и стиль (например, "корпоративный логотип в минималистичном стиле", "научная статья по биотехнологиям").
- Объем и формат (количество страниц, длительность аудио/видео, разрешение изображения).
- Структура (оглавление книги, разделы программы, слои дизайна).
1.3. Требования к содержанию
- Ключевые элементы (персонажи, сюжет, функционал ПО, цвета, шрифты).
- Ограничения (чего нельзя использовать: плагиат, определенные символы, чужие товарные знаки).
- Референсы(примеры аналогичных работ: "как в приложении X, но с упрощенным интерфейсом").
1.4. Технические требования
- Для текста: язык, терминология, ГОСТ/стиль (APA, MLA).
- Для дизайна: формат файлов (AI, PSD, SVG), цветовая модель (CMYK/RGB), размеры.
- Для ПО: язык программирования, совместимость, требования к серверу.
1.5. Порядок приемки
- Критерии оценки ("соответствие ТЗ", "отсутствие ошибок").
- Этапы проверки (черновик, правки, финальная версия).
- Условия доработки (сроки, количество бесплатных исправлений).
1.6. Конфиденциальность и права
- Запрет на публикацию до сдачи.
- Указание, кто будет правообладателем (если не указано в договоре).
Пример ТЗ для разных произведений
Логотип
- Стиль: плоский дизайн, 2–3 цвета.
- Форматы: вектор (AI/EPS), растровый (PNG 3000×3000 px).
- Запреты: не использовать стоковые элементы.
Статья
- Тема: "Влияние ИИ на медицину".
- Объем: 10 000 знаков, уникальность 95%.
- Источники: только PubMed и IEEE Xplore.
Мобильное приложение
- Функции: авторизация, чат, оплата.
-Платформы: iOS (версия 15+), Android (10+).
- Тестирование: проверка на эмуляторах и 3 реальных устройствах.
Ошибки в ТЗ
- Размытые формулировки: "красивый дизайн" → "минимализм, как у Apple".
- Отсутствие примеров – лучше приложить скриншоты или мудборды.
- Нереальные срок – не требовать роман за неделю
Дополнительные рекомендации
- Приложения к ТЗ:
- Референсы (образцы).
- Бренд-гайд (если есть).
- Глоссарий терминов.
- Согласование: обе стороны подписывают ТЗ как приложение к договору.
Чем детальнее ТЗ, тем меньше вопросов возникнет в будущем. Используйте конкретные параметры, цифры и примеры. Если проект сложный, разбейте его на этапы с отдельными ТЗ для каждого.
В договоре авторского заказа важно прописать этапы выполнения работы, чтобы минимизировать риски недопонимания, контролировать процесс и обеспечить прозрачность расчетов.
Основные этапы, которые стоит включить в договор
1.1. Подготовительный этап
- Согласование ТЗ – закрепление технического задания как приложения к договору.
- Аванс (если предусмотрен) – обычно 20–50% от суммы.
- Сроки – дата начала работы.
1.2. Создание черновика / концепции
- Что входит: эскиз, план текста, прототип ПО, наброски дизайна.
- Сроки – например, 14 дней с момента подписания договора.
- Порядок согласования: заказчик проверяет и дает комментарии (фиксируется в письменной форме).
1.3. Доработка (при необходимости)
- Количество правок – например, "2 бесплатных итерации правок, далее – оплата по дополнительному соглашению".
- Сроки внесения изменений – пример:"3 рабочих дня на каждую итерацию".
1.4. Сдача финальной версии
- Форма сдачи – передача исходников, подписанного акта, файлов в оговоренных форматах.
- Приемка – заказчик проверяет соответствие ТЗ (срок проверки – например, 5 рабочих дней).
1.5. Исправление замечаний (если есть)
- Критические недочеты – автор обязан исправить (если они не противоречат ТЗ).
- Субъективные правки – могут оплачиваться отдельно.
1.6. Завершение и оплата
- Подписание акта сдачи-приемки – подтверждение, что работа принята.
- Окончательный расчет – например, в течение 3 дней после подписания акта.
- Передача прав– если не было авансовой передачи (например, подписание отдельного акта о переходе прав).
2. Дополнительные условия по этапам
- Штрафы за срыв сроков – например, 0,1% от суммы договора за каждый день просрочки.
- Форс-мажор – продление сроков при обстоятельствах, не зависящих от сторон.
- Отказ от договора – условия возврата аванса, если заказчик передумал.
Что делать, если этапы не выполнены?
В случае некачественного исполнения заказчик вправе требовать исправлений или расторгнуть договор с возвратом аванса.
Просрочка подразумевает штрафы или право заказчика найти другого исполнителя.
При возникновении спора по приемке можно предусмотреть передачу спора эксперту (например, из авторского общества).
Чем сложнее проект, тем детальнее нужно прописывать этапы. Это защитит обе стороны и упростит разрешение споров. В идеале каждый этап должен иметь измеримый результат (эскиз, текст, версия ПО) и четкие сроки.