«Разработать личный кабинет по согласованному ТЗ» — этого недостаточно, чтобы понять, что исполнитель передаст заказчику: работающий сервис, исходный код, документацию или доступ к репозиторию. Если состав результата останется только в переписке, при сдаче проекта стороны могут оценить одну и ту же работу по-разному. В договоре нужно связать четыре вопроса: что создаётся, как меняется задача, чем подтверждается сдача и какие права получает заказчик.
Речь преимущественно о договорах между компаниями или предпринимателями по российскому праву. Для трудовых отношений, государственного заказа и проектов с иностранным элементом отдельные правила могут менять подход к оформлению. Материал не заменяет индивидуальную юридическую консультацию.
Сначала определите состав результата
Название договора само по себе не определяет обязанности сторон. Разработка может включать создание новой программы, настройку существующей системы, внедрение, консультации и поддержку. Разграничьте эти работы в приложении: иначе требование «устранить ошибку» может касаться как недостатка созданного кода, так и новой функции, которую не заказывали.
Перед подписанием подготовьте:
- Договор — общие правила оплаты, сроков, приёмки, ответственности и прав на результаты.
- Техническое задание или спецификацию — функции, ограничения, интеграции, поддерживаемые среды и проверяемые критерии готовности.
- План этапов — результат, срок и стоимость каждой поставки, если работа выполняется частями.
- Порядок обмена документами — кто вправе согласовывать задачи и какими сообщениями стороны подтверждают решения.
В небольшом проекте всё это может поместиться в одном документе. Важнее, чтобы условия не противоречили друг другу. Если договор и план работ называют разные сроки, заранее установите, какой документ имеет приоритет.
Как сделать техническое задание проверяемым
«Удобный интерфейс» — ожидание, а не критерий приёмки. Опишите пользовательские роли, основные сценарии и условия проверки. Например: администратор создаёт учётную запись, пользователь получает уведомление, операция отражается в журнале. Для интеграции назовите систему и способ обмена данными; укажите, кто предоставляет доступы и документацию API.
Отдельно перечислите, что не входит в работу: наполнение базы исходными данными, покупка лицензий, настройка инфраструктуры заказчика или подготовка текстов интерфейса. Это особенно важно, когда результат зависит от материалов и решений обеих сторон.
Разделите обязанности заказчика и исполнителя
Срок разработки зависит и от заказчика. Если он должен выдать доступ к тестовому стенду, предоставить макеты или согласовать прототип, закрепите срок каждого действия и последствия задержки. Но не стоит автоматически продлевать весь проект на каждый день ожидания. Лучше предусмотреть уведомление о препятствии, оценку его влияния на конкретный этап и согласование нового графика.
Назначьте представителей сторон и определите их полномочия. Менеджер может подтверждать промежуточный вариант экрана, но не вправе существенно увеличивать цену. Поэтому отличайте рабочие комментарии от согласования дополнительных работ. Если решения принимаются по электронной почте или в системе управления задачами, укажите адреса, аккаунты и виды решений, допустимые для каждого канала.
Предусмотрите изменение требований до начала работы
Даже подробное ТЗ редко остаётся неизменным. Согласуйте порядок добавления функций: заказчик описывает запрос, исполнитель оценивает влияние на цену и срок, стороны утверждают изменение — только после этого задача входит в план. Запись в трекере сама по себе не должна менять договор, если уполномоченные представители не согласовали стоимость и последствия для графика.
Для небольших корректировок можно выделить лимит часов или бюджет. Укажите, как он расходуется и кто видит остаток. Иначе «маленькие правки» постепенно превратятся в отдельный проект, который одна сторона считает оплаченным, а другая — нет.
Свяжите оплату с понятными событиями
Разделите в договоре аванс, оплату этапов и расходы сверх цены. Уточните, входят ли в стоимость тестирование, исправление выявленных недостатков, документация, передача кода и развёртывание. При открытом объёме работ согласуйте ставку, правила учёта времени, предел бюджета и периодичность отчётов. Условие «оплата по фактически затраченному времени» без этих деталей оставляет слишком много поводов для спора.
Если платёж привязан к акту, укажите, какой результат подтверждает этот акт. Аванс возможен до передачи результата, но его не следует смешивать с приёмкой: оплата сама по себе не всегда означает, что заказчик проверил программу и получил все материалы. Опишите и досрочное прекращение работы: как определить выполненный объём, какие промежуточные результаты передать и как рассчитать платежи с учётом договора и применимого закона.
Опишите приёмку как процедуру, а не одну подпись
Для цифрового результата мало написать: «заказчик подписывает акт в течение пяти дней». Ему нужно знать, где находится версия для проверки, как её запустить и с какими требованиями сравнивать. Установите способ уведомления о готовности, состав передаваемых материалов, срок тестирования и формат замечаний. В замечании стоит указывать конкретное несоответствие согласованным требованиям и, по возможности, шаги для его воспроизведения.
После исправления недостатков отведите срок на повторную проверку. Разделите ошибки, которые мешают использовать согласованную функцию, и мелкие дефекты, которые стороны готовы устранить после приёмки по отдельному списку. Если отсутствие ответа заказчика считается приёмкой, точно определите момент уведомления и срок для мотивированных замечаний. Это условие не освобождает исполнителя от обязанности передать результат и сохранить доказательства передачи.
Акт фиксирует сдачу работ, но не должен оставаться единственным подтверждением технической передачи. Сохраните номер версии, ссылку на согласованный репозиторий или архив, перечень файлов, инструкции по сборке и сведения о предоставленных доступах. Пароли и секретные ключи лучше передавать через защищённый канал, а в акте отмечать только факт предоставления доступа.
Согласуйте права на код и материалы
При заказной разработке недостаточно фразы «ПО принадлежит заказчику». Российское право предусматривает специальные правила для программ, создаваемых по договору заказа, но распределение прав зависит от содержания договора и характера работ. Определите, кому принадлежат исключительные права на специально созданные результаты, когда они переходят или возникают у соответствующей стороны и включено ли вознаграждение за права в цену.
Укажите состав результата: исходный и объектный код, документацию, дизайн интерфейса, базы данных при наличии охраняемых элементов, графику и другие созданные материалы. Для них могут действовать разные правила, поэтому формулировку о правах нужно соотнести с фактическим составом проекта. Если исполнитель сохраняет право использовать собственные инструменты или типовые модули, отделите их от кода, создаваемого специально для заказчика, и предоставьте заказчику права, необходимые для эксплуатации продукта.
Проверьте происхождение компонентов. В проекте могут использоваться библиотеки с открытым исходным кодом, коммерческие SDK, шрифты, изображения и сервисы третьих лиц. Исполнитель не может передать исключительное право на чужой компонент как на свой. Добавьте к договору перечень зависимостей с лицензиями, ограничениями использования и указанием, кто оплачивает коммерческие лицензии. Условия для сторонних компонентов проверяйте отдельно от условий передачи прав на созданный код.
Установите правила доступа, данных и безопасности
Если разработка ведётся на реальных пользовательских данных, договор не заменяет документы и меры, необходимые для их законной обработки. По возможности используйте обезличенный тестовый набор. Когда доступ к персональным данным необходим, определите цель и допустимые действия исполнителя, меры защиты, круг допущенных лиц, порядок уведомления об инциденте, а также возврата или удаления данных после работы. Учитывайте роль каждой стороны по применимому законодательству.
Отдельно опишите обращение с конфиденциальной информацией: исходным кодом заказчика, архитектурой, ключами доступа и коммерческими данными. Установите порядок выдачи и отзыва доступов, запрет на размещение материалов в несогласованных публичных хранилищах, правила привлечения субподрядчиков и использования инструментов, в которые передаются данные проекта. Ограничения должны соответствовать реальному процессу разработки — иначе команда не сможет их соблюдать.
Не путайте исправление дефектов с поддержкой
После приёмки могут обнаружиться ошибки, пропущенные при тестировании. Укажите период и порядок предъявления требований по недостаткам, сроки реакции, способ подтверждения ошибки и случаи, когда изменение кода заказчиком или внешнего сервиса влияет на обязательства исполнителя. Не называйте любую доработку «гарантийной»: новая роль или интеграция обычно требует отдельного согласования.
Поддержку удобнее описать отдельным разделом или договором: часы доступности, каналы обращений, приоритеты заявок, время реакции, плату и пределы работ. Время реакции на сообщение — не то же самое, что срок устранения проблемы. Если нужны оба показателя, определите каждый отдельно.
Что проверить непосредственно перед подписанием
- Совпадают ли наименования сторон, реквизиты и полномочия подписантов во всех документах.
- Можно ли по спецификации определить завершение каждого этапа без устных договорённостей.
- Указаны ли цена, сроки и порядок согласования изменений, в том числе через рабочие системы.
- Понятно ли, какие файлы, доступы и инструкции передаются вместе с актом.
- Разграничены ли права на новый результат, ранее созданные модули и компоненты третьих лиц.
- Согласованы ли порядок исправления недостатков и условия прекращения проекта.
Перед первой оплатой сохраните подписанные ТЗ и план этапов в одном согласованном месте. Если спецификации ещё нет, не оставляйте всю разработку на условии «ТЗ будет согласовано позднее». Сначала оформите оплачиваемый этап обследования и подготовки ТЗ — со своим результатом и процедурой приёмки.