Заказчик требует вернуть деньги за разработку: что сохранить до ответа на претензию.

Casus. Заказчик требует вернуть аванс, утверждает, что сроки сорваны, а результат не соответствует ТЗ. Разработчик, в свою очередь, уверен, что значительная часть проекта выполнена, но акт не подписан, требования неоднократно менялись, а основная история работ осталась в переписке, таск-трекере и Git.

В такой ситуации одна из ошибок — сразу начинать писать ответ на претензию.

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

Начните с договора и первоначального ТЗ

Прежде всего необходимо установить, о чём стороны договорились изначально:

• какой результат в перспективе согласован;
• каков первоначальный объём работ;
• какие этапы и сроки согласованы;
• как должна проходить приёмка;
• как оформляются изменения требований;
• что считается дополнительной работой;
• когда возникает обязанность по оплате (поэтапно или полная оплата за финальный результат);
• вопросы относительно исходного кода и интеллектуальных прав.

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

Если заказчиком выступает физическое лицо и разработка заказывалась для личных, семейных или иных нужд, не связанных с предпринимательской деятельностью, дополнительно может применяться Закон РФ "О защите прав потребителей". В таком случае правила об отказе от договора, нарушении сроков и недостатках результата могут отличаться от обычных B2B-отношений.

Применительно к подрядной модели закон также различает отказ заказчика из-за нарушения со стороны подрядчика и обычный отказ заказчика от дальнейшего исполнения.

Если подрядчик выполняет работу настолько медленно, что окончание её к сроку становится явно невозможным, у заказчика могут возникнуть основания для отказа по ст. 715 ГК РФ.

Помимо этого заказчик может отказаться от договора до сдачи результата при иных правовых последствиях, о чем говорит ст. 717 ГК РФ.

Поэтому сама фраза в претензии "требую вернуть все деньги" ещё не означает, что именно такой результат следует из договора и закона.

Сначала нужно понять, что в действительности происходило с проектом.

Зафиксируйте все текущие изменения в первоначальном объеме

Типичная ситуация в заказной разработке выглядит так:

• согласовали ТЗ;
• показали первую версию;
• заказчик попросил изменить часть логики;
• добавились новые интеграции;
• отдельные функции были заменены другими;
• появились новые задачи;
• изменившийся объём повлиял на сроки.

Для команды это может выглядеть как обычное развитие продукта. Но при конфликте возникает юридический вопрос: можно ли подтвердить, что заказчик действительно согласовал изменения первоначального scope?

Поэтому необходимо сохранить историю change requests:

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

При толковании договора значение может иметь не только буквальный текст документа, но также переговоры, переписка, сложившаяся практика отношений сторон и их последующее поведение — это прямо предусмотрено ст. 431 ГК РФ.

Отдельно зафиксируйте действия самого заказчика

Не всякая задержка проекта возникает по вине разработчика.

Исполнение может зависеть от того, предоставил ли заказчик вовремя:

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

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

Сохраните сообщения, из которых видно:

что требовалось от заказчика → когда это было запрошено → когда фактически предоставлено → как задержка повлияла на дальнейшие работы.

В подрядной модели это имеет и самостоятельное юридическое значение. В частности, ст. 719 ГК РФ предусматривает возможность не приступать к работе либо приостановить её, если нарушение заказчиком своих обязанностей препятствует исполнению договора.

При этом подрядчику важно своевременно сообщать заказчику об обстоятельствах, которые препятствуют надлежащему выполнению работы или угрожают соблюдению срока. Такие обязанности предусмотрены, в частности, ст. 716 ГК РФ.

Иными словами, недостаточно уже после конфликта сказать:

"Мы ждали заказчика".

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

Сохраните таск-трекер

Jira, YouTrack, Weeek, Trello и другие системы часто содержат значительную часть реальной истории разработки.

Важно сохранить:

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

Особенно внимательно стоит посмотреть задачи, которых не было в первоначальном ТЗ, но которые появились позднее по инициативе заказчика.

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

Само наличие большого количества задач ещё не доказывает исполнение договора. Ценность появляется тогда, когда удаётся построить связку:

требование → задача → выполненное изменение → релиз → передача или демонстрация заказчику.

Git и commits: сохраняйте, но не переоценивайте

В IT-спорах встречаются две крайности.

Первая:

"У нас несколько тысяч коммитов — значит, работа выполнена".

Вторая:

"Git вообще не имеет юридического значения".

Оба подхода слишком упрощённые.

История репозитория способна показать:

• когда создавались изменения;
• кто выполнял работу;
• какие участки проекта изменялись;
• существовал ли определённый код к конкретной дате;
• как развивался продукт;
• какие изменения вошли в релиз.

Но commit необходимо связать с конкретной задачей и договорным обязательством.

Гораздо содержательнее выглядит цепочка:

пункт ТЗ → задача №125 → commit → pull request → release → сообщение заказчику о готовности → комментарии после демонстрации.

чем просто заявление:

"В репозитории много кода".

В IT-споре важно доказать не то, что команда много работала, а то, какие договорные обязательства подтверждает цифровая история проекта.

Не меняйте историю после возникновения конфликта

После получения претензии не стоит без необходимости:

• переписывать историю Git;
• удалять ветки;
• менять старые задачи;
• удалять issues;
• уничтожать переписку;
• "наводить порядок" в старых записях.

Сначала лучше зафиксировать состояние проекта таким, каким оно существовало на дату возникновения спора.

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

По возможности имеет смысл сделать отдельную резервную копию репозитория и сохранить историю проекта в исходном виде.

Зафиксируйте releases, deploy и передачу результата

Для спора важно не только существование кода у разработчика. Нужно понимать, дошёл ли результат до заказчика.

Полезно сохранить:

• release history;
• deployment history;
• CI/CD logs;
• сведения о staging;
• production deploy;
• сообщения о выходе новой версии;
• предоставление тестовых доступов;
• результаты демонстраций;
• замечания заказчика после релиза;
• bug reports.

Если после демонстрации заказчик написал:

"Эту часть приняли, здесь нужно исправить только форму"

— это совсем другая доказательственная ситуация, чем если результат вообще никогда ему не показывался.

Также нужно сохранить данные о передаче доступов:

• административная панель;
• сервер;
• репозиторий;
• домен;
• облачная инфраструктура;
• API;
• аккаунты и ключи.

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

В подрядной модели порядок приёмки отдельно регулируется ст. 720 ГК РФ.

Не ограничивайтесь скриншотами

Скриншоты удобны для первичного анализа, но цифровой проект лучше сохранять шире.

Если технически возможно, дополнительно сохраните:

• экспорт задач;
• оригинальные сообщения и письма;
• резервную копию репозитория;
• историю pull/merge requests;
• журналы релизов;
• логи развёртывания;
• историю изменений документов.

Важно сохранять контекст, а не только отдельные выгодные фрагменты.

Сообщение:

"Да, делаем"

может иметь совершенно разный смысл в зависимости от предыдущих сообщений.

Электронная переписка и документы в цифровой форме могут использоваться в качестве доказательств. В арбитражном процессе это прямо следует, в частности, из ст. 75 АПК РФ.

Что сохранить до ответа на претензию

Я бы собрал материалы по пяти группам.

1. Договорный слой

• договор;
• приложения;
• первоначальное ТЗ;
• последующие версии ТЗ;
• дополнительные соглашения;
• документы по этапам.

2. Коммуникационный слой

• переписка;
• change requests;
• согласование новых задач;
• изменение сроков;
• задержки согласований со стороны заказчика;
• запросы доступов, материалов и данных.

3. Delivery-слой

• задачи;
• Git;
• commits;
• pull/merge requests;
• releases;
• deployment history;
• staging и production.

4. Передача и приёмка

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

5. Коммерческий слой

• счета;
• оплаты;
• стоимость этапов;
• согласованные дополнительные работы;
• задолженность сторон.

Отдельно стоит проверить условия об исходном коде и интеллектуальных правах.

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

Если спор непосредственно касается исходников или прав на код, этот вопрос лучше анализировать отдельно.

После сбора материалов восстановите timeline

Следующий шаг — расположить ключевые события проекта по времени.

Например:

• 12 марта — заключён договор.
• 15 марта — согласовано ТЗ.
• 4 апреля — заказчик запросил новую интеграцию.
• 7 апреля — разработчик сообщил о влиянии изменения на срок.
• 10 апреля — заказчик согласовал изменение.
• 30 апреля — версия размещена на staging.
• 3 мая — получены замечания заказчика.
• 12 мая — опубликован следующий релиз.
• 20 мая — предоставлен production-доступ.

После этого каждое событие сопоставляется с договором.

Так становится значительно проще определить:

• действительно ли была просрочка;
• какой объём должен был быть выполнен к конкретной дате;
• менялось ли ТЗ;
• переносились ли сроки;
• какие работы были дополнительными;
• был ли результат передан;
• заявлял ли заказчик недостатки;
• какая часть обязательств фактически исполнена.

И только после этого имеет смысл формировать юридический ответ на претензию.

Чего лучше не делать

После возникновения конфликта я бы избегал трёх вещей.

Не удалять цифровую историю проекта.
Даже если кажется, что старые ветки, задачи или сообщения больше не нужны.

Не пытаться задним числом сделать документы "идеальными".
Созданный после конфликта документ не заменяет реальную историю отношений сторон.

Не строить позицию на фразах вроде "проект готов на 80%".
Для спора значительно важнее определить, какие конкретные обязательства были выполнены, переданы и согласованы.

Вместо вывода

В IT-споре недостаточно показать договор или количество выполненных задач.

Нужно связать юридические обязательства с фактической историей проекта:

ТЗ → изменения → задачи → код → релизы → передача → использование результата.

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

Поэтому после получения претензии первый практический шаг зачастую не ответ на неё.

Сначала стоит сохранить и восстановить историю проекта.