Договір на розробку програмного забезпечення

Договорів у ІТ неймовірно велика кількість, і ось лише коротенький список тих, які ми зазвичай пропонуємо своїм клієнтам:

• договір на розробку, модернізацію, дебаг, тестування ПЗ
• договір на розробку веб-сайту
• договір на розробку мобільного застосунку
• договір на розробку з застосуванням 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 (документ, що підтверджує обсяг послуг, наданих протягом однієї ітерації), вплив на вартість скорочення об’єму роботи або дострокового розірвання договору. Вартість договору, звичайно ж, може бути обмежена (так звана copped price), і договір при досягненні порогової вартості припиняється або переукладається.

      

На що ж ще треба звернути увагу?

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

«Замовник оплачує виставлений Виконавцем рахунок (інвойс) протягом ___ днів, однак у жодному разі не пізніше 180 днів з моменту виставлення рахунку. У випадку, якщо Замовник не оплачує рахунок (інвойс) протягом ___ днів, Виконавець може звернутися з позовом до господарського суду за місцезнаходженням Виконавця.»

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

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

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

                            

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

Інтелектуальна власність. Замовники схильні вимагати передавати їм права не лише на готове програмне забезпечення, а й будь-яку інформацію та матеріали і побічні продукти, що були створені для виконання договору на розробку ПЗ:

«Виключні майнові права Замовника на об’єкти інтелектуальної власності, створені в процесі виконання Виконавцем цього Договору, поширюються як на готовий об’єкт інтелектуальної власності, так і на матеріали, отримані в ході його розробки, породжувані ними аудіовізуальні відображення, незалежно від мови та форми вираження, включаючи, але не обмежуючись, вихідний текст і об’єктний код.»

Щоб захистити свої інтереси, замовник може вимагати передавати йому майнові права на розроблене ПЗ з моменту створення, як це передбачено Законом України «Про авторське право і суміжні права». Головне – не забути про авторську винагороду:

«Винагорода Виконавця за надані Послуги, в рамках цього Договору, включає авторську винагороду Виконавця за використання об’єктів інтелектуальної власності та передачу виключних майнових прав автора на них.»

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

    

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

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

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

       

Лише за умови, що всі ці елементи будуть присутні, у власника конфіденційної інформації з’явиться можливість підтвердити законність своїх вимог про відшкодування у суді. Разом з цим, якщо основною ціллю є все-таки не утримання працівника, а збереження конфіденційності, то краще надати перевагу укладенню угоди про нерозголошення (non-disclosure agreement, або NDA), щоб запобігти тлумаченню такої угоди як порушення контрагента чи працівника права на працю.

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