Что должно быть в договоре на разработку: чек-лист заказчика

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

Мы сидим по обе стороны стола: пишем договоры как подрядчик и разбираем чужие по просьбе заказчиков, которые хотят понять, что подписывают. По нашей практике почти все споры сводятся к трём непрописанным вещам: что считается результатом, кто и как его принимает и что происходит, когда объём меняется. Ниже — чек-лист по пунктам, а не универсальный шаблон: шаблона, который подойдёт и внедрению CRM за 400 тысяч, и производственной системе за 12 миллионов, не существует.

Предмет: техзадание — приложение к договору, а не переписка в чате

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

Рабочая конструкция такая: в договоре рамка, в приложении № 1 — техническое задание с номером версии, датой и подписями обеих сторон, и прямая оговорка, что приложение является неотъемлемой частью договора. Дальше правило, которое экономит месяцы: любое изменение ТЗ оформляется новой версией приложения или допсоглашением. Если на старте ТЗ объективно не готово — не притворяйтесь, что готово. Сделайте первый этап отдельной работой: обследование и разработка ТЗ со своей ценой и своим результатом — документом, который вы принимаете актом и который становится приложением к следующему этапу. Такой этап обычно занимает 2–4 недели и стоит 5–12% бюджета проекта, зато после него фиксированная цена перестаёт быть фикцией.

Этапы и приёмка: здесь ломается больше всего проектов

Этап — это не отрезок календаря, а пара из результата и способа его проверить. «Настройка интеграции с 1С» результатом не является: настройка бывает какой угодно. Проверяемая формулировка звучит иначе: заказ, созданный в CRM, попадает в 1С в течение 60 секунд с заполненными номенклатурой, количеством и контрагентом; проверено на 20 тестовых заказах без ручного вмешательства. По такому критерию спорить не о чем — он либо выполняется, либо нет. Требуйте, чтобы каждый этап был описан в этой логике, включая последний: у финального этапа критерием обычно становится работа системы на боевых данных в течение оговорённого периода.

1. 1Подрядчик передаёт результат этапа и письменно уведомляет об этом — на адрес, указанный в договоре, а не сообщением в мессенджере. Способ уведомления должен быть прописан.
2. 2Заказчик проверяет в течение согласованного срока. Реалистично — 5–10 рабочих дней; для этапов с интеграциями срок считают от момента предоставления тестового контура.
3. 3Проверка идёт по критериям приёмки из приложения, а не по общему впечатлению. Это защищает обе стороны: подрядчика — от бесконечных доработок, вас — от формальной сдачи неработающего.
4. 4Заказчик подписывает акт или направляет мотивированный отказ со списком конкретных расхождений с ТЗ.
5. 5Подрядчик устраняет расхождения за оговорённый срок; повторная проверка идёт только по спорным пунктам, а не по всему объёму заново.
6. 6Если заказчик молчит дольше срока проверки, работы считаются принятыми. Пункт справедлив, но срок должен быть выполнимым: два рабочих дня на проверку интеграции с 1С физически не хватит.

Про сроки. Для договора подряда начальный и конечный сроки работ — существенное условие (ст. 708 ГК РФ), а без промежуточных сроков этапов весь проект превращается в один длинный этап, к которому нечего предъявить до самого конца. И держите в голове п. 2 ст. 720 ГК РФ: приняв работу без оговорок в акте, вы теряете право ссылаться на явные недостатки. Поэтому мотивированный отказ — не проявление недоверия, а рабочая процедура; нормальный подрядчик к нему относится спокойно.

Этап, у которого нет измеримого критерия приёмки, — это не этап, а отчётный период. Вы платите за прошедшее время, а не за результат.

Деньги: цена этапа, изменение объёма и безопасная сделка

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

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

Безопасная сделка. В IT под этим словом понимают три разных механизма, и их полезно не путать.

• Счёт эскроу и договор условного депонирования (ст. 860.7 и гл. 47.1 ГК РФ): деньги лежат у банка или нотариуса и уходят подрядчику при наступлении условия — обычно это подписанный акт этапа. Механизм рабочий, но требует времени на оформление и стоит денег.
• Безотзывный покрытый аккредитив: та же логика через привычный банковский инструмент, раскрытие — против подписанного акта. Для большинства компаний это более простая замена эскроу; комиссия измеряется долями процента от суммы плюс фиксированный минимум — точные тарифы смотрите в своём банке.
• Депонирование исходного кода: у третьей стороны хранится актуальная копия кода и инструкции по сборке, а вы получаете к ним доступ, если подрядчик исчез, обанкротился или нарушил договор. Нужно тем, чей бизнес встанет при отказе системы, и кто не держит код у себя.
• Бесплатная альтернатива всем трём — дробление на короткие этапы с авансом 30–50% и этапом длиной 2–4 недели. Максимальный риск равен авансу одного этапа, а не бюджету проекта.

Честно про границы: в проектах до 1–1,5 млн ₽ эскроу почти всегда избыточен — короткие этапы защищают лучше и не стоят ничего. Эскроу и аккредитив начинают окупать возню от нескольких миллионов, при работе с незнакомым подрядчиком или когда платёж согласует финансовый контур, которому нужен формальный механизм. Депонирование кода имеет смысл, когда подрядчик хостит систему у себя; если репозиторий и серверы ваши, вопрос снимается сам.

Права на код, доступы и персональные данные

По ст. 1296 ГК РФ исключительное право на программу, созданную по договору, предметом которого было её создание, принадлежит заказчику, если договором не предусмотрено иное. Ловушек здесь две. Первая — оговорка про иное: подрядчик вправе вписать предоставление лицензии вместо отчуждения права, и это законно. Вторая — ст. 1297: если создание программы не было прямо предусмотрено договором (вы заказали обследование, а по ходу написались скрипты), права остаются у подрядчика. Отсюда правило: предмет договора прямо называет создание программы для ЭВМ, а пункт о правах прямо говорит об отчуждении исключительного права в полном объёме с момента подписания акта соответствующего этапа.

• Исходный код и всё, без чего он не собирается: конфигурации, миграции базы, скрипты развёртывания. Формулировка «код передаётся по запросу заказчика» без срока и формата не значит ничего. Проще другое: репозиторий заводится в вашем аккаунте с первого дня, подрядчик работает в нём как участник, а не как владелец.
• Документация уровня «другой разработчик поднимает систему с нуля»: схема данных, описание интеграций, переменные окружения, инструкция по развёртыванию. Проверяется одним действием — на приёмке финального этапа попросите развернуть копию на чистом сервере по этой инструкции.
• Сторонние библиотеки с перечнем лицензий и заверение, что среди них нет требующих раскрытия вашего кода или запрещающих коммерческое использование. Это ровно тот случай, для которого существуют заверения об обстоятельствах (ст. 431.2 ГК РФ).
• Для ИИ-решений отдельным абзацем: кому принадлежат промпты, размеченные наборы данных и дообученные модели, и вправе ли подрядчик использовать ваши данные для обучения своих продуктов. По умолчанию на последний вопрос ответ должен быть отрицательным.

Доступы описываются так же конкретно: что выдаём (CRM, телефония, 1С, серверы), с каким уровнем прав, кому персонально, на какой срок. Плюс обязанность вернуть или уничтожить копии данных и подтвердить это письмом в течение 5 рабочих дней после закрытия проекта. Отзыв доступов — это процедура с чек-листом, а не намерение: по нашей практике учётные записи подрядчиков живут в системах годами после окончания работ. Конфиденциальность лучше держать разделом договора, а не отдельным красивым NDA: нужны определение защищаемой информации, срок действия (обычно 3–5 лет после окончания работ) и размер ответственности — обязательство без суммы штрафа не работает. Если подрядчик касается персональных данных ваших клиентов, оформляется поручение на обработку по ч. 3 ст. 6 152-ФЗ с перечнем действий, целями и требованиями к защите. Перед клиентом за утечку отвечаете вы как оператор, а не подрядчик, — поэтому ответственность подрядчика перед вами прописывается отдельным пунктом с суммой.

Гарантия и ответственность: что считается дефектом

Гарантийный период без определения дефекта — источник вечного спора. Дефект — это расхождение поведения системы с ТЗ и принятыми критериями приёмки. Не дефект — новое требование, изменение внешнего API стороннего сервиса, поломка после правок ваших сотрудников. Рабочая конструкция: гарантия 6–12 месяцев с даты финального акта, устранение дефектов бесплатно, сроки реакции разнесены по критичности — например, блокирующий дефект (процесс встал) — реакция 4 рабочих часа и обходное решение в течение рабочего дня, некритичный — 10 рабочих дней. Если гарантийный срок не установлен вовсе, по ст. 724 ГК РФ требования по недостаткам можно предъявить в разумный срок в пределах двух лет, но доказывать придётся существенно больше — дешевле написать явно.

Ответственность за срыв сроков. Неустойка 0,1% от стоимости просроченного этапа за день просрочки — рыночная норма: это около 3% в месяц, ощутимо и при этом не разорительно. Смотреть надо на три вещи. От какой базы считается процент: от стоимости просроченного этапа, а не от неоплаченного остатка. Есть ли потолок и какой: потолок в 5% делает пункт декоративным, 10–20% от стоимости этапа — рабочий диапазон. И симметричен ли пункт: за задержку приёмки, согласований и предоставления доступов с вашей стороны ответственность тоже обычно предусматривают, и это справедливо — половина сорванных сроков в автоматизации возникает на стороне заказчика. Заодно проверьте, не выключено ли договором ваше право на односторонний отказ: по ст. 717 ГК РФ заказчик может отказаться от договора подряда до сдачи результата, оплатив фактически выполненное.

Чек-лист заказчика

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