Уявіть, що замовники вчасно оновлюють технічні завдання, надсилають матеріали, відповідають на запити та оплачують роботу. Досягти таких результатів можна за допомогою детально пропрацьованого договору на розробку програмного забезпечення. Документ фіксує правила комунікації, обов’язки сторін та робить процес розробки передбачуваним.
Для чого IT-компаніям розробляти та підписувати договори на розробку ПЗ із клієнтами?
Існує щонайменше 3 причини, чому вашій компанії варто підписати договір на розробку ПЗ із клієнтами.
1. Пройти банківський compliance і подати звітність до податкової та органів фінансового моніторингу
Коли IT-компанія отримує міжнародний грошовий переказ на банківський рахунок від замовника, банк може попросити підтвердити легальність походження коштів. Для цього подають договір на розробку програмного забезпечення. Банк аналізує 3 пункти у договорі: предмет, ціну та сторін.
Наприклад, у більшості українських банків, якщо сума платежу перевищує 150 000 грн, починається посилений банківський контроль. Це означає, що банк попросить договір, і, якщо його не подати, може заблокувати рахунок IT-компанії. Щоб не довелося “переїжджати” до іншого банку та заморожувати на цей час рух коштів на рахунках, детально опишіть продукт, який розробляєте для замовника. Так буде простіше довести, за що компанія отримує гроші. Якщо цього не зробити, IT-компанію чекає розірвання договору з поточним банком та переведення коштів на рахунок у іншому банку.
Договір на розробку програми — це підтвердження джерела доходів. Якщо сума платежу за контрактом перевищує 400 000 грн, здійснюється державний фінансовий моніторинг. Контролюючий орган аналізує звідки надійшла сума, чи сплачує замовник податки та інші аспекти.
2. Визначити список послуг, які надаються замовнику
Предмет договору слід прописати так, щоб він відповідав міжнародним вимогам та визнавався в державі, у якій надаються послуги. До прикладу, у США вас не зрозуміють, якщо у контракті буде написано “послуги креативного директора”. Тому обирайте універсальні назви для типів послуг.
Крім цього, не варто розмивати предмет угоди загальними формулюваннями. Опишіть послуги або продукт, який розробляєте, відповідно до міжнародних видів діяльності у сфері IT. Наприклад, software development.
3. Визначити правила менеджерування проєкту
Щоб процес розробки був передбачуваним, а комунікація з клієнтом комфортною, кожна сторона повинна розуміти зону своєї відповідальності та свої обов’язки. Для цього договір повинен відповідати на питання:
- Як, де та хто ставить задачі?
- Хто може відмінити або внести зміни до технічного завдання? Який алгоритм дій для цього?
- Хто приймає остаточне рішення за результатами роботи?
- Хто проводить тестування? Як довго воно триває та як оплачується?
Відсутність ефективної комунікації IT-компанії з клієнтами призводить до фінансових втрат. Так сталося у американської компанії з прокату автомобілів Hertz та IT-компанії Accenture. Hertz подала позов до суду з вимогою виплатити 32 млн. доларів США, бо Accenture не змогли реалізувати проєкт дизайну вебсайту та мобільних додатків. SVP з маркетингу компанії Hertz визнає, що компанія-замовник не брала активної участі у проєкті. За її словами, поширеною помилкою є те, що замовник залишається пасивним та дозволяє IT-компанії ухвалювати рішення самостійно, вважаючи, що все буде добре. Щоб уникнути конфліктів, у договорі на розробку ПЗ слід встановити обов’язок замовника брати участь у розробці продукту, вчасно надсилати матеріали, давати фідбек, ставити та оновлювати технічні завдання.
Ключові пункти договору на створення програмного забезпечення
У IT-сфері не прижилася практика розробки договору під кожного клієнта, тому IT-юристи розробляють універсальний темплейт, а деталі кожного окремого проєкту, або його стадій, описують у технічних завданнях. У цій статті наші юристи розповіли які пункти повинні бути у договорі, щоб захистити бізнес-інтереси IT-компанії, та як їх описати.
Предмет договору: які послуги надає IT-компанія?
У цьому розділі угоди слід визначити які послуги надає IT-компанія, наприклад, послуги з розробки програмного забезпечення та його сервісного обслуговування, або послуги UX/UI-дизайну. Деталі проєкту або його окремих стадій описують у технічних завданнях (ТЗ). За допомогою ТЗ сторони визначають бажаний результат та встановлюють скоуп робіт.
У договорі радимо описати як формулюється технічне завдання:
- У якій формі?
- Що містить?
- Чи можна змінити та протягом якого часу потрібно попередити про це?
Правила внесення змін до ТЗ важливо описати у договорі. Замовник може направити запит на внесення змін, у якому опише додаткові роботи та визначить дедлайни. До запиту додаються технічні специфікації, референси та інші деталі додаткових робіт. Послуги за заявою на внесення змін оцінюються заново та оплачуються замовником додатково. IT-компанія розраховує бюджет, дату поставки продукту, кількість годин для надання послуг, тривалість надання послуг, технологію, що використовується, задачі та етапи, ресурси та інші умови.
У договорі на розробку ПЗ можна встановити строк, протягом якого IT-компанія оцінює зміни, а замовник затверджує оновлене ТЗ. Наприклад, IT-компанія здійснює оцінку протягом 10 робочих днів з дати отримання запиту, а замовник повинен затвердити нове ТЗ протягом 5 днів з моменту отримання оціночної таблиці. Узгодження змін фіксується у новому ТЗ, яке підписується сторонами.
Відносьтеся до підписання ТЗ з усією серйозністю, щоб у разі конфлікту мати можливість стягнути заборгованість з замовника. Тільки детальні та підписані ТЗ можуть використовуватися у суді як докази, якщо клієнт відмовляється оплатити надані послуги. Такий спір розглядався у Делаверському окружному суді США. IT-компанія CIGNEX подала позов проти клієнта, який відмовився сплатити більше $350 000 за послуги, надані відповідно до п’яти запитів на зміни. Три з них були підписані сторонами та визначали етапи проєкту, необхідний час на кожен етап, а також погодинні ставки розробників. Два інших запити на зміни не були узгоджені та оформлені у письмовому вигляді, тому суд ухвалив рішення про стягнення лише за трьома запитами на зміни. Це означає, що навіть невеликі зміни слід фіксувати у нових ТЗ та підписувати, щоб зобов’язати клієнта оплатити всю роботу команди.
Порядок оплати: коли та скільки платити?
Оплата здійснюється на основі інвойсу до міжнародного контракту, або акту до українського договору. Ціна за видами роботи вказується у технічному завданні.
У договорі на розробку програмного забезпечення сторони визначають процедуру оплати та відповідають на питання:
- Як часто виставляються інвойси?
- Протягом якого часу здійснюється оплата?
- Який розмір пені за прострочення оплати?
Після виконання технічного завдання IT-компанія направляє замовнику інвойс. У договорі слід зафіксувати строк, протягом якого замовник повинен затвердити та оплатити рахунок, наприклад, протягом 7 календарних днів з моменту його отримання.
Замовник може зробити зауваження за результатами розробки та вимагати внесення правок. В угоді повинен бути гарантійний період, протягом якого замовник може заявити претензії, наприклад, протягом 45 днів з моменту передачі результатів роботи. Правки можна класифікувати таким чином:
- Перша група правок стосуються невідповідності функціональних можливостей об’єкта або його частини технічним характеристикам, визначеним у ТЗ. Також до цієї групи слід віднести ситуації, коли команда IT-компанії не виконала роботу у об’ємі, описаному в ТЗ. У такому випадку IT-компанія встановлює строк внесення змін без додаткової оплати замовником. Сторони додатково узгоджують новий дедлайн. Строк оплати рахунка поновлюється з дати повторної передачі об’єкта на перевірку клієнту після внесення змін.
- Друга група правок стосується додаткових завдань, які оцінюються за правилами запиту на внесення змін. Якщо IT-компанія відносить правки до другої групи, замовник повинен оплатити передані йому об’єкти.
Якщо замовник заявляє претензію за першою групою правок, важливо попередити його про те, що усунення багів буде безкоштовним якщо:
- Баг було неможливо виявити на момент перевірки результатів розробки.
- Баг виник у зв’язку з явною технічною помилкою команди розробників при використанні конкретної технології, тому програмне забезпечення не відповідає ТЗ або технічним специфікаціям.
- Сторонні особи не вносили жодних змін до програмного коду, а отже ексклюзивним розробником програмного коду є IT-компанія.
Ще одне питання, на яке варто відповісти у договорі: що робити, якщо замовник не платить? Пропонуємо передбачити такий пункт: якщо замовник не оплатив послуги протягом 14 календарних днів, виконавець може припинити роботу до моменту оплати рахунка.
Якщо призупинення роботи не мотивувало замовника оплатити рахунок, нагадуємо йому про пеню. Щоб у арсеналі був такий “інструмент впливу”, у договорі пишемо: якщо замовник не оплатив послуги, з нього стягується неустойка (пеня) у розмірі 0,1% від вартості наданих, але не оплачених послуг, за кожен день затримки платежу.
У контрактах IT-юристи часто зустрічають умову про те, що замовник може зменшити оплату, якщо IT-компанія не виконала роботу у повному об’ємі. Але ми радимо замінити такий пункт та написати про те, що замовник оплачує роботу у повному об'ємі, але робочі години переносяться на наступний період. Це допоможе уникнути касових розривів.
Права інтелектуальної власності: які передати замовнику та що залишити собі?
У договорі про розробку програмного забезпечення важливо описати об’єм прав на результати робіт, які передаються замовнику.
Пропонуємо у договорі закріпити такий перелік прав:
- Право використовувати програмний продукт: паблішити, монетизувати та продавати.
- Право дозволяти використання: ліцензувати продукт.
- Право запобігати неналежному використанню об’єкта: звертатися до арбітражу та суду у разі плагіату, крадіжки програмного коду та інших порушень.
- Інші права інтелектувальної власності, які існують сьогодні або з’являться у майбутньому.
У договорі важливо окреслити не лише які права передаються замовнику, але і в який момент відбувається перехід. Радимо вказати, що права на об’єкти інтелектуальної власності переходять до замовника лише після здійснення повної оплати за рахунками. В угодах, які клієнти надсилають нам на вичитку, ми часто зустрічаємо пункт про те, що авторські права переходять до замовника у момент створення об’єкта. Так ви ризикуєте виконати роботу, але не отримати оплату, тому моментом переходу повинна бути оплата у повному об’ємі.
Частина прав інтелектуальної власності залишається у IT-компанії, наприклад, права на базу знань, внутрішні рішення, куплені ліцензії на зовнішні програмні продукти та безкоштовні програмні продукти, які вважаються Open Source рішеннями.
Давайте розберемося, що відноситься до об’єктів інтелектуальної власності, які залишаються у IT-компанії навіть після завершення роботи з клієнтом.
- База знань — це основні ідеї, підходи, прийоми, методології, алгоритми, парадигми програмування та IT-розробки.
- Внутрішні програмні рішення — це приватні пакетовані коди, макети, прототипи, мокапи, які IT-компанія повторно використовує при створенні рішень для нових клієнтів.
- Зовнішнє пропрієтарне програмне забезпечення — це софт, який IT-компанія придбала за ліцензією для тимчасового використання. Зазвичай витрати на його придбання та продовження несе замовник.
До прикладу, IT-компанія розробила сайт з онлайн-чатом. Проєкт успішно завершили, але замовник побачив на сайті іншої компанії онлайн-чат, який працює за тим же алгоритмом та візуально схожий на його рішення. Обидві компанії співпрацювали з один виконавцем. Це означає, що розробники перевикористали рішення. Замовник звернувся з претензією, але IT-компанія вказала на пункт договору, в якому вказано, що онлайн-чат — це внутрішнє програмне рішення компанії. Це означає, що права інтелектуальної власності не перейшли до клієнта та рішення можна використовувати для розробки IT-продуктів для інших замовників.
Ще один важливий крок, закріпити у договорі на розробку та супроводження програмного забезпечення можливість генерувати рішення на базі Open Source, перевикористовувати існуючі рішення, напрацювання та підходи, а саме зовнішні пакетовані бібліотеки, тули для тестування та інші інструменти. Для цього напишіть у договорі, що виконавець та його команда розробників можуть використовувати інтелектуальну власність, на яку поширюються безкоштовні ліцензії та ліцензії на програмне забезпечення з відкритим вихідним кодом.
Неконкуренція та непереманювання: який штраф доведеться сплатити замовнику за порушення?
Щоб захистити комерційну таємницю та заборонити клієнтам переманювати співробітників та підрядників, IT-юристи додають в угоду пункти про неконкуренцію та непереманювання.
Радимо заборонити клієнтам пропонувати співробітникам IT-компанії трудові чи комерційні відносини, прямо або опосередковано переманювати працівників, підрядників, клієнтів або партнерів.
Конкретизуйте, які дії вважатимуться переманюванням. Наприклад, додайте до контракту такий опис.
Переманювання - це дії, які призвели до:
- Початку трудових, комерційних або інших ділових відносин між співробітниками, підрядниками, постачальниками або партнерами IT-компанії та замовником.
- Припинення трудових, комерційних або інших ділових відносин між IT-компанією та поточними співробітниками, підрядниками, постачальниками та партнерами.
Після того, як визначилися з заборонами, не забудьте передбачити штрафи за порушення. Наприклад, за кожен випадок порушення правил непереманювання замовник сплачує виконавцеві 15 000 доларів США компенсації за кожного члена команди.
На відміну від непереманювання, пункти про неконкуренцію частіше обмежують виконавця. Замовник прагне заборонити IT-компанії створювати, розробляти та продавати ідентичний програмний продукт. Крім цього, у договорах часто забороняють створювати, допомагати чи брати участь у створенні компанії або підприємства, які будуть вести схожий або конкуруючий бізнес, по відношенню до бізнесу замовника. Якщо темплейт договору вам надіслав замовник і ви виявили у ньому пункти про неконкуренцію, перш ніж підписувати угоду, оцініть наскільки обтяжливими та виконуваними є такі вимоги.
Конфіденційність: що зберігати в секреті?
У процесі роботи IT-компанія та клієнти обмінюються конфіденційною інформацією, розголошення якої може принести до краху бізнесу. Тому IT-юристи додають до договору положення про нерозголошення конфіденційної інформації. Завдання юристів визначити яку інформацію заборонено розголошувати та протягом якого строку. Чим конкретніший перелік об’єктів конфіденційної інформації, тим простіше довести порушення та отримати компенсацію. Строк дії обмежень радимо встановлювати 3 роки після закінчення дій договору.
Кожна IT-компанія хоче поповнювати портфоліо новими кейсами для демонстрації експертизи новим клієнтам. Щоб отримати таку можливість, напишіть у договорі, що можете робити заяви про співпрацю з клієнтом, публікувати прес-релізи, та вносити кейси до портфоліо. Якщо замовник проти, запропонуйте написати у договорі, що заздалегідь будете запитувати дозвіл клієнта на здійснення публічної заяви про співпрацю.
Обробка персональних даних: що збираємо, як обробляємо та де зберігаємо?
IT-компанія отримує доступ до інформації не тільки про замовника, але і про його співробітників та кінцевих клієнтів. До прикладу, у процесі розробки продукту у сфері FinTech, співробітники IT-компанії отримують доступ до персональної інформації клієнтів банків, інвестиційних компаній та інших представників ринку фінансових послуг. До особистих даних належать ім’я, прізвище, громадянство, індивідуальний податковий номер, банківські реквізити, сімейний стан, номери телефонів, адреса електронної пошти, місце реєстрації та адреса фактичного проживання, дані доступу та авторизації. Замовник гарантує безпеку такої інформації своїм клієнтам, а отже йому важливо бачити у договорі розділ про обробку персональних даних. Тут слід закріпити відповіді на питань:
- До яких даних IT-компанія отримує доступ?
- Для чого розробники використовують персональну інформацію?
- Де зберігаються персональні дані?
- Які заходи безпеки запроваджуються для захисту особистої інформації?
- Кому відкриваються та передаються дані?
Крім пункту про обробку персональних даних у основному контракті, замовник з Європейського Союзу може запросити підписання Data Protection agreement. Угода допомагає компаніям описати правила обробки персональних даних та відповідати вимогам GDPR, а також отримати гарантії безпеки.
Вирішення конфліктів: як діяти, якщо виник спір?
Більшість спорів у IT не доходять до суду та вирішуються за допомогою переговорів, тому у контракті важливо передбачити обов’язкову процедуру досудового врегулювання спору.
Якщо сторони не можуть досягти згоди, наступний крок — залучити медіатора для вирішення конфлікту. Не забудьте узгодити, хто оплачуватиме послуги медіатора. У контрактах для наших клієнтів ми пропонуємо оплату 50 на 50.
Якщо попередні етапи не допомогли вирішити конфлікт, спір розглядається в арбітражі або в суді. Залежно від держави реєстрації клієнта, у договорі визначають який суд або арбітраж розглядатиме спір.
Припинення договору: в якому випадку можна розірвати угоду?
Кожна зі сторін договору може припинити його дію, але важливо передбачити, за скільки днів виконавець або замовник повинні попередити один одного про це. Якщо договір буде розірвано за ініціативою замовника, він оплачує виконавцеві фактично надану частину послуг.
Договір можна припинити і шляхом укладення додаткової угоди між виконавцем та замовником. Тоді у документі вказують скоуп робіт, які необхідно виконати до завершення співпраці, та строк, протягом якого це необхідно зробити.
Електронний документообіг : як і де підписати договір та ТЗ?
Договір з клієнтом та доповнення до нього підписують в електронній формі за допомогою 3-х способів:
- Обмін скан-копіями договору. Скан має силу оригіналу до отримання паперової версії документа.
- За допомогою сервісів та простого цифрового підпису. Наприклад, через сервіс Вчасно в Україні, або американський сервіс Docusign.
- За допомогою електронного цифрового підпису, що виданий одним з акредитованих центрів сертифікації.
У договорі можна передбачити альтернативні варіанти документообігу. Для цього додайте пункт про те, що договір та доповнення до нього підписуються за допомогою сервісів цифрового підпису або електронного цифрового підпису (ЕЦП), який видано одним з акредитованих центрів сертифікації. Крім цього, сторони можуть обмінюватися скан-копіями документів. При цьому такі скан-копії вважатимуться чинними до моменту отримання підписаного оригіналу документа у письмовій формі.
Якщо ви плануєте використовувати сервіси цифрового підпису, напишіть у контракті їх назву.
Ми виділили пункти, які містяться у всіх IT-контрактах з клієнтами, але кожен тип угоди про розробку програмного забезпечення має свої особливості, які необхідно брати до уваги. Положення у Time & Material, Fixed Price або Dedicated team контрактах будуть відрізнятися. Контракт повинен враховувати бізнес-ризики кожної моделі співпраці, щоб захист інтересів був реальним, а не формальним.
