Привет. Я работаю с субподрядчиками из разных стран уже несколько лет, и я выучил это нелегко: плохо написанный контракт может стоить тебе больше, чем экономия на субподряде.
О чем-то я узнал с помощью юристов, что-то методом проб и ошибок. Вот что я считаю критическим для кроссбордерных контрактов:
-
Юрисдикция и разрешение споров — это не формальность. Когда возникает конфликт, нужно четко написать, по какому закону работает контракт и где можно подать в суд. Я использовал универсальные условия арбитража через хаб, и это сильно помогло.
-
Двуязычный контракт — я раньше пренебрегал этим, но потом случилось: субподрядчик из России понял одну фразу иначе, чем я. Мы потратили неделю на разбор. Теперь я всегда делаю версии на двух языках и оговариваю, что в случае конфликта интерпретаций приоритет у русской версии (если работаю с рф-партнером).
-
Права на интеллектуальную собственность — очень важно. Я раньше не думал об этом, а потом один субподрядчик заявил, что его работа его собственность и он ее может использовать в другом месте. Теперь я четко пишу: права переходят ко мне сразу после оплаты.
-
Конфиденциальность и GDPR — если работаешь с клиентскими данными, особенно из ЕС, нужно убедиться, что субподрядчик понимает обязания. Я видел кейсы, где это стоило штрафов.
-
SLA и условия переделки — когда качество не в нормале, должно быть написано, что и как переделывается. Без этого становится спор: я говорю “это не качество”, он говорит “я все сделал как в брифе”.
-
Условия выплаты и штрафы за задержку — кроссбордерные переводы могут быть непредсказуемы. Я указываю четкие сроки и условия, при которых платеж считается осуществленным.
Мне интересно: какие еще разделы контракта вы считаете критическими? И как вы проверяете, что субподрядчик действительно согласен с условиями? Я делаю это через collaboration threads, отправляю контракт, даю неделю на вопросы. Но может быть, есть лучший процесс?
Mark, отличный обзор. Я добавил бы еще несколько пунктов на основе своего опыта:
-
Резервный контакт — я включаю пункт, что если основной контакт в команде субподрядчика уходит, он обязан предоставить замену. Была ситуация, когда мой основной контакт ушел из компании, и все знания с ним испарились.
-
Процесс передачи проекта — я теперь всегда пишу, как именно передается проект (какие файлы, какой формат, какая документация). Потому что я видел, как один субподрядчик передал мне правки в формате, который я не мог открыть.
-
Версионирование и история изменений — важно писать, что файлы должны быть с версионированием и что-то типа Google Docs для прозрачности.
И насчет проверки согласия: я добавил пункт, где субподрядчик должен явно написать в письме (в хабе, в email, не важно), что он прочитал контракт, понял все условия и согласен. Это создает бумажный след.
Еще один момент — я всегда включаю clausule о том, что субподрядчик должен использовать только лицензированное ПО. Я был в ситуации, когда субподрядчик использовал пиратский Adobe, и потом были проблемы с лицензированием финального продукта.
Mark, вопрос: как ты поступаешь с контрактом, если один из партнеров захочет его изменить уже во время работы? Ты требуешь addendum или ты гибче?
Я смотрю на это как криэйтор, и я могу сказать, что многие субподрядчики боятся плохих контрактов. Я видела соглашения, где права на работу переходят заказчику, но потом заказчик может использовать мою работу для других целей или продавать без моего ведома.
Мой совет для агентств: будьте честны с субподрядчиками насчет того, что вы будете делать с их работой. Если вы хотите полные права — скажите это в контракте и платите за полные права. Не пишите в контракте “частичные права” и потом используйте работу везде.
Хороший контракт — это контракт, который обе стороны понимают одинаково.
Я также всегда прошу, чтобы в контракте было написано, как быстро отправляются ревизии. Потому что было: я сделала работу, отправила, а ревизии приходят месяц спустя. Наличие SLA на ревизии помогает.
Mark и Alex, спасибо за развёрнутые примеры. Я часто помогаю партнерам в хабе с оформлением контрактов, и я всегда рекомендую:
-
Language Clause — я обязательно пишу, на каком языке будут приниматься все документы по проекту (техспеки, ревизии, отчеты). И что если есть неоднозначность, приоритет дает определенный язык.
-
Escalation Process — если возникает проблема по качеству или срокам, есть ли четкий процесс: кому сообщить, какие сроки на ответ, какие варианты разрешения.
-
Communication Channel — я явно указываю, что все важное должно быть в письме (в хабе или в email), а не в устных разговорах. Потому что потом спор: “Я тебе сказал” vs “Я не слышал”.
Я помогу любому из вас с шаблоном, если нужно. У меня есть несколько версий для разных типов субподрядов.
И еще: я всегда организую предварительное совещание (встречу в хабе или zoom) перед подписанием контракта. На этой встрече я прохожу контракт пункт за пунктом вместе с субподрядчиком. Это занимает час, но потом не бывает сюрпризов. Обе стороны точно знают, что ожидается.
Еще момент из данных: агентства, которые используют collaboration threads в хабе для обсуждения условий контракта ДО его подписания, имеют на 30% меньше споров позже. Потому что есть письменный след всех договоренностей, и обе стороны могут на него ссылаться.
Mark, спасибо за обстоятельный список. Я как раз столкнулся с несколькими из этих проблем при работе с американскими партнерами при выходе на рынок США.
Единственное, что я добавил бы: Культурные нюансы в контракте. В России, например, часто есть подход “давайте разбираться по мере необходимости”. В США более формальный подход — все должно быть в контракте.
Я с помощью Светланы переделал контракт с одним из партнеров, учитывая эти различия. И вот что я заметил: когда я явно написал, что “любые изменения требуют письменного addendum”, это избавило нас от дальнейших разночтений.
Поэтому я считаю, что двуязычный контракт — это не просто перевод на другой язык. Это адаптация к способу ведения бизнеса в разных странах.