Договор на разработку программного обеспечения. ІТ контракты

Договоров в ИТ невероятно большое количество, и вот только короткий список тех, которые мы обычно предлагаем своим клиентам:

• договор на разработку, модернизацию, дебаг, тестирование ПО
• договор на разработку сайта
• договор на разработку мобильного приложения
• договор на разработку с применением VR / AR
• договор на поисковую оптимизацию
  
• договор об оказании услуг в сфере информатизации
  
• договор на техподдержку
  
• договор на облачные услуги (и здесь мы остановимся, чтобы перевести дыхание).
                          

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

Стандартный договор на разработку?

Договор на разработку не должен быть универсальным: мы составляем их каждый раз заново в зависимости от того, какую модель разработки ПО договор должен отражать. Например, наиболее классическим примером можно считать договор, основанный на Waterfall-модели, однако более широко используются Agile-договоры, часто объединяемые с аутстафом (outstaffing) или dedicated team. Они имеют разную начинку и всегда предусматривают внимание к интересам клиента.

Кроме того, всегда существуют дополнительные специфические договоренности между разработчиком и заказчиком: кто получает имущественные права на конечный продукт? Охраняется ли коммерческая тайна? Как разработчик может выйти из проекта? Существует ли порог стоимости разработки? Так еджайл или вотерфол?
Договор должен отражать ту модель, которую разработчик и заказчик выбрали для сотрудничества. Стоит помнить, что договор нужен для защиты обеих сторон, и поэтому юрист должен прежде всего понимать суть и последствия выбранной Вами модели разработки ПО.

Вотерфол

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

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

«Стороны соглашаются, что стоимость услуг составляет _ евро за час, при условии, что в сумме Исполнитель потратит _ часов на оказание услуг в соответствии с Техническим заданием.»

Если у заказчика ограниченный бюджет или он боится затянуть проект и потратить неоправданную количество денег, то он будет настаивать на fixed-bid pricing (фиксированной стоимости договора), когда вся сумма балок ПО вписывается в договор и не может быть изменена (например, разбита на этапы) без заключения дополнительных соглашений (например, если добавляется новая функция или выбрасываются уже неактуальны для рынка). Часто платеж делится на аванс и расчет, и разработчик получает честно заработанные деньги только после завершения проекта (и в связи с этим, разработчики не очень склонны брать долгосрочные fixed-bid проекты — иногда приходится ждать финальных расчетов слишком долго!)

Однако в тех случаях, если заказчик хочет заглядывать под вуаль таинства разработки его ПО, стороны могут договориться о milestone-based pricing (оплата частями в течение определенного периода): в таком случае заказчик может присутствовать на нескольких промежуточных остановках (так называемых milestones), под время которых заказчик отдает часть стоимости, чтобы разработчик мог работать дальше, смотрит на прогресс работы, тестирует уже имеющиеся фишки и в целом убеждается, что работа куда движется.

Принятие и тестирование. По общему правилу, ПО передается уже в конце проекта. Далее заказчик тестирует ПО и оплачивает, если недостатков не выявлено.

В случае, если оплата зависит от milestones schedule (то есть оплата разбита на несколько этапов в зависимости от завершенности продукта), проект делится на заранее определенное количество milestones, и заказчик должен утвердить и принять результаты на каждом этапе, чтобы разработчик мог переходить к следующему этапу.

«Общий срок предоставления Услуг составляет _ месяцев с момента подписания настоящего Договора. После получения Результаты разработки Заказчик, согласно Milestone Schedule, должен в течение пяти рабочих дней проверить Результаты на наличие дефектов и сообщить Исполнителю о результатах тестирования ».

Разработчик тестирует ПО перед каждым следующим этапом. Заказчик тоже имеет тестировать результаты и сообщать разработчику о выявленных недостатках в течение короткого времени -примерно 3-5 рабочих дней. Сообщение лучше получать в письменном или электронном виде. При тестировании заказчик обязуется проверять ПО на соответствие техническому заданию и другим требованиям, о которых договариваются стороны. Если же заказчик не сообщит о результатах тестирования, то считается, что заказчик принял и одобрил предоставленные ему результаты (поскольку об этом указано в договоре, конечно же).

Аджайл

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

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

Outstaffing или dedicated team? Бывают случаи, когда в разных разработчиков, которых компания-поставщик предлагает заказчику, разный рейт за час работы. Как же заказчику убедиться, что он заплатил за работу Синьора, а работу фактически не выполняют Джуны? Для этого стороны еще во время переговоров договариваются о выделении dedicated team или включают в договор outstaffing clause. Важно не ограничивать свою ИТ компании только трудоустроены разработчиками:

«Заказчик услуги путем привлечения разработчиков из собственного штата и / или самозанятых ИТ-разработчиков (« Команда Разработчиков ») и отвечает за надлежащий уровень экспертизы каждого разработчика.»

Заказчик может оценить уровень подготовки и экспертизу каждого из выделенных на его проект разработчиков и, в случае необходимости, требовать их замены. Также заказчик все еще может оставить за собой право сократить штат команды, чтобы снизить стоимость разработки на каком-то этапе:

«Разработчики привлекаются к проекту только после согласования их кандидатур с Заказчиком, который подписывает соответствующий Приложение или Дополнительное соглашение.»

«Заказчик имеет право требовать исключить конкретного разработчика с Команды Разработчиков, или уменьшить количество Разработчиков, занятых в предоставлении услуг без предварительного согласия Исполнителя.»

Dedicated team отличается от outstaffing если аутстаф предусматривает выделение команды среди трудоустроенных разработчиков, которых работодатель «передает» заказчику ПО в штат (что связано с определенными трудностями ввиду того, что законодательство Украины о труде требует согласия каждого из работников на такое перемещение), то dedicated team фокусируется на распределении трудовых обязанностей внутри трудового коллектива, и не связан с изменением места работы или работодателя.

Оплата может базироваться на различных системах, объединенных в Time & Materials (T & M-based) pricing, когда сумма договора зависит от фиксированного платежа за итерацию, фиксированного платежа на user story или согласованную их количество и тому подобное. В договоре обязательно указываются модель расчетов, время, когда направляются инвойсы, кто оплачивает незавершенную работу во время итерации и фичи, которые не выполняют необходимых требований в Definition of Done (документ, подтверждающий объем услуг, предоставленных в течение одной итерации), воздействие на стоимость сокращения объема работы или досрочного расторжения договора. Стоимость договора, конечно же, может быть ограничено (так называемая coppedprice), и договор при достижении пороговой стоимости прекращается или перезаключается.

На что же еще нужно обратить внимание?

Работа с заказчиками-нерезидентами. При работе с иностранными контрагентами следует помнить об особом порядке расчетов. Сегодня и до вступления в силу Закона Украины «О валюту и валютные операции», законодательство Украины еще предусматривает ряд валютных ограничений, которые существенно влияют на расчеты в валюте. Например, в договоре с иностранными заказчиками следует ограничивать время, когда осуществляются расчеты:

«Заказчик оплачивает выставленный Исполнителем счет (инвойс) в течение _ дней, однако в любом случае не позднее 180 дней с момента выставления счета. В случае, если Заказчик не оплачивает счет (инвойс) в течение _ дней, Исполнитель может обратиться с иском в хозяйственный суд по местонахождению Исполнителя. »

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

Момент и факт перехода прав на разработанное ПО. Поскольку часто заказчик и разработчики могут ни разу не увидеть друг друга вживую, важно зафиксировать момент, когда права на ПО переходят от одной стороны к другой. Часто в договорах указывается, что договор считается выполненным в момент загрузки ПО в репозиторий вроде GitHub, который для удобства в договорах упоминается как «Система»:

«Результаты оказанных услуг передаются Исполнителем Заказчиком путем загрузки Исполнителем таких результатов в Систему, если иное не было согласовано Сторонами.»

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

Интеллектуальная собственность. Заказчики склонны требовать передавать им права не только на готовое программное обеспечение, но и любую информацию и материалы и побочные продукты, которые были созданы для выполнения договора на разработку ПО:

«Исключительные имущественные права Заказчика на объекты интеллектуальной собственности, созданные в процессе выполнения Исполнителем настоящего Договора, распространяются как на готовый объект интеллектуальной собственности, так и на материалы, полученные в ходе его разработки, порождаемые ими аудиовизуальные отображения, независимо от языка и формы выражения, включая, но не ограничиваясь, исходный текст и объектный код. »

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

«Вознаграждение Исполнителя за предоставленные услуги, в рамках настоящего Договора, включая авторское вознаграждение Исполнителя за использование объектов интеллектуальной собственности и передаче исключительных имущественных прав автора на них.»

Сбор и обработка персональных данных. Учитывая то, что наиболее экономически активные страны активно включились в разработку законодательства о защите персональных данных, следует убедиться, что договор предусматривает защиту Вас от ответственности по праву Вашего контрагента. Особенно внимательно следует отнестись контрагентов с ЕС, США (в частности, штат Калифорния), Сингапур, Гонконг, Российской Федерации, Австралии и других стран, которые сейчас крайне внимательно относятся к защите персональных данных своих граждан.

Неконкуренция и защита конфиденциальной информации. Формулировать соглашение о неконкуренции (non-compete agreement) как наказание работника за смену работодателя не следует — это повредит не только репутации как работодателя, но еще и не даст никаких дополнительных шансов победы в суде. Несмотря на то, что суды традиционно становятся на сторону нарушителя, соглашения о неконкуренции могут применяться или как способ предотвратить нарушение работником или контрагентом взятых на себя обязательств, или как способ защитить конфиденциальную информацию, которую такой контрагент или работник получил во время сотрудничества. Однако это касается в основном тех случаев, когда правом договора остается право Украины: не исключено, что если договор о разработке ПО подчиняется иностранному праву, то такая сделка будет признана действительной в иностранном суде.

  Однако чтобы воспользоваться non-compete agreement (или NCA) как способом предотвратить утечки конфиденциальной информации, следует соблюдать несколько важных условий:

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

Только при условии, что все эти элементы будут присутствовать, у владельца конфиденциальной информации появится возможность подтвердить законность своих требований о возмещении в суде. Вместе с тем, если основной целью является все-таки не содержание работника, а конфиденциальности, то лучше отдать предпочтение заключению соглашения о неразглашении (non-disclosure agreement, или NDA), чтобы предотвратить толкованию такого соглашения как нарушение контрагента или работника права на труд .

We are fair ’cause we care.
Хороший договор на разработку должно напоминать сторонам о все договоренности, достигнутые на переговорах, а качественный договор призван еще и защищать разработчика или заказчика от непредвиденных ситуаций, не приходят в голову сразу.