ТЗ как приложение к договору: что зафиксировать

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

Связь с договором

В договоре должна быть ссылка на ТЗ как на неотъемлемую часть. Важно, чтобы условия не противоречили друг другу: если в договоре указан один срок, а в ТЗ — другой, возникает спор, какой документ главнее. Укажите в договоре, что при расхождении приоритет имеет договор или конкретный раздел ТЗ.

Состав работ и результат

ТЗ должно описывать не только функции, но и что именно передаётся заказчику:

• Программа или система с перечнем функций
• Исходный код и где он размещается
• Документация: для пользователей, администраторов, разработчиков
• Развёртывание на сервере заказчика
• Обучение сотрудников
• Перенос данных, если он входит в работы

Если что-то не входит в работы, это тоже стоит написать: например, наполнение контентом, закупка лицензий, оплата хостинга. Список «что не входит» часто экономит больше нервов, чем список того, что входит.

Проверяемые требования

Каждое требование должно проверяться при приёмке. Формулировки «удобный интерфейс», «быстрая работа», «современный дизайн» нельзя проверить, и они становятся предметом спора. Вместо них — конкретика: шаги сценария, время ответа при определённом числе пользователей, соответствие утверждённым макетам.

Этапы и приёмка

Разбейте работу на этапы с результатом каждого. Для каждого этапа укажите, как проходит приёмка: кто проверяет, в какой срок, как оформляются замечания, сколько времени на их исправление. Пропишите, что происходит, если заказчик не подписал акт и не прислал замечаний в установленный срок, — это защищает исполнителя от бесконечной приёмки.

Критерии приёмки

Отдельный раздел или приложение с программой испытаний: какие сценарии проверяются, на каких данных, какой результат считается успешным. Чем подробнее критерии, тем короче и спокойнее приёмка.

Изменения требований

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

Права на результат

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

Гарантия и поддержка

Гарантийный срок, в течение которого исполнитель бесплатно исправляет ошибки. Что считается ошибкой, а что новым пожеланием. Сроки реакции на критичные ошибки. Поддержка после гарантии — обычно отдельным договором.

Ответственность заказчика

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

Перед подписанием

Попросите юриста прочитать ТЗ вместе с договором, а технического специалиста — проверить реализуемость требований. Документ, который понятен обеим сторонам одинаково, — главная защита от споров.