м. Київ, вул. Кудряшова 3
ПН-ПТ: 9:00-19:00 СБ: 10:00-17:00

Договір на розробку програмного забезпечення з клієнтами: ключові пункти

Уявіть, що замовники завжди вчасно оплачують роботу, а податкові перевірки проходять швидко і без штрафів. Домогтися такого результату можна за допомогою детально опрацьованого договору розробки програмного забезпечення.

Навіщо 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 має свої особливості, які необхідно брати до уваги. Тому розробка контракту вимагає врахування бізнес-процесів компанії, щоб захист інтересів була реальним, а не формальним.

 

Останні статті
Інструкція для IT-компаній зі складання гіг-контрактів
Нова стаття
25.08.21
Інструкція для IT-компаній зі складання гіг-контрактів
Розповідаємо про плюси і мінуси гіг-контракту, і чим він відрізняється від договору з ФОП.
Читати статтю
Дія Сіті – нові правила гри для IT-бізнесу
Нова стаття
06.08.21
Дія Сіті – нові правила гри для IT-бізнесу
80% IT-фахівців проти Дія City. Водночас SoftServe та EPAM підтримують новий правовий режим. Давайте розберемося чому так відбувається.
Читати статтю
Договір на створення програмного продукту з девелоперами: поради IT-юристів
Нова стаття
26.07.21
Договір на створення програмного продукту з девелоперами: поради IT-юристів
Пункти, які ви зазначите у договорі, будуть застосовуватися до організації робочого процесу і допоможуть вирішити конфлікти у команді.
Читати статтю
Слідкуйте за останніми новинами
Передзвоніть мені IT-юрист зв'яжеться з вами
для обговорення деталей
Дякуємо за звернення!

IT-юрист зв'яжеться з вами та розкаже про юридичні рішення

OK
Дякуємо за запит!

IT-юрист зателефонує вам для з'ясування деталей

OK
Дякуємо за відгук!

Ми будемо раді, якщо ви розкажете про нас друзям і колегам

OK
Дякуємо за запит!

Команда IT-юристів зв'яжеться з вами та розкаже про варіанти рішень

OK
Дякуємо за запит!

IT-юрист зв'яжеться з вами та поставить декілька додаткових питань

OK
Дякуємо за інтерес!

Очікуйте рекомендації IT-юристів

OK
Дякуємо за запит!

Команда IT-юристів підготує рішення для вас

OK
Дякуємо за звернення!

IT-юрист розбере вашу ситуацію та запропонує рішення

OK