Договор на разработку ПО: что прописать заказчику, чтобы потом не зависеть от подрядчика

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

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

Права на код

По Гражданскому кодексу (статья 1296) исключительное право на программу, созданную по договору заказа, принадлежит заказчику, если договор не говорит иного. Поэтому смотреть нужно как раз на «иное»: нет ли в договоре пункта, по которому права остаются у подрядчика, а вам выдаётся лицензия.

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

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

Передача исходного кода

Пишите конкретно, что передаётся и когда:

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

Лучший вариант, когда репозиторий с первого дня создан в аккаунте вашей компании, а подрядчик работает в нём как приглашённый участник. Тогда передавать в конце нечего.

Серверы, домены и аккаунты

Сервер, домен, аккаунт облака, аккаунт бота в Telegram, кабинет разработчика в магазине приложений, ключи платёжного сервиса регистрируются на вашу компанию. Подрядчику дают доступ, владельцем остаётся компания.

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

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

Договор на разработку без этапов превращается в спор в конце. В нём должны быть:

Этапы с результатом. Каждый этап заканчивается тем, что можно проверить: работающий модуль на тестовом сервере. Формулировку «выполнено 40% работ» проверить нельзя.

Критерии приёмки. Что именно проверяется и на каких данных. Без них приёмка превращается в обмен мнениями. Как проводить её на деле, мы разобрали в статье как принимать работу у подрядчика по этапам.

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

Изменение объёма

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

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

Гарантия покрывает ошибки подрядчика в течение срока после приёмки, чаще всего от трёх до шести месяцев. Поддержка, то есть обновления, мелкие доработки и реакция на сбои, оформляется отдельно. Об этом подробнее в статье сколько стоит поддержка после запуска.

Персональные данные

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

Расторжение

Напишите, что вы получаете, если договор прекращается на середине: код на дату расторжения, документацию по сделанному, доступы. И за какие этапы платите. Этот пункт кажется лишним в начале и становится главным, когда отношения испортились.

Частые вопросы

Нужно ли техническое задание в приложении к договору? На первый этап хватит описания результата. Подробное задание обычно появляется после разбора процесса и прикладывается к договору на разработку.

Что если подрядчик не хочет передавать код до конца проекта? Спросите почему. Частый ответ про защиту от неоплаты решается передачей после каждого оплаченного этапа.

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

Правило

Прочитайте договор так, будто подрядчик исчезнет через месяц после подписания. Всё, что в этом случае вы не сможете получить, нужно дописать.