Судебный кейс. Не занимайтесь «самолечением»: как нужно принимать результат работ, искать и исправлять явные или скрытые недостатки в ПО
Ключевой вывод по делу № 1ИГИП2010
Вмешательство в код ПО и несанкционированная модификация ПО может повлечь автоматическое прекращение гарантийных обязательств.
Фактические обстоятельства
Заказчик и Исполнитель в 2017 году заключили договор возмездного оказания услуг по разработке программного обеспечения веб-сайта (на доменной зоне .by). Технические требования подлежали согласованию и детализации в приложении к договору, а также в онлайн-реестре задач Jira. Общая стоимость услуг по договору составляет 19 000 USD.
В Договоре предусмотрен следующий порядок сдачи-приёмки оказанных услуг (работ):
- Исполнитель не позднее 3 рабочих дней с момента окончания оказания услуг предоставляет на рассмотрение Заказчику результаты оказанных услуг и акт сдачи-приёмки по электронной почте и (или) на своём сервере. Исполнитель также обязался предоставить Заказчику доступ к тестовой версии ПО веб-сайта для проведения испытаний и сдачи-приемки
- Заказчик в течение 5 рабочих дней внимательно их проверяет; направляет Исполнителю подписанный акт сдачи-приёмки оказанных услуг или мотивированный отказ от их приёмки. Стороны подписывают акт сверки отклонений
- В случае обнаружения новых отклонений, не перечисленных в подписанном ранее акте сверки, Исполнитель дорабатывает результат в рамках гарантийных обязательств
- Одновременно с актом сдачи-приемки Исполнитель уступает Заказчику исключительные права на результат разработки
Гарантийный срок на результаты разработки составляет 1 год при их правильной эксплуатации и исчисляется с момента подписания акта сдачи-приёмки оказанных услуг. В случае любого модифицирования результатов оказанных услуг, в том числе кода программного обеспечения, заказчиком и (или) третьими лицами без участия и (или) согласования Исполнителя, гарантийные обязательства полностью снимаются.
Исполнитель завершил разработку в феврале 2018 году и по трем актам сдачи-приемки Заказчик принял и оплатил в полном объеме результат без замечаний. Заказчик принял результаты разработки фактически без проверки.
Кроме того, в марте 2018 года Заказчик и другая компания заключили договор оказания услуг по технической поддержке его веб-сайта, в том числе выполнение работ по устранению технических неисправностей, развитию и разработке нового функционала сайта. Чем конкретно занималась эта организация, Заказчик в суде пояснить не смог.
В процессе эксплуатации ПО периодически возникали проблемы, в устранении которых Исполнитель принимал участие, связывая их с некорректной эксплуатацией Заказчиком.
В ноябре 2018 года Исполнитель выявил факт несанкционированной модификации результатов выполненных им работ: замены модуля обмена на иной, частичного изменения исходного кода программного обеспечения, в связи с чем он заявил о прекращении гарантийных обязательств по Договору.
Заказчик не оспаривал правомерность прекращения гарантийных отношений и заключил самостоятельные договоры с ИП по поиску ошибок (недостатков) в функционировании ПО. Общая стоимость услуг ИП составляла 55 000 BYN, из которых Заказчик оплатил 14 000 BYN. По мнению Заказчика, сумма 55 000 BYN являлась убытками, необходимыми для выявления и устранения недостатков в ПО, и потребовал у Исполнителя выплаты этой суммы.
В связи с неурегулированием спора, Заказчик (Истец) обратился с иском в судебную коллегию по делам интеллектуальной собственности Верховного Суда Республики Беларусь (СКИД) с требованием о взыскании с Исполнителя (Ответчик) убытков в размере 14 000 BYN, то есть в сумме работ, выполненных ИП и оплаченных Заказчиком. Позднее Истец изменил предмет иска и просил снизить цену по договору с Ответчиком на 14 000 BYN и взыскать с него сумму переплаты в размере 14 000 BYN.
СКИД отказал в удовлетворении иска в полном объеме.
ПОЗИЦИЯ ИСТЦА
- ИП выявил в ПО скрытые недостатки, являющиеся следствием некачественного выполнения Ответчиком работ
- Общая сумма расходов Истца по оплате работ по выявлению и устранению недостатков в ПО составила 55 000 BYN, из которых уплачена сумма в размере 14 000 BYN
- Доработанный по вышеуказанным и иным договорам интернет-сайт Истца до настоящего времени должным образом не функционирует
- Акты сдачи-приёмки работ со стороны Истца были подписаны без надлежащей проверки выполненных работ, исключительно на доверии
ПОЗИЦИЯ ОТВЕТЧИКА
- Ответчик надлежащим образом выполнил обязательства, что подтверждается подписанными актами, действиями Истца по их приёмке и оплате в полном объёме
- В течение гарантийного срока Ответчик оказывал Истцу техническую и консультативную поддержки по эксплуатации программного обеспечения. При этом многие из обращений Истца были связаны с допущенными его сотрудниками ошибками при эксплуатации программного обеспечения
- Истец не представил доказательств, что указанные недостатки ПО имелись до передачи его Истцу по актам, а не возникли в связи с пего модификацией Истцом или третьими лицами
- Истец в пределах гарантийного срока (1 год) не заявил требований по качеству работ
- В случае установления судом скрытых недостатков, Истец в силу договора и п. 3 ст. 677 ГК не вправе предъявлять по ним требования в связи с истечением гарантийного срока
Выводы СКИД
- О явных недостатках в ПО:
- согласно п. 3 ст. 673 ГК заказчик, принявший результаты работы без проверки, лишается права ссылаться на недостатки работы, которые могли быть установлены при обычном способе ее приемки (явные недостатки)
- истец не имел претензий по объёму, качеству и срокам выполнения работ (оказания услуг) при приемке работ. О наличии недостатков на момент их принятия и в период гарантийного срока обслуживания ПО Истец не заявлял
- учитывая, что работы Истец принял фактически без проверки, в случае наличия явных недостатков в выполненных работах, в силу п. 3 ст. 673 ГК Истец лишается права ссылаться на них в обоснование заявленного иска
- О гарантийных обязательствах и модификации ПО:
- согласно п. 3-5 ст. 677 ГК, если предусмотренный договором гарантийный срок менее 2 лет, а недостатки обнаружены заказчиком после его истечения, но в пределах 2-летнего срока, то подрядчик несет ответственность, если недостатки возникли до передачи результата работ или по причинам, возникшим до передачи
- истец не оспаривал факт модификации ПО и обоснованность прекращения гарантийных обязательств. Также Истец не заявлял Ответчику требований о проведении разбирательства на предмет установления недостатков выполненных работ, причин и периода времени их возникновения, в том числе путём проведения экспертизы
- на текущий момент ПО существенно изменено и модифицировано. Договор не предусматривал право Истца на устранение недостатков выполненных работ в случае их обнаружения
- О скрытых недостатках в ПО:
- в соответствии с п. 4 ст. 673 ГК заказчик, обнаруживший после приемки результата работы отступления от договора подряда или иные недостатки, которые не могли быть установлены при обычном способе приемки (скрытые недостатки), в том числе умышленно скрытые подрядчиком, обязан известить об этом подрядчика об их обнаружении
- истец не представил допустимых доказательств, с достоверностью подтверждающих факт наличия недостатков в выполненных Ответчиком работах. Истец не представил бесспорных и убедительных доказательств, что предполагаемые недостатки работ (при их наличии) носили скрытый характер и не могли быть выявлены при обычном способе приёмки
- истец не представил достоверных доказательств, подтверждающих причинно-следственную связь между действиями Ответчика по исполнению Договору и понесенными Истцом расходами по оплате услуг третьих лиц
Комментарии REVERA
Сложность разработки зачастую не позволяет сторонам заранее согласовать все требования к результату. Кроме того, после множества итераций, хаотичного внесения изменений в требования к ПО – от изначального видения проекта остается 10-20%.
Как показывает практика, нередко гибкие модели разработки, бездокументарный процесс, вместе с недостатками организации процесса разработки – ведут к разрыву отношений с заказчиком и спору о предмете разработке, требованиях к нему и качеству итогового результата.
Мы достаточно часто сталкиваемся в практике с ситуациями, когда ни заказчик, ни разработчик не понимают, что за ПО разрабатывается и какие к нему предъявляются требования. Первоначальные многостраничные технические документы, которые подрядчик разрабатывал за отдельную плату, практически не используются в ходе разработки. Разберем некоторые нюансы.
- Процесс разработки
Исходя из практики, невозможно подготовить полноценное техническое задание на разработку ПО. Разработчик, начиная работу, обычно имеет базовое представление об итоговом результате, изложенное в общем описании, user cases, описании архитектуры, user wireframes. В дальнейшем требования к функционалу, отображению углубляются по ходу разработки и коммуникации с Клиентом, часть требований, наоборот, снимаются или изменяются.
Если процесс изменения требований не контролировать, то позднее стороны могут прийти к спору о требованиях к ПО. При рассмотрении дела в суде или арбитраже, независимо от страны разрешения спора, у судьи (арбитров) возникает вопрос: что именно делал разработчик, как это соотносится с договором и почему его работа подлежит оплате.
Если разработчик не сможет пояснить и доказать, что он реально осуществлял разработку по заданию заказчика, и это входило в объем разработки, то есть вероятность, что суд (арбитраж) откажет в удовлетворении требования об оплате.
Продолжая придерживаться принципа «отношения с заказчиком важнее согласования условий контракта», рекомендуется всё-таки фиксировать изменения требований к ПО, к примеру, путем направления follow-up сообщений по электронной почте заказчику после встреч; отслеживания списков задач после спринта, использования систем управления проектами, форм и т.д. - Приемка ПО
Наиболее важная стадия, которую заказчик часто пропускает. Приемка напрямую вытекает из согласованных сторонами требований к ПО, так как проводится проверка по этим согласованным требованиям. Если требования к ПО хаотичны и разбросаны по мессенджерам, Jira, email, Google Docs – сторонам будет крайне сложно разобраться, каким требованиям должно соответствовать ПО.
Иногда приемка разбивается на два этапа: внутреннее тестирование ПО разработчиком (1); потом проверка работоспособности ПО заказчиком на его сервере или оборудовании (2). Следует учитывать, что запуск и работоспособность ПО на оборудовании или сервере разработчика, не означает, что ПО будет также работоспособным на оборудовании или сервере заказчика. Приемка «на доверии» ведет к невозможности ссылаться на явные недостатки (п. 3 ст. 673 ГК). - Эксплуатация и менеджмент недостатков в ПО
Крайне не рекомендуется заниматься «самолечением». При выявлении недостатков в ПО, нужно немедленно уведомлять разработчика. Если разработчик отказывается устранить недостатки – заказчик может привлечь эксперта для проведения досудебной экспертизы. Опять же, экспертиза невозможна, если нельзя восстановить из хаоса процесса разработки четкие требования к ПО.
Если заказчик привлекает третье лицо для устранения недостатков, то нужно разграничивать собственно устранение недостатков и модификацию ПО. В первом случае, заказчик может потребовать возмещения обоснованных расходов на устранение недостатков третьим лицом. Во втором случае, если разработчик докажет, что третье лицо занималось модификацией ПО, а не устранением недостатков, то заказчик не вправе требовать возмещения этих расходов.
Из недавней практики СКИД:
- подписанные сторонами в ходе разработки ПО отчеты могут подтверждать качественное выполнение работ при отсутствии акта сдачи-приемки (дело № 1ИГИП2122)
- существенные недостатки и противоречия акта приема-передачи прав на ПО, отсутствие доказательств реальности разработки ПО и его передачи заказчику – влекут отказ в удовлетворении иска о взыскании вознаграждения (дело № 1ИГИП2134)
Ссылка на дело: http://court.gov.by/ru/justice_rb/praktice/intell/comp/ba5d6e31ef6945c3.html
