В договоре написано: «Разработать систему по техническому заданию заказчика». Но задание так и не согласовали, изменения обсуждали в переписке, а готовую систему заказчик оценил словами «работает не так, как ожидали». Теперь сторонам придется выяснять, что именно обещал исполнитель, какие доработки входили в цену и была ли работа принята. Договориться об этом до первого платежа и выдачи доступа к репозиторию проще, чем разбираться после конфликта.
Речь идет преимущественно о договорах, подчиненных российскому праву. Если стороны, разработчики или используемые компоненты связаны с другими юрисдикциями, условия о правах и ответственности нужно проверять отдельно.
Ошибка 1. Назвать продукт, но не определить результат
«Личный кабинет», «CRM» и «платформа для публикаций» обозначают идею, но не объем работ. В договоре нужны характеристики, которые можно проверить: роли пользователей, основные сценарии, интеграции, требования к безопасности, поддерживаемые среды, ограничения производительности и состав передаваемых материалов. Каждый экран заранее описывать необязательно. Главное — отделить обязательный функционал от гипотез и пожеланий, которые команда будет исследовать в ходе проекта.
Требования удобно разбить на модули. Для каждого указать результат, способ его проверки и то, что должен предоставить заказчик: API, тестовые данные или доступ к инфраструктуре. Отдельным списком — материалы, которые исполнитель передает вместе с работающим сервисом: исходный код, инструкции по развертыванию, описание интеграций, тесты, документацию. Доступ к запущенной программе не означает, что заказчик получил все перечисленное.
Если часть требований пока неизвестна, можно начать с этапа обследования или проектирования. По его итогам стороны согласуют спецификацию, сроки и стоимость дальнейших работ. Это точнее, чем назначать фиксированную цену за объем, который еще не определен.
Где договору нужна определенность, а где — гибкость
При итерационной разработке не обязательно оформлять каждую задачу многостраничным дополнительным соглашением. Но договор должен устанавливать, кто вправе ставить задачи, где их фиксируют, в какой момент они считаются согласованными и как меняют бюджет. Одной ссылки на «задачи в трекере» мало, если не определены доступ к нему, значение статусов и сохранение истории.
Ошибка 2. Не согласовать порядок изменений
После начала работы заказчику могут понадобиться новые поля в отчетах, другой сценарий регистрации или дополнительная интеграция. Если договор не отделяет исправление дефекта от новой задачи, заказчик сочтет изменение частью исходной цены, а исполнитель выставит отдельный счет. Когда первоначальный объем не зафиксирован, доказать свою позицию трудно обоим.
Порядок можно выстроить так: инициатор описывает изменение, исполнитель оценивает влияние на цену, сроки и связанные модули, затем уполномоченные представители подтверждают решение в согласованном канале. Пока подтверждения нет, новая задача не заменяет прежнее обязательство. Для оплаты по затраченному времени дополнительно нужны ставка, учет часов, лимит на период и правило согласования перерасхода. Для фиксированной цены — порядок оценки дополнительных работ.
Исправление несоответствия согласованным требованиям не становится платной доработкой лишь потому, что ошибку заметили после демонстрации. И наоборот: новая бизнес-идея не становится дефектом только потому, что заказчик рассчитывал увидеть ее в продукте.
Ошибка 3. Привязать оплату к этапам, которые нельзя проверить
«Первый этап — 50% разработки» не объясняет, за что выставляется счет. У этапа должен быть наблюдаемый результат: прототип с определенными сценариями, готовый модуль или версия в тестовой среде. Если предусмотрен аванс, его стоит отличать от оплаты принятого результата и заранее прописать расчеты при досрочном прекращении договора.
Проверьте, отвечает ли договор на вопросы:
- Какие материалы и в каком формате исполнитель передает по завершении этапа?
- Где заказчик проверяет результат и кто предоставляет тестовую среду?
- Сколько времени есть на проверку и как направлять мотивированные замечания?
- Как проходит повторная передача после устранения замечаний?
- Можно ли принять независимую часть результата, пока другую исправляют?
Автоматическая приемка при молчании заказчика может быть полезна, но она не заменяет доказательств передачи результата и разумной возможности его проверить. Лучше заранее определить адреса и каналы уведомлений, форматы файлов и способ подтверждения доставки. Иначе спор начнется уже с вопроса о том, когда пошел срок приемки.
Приемка не должна маскировать поддержку
Исправление ошибок в согласованном результате, гарантийные обязательства и развитие продукта — разные виды работы. В договоре можно определить, что считать дефектом, как оценивать его критичность, в какие сроки исполнитель реагирует и что не входит в бесплатное исправление. Например, последствия изменений кода третьими лицами. Поддержку после приемки, обновление зависимостей и работу с новыми версиями внешних сервисов лучше описать отдельно. Обязанность «обеспечивать работоспособность» без срока и границ почти неизбежно вызовет разногласия.
Ошибка 4. Считать, что оплата автоматически решает вопрос с правами
Из факта оплаты не следует, что заказчику принадлежат все права на продукт. Договор должен закреплять подходящую правовую конструкцию с учетом характера работ: создание программы по заказу, передачу исключительного права либо лицензию на отдельные компоненты. По российскому праву для программы, созданной по договору, предметом которого было ее создание, действуют специальные правила о принадлежности исключительного права, если стороны не предусмотрели иное. Но правило по умолчанию не определит за них состав продукта, статус ранее созданных модулей и объем прав на сторонние элементы.
Перечислите, что входит в результат: программный код, материалы интерфейса, документация, оригинальные базы данных, если они есть. Если исполнитель использует собственный фреймворк или ранее созданный модуль, укажите, сохраняет ли он права на этот компонент и что заказчик вправе с ним делать: использовать в составе продукта, изменять, передавать вместе с продуктом. Формулировка «все права на все разработки исполнителя» может оказаться шире сделки и лишь добавить неопределенности.
Не забудьте о цепочке прав. Код могут создавать сотрудники исполнителя, привлеченные специалисты и субподрядчики. Основной подрядчик должен обеспечить права, необходимые для выполнения обязательств перед заказчиком, и сообщать о привлечении третьих лиц, если это существенно для проекта. Заказчику не обязательно по умолчанию получать личные договоры каждого разработчика; важнее проверяемые заверения, а для значимого проекта — подтверждение цепочки прав в допустимом объеме.
Права на код и фактический контроль над ним — не одно и то же. Даже согласовав переход исключительного права, заказчик не сможет продолжить разработку, если исходники хранятся только в закрытом репозитории подрядчика, а инструкции по развертыванию нет.
Ошибка 5. Не проверить сторонние компоненты
В продукте почти всегда есть чужие компоненты: библиотеки, шрифты, шаблоны, изображения, API или облачные сервисы. Исполнитель не может передать заказчику исключительное право на то, чем сам не владеет. Составьте перечень сторонних компонентов: происхождение, применимые лицензии, ограничения использования и необходимые платежи. Для открытого ПО важны условия конкретной лицензии и то, как компонент включен в продукт. Фразы «можно использовать бесплатно» недостаточно.
Если работа продукта зависит от стороннего сервиса, распределите ответственность за его выбор, регистрацию аккаунта, оплату подписки и изменения условий доступа. Исполнитель обычно не может гарантировать, что чужой API останется неизменным. Зато он может отвечать за корректную реализацию согласованной интеграции и уведомление об известных ограничениях.
Отдельно разберите материалы заказчика — дизайн, контент и наборы данных. Кто отвечает за наличие прав на их использование? Что делает исполнитель, если замечает очевидное препятствие? Такое распределение обязанностей не отменяет требований закона, но не возлагает на одну сторону контроль над материалами другой.
Ошибка 6. Дать доступ к данным без рабочих правил
Даже тестовая среда может содержать реальные данные клиентов и сотрудников. Одной оговорки о конфиденциальности мало, когда подрядчик получает учетные записи, скачивает базу на свой компьютер или подключает внешние инструменты. В договоре и приложениях нужно определить цели доступа, категории данных, круг уполномоченных лиц, порядок выдачи и отзыва учетных записей, требования к защите и действия при инциденте.
Если подрядчик обрабатывает персональные данные по поручению заказчика, российское законодательство предъявляет к такому поручению специальные требования. Его условия и организационные меры должны соответствовать реальному процессу обработки. Общая фраза «стороны соблюдают закон» этого не заменит. Для испытаний лучше брать обезличенные или синтетические данные, когда с их помощью можно проверить функциональность.
Перечислите аккаунты, домены, облачную инфраструктуру и репозитории, без которых продукт нельзя эксплуатировать. Зафиксируйте, на кого они оформлены, кто управляет ими во время проекта и как передает управление при завершении работы. Пароль в личном мессенджере не должен оставаться единственным способом попасть в критическую систему.
Ошибка 7. Не предусмотреть остановку проекта
Проект может остановиться и без нарушения договора: изменятся бюджет, стратегия или потребность в продукте. Поэтому порядок выхода нужен даже партнерам, которые сейчас хорошо ладят. Укажите, как направляется уведомление, как оплачивается уже выполненная работа, что происходит с авансом, промежуточными результатами и доступами, какие права заказчик получает на оплаченные материалы. Последствия расторжения зависят от вида обязательств, условий договора и применимого права; универсальная фраза «все деньги не возвращаются» может не сработать.
В длительном проекте код и документацию разумно передавать в согласованный репозиторий по мере готовности, а не только в конце. Тогда при остановке не придется отдельно доказывать само существование промежуточных результатов. Если работу продолжит другая команда, можно заранее предусмотреть ограниченную по сроку передачу знаний и отдельную оплату этой помощи.
Что проверить непосредственно перед подписанием
Прочитайте договор и приложения так, как их будет читать менеджер проекта, которому предстоит по ним работать. Сверьте шесть пунктов:
- Одинаково ли описаны продукт, этапы, цена и сроки в договоре, смете и спецификации?
- Понятно ли, кто согласовывает задачи и изменения и где сохраняется история решений?
- Определены ли критерии приемки, сроки проверки и порядок исправления замечаний?
- Разделены ли права на новый результат, прежние разработки исполнителя и сторонние компоненты?
- Названы ли материалы, доступы и сведения, которые стороны передают по завершении каждого этапа?
- Можно ли выполнить условия о данных и безопасности без неоговоренных выгрузок и общих аккаунтов?
Особенно внимательно сопоставьте коммерческое предложение с приложениями к договору. Если предложение обещает больше, перенесите значимые условия в согласованные документы или прямо определите статус предложения. Иначе стороны могут по-разному понимать, какие обещания стали требованиями к результату.
Материал не заменяет индивидуальную юридическую консультацию. Перед подписанием конкретного договора проверьте, совпадает ли юридическая формулировка с техническим порядком передачи: если в акте значится «исходный код», в приложении должны быть указаны репозиторий, уровень доступа и момент его предоставления.