Многие IT компании рано или поздно сталкиваются с тем, что заказчик отказывается оплачивать работу полностью или частично. Часто это связано с изменением видения заказчиком конечного результата, с неточными формулировками ТЗ, с неучетом рисков и дополнительных расходов, возникающих в ходе работ и т.д.

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

Между продажей и стартом работ

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

Дальше вам нужно не просто подписать контракт, а провести еще одну стадию переговоров с потенциальным партнером — согласовать также вопросы сотрудничества, которые не обсуждалсь до этого.

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

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

Именно поэтому, прежде чем подписывать контракт, советуем обсудить с клиентом следующие вопросы:

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

В прошлом году к нам обратился фаундер IT компании, оказавшейся в ситуации, когда заказчик не хотел оплачивать первый спринт. Работали по Time&Material, а заказчик требовал внести изменения в продукт, которые не были оговорены в начале, без оплаты дополнительно затраченного командой времени. В то же время у них уже был законтрактован второй спринт. В контракте зафиксировано, что с одной стороны, они могут разорвать отношения с заказчиком, предупредив его за три месяца, и не было ничего сказано о том, что они имеют право не выполнять работы по второму спринту в случае неоплаты предыдущего. С другой стороны, было положение о том, что в случае нанесения ущерба заказчику, IT компания обязана их компенсировать. Невыполнение второго спринта заказчик расценивал как нанесение ему ущерба.

На стадии подписания контракта в IT компании не обратили внимания на эти фразы, считая их простой формальностью. Ведь не планировали ни разрывать отношения с клиентом, ни наносить ему ущерб. То есть наш клиент попал в ловушку, которая была заложена в контракте. Им пришлось вносить изменения. Заказчик не оплатил человеко-часы, потраченные на это. Вместо ожидаемых 3000 $ дохода получили только 500 $.

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

Положения контракта, которые защищают от неоплат

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

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

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

Советую всегда, без каких-либо особых причин придерживаться следующих правил:

1. Если работаете по Time&Material, внимательно следите, чтобы договор не фиксировал качественных требований к продукту в любом виде.

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

2. Если работаете по Fixed Price, подробно обсудите с заказчиком конечный результат, чтобы максимально правильно понять его видение. А также требуйте четкого ТЗ без критериев, которые можно трактовать неоднозначно.

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

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

3. Независимо от вида контракта зафиксируйте, что права на IP (интеллектуальную собственность) переходят к заказчику после полной оплаты им работ по данному контракту.

Это положение — реальная защита для компании-разработчика. С ним, особенно в сочетании со следующим правилом, риск неоплаты вашей работы достаточно низкий.

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

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

Undisputed инвойс — это тот, который не оспаривается сторонами. То есть, если заказчик будет не согласен с чем угодно в вашем инвойсе: качеством, сроками, объемом или просто ему субъективно не понравится результат — он имеет право не оплачивать вашу работу.

Это требование довольно часто встречается в контрактах иностранных заказчиков. Понятно, что не всегда до него доходит дело. Но в случае конфликта, вы будете практически не защищены от неоплаты со стороны заказчика.

Как это работает на практике

Несколько месяцев назад в Tretten Lawyers обратился фаундер небольшой украинской IT компании с вопросом «что делать — клиент должен нам $ 45k, не рассчитывается уже несколько месяцев?»

Мы изучили их контракт с этим заказчиком и увидели в нем:

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

Судиться в USA за $ 45k было экономически нецелесообразно. В случае победы (которая вовсе не была гарантированной) почти все полученные средства пошли бы на перелеты и адвокатов. Но положение об IP, которая к заказчику переходит только после оплаты работ, вселяло надежду.

Как выяснилось, конечным потребителем кода была американская продуктовая компания. А наш заказчик взял украинских разработчиков на субподряд. Мы обратились к конечному потребителю и объяснили ему, что они пользуются кодом, который им не принадлежит. Ведь подрядчик передал им IP, которая так и не стала их собственностью.

Продуктовая компания была важным партнером для нашего заказчика, поэтому они сразу рассчитались с украинской IT компанией.
Так одна строка в контракте защитил IT бизнес от потери $ 45k. Хотите проверить свои контракты или разработать новые, более защищенные — пишите нам по ссылке. Сделаем так, чтобы ваши дела были в порядке.