Судебный кейс. Не занимайтесь «самолечением»: как нужно принимать результат работ, искать и исправлять явные или скрытые недостатки в ПО

Ключевой вывод по делу № 1ИГИП2010

Вмешательство в код ПО и несанкционированная модификация ПО может повлечь автоматическое прекращение гарантийных обязательств.

Фактические обстоятельства

Заказчик и Исполнитель в 2017 году заключили договор возмездного оказания услуг по разработке программного обеспечения веб-сайта (на доменной зоне .by). Технические требования подлежали согласованию и детализации в приложении к договору, а также в онлайн-реестре задач Jira. Общая стоимость услуг по договору составляет 19 000 USD.

В Договоре предусмотрен следующий порядок сдачи-приёмки оказанных услуг (работ):

  1. Исполнитель не позднее 3 рабочих дней с момента окончания оказания услуг предоставляет на рассмотрение Заказчику результаты оказанных услуг и акт сдачи-приёмки по электронной почте и (или) на своём сервере. Исполнитель также обязался предоставить Заказчику доступ к тестовой версии ПО веб-сайта для проведения испытаний и сдачи-приемки
  2. Заказчик в течение 5 рабочих дней внимательно их проверяет; направляет Исполнителю подписанный акт сдачи-приёмки оказанных услуг или мотивированный отказ от их приёмки. Стороны подписывают акт сверки отклонений
  3. В случае обнаружения новых отклонений, не перечисленных в подписанном ранее акте сверки, Исполнитель дорабатывает результат в рамках гарантийных обязательств
  4. Одновременно с актом сдачи-приемки Исполнитель уступает Заказчику исключительные права на результат разработки

Гарантийный срок на результаты разработки составляет 1 год при их правильной эксплуатации и исчисляется с момента подписания акта сдачи-приёмки оказанных услуг. В случае любого модифицирования результатов оказанных услуг, в том числе кода программного обеспечения, заказчиком и (или) третьими лицами без участия и (или) согласования Исполнителя, гарантийные обязательства полностью снимаются. 

Исполнитель завершил разработку в феврале 2018 году и по трем актам сдачи-приемки Заказчик принял и оплатил в полном объеме результат без замечаний. Заказчик принял результаты разработки фактически без проверки.

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

В процессе эксплуатации ПО периодически возникали проблемы, в устранении которых Исполнитель принимал участие, связывая их с некорректной эксплуатацией Заказчиком.

В ноябре 2018 года Исполнитель выявил факт несанкционированной модификации результатов выполненных им работ: замены модуля обмена на иной, частичного изменения исходного кода программного обеспечения, в связи с чем он заявил о прекращении гарантийных обязательств по Договору.

Заказчик не оспаривал правомерность прекращения гарантийных отношений и заключил самостоятельные договоры с ИП по поиску ошибок (недостатков) в функционировании ПО. Общая стоимость услуг ИП составляла 55 000 BYN, из которых Заказчик оплатил 14 000 BYN. По мнению Заказчика, сумма 55 000 BYN являлась убытками, необходимыми для выявления и устранения недостатков в ПО, и потребовал у Исполнителя выплаты этой суммы.

В связи с неурегулированием спора, Заказчик (Истец) обратился с иском в судебную коллегию по делам интеллектуальной собственности Верховного Суда Республики Беларусь (СКИД) с требованием о взыскании с Исполнителя (Ответчик) убытков в размере 14 000 BYN, то есть в сумме работ, выполненных ИП и оплаченных Заказчиком. Позднее Истец изменил предмет иска и просил снизить цену по договору с Ответчиком на 14 000 BYN и взыскать с него сумму переплаты в размере 14 000 BYN.

СКИД отказал в удовлетворении иска в полном объеме.

ПОЗИЦИЯ ИСТЦА

  1. ИП выявил в ПО скрытые недостатки, являющиеся следствием некачественного выполнения Ответчиком работ
  2. Общая сумма расходов Истца по оплате работ по выявлению и устранению недостатков в ПО составила 55 000 BYN, из которых уплачена сумма в размере 14 000 BYN
  3. Доработанный по вышеуказанным и иным договорам интернет-сайт Истца до настоящего времени должным образом не функционирует
  4. Акты сдачи-приёмки работ со стороны Истца были подписаны без надлежащей проверки выполненных работ, исключительно на доверии

ПОЗИЦИЯ ОТВЕТЧИКА

  1. Ответчик надлежащим образом выполнил обязательства, что подтверждается подписанными актами, действиями Истца по их приёмке и оплате в полном объёме
  2. В течение гарантийного срока Ответчик оказывал Истцу техническую и консультативную поддержки по эксплуатации программного обеспечения. При этом многие из обращений Истца были связаны с допущенными его сотрудниками ошибками при эксплуатации программного обеспечения
  3. Истец не представил доказательств, что указанные недостатки ПО имелись до передачи его Истцу по актам, а не возникли в связи с пего модификацией Истцом или третьими лицами
  4. Истец в пределах гарантийного срока (1 год) не заявил требований по качеству работ
  5. В случае установления судом скрытых недостатков, Истец в силу договора и п. 3 ст. 677 ГК не вправе предъявлять по ним требования в связи с истечением гарантийного срока
Выводы СКИД
  1. О явных недостатках в ПО:
    • согласно п. 3 ст. 673 ГК заказчик, принявший результаты работы без проверки, лишается права ссылаться на недостатки работы, которые могли быть установлены при обычном способе ее приемки (явные недостатки)
    • истец не имел претензий по объёму, качеству и срокам выполнения работ (оказания услуг) при приемке работ. О наличии недостатков на момент их принятия и в период гарантийного срока обслуживания ПО Истец не заявлял
    • учитывая, что работы Истец принял фактически без проверки, в случае наличия явных недостатков в выполненных работах, в силу п. 3 ст. 673 ГК Истец лишается права ссылаться на них в обоснование заявленного иска
  2. О гарантийных обязательствах и модификации ПО:
    • согласно п. 3-5 ст. 677 ГК, если предусмотренный договором гарантийный срок менее 2 лет, а недостатки обнаружены заказчиком после его истечения, но в пределах 2-летнего срока, то подрядчик несет ответственность, если недостатки возникли до передачи результата работ или по причинам, возникшим до передачи
    • истец не оспаривал факт модификации ПО и обоснованность прекращения гарантийных обязательств. Также Истец не заявлял Ответчику требований о проведении разбирательства на предмет установления недостатков выполненных работ, причин и периода времени их возникновения, в том числе путём проведения экспертизы
    • на текущий момент ПО существенно изменено и модифицировано. Договор не предусматривал право Истца на устранение недостатков выполненных работ в случае их обнаружения
  3. О скрытых недостатках в ПО:
    • в соответствии с п. 4 ст. 673 ГК заказчик, обнаруживший после приемки результата работы отступления от договора подряда или иные недостатки, которые не могли быть установлены при обычном способе приемки (скрытые недостатки), в том числе умышленно скрытые подрядчиком, обязан известить об этом подрядчика об их обнаружении
    • истец не представил допустимых доказательств, с достоверностью подтверждающих факт наличия недостатков в выполненных Ответчиком работах. Истец не представил бесспорных и убедительных доказательств, что предполагаемые недостатки работ (при их наличии) носили скрытый характер и не могли быть выявлены при обычном способе приёмки
    • истец не представил достоверных доказательств, подтверждающих причинно-следственную связь между действиями Ответчика по исполнению Договору и понесенными Истцом расходами по оплате услуг третьих лиц
Комментарии REVERA

Сложность разработки зачастую не позволяет сторонам заранее согласовать все требования к результату. Кроме того, после множества итераций, хаотичного внесения изменений в требования к ПО – от изначального видения проекта остается 10-20%.

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

Мы достаточно часто сталкиваемся в практике с ситуациями, когда ни заказчик, ни разработчик не понимают, что за ПО разрабатывается и какие к нему предъявляются требования. Первоначальные многостраничные технические документы, которые подрядчик разрабатывал за отдельную плату, практически не используются в ходе разработки. Разберем некоторые нюансы.

  1. Процесс разработки
    Исходя из практики, невозможно подготовить полноценное техническое задание на разработку ПО. Разработчик, начиная работу, обычно имеет базовое представление об итоговом результате, изложенное в общем описании, user cases, описании архитектуры, user wireframes. В дальнейшем требования к функционалу, отображению углубляются по ходу разработки и коммуникации с Клиентом, часть требований, наоборот, снимаются или изменяются.

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

    Если разработчик не сможет пояснить и доказать, что он реально осуществлял разработку по заданию заказчика, и это входило в объем разработки, то есть вероятность, что суд (арбитраж) откажет в удовлетворении требования об оплате.
     
    Продолжая придерживаться принципа «отношения с заказчиком важнее согласования условий контракта», рекомендуется всё-таки фиксировать изменения требований к ПО, к примеру, путем направления follow-up сообщений по электронной почте заказчику после встреч; отслеживания списков задач после спринта, использования систем управления проектами, форм и т.д.
  2. Приемка ПО
    Наиболее важная стадия, которую заказчик часто пропускает. Приемка напрямую вытекает из согласованных сторонами требований к ПО, так как проводится проверка по этим согласованным требованиям. Если требования к ПО хаотичны и разбросаны по мессенджерам, Jira, email, Google Docs – сторонам будет крайне сложно разобраться, каким требованиям должно соответствовать ПО.

    Иногда приемка разбивается на два этапа: внутреннее тестирование ПО разработчиком (1); потом проверка работоспособности ПО заказчиком на его сервере или оборудовании (2). Следует учитывать, что запуск и работоспособность ПО на оборудовании или сервере разработчика, не означает, что ПО будет также работоспособным на оборудовании или сервере заказчика. Приемка «на доверии» ведет к невозможности ссылаться на явные недостатки (п. 3 ст. 673 ГК).
  3. Эксплуатация и менеджмент недостатков в ПО
    Крайне не рекомендуется заниматься «самолечением». При выявлении недостатков в ПО, нужно немедленно уведомлять разработчика. Если разработчик отказывается устранить недостатки – заказчик может привлечь эксперта для проведения досудебной экспертизы. Опять же, экспертиза невозможна, если нельзя восстановить из хаоса процесса разработки четкие требования к ПО.

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

Из недавней практики СКИД:

  • подписанные сторонами в ходе разработки ПО отчеты могут подтверждать качественное выполнение работ при отсутствии акта сдачи-приемки (дело № 1ИГИП2122)
  • существенные недостатки и противоречия акта приема-передачи прав на ПО, отсутствие доказательств реальности разработки ПО и его передачи заказчику – влекут отказ в удовлетворении иска о взыскании вознаграждения (дело № 1ИГИП2134)

Ссылка на дело: http://court.gov.by/ru/justice_rb/praktice/intell/comp/ba5d6e31ef6945c3.html