Все в суд. Айтишники предпочитают не судиться — и зря, объясняют юристы

В ситуации, когда заказчик и разработчик остаются недовольны друг другом, возникает вопрос: как получить компенсацию от стороны, которая налажала? Как доказать, что налажала именно она? Юрист судебной практики REVERA Пётр Гринюк рассказывает, как составлять техзадание и зачем выбирать суд на этапе заключения договора — даже если пока ни с кем не собираешься судиться.

Юристы говорят, что айтишники часто решают не доводить дело до крайней точки —  до суда доходит всего около десятка споров. Одна из главных причин — плохо составлен договор. Кто виноват — непонятно, но отношения лучше не портить, и кто-то из сторон идёт на попятную.

Среди прочих причин:

• Стороны переживают за репутацию: по умолчанию дела рассматривает государственный суд. Заседания открытые — никакой анонимности.
• Заказчик и исполнитель — резиденты разных стран. Без подготовки такое разбирательство может затянуться надолго. Чем закончится — неизвестно.

Эти страхи можно исключить, если грамотно вести документацию. Как это сделать?

Очень подробное техническое задание

— В Беларуси не принято заключать огромные договоры, ведь почти все сферы регулируются законодательством, — говорит Петр Гринюк. — Можно что-то не прописать в документе, но в стране уже есть законы или акты, которые регулируют стандарты качества и прочее.

Для разработки ПО таких законов нет. Как должен выглядеть интерфейс, как измерить, удобный он или нет? Что должна уметь делать программа, а что не обязательно? Если стороны не составят подробное техзадание, суд не поймёт, о чём они договорились. И не сможет никого защитить.

Базово в договоре прописать: 

• Как ПО должно создаваться, каким параметрам соответствовать, в какие сроки быть сделано? Как его будут принимать и оплачивать?
• Права на продукт переходят заказчику или он получает только лицензию на использование? Исключительную или неисключительную?
• Кто за что отвечает — очень подробный алгоритм. 
• Какой процент ошибок может быть в продукте? Кто ответственный за тестирование? Какие ошибки критичные, какие нет? Если что-то идёт не так, в какие сроки нужно исправить? Можно вписать: если ошибка критическая, то разработчик должен исправить её в любой срок. Если нет, то он несёт ответственность только первый месяц. А дальше заказчик исправляет всё сам или доплачивает разработчику.

Подробное ТЗ поможет решить основные споры: по качеству, срокам и оплате.

Споры о качестве 

Суть споров: продукт не работает; работает не так, как нужно; работа не сделана до конца.

ТЗ поможет доказать:

• Что продукт соответствует / не соответствует заявленному качеству. В техзадании прописываем эталон продукта. Подробно, вплоть до цвета кнопок в таком-то окне. Разработчика это обезопасит от дополнительных изменений вроде «не нравится цвет, давайте попробуем синий вместо красного». Заказчика — от халтуры. Если ТЗ расплывчатое, суд может признать, что стороны не договорились вообще.
• Кто будет нести ответственность за изменения. Часто случаются споры, когда нужно изменить ТЗ и, соответственно, конечный продукт. Рекомендуем закрепить в договоре: кто и в каких случаях должен вносить эти изменения, в какой срок и за чей счёт. Приостанавливается ли разработка, пока дописывается ТЗ? Как часто можно вносить изменения не из-за технической необходимости, а по желанию заказчика? Сколько это будет стоить?

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

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

Если ТЗ слабое, эксперт сможет оценить только базовые функции: работает ли ПО и способно ли выполнять минимум, для которого сделано? Тут сильная позиция — у разработчика. Вот он разработал калькулятор. Если заказчик скажет: «Мы хотели инженерный, а не обычный», разработчик всегда может ответить: «Он считает, других уточнений нет, до свидания».

Споры о сроках

Самый частый — изменение сроков в процессе работы. Разработчик в сильной позиции, если предвидел ошибки заранее и вписал риски, «плюс ко времени», в договор. Если нет, то, увеличивая срок, разработчик может сослаться только на форс-мажор: наводнение, ураган. Сильная позиция будет у заказчика. Физлицо еще может объяснить задержку болезнью. Юрлицо — нет. Субъект предпринимательской деятельности по закону должен предвидеть все риски.

Спор о сроках и качестве тестирования. Разработчик в сильной позиции, если прописал инструкции, которые должен выполнять заказчик, когда внедряет продукт. Например, непрерывно тестировать сервис три месяца с такой-то нагрузкой. Если заказчик придерживался инструкции, при сбое разработчик должен исправить все ошибки. Нет — может отказаться и потребовать доплату.

Исходный код как гарантия

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

Как выбрать суд заранее и зачем вписывать его в договор

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

Пример из практики: конфликт между заказчиком в Беларуси и исполнителем в США. В договоре не прописано, как стороны договорились разбирать судебные споры. По умолчанию срабатывает общее правило: суд будет проходить по месту нахождения ответчика. В нашем случае — в штате Флорида. Язык — английский. Что имеет белорусский заказчик? Ему нужно обратиться в американский суд, найти американских юристов и заплатить им, потратить несколько лет на процесс (который неизвестно, чем кончится), получить решение и дождаться его исполнения. Итог: заказчик понял, что процесс может выйти дороже, чем потерянная сумма, и свернул его.

Как обезопасить себя белорусским айтишникам, которые работают с иностранными заказчиками / подрядчиками? Мы советуем вписывать в договор, через какой суд стороны будут решать споры, если они возникнут. И рекомендуем арбитраж.

В чём плюсы арбитража перед государственным судом:

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

Ситуация: Разработчик — резидент Беларуси, заказчик — нерезидент. По договору предварительная оплата за разработку ПО не предусмотрена. Разработчик хочет обезопасить себя и, если заказчик решит его пробросить, иметь возможность обратиться в суд. В договоре белорусскому разработчику выгодно прописать Международный арбитражный суд при БелТПП, если страна нерезидента является участницей Нью-Йоркской конвенции. Плюсы: будет проще, быстрее и дешевле рассмотреть дело в Беларуси, а потом исполнить вынесенное решение на территории той страны, где находится имущество нерезидента.

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

Минусы арбитража:

• Решение арбитражного суда не пересматривается. Если вы — потенциальный ответчик, рекомендуем привлечь юриста для помощи.
• Судебные издержки. Если цена иска меньше $100 тыс, то расходы на процесс и исполнение превысят эту цену.

Государственный суд — хорошее решение, если заказчик — резидент России. 

Кто признаёт решения судов Беларуси

Только те страны, с которыми Беларусь заключила международные договоры. Это может быть двусторонний договор, как с Латвией. То есть решение белорусского суда признается в Латвийской Республике и наоборот. Может быть конвенция, как между странами бывшего СССР. Или принцип взаимности — Беларусь исполняет решение судов Италии, а Италия исполнит решения судов Беларуси. Но если в нашей стране не было исполнено ни одного решения итальянского суда (никто не обращался), итальянский суд всегда может сказать: извините, о каком принципе взаимности может идти речь?

Постановления судов Республики Беларусь не признаются и не исполняются в Германии, США, Испании, Нидерландах, Эстонии, Австрии и Словении.

С арбитражем таких проблем нет. По Нью-йоркской конвенции 1958 года страны договорились: если стороны сами выбрали и согласовали арбитров, и этот суд решил спор, то это решение исполняется на территории всех стран-участниц конвенции. Стран таких — более 150, почти все в мире.

Арбитраж ad hoc

Иногда стороны решают не обращаться в учреждение, а просто выбирают людей, которые их рассудят. Это называется арбитраж ad hoc. Решение таких арбитров тоже будет обязательным к исполнению и будет признаваться на территории всех 150 стран Нью-Йоркской конвенции. В суде ad hoc арбитром может быть любой человек, в том числе без юридического образования. Спор в ИТ-сфере могут разбирать три технаря, например, просто потому что они более компетентны в данном случае. Суд ad hoc тоже следует прописать в договоре, если вы решили его выбрать. 

Серая зона — репутационные издержки

Споры о репутации в законодательстве Беларуси — проблема. Если вы столкнулись с репутационными потерями, придется доказать:

• Что убытки действительно были: я потерял конкретную сумму. Или не получил ту сумму, которую должен был, если речь идет о клиентах, которые ушли от меня из-за испорченной репутации.
• Доказать четкую причинно-следственную связь: убытки действительно связаны с действиями какого-то человека или организации. Человек будет в сильной позиции, если у него есть фактические потери. В слабой, если потери косвенные. Ситуация: человек пришёл устраиваться на работу, а его не берут. Через знакомых он узнаёт, что причина в слухах, которые о нём распускает бывший работодатель. Вряд ли человеку напишут официальное письмо, мол, извините, мы не принимаем вас на работу, потому что нам рассказали о вас то-то. Значит и в суде будет сложно доказать, что только это, и ничего другого (компетенция, стаж, портфолио, знание английского) не повлияло на итоги собеседование. Трудно будет доказать, что из-за действий партнера / заказчика вы можете растерять клиентов в будущем.
• Доказать виновность действий. То есть заказчик / партнер / исполнитель не просто сделали что-то неправомерное, но и осознавали это.  

Составной продукт

Часто бывает, что программный продукт разрабатывается по структуре: скелет, а к нему отдельные блоки (блок для автоматизации одного оборудования, другого, интерфейс). Этапов разработки несколько, но по отдельности они не представляют никакой ценности.

Заказчик платит за все этапы: 

1. Разработка ТЗ.
2. Понимание, как будет строиться весь алгоритм.
3. Блок для оборудования 1, блок для оборудования 2.
4. Соединение всех блоков в один программный продукт, добавление интерфейса.

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

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

Заключение

— Пётр, вы бы посоветовали людям из белорусского ИT меньше бояться судов?

— Да. Это поможет установить дисциплину в отношениях разработчик — заказчик. Люди будут больше понимать возможные последствия за нарушение условий договора. Разработчики же смогут защищать свои интересы. Можно будет проще и быстрее сформировать предсказуемую судебную практику.

16 лет dev.by — «дефолтный» источник информации о беларусском ИТ

Вы можете...