Разработка ПО: споры цифрового подряда

Спор по разработке программы начинается, когда заказчик считает, что получил не то, что заказывал, или получил слишком поздно, а разработчик уверен, что всё сделал и ждёт оплаты. Юридически такие договоры чаще всего квалифицируются как подряд по главе 37 ГК РФ, иногда как смешанный договор с элементами подряда, услуг и отчуждения исключительного права. Суд оценивает не название документа, а то, что стороны на самом деле договорились создать и передать. От квалификации зависят правила приёмки, возможность отказаться от договора и судьба прав на исходный код.

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

Ниже разобраны споры о техническом задании, срывах сроков, приёмке, правах на код, а также типичный ход таких дел в арбитражном суде.

Техническое задание как предмет договора

В подряде должно быть определено, какой результат создаётся. Для программы это функциональность, интерфейсы, требования к производительности и совместимости, состав документации. Если ТЗ нет или оно сведено к одной странице общих слов, разработчик получает аргумент, что предмет не согласован, а договор не заключён. Заказчик в ответ доказывает, что стороны исполняли договор и понимали, что создаётся. Суды склонны признавать договор заключённым, если работы фактически велись и частично принимались.

Размытое ТЗ и спор о том, что входило в работу

Большинство конфликтов возникает не из-за отсутствия ТЗ, а из-за его неполноты. Заказчик считает, что интеграция с платёжной системой подразумевалась, разработчик — что это доработка за отдельную плату. Суд смотрит на текст ТЗ, прототипы, дизайн-макеты, обсуждения при оценке проекта, коммерческое предложение. Если разработчик сам указывал функцию в оценке трудозатрат, отказаться от неё потом сложно.

Гибкая разработка и изменение требований

При работе спринтами ТЗ меняется постоянно. Каждое изменение требований меняет объём работ и может сдвигать сроки. Если договор не предусматривает порядок согласования изменений, стороны спорят, были ли они согласованы. Доказательствами служат задачи в трекере с подтверждением заказчика, протоколы демонстраций, письма с одобрением бэклога. Изменения, внесённые устно на созвоне без фиксации, в суде доказать трудно.

Что должно быть в ТЗ, чтобы спор был разрешим

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

Сроки: просрочка, встречные обязанности и отказ от договора

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

Когда разработчик не отвечает за задержку

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

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

Отказ заказчика от договора

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

Расчёт при прекращении договора

Когда заказчик отказывается от договора, подрядчик требует оплатить выполненное. Если этапы не сдавались, объём определяется экспертизой: что из кода работоспособно, какая доля функций реализована, сколько стоят такие работы по рынку. Заказчик, в свою очередь, требует вернуть аванс за невыполненную часть и получить наработки. Заранее прописанная поэтапная сдача с отдельной оценкой каждого этапа сильно упрощает расчёт.

Приёмка: акты, тестирование, мотивированный отказ

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

Односторонний акт и молчание заказчика

Если заказчик не подписывает акт и не направляет мотивированного отказа, подрядчик вправе оформить акт в одностороннем порядке. Такой акт признаётся надлежащим доказательством выполнения, если заказчик не докажет обоснованность отказа от подписания. Типичная ошибка заказчика — не отвечать вовсе или ответить «есть замечания, доработайте» без их перечня. Суд признаёт работу принятой, а заказчик остаётся с долгом.

Как составить мотивированный отказ

1. Перечислить конкретные несоответствия ТЗ со ссылкой на пункт.
2. Приложить доказательства: скриншоты ошибок, логи, протокол тестирования.
3. Указать, какие недостатки препятствуют использованию, а какие нет.
4. Установить разумный срок на устранение.
5. Направить отказ способом, предусмотренным договором, и сохранить подтверждение.

Опытная эксплуатация и гарантийный период

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

Недостатки против доработок

Разработчик называет замечание заказчика новой функцией, заказчик называет его устранением недостатка. Критерий один: соответствует ли программа ТЗ и обычно предъявляемым требованиям. То, что в ТЗ не было и не следует из назначения программы, считается доработкой, которая оплачивается отдельно.

Права на код: кому принадлежит программа

Программа для ЭВМ охраняется как литературное произведение. Создание программы и передача прав на неё — разные вещи, и договор должен решать обе задачи.

Правило о программе, созданной по заказу

Исключительное право на программу, созданную по договору, предметом которого было её создание, принадлежит заказчику, если договором не предусмотрено иное. Это правило закреплено в статье 1296 ГК РФ. Если право остаётся за разработчиком, заказчик получает право безвозмездно использовать программу для собственных нужд на условиях простой лицензии в течение всего срока действия исключительного права.

Главная ловушка — формулировки вида «разработчик предоставляет заказчику право использования» вместо «исключительное право переходит к заказчику». Первая формулировка означает лицензию, вторая — отчуждение. Для заказчика, который планирует продавать продукт или привлекать инвестиции, разница принципиальна.

Библиотеки, фреймворки и заимствованный код

Любая программа содержит сторонние компоненты: открытые библиотеки, модули под собственными лицензиями, собственные наработки студии. На такие части исключительное право к заказчику не переходит. Некоторые открытые лицензии обязывают раскрывать исходный код производного продукта. Заказчику стоит требовать перечень использованных сторонних компонентов с указанием лицензий, а разработчику — прописывать, что его типовые модули остаются за ним с лицензией для заказчика.

Передача исходного кода и доступов

Договор должен прямо обязывать разработчика передать исходный код, инструкции по сборке, доступы к репозиторию, серверам, магазинам приложений. Если это не прописано, разработчик может передать только скомпилированную версию. Отдельный спор возникает, когда репозиторий и аккаунты зарегистрированы на разработчика, и после конфликта он блокирует доступ. Требование о передаче кода и доступов заявляется в иске вместе с требованиями о деньгах.

Авторы-сотрудники и фрилансеры

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

Фиксированная цена и оплата по часам: споры о деньгах

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

Твёрдая и приблизительная смета

Цена работы по договору подряда может быть определена твёрдой или приблизительной сметой. Если смета твёрдая, подрядчик не вправе требовать её увеличения, даже если затраты оказались выше. Если приблизительная и возникла необходимость существенно её превысить, подрядчик обязан своевременно предупредить заказчика. Заказчик, не согласный на превышение, вправе отказаться от договора, оплатив выполненную часть. Подрядчик, не предупредивший о превышении, обязан выполнить работу по цене, определённой в договоре. Для ИТ-проектов эти правила работают, если в договоре цена привязана к конкретному объёму функций.

Модель «время и материалы»

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

Удержание результата при неоплате

Разработчик, которому не платят, иногда отключает сервис, блокирует админ-панель или внедряет в код ограничения. Такие действия опасны для него самого. Если договор не даёт права приостановить доступ, а программа уже передана заказчику, блокировка может стать основанием для требования о возмещении убытков. Законный инструмент — приостановление работ до оплаты с письменным уведомлением и иск о взыскании долга.

Арбитражный процесс по ИТ-подряду

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

Претензия и сроки

До иска о взыскании долга или неустойки нужно направить претензию и выждать 30 календарных дней, если договор не устанавливает иной срок. Для требований о качестве работ действует сокращённый срок исковой давности, если недостатки выявлены в гарантийный период. Сроки лучше проверять сразу, а не накануне подачи иска.

Экспертиза программного продукта

Почти любой спор о разработке упирается в экспертизу. Эксперт отвечает, соответствует ли программа ТЗ, какие функции работоспособны, какова стоимость выполненной части, есть ли в коде заимствования. Формулировка вопросов определяет полезность заключения. Вопрос «качественно ли выполнена работа» бесполезен, вопросы нужно привязывать к конкретным пунктам ТЗ и конкретным функциям. Для экспертизы код должен быть зафиксирован: депонирование, выгрузка репозитория с хешами, нотариальный осмотр.

Доказательства переписки

Таск-трекеры, системы контроля версий, мессенджеры — основной массив доказательств. История коммитов показывает, кто и когда писал код. Задачи в трекере показывают согласования и изменения требований. Переписку нужно выгружать заранее, пока доступ есть. После конфликта разработчик или заказчик может закрыть рабочее пространство.

SLA и поддержка после запуска

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

Практика: типовые споры заказчиков и студий

Ниже описаны типовые ситуации. Это модели того, как обычно развиваются споры по ИТ-подряду, а не описание конкретных дел.

Заказчик не оплачивает, ссылаясь на ошибки

Студия сдала мобильное приложение, заказчик не подписал акт и не заплатил последний этап, сославшись на ошибки. Мотивированного отказа не было, ошибки перечислены в чате общими словами. Студия оформляет односторонний акт и требует оплату. Если заказчик не докажет существенные недостатки экспертизой, долг обычно взыскивается. Заказчику в такой ситуации выгоднее сразу оформить отказ с перечнем дефектов.

Проект сорван, заказчик требует вернуть аванс

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

После разрыва разработчик не отдаёт код

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

Как адвокат строит защиту

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

Основной канал связи с адвокатом — электронная почта arbitrazhdelo@gmail.com.