Представьте, что заказчики всегда вовремя оплачивают работу, а налоговые проверки проходят быстро и без штрафов. Добиться такого результата можно с помощью детально проработанного договора разработки программного обеспечения.
Зачем IT-компаниям разрабатывать и подписывать договоры на разработку ПО с клиентами?
IT-юристы советуют разработать документ, чтобы:
1. Пройти банковский compliance
Когда IT-компания получает международный денежный перевод на банковский счет от заказчиков, банк может попросить подтвердить легальность происхождения средств. Для этого подают договор на разработку ПО. Банк анализирует 3 пункта контракта: предмет, цена и стороны.
Например, в большинстве украинских банков, если сумма платежа превышает 150 000 грн, начинается усиленный банковский контроль. Это значит, что банк запросит контракт самостоятельно, и если его не подать, может заблокировать счет IT-компании. Чтобы не пришлось “переезжать” в другой банк и замораживать на это время движение денег по счетам, детально опишите продукт, который разрабатываете для заказчика. Так будет проще доказать, за что компания получает деньги. Если этого не сделать, IT-компанию ждет расторжение договора с текущим банком и перевод денег на счет в другом банке.
2. Подать отчетность в налоговую и органы финансового мониторинга
Договор на разработку программы - это подтверждение источника дохода. От того, как описан предмет договора зависит налоговая нагрузка IT-компании. Например, может ли компания рассчитывать на льготу по НДС. В Украине, если программный продукт передается в собственность заказчика, ставка НДС - 0%.
Когда сумма платежа по контракту больше 400 000 грн, начинается государственный финансовый мониторинг. Контролирующий орган анализирует откуда пришла сумма, платит ли заказчик налоги и другие аспекты.
3. Определить список услуг, которые предоставляются заказчику
Предмет контракта нужно прописать так, чтобы он соответствовал международным требованиям и признавался в стране, в которой предоставляются услуги. Например, в США вас не поймут, если в контракте будет написано “услуги креативного директора”. Поэтому выбирайте универсальные названия для типов услуг.
Кроме того, не стоит размывать предмет договора общими формулировками. Опишите услуги или продукт, который разрабатываете, согласно международным видам деятельности в сфере IT. Например, software development.
4. Определить правила менеджерирования проекта
Как, где и кто ставит задачи? Ответы на эти вопросы советуем закрепить в договоре, чтобы избежать конфликтов в процессе работы.
Ваша задача определить кто отвечает за предоставление материалов и дополнительной информации, постановку задач, проверку качества выполнения работы, оплату по инвойсам. Важно установить срок, в течении которого заказчик проводит проверку и критерии, по которым он может отказаться принять результаты работы. Таких критерием может быть два: не реализован функционал по техническому заданию или работа выполнена некачественно. В договоре напишите контактную информацию каждого члена команды, которые участвуют в процессе разработки. Например, корпоративные почты Project Manager, Team Lead, финансового отдела.
Кроме того, не забудьте уточнить, кто принимает окончательное решение по результатам работы. Если тестирование IT-продукта проводится на стороне заказчика, в договоре раскройте такие вопросы:
- кто проводит тестирование;
- как долго длится тестирование;
- как сообщаются результаты теста (лучший способ - письменно);
- кто оплачивает тестирование.
Работа по принципу “мы все сами” может стоить IT-компании 32 миллиона $. Так случилось у американской компании по прокату автомобилей Hertz и IT-компании Accenture. Hertz подала иск в суд за неспособность Accenture реализовать проект редизайна их веб-сайта и мобильных приложений. SVP по маркетингу компании Hertz Лиз Миллер признает, что они не принимали активного участия в проекте. Это и стало причиной спора в суде. По словам SVP, после взаимодействия с клиентом распространенной ошибкой является то, что заказчик бездельничает и позволяет IT-компании делать работу, предполагая, что все будет хорошо.
Чтобы избежать споров установите обязанность заказчика участвовать в разработке продукта, давать вовремя материалы и фидбек.
Ключевые пункты договора на создание программного обеспечения
В IT-сфере не прижилась практика разработки контрактов под каждого клиента и отдельные задачи. Поэтому IT-юристы разрабатывают единый универсальный контракт, а объем работ описывают в техническом задании. В контракте важно предусмотреть пункты, которые защитят бизнес-интересы IT-компании. Вот некоторые из них.
Предмет договора: что стороны должны друг другу?
Например, исполнитель предоставляет услуги по разработке программного обеспечения и его сервисному обслуживанию, а заказчик обязуется их оплатить. Передача результатов и принятие услуг описываются в технических заданиях (SOW).
То есть с помощью технического задания стороны описывают желаемый результат и устанавливают скоуп работ.
А дальше описываем как формируется техническое задание:
- в какой форме?
- что содержит?
- можно ли изменить и в течение какого времени?
Предлагаем написать так:
Исполнитель формирует SOW в письменной форме. Заказчик имеет право изменить условия и объем работы. Об этом он письменно сообщает исполнителю за 30 дней.
Каждое SOW будет содержать:
план реализации проекта;
план коммуникации;
вехи;
полное описание результатов, которые необходимо достичь;
цена, которую заказчик платит исполнителю за работу;
задачи и обязанности каждой стороны и другие пункты.
Еще один проблемный вопрос - правки. Особенно болезненно они воспринимаются, когда стороны подписывают Fixed Price контракт. В таком случае ограничьте раунды правок, а все что “сверху” - дополнительно оплачивается. Кроме этого разграничьте понятие ошибок и хотелок клиентов. Для этого определите понятие ошибки или дефекта и критерии их оценки. Ошибки исправляются, хотелки дополнительно оплачиваются.
Порядок оплаты: когда и сколько платить?
Цена по виду работы указывается в техническом задании. А оплата происходит на основании инвойса к международному контракту, или в акте к локальному, например украинскому, контракту.
В договоре на разработку программного обеспечения стороны определяют процедуру оплаты и отвечают на вопросы:
- как часто выставляются инвойсы;
- в течение какого времени производится оплата;
- какой размер пени за просрочку оплаты.
А вот и пример пункта из контракта: после выполнения технического задания исполнитель направляет заказчику инвойс. Если заказчик принимает результаты работы, он должен оплатить их на протяжении 7 календарных дней.
У заказчика есть возможность сделать замечания. Чтобы не затягивать следующие этапы работы, определить срок, в течение которого заказчик может предъявить претензии. Предлагаем сделать это так: если у заказчика есть замечания или претензии, он направляет их исполнителю в течение 10 календарных дней с даты получения инвойса, в электронной или письменной форме.
Еще один вопрос, на который стоит ответить в договоре: что делать, если заказчик не платит? Предлагаем предусмотреть такой пункт: если заказчик не оплатил услуги в течение 14 календарных дней, исполнитель может прекратить работу до момента оплаты инвойса.
Если и приостановление работы не помогает, напоминаем заказчику про пеню. Чтобы в арсенале был такой “инструмент влияния”, в договоре пишем: если заказчик не оплатил услуги, с него взимается неустойка (пеня) в размере 0,1% от стоимости предоставленных, но неоплаченных услуг, за каждый день задержки платежа. Размер пени подбирайте под каждый проект отдельно.
В контрактах IT-юристы часто встречают условие о том, что заказчик может уменьшить оплату, если IT-компания не выполнила работу в полном объеме. Но мы советуем заменить такой пункт не менее справедливым: заказчик оплачивает работу в полном объеме, но рабочие часы переносятся на следующий период.
Права интеллектуальной собственности: какие передать заказчику и что оставить себе?
В договоре о разработке программного обеспечения важно описать объем прав на результаты работ, которые передаются заказчику.
Предлагаем в договоре закрепить такой перечень прав:
- право использовать программный продукт: паблишить, монетизировать и даже продавать;
- право разрешать использование: лицензировать продукт;
- право предотвращать ненадлежащие использование объекта: общаться в арбитраж и суд в случае плагиата, кражи программного кода и других нарушений;
- другие права интеллектуальной собственности, которые существуют сегодня или появятся в будущем.
Кажется, что после таких пунктов в контракте, IT-компания передает заказчику все “до последней капли”. Но нет, у исполнителя остается база знаний, право на внутренние решения, купленные лицензии на внешние программные продукты и бесплатные программные продукты, которые считаются Open Source решениями.
Предлагаем подробнее раскрыть, что входит в объекты интеллектуальной собственности, которые останутся у IT-компании даже после окончания работы с клиентом:
- База знаний - это основные идеи, подходы, приемы, методологии, алгоритмы, парадигмы программирования и IT-разработки.
- Внутренние программные решения - это частные пакетированные коды, макеты, прототипы, мокапы, которые IT-компания переиспользует при создании решений для новых клиентов.
- Внешние проприетарное программное обеспечение - это софт, который IT-компания купила по лицензии для временного использования. Чаще всего расходы на его приобретение и продление несет заказчик.
К примеру, IT-компания разрабатывала сайт с онлайн-чатом. Проект успешно завершили, но заказчик увидел на сайте другой компании онлай-чат, который работает по такому же алгоритму и визуально похож на его решение. Обе компании работали с одним исполнителем. Это значит, что разработчики переиспользовали решения. Заказчик обратился с претензией. Но IT-компания указала на пункт договора, где написано, что онлайн-чат - это внутреннее программное решение. Значит, права интеллектуальной собственности не перешли к клиенту и решение можно использовать для разработки IT-продуктов для других заказчиков.
Еще один важный шаг - в договоре на разработку и сопровождение программного обеспечения закрепить возможность генерировать решения на базе Open Source, переиспользовать существующие решения, наработки и подходы: внешние пакетированные библиотеки, тулы для тестирования и другие инструменты. Для этого напишите: исполнитель и его команда разработчиков могут использовать интеллектуальную собственность, на которую распространяются бесплатные лицензии или лицензии на программное обеспечение с открытым исходным кодом.
И главное юридическое решение: напишите, что права на объекты интеллектуальной собственности переходят к заказчику только после полной оплаты по инвойсам. В договорах, которые клиенты присылают нам на вычитку, мы часто встречаем пункт о том, что авторские права переходят к заказчику в момент создания объекта. Так вы рискуете выполнить работу, но не получить оплату.
Неконкуренция и непереманивание: какой штраф придется заплатить заказчику за нарушение?
Чтобы защитить коммерческую тайну компании и запретить клиентам переманивать сотрудников и подрядчиков, в договор IT-юристы добавляют пункты о неконкуренции и непереманивании.
Советуем запретить клиентам предлагать сотрудникам IT-компании вступить с ними в трудовые, коммерческие отношения, прямо или косвенно переманивать сотрудников, подрядчиков, клиентов или партнеров.
Уточните, какие действия будут считаться переманиваем. Например добавьте в контракт такое описание:
Переманивание - это действия, которые привели к:
- возникновению трудовых, коммерческих или других деловых отношений между сотрудниками, подрядчиками, поставщиками или партнерами IT-компании и заказчиком в текущем проекте;
- прекращению трудовых, коммерческих или других деловых отношений между IT-компанией и ее потенциальными или текущими сотрудниками, подрядчиками, поставщиками или партнерами.
А вот пункты о неконкуренции чаще ограничивают исполнителя. Заказчик стремится запретить IT-компании создавать, разрабатывать и продавать идентичный программный продукт. А также создавать, помогать или участвовать в создании компании или предприятия, которые будут вести подобный или конкурирующий бизнес, по отношению к бизнесу Заказчика.
После того, как определились с запретами, не забудьте предусмотреть штрафы за нарушение. Например, за каждый случай нарушения правил непереманивания заказчик платит исполнителю 15 000 долларов США компенсации за каждого члена команды.
Конфиденциальность: что хранить в секрете?
В процессе работы IT-компания и клиенты обмениваются конфиденциальной информацией, разглашение которой может привести к краху бизнеса. Поэтому IT-юристы добавляют в договор подряда на программное обеспечение пункт о неразглашении конфиденциальной информации.
Задача юристов определить какую конкретно информацию запрещено разглашать и как долго. Чем конкретнее перечень объектов конфиденциальной информации, тем проще доказать нарушении и получить компенсацию. Срок действия ограничений советуем устанавливать 3 года после окончания действия договора.
Мы знаем истории, когда благодаря NDA IT-компании оперативно решали бизнес-вопросы и конфликты. Вот одна из них. Наш клиент из Израиля и заказчик из США заключили аутстаффинговый контракт на разработку E-commerce платформ. Со временем израильская IT-компания увеличила стоимость работы девелоперов с 25$ до 45$ за час. Но, спустя 3 месяца работы, заказчик отказался платить по новому прайсу и задолжал 237 000 $. К сожалению договоренности компаний об изменении цены были в устной форме. Единственным доказательством была переписка в мессенджере. Исполнитель и заказчик не подписывали дополнительное соглашение с новым прайсом.
Но IT-юристы отыскали спасательный круг в тексте договора о неразглашении конфиденциальной информации. В NDA между израильской и американской компаниями нашли положение, в котором предусмотрено право исполнителя выйти из NDA и разглашать конфиденциальную информацию, если заказчик не оплачивает работу. Так наработки по проекту можно было продать компании-конкуренту. Под угрозой потерять результаты работы, заказчик оплатил их стоимость.
Каждая IT-компания хочет пополнять портфолио новыми, интересными кейсами. Возможность называть себя автором продукта облегчает привлечение новых клиентов. Поэтому, напишите в договоре, что можете делать заявления о сотрудничестве с клиентом, размещать пресс-релизы, вносить кейс в портфолио. Если заказчик против, предложите написать в договоре, что предварительно будете запрашивать разрешение клиента на публичное заявление о сотрудничестве.
Обработка персональных данных: что собираем и где храним?
IT-компания получает доступ к информации не только о заказчике, но и о его сотрудниках и конечных клиентах. К примеру, в процессе разработки продукта в сфере FinTech, сотрудники IT-компании получают доступ к персональной информации клиентов банков, инвестиционных компаний и других представителей рынка финансовых услуг. К личным данным относятся имя, фамилия, гражданство, индивидуальный налоговый номер, банковские реквизиты, семейное положение, номера телефонов, адреса электронной почты, место регистрации и адрес фактического проживания, данные доступа и авторизации. Заказчик гарантирует безопасность такой информацию своим клиентам, а значит ему важно видеть в договоре раздел об обработке персональных данных. Здесь нужно закрепить ответы на 5 вопросов:
- к каким данным IT-компания получает доступ?
- зачем разработчики используют персональную информацию?
- где хранятся персональные данные?
- какие меры безопасности предприняты для защиты личной информации?
- кому открываются и передаются данные?
Разрешение конфликтов: где рассматривать IT-спор?
Большинство споров в IT не доходят до суда, и решаются с помощью переговоров. Предлагаем не изменять позитивную практику и предусмотреть в договоре обязательною процедуру досудебного урегулирования спора.
Если стороны не могут достичь согласия, следующий шаг - привлечь медиатора для разрешения конфликта. Не забудьте предусмотреть, кто платит за услуги медиатора. В контрактах для наших клиентов мы предлагаем оплату 50 на 50.
Когда предыдущие этапы не помогли решить конфликт, спор рассматривается в арбитраже или суде. В зависимости от страны регистрации клиента, в договоре определяют какой конкретно суд или арбитраж рассмотрит спор.
Прекращение договора: в каком случае можно расторгнуть соглашение?
Каждая из сторон договора может прекратить его действие. Но важно предусмотреть, за сколько дней исполнитель или заказчик должны предупредить друг друга об этом. Если договор будет расторгнут по инициативе заказчика, он оплачивает исполнителю фактически оказанную часть услуг.
Договор можно прекратить и по дополнительному соглашению между исполнителем и заказчиком. Тогда в документе указывают скоуп работ, которые нужно выполнить до завершения сотрудничества, и срок, в течении которого это необходимо сделать. Конкретный срок в дополнительном соглашении поможет избежать срыва дедлайнов.
Электронный документооборот: как и где подписать договор?
Договор с клиентом и дополнения к нему подписывают в электронной форме с помощью 3х способов:
- обмен скан-копиями договора. Такой скан имеет силу оригинала до получения бумажной версии документа.
- С помощью сервисов и простой цифровой подписи. Например, сервиса Вчасно в Украине, или американского сервиса Docusign.
- С помощью электронной цифровой подписи, которая выдана одним из аккредитованных центров сертификации.
В договоре можно предусмотреть альтернативные варианты электронного документооборота. Для этого добавьте пункт о том, что договор и дополнения к нему подписываются с помощью сервисов цифровой подписи или электронной цифровой подписи (ЭЦП), которая выдана одним из аккредитованных центров сертификации. Кроме этого, стороны могут обмениваться скан-копиями документов. При этом, такие скан-копии будут иметь юридическую силу до момента получения подписанного оригинала документа в письменной форме.
Если вы планируете использовать сервисы цифровой подписи, напишите их название в договоре.
Мы выделили пункты, которые содержатся во всех IT-контрактах с клиентом. Но каждый тип соглашения о разработке программного обеспечения: Time & Material, Fixed Price или Dedicated team имеет свои особенности, которые необходимо брать во внимание. Поэтому разработка контракта требует учета бизнес-процессов компании, чтобы защита интересов была реальной, а не формальной.
