Веб-дизайнерам и разработчикам: заказчик подписал акты, а суд взыскал с исполнителя 345 668 рублей
У исполнителя был договор, несколько подписанных актов и доказательства того, что сайт размещён в интернете и индексируется «Яндексом». Заказчик перечислил за работу 491 400 рублей. Тем не менее договор расторгли, а с разработчика взыскали большую часть полученной оплаты и судебные расходы.
Сразу обозначу дату: решение первой инстанции по делу № А70-9598/2021 вынесено 14 апреля 2022 года, последний судебный акт датирован 27 марта 2023 года.
Я выбрала это дело для разбора намеренно. В спорах о разработке сайтов не так часто встречается подробная техническая экспертиза, в которой отдельно проверены дизайн, вёрстка, сборка сайта и работа модулей. Кроме того, дело прошло апелляцию и кассацию, а Верховный Суд РФ отказал в передаче жалобы исполнителя на дальнейшее рассмотрение.
Нормы ГК РФ, которые применили суды, продолжают действовать. Да и сами проблемы никуда не исчезли: технические задания по-прежнему согласовывают в переписке, изменения не оформляют, сроки двигают устно, а этапы закрывают одинаковыми актами.
Что заказали у исполнителя
В августе 2019 года два индивидуальных предпринимателя заключили договор на разработку интернет-магазина.
Проект состоял из четырёх этапов:
- фирменный стиль и дизайн-макеты — 120 000 рублей;
- HTML-вёрстка — 165 000 рублей;
- сборка и настройка сайта на 1С-Битрикс — 120 000 рублей;
- подключение поставщиков — 48 000 рублей.
Изначальная стоимость составляла 453 000 рублей. Затем появились дополнительные работы по интеграции, и в общей сложности заказчик заплатил 491 400 рублей.
На разработку отводилось 60 рабочих дней. В договоре также было указано, что время согласования в этот срок не входит. Фактически итоговый акт стороны подписали только 26 января 2021 года.
Все акты были подписаны без замечаний. На этом во многом и строилась позиция исполнителя: заказчик принял работу, сайт находился в открытом доступе, его страницы индексировались, следовательно, результат создан и используется.
После запуска заказчик обнаружил проблемы в работе сайта. Замечания обсуждались по электронной почте и в Viber. Позже заказчик предложил провести экспертизу и потребовал сообщить сроки исправления недостатков. Исполнитель отказался.
Что обнаружил эксперт
Экспертиза подтвердила, что часть проекта выполнена нормально.
Фирменный стиль и дизайн-макеты были готовы полностью. Недостатки HTML-вёрстки эксперт назвал незначительными и не влияющими на работу сайта. Возможность подключения поставщиков тоже была реализована.
Серьёзные претензии возникли к третьему этапу — сборке и настройке сайта.
В техническом задании были предусмотрены модули «Каталог запчастей» и «Каталог TECDOC2». Эксперт установил, что они не выполнены, хотя имели существенное значение для работы интернет-магазина. На момент обследования сайт не был готов к эксплуатации.
Недостатки при этом оказались устранимыми. Стоимость их исправления с привлечением другого разработчика эксперт оценил в 187 268 рублей.
Суд признал, что выполненная часть проекта имеет ценность для заказчика, и разрешил исполнителю удержать 145 732 рубля. Оставшиеся 345 668 рублей разработчика обязали вернуть.
Дополнительно с него взыскали 15 032 рубля госпошлины и 63 576 рублей расходов на судебную экспертизу. Общая сумма взыскания составила 424 276 рублей.
Решение оставили в силе апелляционный и кассационный суды. Верховный Суд РФ не нашёл оснований для пересмотра дела.
Почему акты не закрыли вопрос с качеством
Акт подтверждает, что заказчик получил результат и принял его в установленном порядке. Но последствия приёмки зависят от того, о каких недостатках идёт речь.
Согласно статье 720 ГК РФ, заказчик, принявший работу без проверки, обычно лишается возможности ссылаться на явные недостатки. То есть на те, которые можно было заметить при обычной приёмке.
Скрытые недостатки могут проявиться уже во время эксплуатации. В таком случае заказчик сохраняет право предъявить требования, если сообщит о проблеме исполнителю в разумный срок.
В этом споре работоспособность отдельных модулей проверял судебный эксперт. Поэтому общей фразы в актах о том, что работы выполнены и претензий нет, оказалось недостаточно.
Не подтвердило надлежащее качество и нахождение сайта в открытом доступе. Опубликованный сайт может загружаться и индексироваться, но при этом не выполнять функции, указанные в техническом задании.
Приёмку такого проекта желательно связывать с проверкой конкретных сценариев: открывается ли каталог, работает ли поиск, передаются ли данные, можно ли оформить заказ, корректно ли выполняется интеграция.
Подписанного технического задания в деле не оказалось
В договоре было прямо указано, что исполнитель разрабатывает сайт в соответствии с техническим заданием. Однако экземпляра ТЗ, подписанного обеими сторонами, в материалах дела не было.
Для экспертизы суд использовал версию, которую сам разработчик отправил заказчику по электронной почте 16 января 2020 года. Стороны фактически ориентировались на этот документ, поэтому эксперт сравнивал готовый сайт именно с ним.
Получилась невыгодная для исполнителя ситуация: подписанного ТЗ нет, но направленная им версия документа всё равно стала главным критерием оценки работы.
Если в процессе разработки стороны меняют функционал, согласованное ТЗ должно меняться вместе с ним. Иначе при споре сайт будут сравнивать с первоначальными требованиями.
Изменение функционала обсуждали, но не оформили
Из переписки следовало, что стороны могли обсуждать отказ от отдельных модулей и использование коммерческих каталогов сторонних организаций.
Эксперт отдельно указал: такая замена была допустима, но её следовало оформить как изменение технического задания.
В материалах дела подтверждения не нашлось. Поэтому модули, включённые в ТЗ, суд посчитал невыполненной частью проекта.
В обычной работе такие решения часто выглядят безобидно:
«Давайте не будем делать этот каталог».
«Эта функция нам больше не нужна».
Пока отношения хорошие, всем понятно, о чём договорились. После возникновения конфликта каждая сторона помнит разговор по-своему.
Изменение, которое затрагивает объём работ, функционал, стоимость или срок, стоит оформлять до начала доработки. Для этого не обязательно каждый раз составлять многостраничное дополнительное соглашение. Можно заранее установить в договоре короткий порядок согласования изменений и подготовить удобную форму заявки.
Формулировка о согласовании не объяснила длительную задержку
На разработку сайта отводилось 60 рабочих дней, но между заключением договора и итоговым актом прошло значительно больше времени.
В договоре была оговорка: время согласования в срок разработки не включается. Проблема в том, что из такой оговорки невозможно установить, сколько именно дней заняло согласование и чем была вызвана задержка.
Если заказчик не передал тексты, фотографии, доступы или сведения для интеграции, это нужно фиксировать в момент возникновения задержки.
Исполнитель направляет уведомление, перечисляет недостающие материалы и сообщает, что срок сдвигается. После получения информации стороны определяют новую дату сдачи.
Право приостановить работу при неисполнении заказчиком встречных обязанностей предусмотрено статьёй 719 ГК РФ. Для суда при этом важна хронология: что должен был передать заказчик, когда его об этом попросили, когда он ответил и на какой срок остановилась работа.
Отказ разбираться с недостатками ухудшил положение исполнителя
По условиям договора исполнитель предоставлял шестимесячную гарантию и должен был устранять неполадки в течение пяти рабочих дней.
Заказчик сообщил о проблемах, предложил провести экспертизу и попросил назвать сроки исправления. Исполнитель отказался. Суд учёл это обстоятельство при рассмотрении требования о расторжении договора.
Статья 723 ГК РФ позволяет заказчику потребовать безвозмездно устранить недостатки или уменьшить цену. В предусмотренных законом и договором случаях он может потребовать возместить расходы на исправление.
Если недостатки не устранены в разумный срок либо являются существенными, заказчик получает основания отказаться от договора и заявить требование о возмещении убытков.
В этом деле суд также сослался на статью 397 ГК РФ и учёл стоимость работ другого разработчика.
Получив претензию, исполнителю следовало запросить доступы и описание ошибок, проверить сайт, зафиксировать его текущую версию и дать мотивированный ответ. Если проблема подпадала под гарантию, её можно было устранить. Если заказчик требовал новую функцию, нужно было показать, что её нет в согласованном ТЗ, и предложить отдельную стоимость.
Отказ от проверки лишил исполнителя возможности решить вопрос до судебной экспертизы.
Какие документы нужны для такого проекта
Для разработки интернет-магазина с модулями и интеграциями я бы готовила не один договор, а комплект документов:
- договор на разработку сайта с обязанностями заказчика и исполнителя;
- техническое задание с перечнем страниц, функций, модулей, интеграций и критериями готовности;
- календарный план со сроками и стоимостью каждого этапа;
- форму согласования изменений ТЗ и дополнительных работ;
- акты сдачи-приёмки отдельных этапов и итоговый акт;
- протокол тестирования или перечень замечаний с результатами проверки и сроками исправления;
- акт передачи сайта, исходных файлов, документации, логинов и паролей.
Состав комплекта зависит от самого проекта. Для небольшого лендинга часть документов можно объединить. Для интернет-магазина, личного кабинета или сайта с несколькими интеграциями лучше разделить этапы, проверку и передачу результата.
Важно, чтобы документы использовались во время работы. Если договор подписали перед оплатой, а потом больше года к нему не возвращались, большая часть проекта остаётся в переписке и устных договорённостях.
Могли ли документы изменить результат дела
Подписанное ТЗ с оформленными изменениями позволило бы точно установить, сохранялась ли обязанность разработать спорные модули.
Протокол проверки показал бы, какие функции заказчик тестировал перед подписанием акта.
Уведомления о задержках помогли бы отделить просрочку исполнителя от времени, которое заказчик потратил на согласование и передачу материалов.
Зафиксированная копия сайта позволила бы установить, в каком состоянии он был передан и что изменилось после получения доступов заказчиком.
Наконец, нормальный порядок работы с недостатками дал бы разработчику возможность устранить ошибку до расторжения договора и привлечения другого подрядчика.
У сайта действительно были проблемы, установленные экспертизой. Поэтому полностью сводить спор к неудачным формулировкам договора было бы неправильно. При этом проект не был признан проваленным целиком: дизайн, вёрстка и подключение поставщиков имели самостоятельную ценность. Основной конфликт возник вокруг одного этапа, содержания ТЗ и несогласованных изменений. Как раз в этой части качество документов могло повлиять и на объём требований, и на расчёт суммы.
Договор должен соответствовать тому, как исполнитель работает
У ответчика был договор. Но фактическая работа постепенно ушла в электронную почту и Viber: там обсуждались изменения, замечания и дальнейшая судьба отдельных функций.
Типовой договор из интернета обычно не учитывает, где исполнитель показывает макеты, кто отвечает за тексты и доступы, сколько времени даётся на согласование, как меняется ТЗ, кто оплачивает сторонние сервисы и по каким сценариям проверяется готовый сайт.
Когда ко мне обращается разработчик или веб-дизайнер, я сначала выясняю, как у него устроен проект на практике. Какие сайты он создаёт, работает ли один или с командой, привлекает ли программистов, где согласовывает макеты, от кого зависят интеграции и как передаёт готовый результат. После этого можно подготовить договор и приложения, которыми действительно удобно пользоваться.
Если большая часть ваших договорённостей с заказчиками сейчас остаётся в чатах, напишите мне в тг @yana_gorkunova и коротко расскажите, какие проекты вы выполняете и как принимается работа. Я предложу состав документов под вашу схему работы.