Когда заказчик видит баг, а суд — исполнение обязательств

История о том, как заказчик, получив исходный код, требовал вернуть назад уплаченные 11,2 млн рублей с разработчика, Он утверждал, что программный продукт «не имеет потребительской ценности». Исполнитель доказывал обратное: готовность проекта – 98 %, а недоработки – устранимы и несущественны. Суд встал на сторону исполнителя. Результат признан промышленно применимым, а требование о возврате денег необоснованным. Этот кейс стал хорошей иллюстрацией того, как в ИТ-договорах на первый план выходит не код, а юридическая логика и доказательная база.

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

Стороны заключили договор на разработку ПО стоимостью 11 210 000 рублей. Стандартный договор на разработку на арендуемом исполнителем сервере с последующей передачей доступа к указанному серверу. Проблемы начались, когда заказчику перестало быть нужным ПО, которое разрабатывал исполнитель. С этого момента заказчик стал искать поводы не принимать работу и указывать на неработоспособность Программы вовсе, чтобы указывать на то, что отсутствует функционирующий результат по договору. Затем заказчик сменил сервер, в связи с чем вся инфраструктура ПО была перенесена на новый. При этом объективно проблемы возникали при развертывании ПО на сервере заказчика и что дело не в написанном исходном коде.

Исполнитель неоднократно пытался объяснить заказчику, что проблемы имеют устранимый характер, не связаны с самим результатом работ: проблемы идут с подключаемым окружением из-за нового сервера и неправильно выбранных веток в разработке.

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

Термин «разработка» – это набор действий, результатом выполнения которых являются программные средства. При этом разработка ПО включает в себя следующие процессы:

Помимо понятий «разработка» есть понятие «инсталляция», которая ставит своей задачей гарантию готовности программного продукта к применению в предназначенной для него среде.

Работы (услуги) по установке (инсталляции) могут в том числе включать в себя такие этапы, как:

Тем самым если в своем предмете договора указываете «разработка» и точка – значит вы осуществляете проектирование, кодирование или интеграцию ПО.

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

Лучше это все разбить по этапам и подписывать акты. Наличие подписанных актов, которые принимались без замечаний какое-то продолжительное время тоже будет определенным показателем для суда, что у заказчика не возникало вопросов все это время. А возникли они почему-то только спустя длительное время.

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

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

По мнению заказчика, результат «не функционирует», является неготовым, а потому не имеет потребительской ценности.

Мы же в свою очередь со стороны разработчика указывали на то, что в ИТ-сфере "Готовое ПО" – это коробочное решение, которые уже разработаны и протестированы для широкого круга пользователей и которое не связано с кастомной разработкой.

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

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

Работоспособность подтверждена экспертизой. Из 668 требований ТЗ выполнено 665, что составляет 98%. Такая работоспособность Программы явно несоразмерна пользованию истцом правом на отказ от договора с возвратом всей суммы. Большая часть средств ушла на оплату труда разработчиков.

Суд согласился с выводами эксперта:

Апелляция оставила решение в силе. Требования о возврате средств и взыскании процентов отклонены.