Договор IT-разработки. Что заказчику обязательно включить

Заказчик IT-разработки чаще всего получает не то, что заказывал, в сроки, которые сдвинулись, и без понимания, кому принадлежит код. Большая часть этих проблем закрывается грамотным договором, а не борьбой постфактум.

ТЗ как приложение, а не пожелания в переписке

Техническое задание должно быть приложением к договору и подписываться обеими сторонами. Без этого спор «что именно было заказано» уходит в субъективную плоскость и почти всегда проигрывается заказчиком.

В ТЗ фиксируются:

• функциональные требования с критериями приёмки
• нефункциональные требования (нагрузка, отклик, совместимость)
• состав поставки (исходники, документация, инфраструктура)
• стек технологий, чтобы потом не получить продукт, который некому поддерживать

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

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

Разбейте проект на этапы с отдельными актами. Это даёт заказчику точки выхода и контроль качества по дороге, а исполнителю - предсказуемые платежи.

По каждому этапу пропишите:

• результат этапа (артефакт, который передаётся)
• срок и форму приёмки
• срок на тестирование заказчиком
• последствия отказа от приёмки и порядок устранения замечаний

Без процедуры приёмки исполнитель имеет право считать работу принятой по факту использования.

Передача исключительных прав

Это пункт, который чаще всего игнорируют, а потом не могут продать бизнес или внести его в M&A. По умолчанию исключительные права на код принадлежат исполнителю или его сотруднику.

В договоре прямо укажите:

• момент перехода прав (после оплаты этапа или по факту приёмки)
• объём прав (исключительные, в полном объёме, на весь срок)
• территорию (весь мир)
• право переработки и сублицензирования

Отдельный пункт - права на сторонние библиотеки и open-source компоненты. Исполнитель обязан передать список с лицензиями.

Конфиденциальность

Разработчик получает доступ к бизнес-логике, базам, иногда персональным данным клиентов. NDA в составе договора или отдельным документом обязателен, со штрафом за нарушение и обязанностью уничтожить копии после завершения работ.

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

Стандартная формулировка про «принять все разумные меры» не работает. Нужна конкретика:

• неустойка за день просрочки сдачи этапа
• право заказчика на односторонний отказ при просрочке свыше N дней
• право на удержание из последующих платежей сумм за устранение дефектов
• гарантийный срок на код и порядок исправления багов

Полезно также оговорить ситуации форс-мажора и зависимости от заказчика (если ТЗ менялось, сроки сдвигаются пропорционально).

Доступы и репозитории

Отдельный раздел договора - доступы. Кто владеет репозиторием, аккаунтами облачных сервисов, доменами, ключами API. Регулярно встречается ситуация, когда после ссоры с подрядчиком заказчик остаётся без доступа к собственному продукту.

Фиксируйте:

• репозиторий принадлежит заказчику с первого дня
• учётные записи в облаке (AWS, Я.Облако, Selectel) оформлены на компанию заказчика
• передача всех логинов и ключей при завершении работ под акт
• запрет на удалённое отключение продукта

Корпоративная сторона

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

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