Проверка четырех видов IT контрактов — чек-лист для СЕО

Большинство проблем, с которыми к нам обращаются клиенты, возникали именно из-за недостатков и особенностей их контрактов с заказчиками.

За 7 лет работы в IT сфере я видел много бизнесов, где контракт «дал друг», «скачали из интернета» или «у клиента был свой, и он не хотел вносить изменения». И все это даже работало!

Но со временем одни замечали, что деньги из бизнеса, «как вода сквозь пальцы». Другие столкнулись с отказом оплачивать их работу. Третьи — попадали в ловушку невыгодных условий о неконкуренции и т.д.

Чтобы надежнее защитить доходы вашего бизнеса, предлагаю небольшой чек-лист по подписанию контрактов с заказчиками.

Шаг 1. Проверяем требования ко всем видам контрактов

1. Предмет договора.

Убедитесь, что этот пункт сформулирован правильно и однозначно. Он должен давать четкий ответ на вопрос: «что мы делаем?» Приложение, сайт, обновление для существующего продукта или что-то другое.

2. Переход прав на Intellectual Property (IP).

Самый безопасный для IT компании вариант, когда в контракте зафиксировано, что «неимущественные права на IP переходят к заказчику после всех расчетов по данному контракту». 

Это положение уже не раз спасало наших клиентов, когда заказчики (по разным причинам) отказывались платить.

3. Требование к чистоте IP.

Если оно звучит примерно так «Компания-разработчик гарантирует абсолютную чистоту интеллектуальных прав» — приложите максимум усилий, чтобы убрать его из контракта.

Оно предусматривает, что создавая что-то в рамках данного проекта, вы не нарушаете ничьих во всем мире прав на IP.

Чтобы выполнить это обязательство, нужно проводить глобальную экспертизу по каждой из частей кода. Это долго и дорого. И все равно не гарантирует, что кто-то не сделает то же, что и вы. А если у кого-то будут претензий к вашему заказчику по поводу IP на код или продукт, сделанные вами, вам придется за это отвечать.

4. Undisputed инвойс как условие оплаты.

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

На практике это означает, что вы будете вносить изменения в код или продукт, тратя время и другие ресурсы, которые вам не оплатят.

5. Положение о непереманивании сотрудников.

Важно, чтобы этот пункт в принципе был. Если нет — предлагайте добавить. В нем также должна быть серьезная ответственность за нарушение — ориентировочно $50-100k. Если в контракте будет просто указано, что запрещено переманивать персонал, это вас не защитит.

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

6. Завышенные требования к конфиденциальности.

Если заказчик хочет запретить любые упоминания о вашем партнерстве, важно оценить конкретную ситуацию.

В случае типичного для вас проекта, согласиться на это требование будет нормальным.

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

Может, он дал вам свой обычный контракт, а в целом не против, чтобы вы добавили их проект в ваше портфолио. В любом случае, этот момент важно согласовать.

7. Положение о неконкуренции.

Оно точно не должно ограничивать развитие вашего бизнеса на практике.

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

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

8. Форс-мажоры.

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

Вместо размытого «форс-мажором считается пандемия COVID-19», лучше прописать «форс-мажором считается ситуация, когда компания-заказчик понесла прямые и невозобновляемые убытки из-за пандемии COVID-19». И так по каждому из пунктов этого раздела.

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

9. Юрисдикция рассмотрения споров.

Важно, чтобы она была доступной для вашей компании (географически и материально). Этот вопрос каждый раз следует решать индивидуально. И на него точно стоит обращать внимание.

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

Хотите проверить свои контракты или спроектировать договоры под новые бизнес-задачи — сделаем, переходите по этой ссылке. 

Шаг 2. Проверяем требования к контрактам по видам

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

Поэтому, когда читаете договор определенного вида, вы должны понимать: 1) что в нем обязательно должно быть, 2) чего там точно быть не должно.

Итак, проверяем на соответствие контракты по видам:

Fixed Price:

• подробное и однозначно понятное ТЗ (видите неопределенность — просите устранить),
• сроки принятия работ (без этого заказчики могут затягивать оплату, решая собственные вопросы),
• пошагово описан процесс внесения изменений в ТЗ,
• зафиксировано, что дедлайны могут переноситься, если у команды не было возможности бесперебойно работать, по вине заказчика,
• если есть гарантийный срок на ваши услуги, то он должен быть реалистичным и адекватным (в среднем 2 — 3 месяца, а не несколько лет).

Time & Material:

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

Dedicated Team:

• все требования, что и для Time & Material, а также
• урегулирован вопрос оплаты больничных и отпусков для людей из dedicated team,
• указаны имена специалистов, входящих в dedicated team,
• прописана процедура замены работников,
• указано допустимое количество замен работников.

Outstaff:

• те же требования, что и к Dedicated Team, а также
• урегулирован процесс подбора персонала для заказчика (требования к разработчикам, сроки, процесс согласования кандидатов и т.д.),
• конкретные условия, которые компания обязуется создать для аутстаф-команды,
• зафиксировано, что организационное и техническое управление аутстаф-командой осуществляет заказчик.

Как это работает в реальной жизни

В чек-листе мы зафиксировали идеальные требования к контрактам, которые принесут вам максимальную выгоду. Это то, к чему любой IT предприниматель должен стремиться.

Но жизнь — значительно богаче каких-то идеальных требований. Поэтому далеко не всегда мы подписываем исключительно идеальные контракты.

Однако, пользуясь этим чек-листом, вы будете знать о лучших условиях для вашего бизнеса и сможете их отстаивать. А если придется поступиться чем-то, вы уже будете делать это более осознанно, понимая все риски и выгоды.
Чтобы ваши дела были в порядке, мы в Tretten Lawyers, будем рады помочь вам вычитать существующий или создать новый контракт для работы с заказчиком. Обращайтесь к нам по ссылке.