Нояб. 21

На що звернути увагу ІТ-спеціалісту під час підписання договору із замовником. Поради юриста

Договори без звички читати складно. Їх написано формалізованою мовою, вони довгі й часто містять фрактальні уточнення та купу посилань на інші пункти... У них легко заплутатися. Окрім того, якщо ваша робота не пов’язана з договорами, легко прогледіти щось важливе й не завжди можна тверезо оцінити, чому якісь із пунктів дійсно істотно впливають на процес роботи з контрагентом, а якісь уписано лише для залякування чи формальності. Проте в ІТ-сфері більшість роботи все-таки пов’язана з угодами, і людям з далекою від права професією часто хочеться поліпшити свої навички читати юридичні тексти й оцінювати наслідки їхніх положень. Дехто навіть пише собі шпаргалки: на що звернути увагу? Що перевірити насамперед?

Я юрист і переважно працюю з контрактами, GDPR/ССРА (тобто персональними даними) й інтелектуальною власністю. У цій статті поговоримо про укладення договорів на розробку програмного забезпечення. Ми пройдемо по ключових, типових та страшних пунктах і розберемося, що це все означатиме для розробника. Стаття буде корисна девелоперам, які укладають договори з ІТ-компаніями на постійній основі чи у проектному режимі.

FAQ

Перш ніж розпочати екскурс у договори, ми швидко пройдемося найчастішими запитаннями й дамо на них відповіді.

Чому одні договори двомовні, а інші одномовні?

Тому що під час укладання договорів у межах України (наприклад, якщо замовник і виконавець — українські компанії, ФОПи чи громадяни) договори все-таки ліпше укладати українською. Тоді не буде складнощів у роботі з державними органами чи банками, які надають перевагу державній мові й під час проведення платежів за договором регіональною мовою можуть вимагати (завірений) переклад.

Якщо одна зі сторін іноземна (тобто договір укладено між, наприклад, українським ФОПом та американською компанією), то звичною діловою практикою стало вкладання двомовного договору (зазвичай українсько- й англомовною версією): так державні органи й банки відразу матимуть погоджений переклад українською мовою. Багато банків також приймають російськомовні тексти, але, щоб запобігти затримкам, найбезпечнішим буде вписати паралельний український переклад.

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

Чим надання послуг відрізняється від виконання робіт?

Послуга, у більшості випадків, споживається у процесі її надання. Наприклад, консультування — це послуга, бо інформацію надають у процесі виконання договору.

Але робота має певний утілений у матерії результат: якщо підрядник має виконати якісь дії для створення об’єкта, і замовник потім має результат роботи оглянути й прийняти, то в більшості випадків це вважатимуть роботою.

Що дійсно важливо знати, так це те, що акти після виконання договору ліпше підписувати як під час надання послуг, так і під час виконання робіт.

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

Яким завтовшки має бути договір за стандартом?

ДСТУ щодо кількості сторінок у договорах немає. Вони можуть бути великі й докладні, а можуть бути стислі та небагатослівні: усе визначають природа послуг чи робіт і роль кожної сторони. Однак договір — це правила гри: що докладніша інструкція, то менше запитань у процесі співпраці щодо невиправданих сподівань.

Вимог щодо розміру шрифту немає. Тут скоріше діє логіка: кожен пункт в договорі має бути читабельним з точки зору розміру шрифту.

Яка різниця між ФОПом і працівником? Чи є ці слова синонімами?

Ні. Працівників захищають права (і вони несуть обов’язки) не лише відповідно до трудового договору або контракту, а й згідно з трудовим законодавством (славнозвісним КЗпП). Вони мають право на відпустки, лікарняні й оплату за роботу понад установлений робочий день чи у вихідні та святкові дні.

Абсолютна більшість ІТ-індустрії в Україні пропонує розробникам надавати послуги через формат співпраці з ФОП. ФОП — суб’єкт господарювання, що укладає господарський договір, і тому в такому договорі можна писати все, що можна писати в межах свободи договору, і такі пункти будуть діяти. Наприклад, досить проблемним є одностороннє розірвання договору з боку розробника, якщо це прямо заборонено договором, і за це є штраф.

Фізичні особи-підприємці — такі самі підрядники, якими можуть бути й, скажімо, компанії. ФОП, за рідкісними винятками, сам установлює, працювати йому у вихідний день чи ні, й отримує винагороду не за факт установлення відносин із замовником і виконання поточних робочих завдань, а за надані конкретні послуги чи виконані роботи. Окрім того, компанії робота з підрядниками часто вигідніша, аніж із працівниками, але сильне захоплення підрядами й ставлення до своїх ФОПів уже як до своїх працівників можуть стати прикрим відкриттям для податківців і Держпраці.

У нормі ФОП сплачує єдиний податок у 5% (або ж 3% + ще ПДВ). У багатьох ІТ-компаніях, що наймають працівників, із зарплати зі свого боку утримують ПДФО (18%) і військовий збір (1,5%). Водночас не зникає потреба платити ЄСВ: у ФОПа він не має бути меншим за 22% від мінімальної заробітної плати, а під час працевлаштування компанія нараховуватиме ЄСВ на заробітну плату працівника.

Але вигідним може бути не лише оподаткування: у випадку з договорами на розробку й авторськими договорами отримувач послуг має зручніший інструмент впливу на підрядників, ніж на працівників за трудовими: наприклад, може розірвати договір з підрядником у найкоротші строки з мінімальними формальностями (звісно, якщо це прописано в договорі) чи навіть притягти його до відповідальності за неотриманий прибуток (якщо зможе довести в суді причинно-наслідковий зв’язок між поведінкою підрядника та неотриманим прибутком і надати переконливі аргументи щодо існування таких можливостей та завданих компанії збитків). Інакше кажучи, за наявності по суті умов відносин працевлаштування той, хто бажає отримати певні послуги, може перебувати в привілейованому становищі з погляду законодавства про працю. Тому держава намагається відстежувати приховані трудові відносини.

Якщо в мене договір з іноземною компанією, то закони якої країни застосовуються?

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

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

Ілюстрації: Каталіна Маєвська

Non-disclosure

Страшно, коли тебе зв’язує NDA: ніколи не знаєш, як багато можеш розповісти друзям у барі після важкого тижня. Запитання «Як справи? Що на роботі?» й сухе «NDA» у відповідь можуть згубити чудову дружбу! (А скільки ж запитань чують юристи, коли ввечері святкують у барі прийнятий другом офер!)

Випереджаю запитання: так, NDA дійсно в окремих випадках загрожують неприємностями. Однак не слід плутати Non-disclosure agreement (NDA) з Non-compete agreement (NCA). У наступному пункті ми зупинимося на цьому докладніше, але поки що:

NDA = NCA

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

У договорі про конфіденційність одна сторона (зазвичай замовник, або конфідент, Discloser, Disclosing Party) розкриває, а інша (виконавець, конфіденціал, Recipient, Receiving Party) дістає доступ до певної інформації й зобов’язується не розголошувати та не використовувати її поза межами виконання договору з першою стороною.

NDA можуть слугувати і як засіб залякування, і як ефективний інструмент: саме тому до них таке змішане ставлення. Однак якщо залишити етичну сторону й говорити про перспективи потрапити до суду за порушення конфіденційності, то тут приходить і велика відповідальність: щоб розраховувати на шанс дійсно захиститися з допомогою NDA в суді, замовникові послуг доведеться пропрацювати текстову та організаційну частини, тобто уважно підійти до (1) складання самого тексту NDA (до самих формулювань), і (2) комплексного використання NDA.

Текстова частина: NDA потребує обережного формулювання. Ліпше ні угоду, ні пункт контракту не брати з Інтернету чи іншого договору. Поганою ідеєю є також скористатися автоматичним перекладом іншого (хай навіть англомовного та підготованого найліпшими британськими юристами) договору. NDA — річ тонка, і в хорошому пункті чітко зазначать, зокрема:

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

Водночас усі ці деталі припасують до конкретної домовленості. Наприклад, у сейлза й розробника буде доступ до різної інформації: оскільки конфіденційності зазвичай найліпше відповідає принцип need-to-know як передумова доступу до інформації, то для різних ролей підрядників і посад працівників ліпше скласти окремі редакції NDA (і вносити туди лише ті види інформації, способи захисту та санкції, які відповідають конкретним завданням підрядника або посадовій інструкції працівника).

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

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

Однак на практиці NDA можуть принести несподівані радощі ні в чому не винному підрядникові чи працівникові. У ситуації, якщо, скажімо, дизайнер підпише договір, який підпорядковано праву США, то саме замовник буде зобов’язаний доводити витік даних і зв’язок між злитими в канали Telegram скринами редизайну гри й виною саме цього українського дизайнера. Схожі моменти існують і з працевлаштуванням: хоча в багатьох юрисдикціях підписання NDA є нормальною практикою (у тих самих Штатах), в Україні спробу роботодавця через суд виконати положення договору про конфіденційність можуть сприймати як порушення КЗпП (стаття 9 якого забороняє вкладати з працівниками договори, умови яких погіршують становище працівників, як порівняти із чинним законодавством), і суди переважно відмовляються визнавати такі NDA дійсними.

Ще один плюс роботи з підрядниками в такому разі: до працівників не можна застосувати відповідальність, яку передбачає стаття 24 Закону України «Про захист від недобросовісної конкуренції»: цей закон поширюється тільки на суб’єктів господарювання (зокрема компанії й ФОПів). Тобто в разі, якщо конфіденційність порушив працівник, то позов можна засновувати на загальних засадах, передбачених Цивільним кодексом, але не Господарським кодексом чи законодавством про захист конкуренції.

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

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

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

Попри це, ліпше відразу оцінити свої шанси поповнити вітчизняну судову практику власним прикладом, перш ніж (1) підписувати NDA і (2) розголошувати конфіденційну інформацію. З питаннями збереження конфіденційності також інколи пов’язують захист ділової репутації, і часто репутація може бути куди ціннішим ресурсом для потенційного відповідача, аніж прибуток від частково проданої клієнтської бази попереднього замовника послуг.

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

Non-compete/Non-solicit

Non-compete (NCA), або договір про неконкуренцію, частіше вживають для опису домовленості між замовником і працівником/підрядником про те, що колишній працівник або підрядник не конкуруватиме зі своїм замовником або роботодавцем, зокрема в тій самій сфері або на тій самій території, протягом певного часу — кількох місяців або навіть років. Non-solicitatiton (NSA) зі свого боку стосується й (не)переманювання працівників і підрядників одна в одної, і заборони впливати на клієнтів іншої компанії з умовляннями відмовитися від послуг конкурента. Обидві використовують зазвичай для досягнення таких цілей:

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

Тут усе просто: суди в Україні тепер не визнають ніяких NCA чи NSA, які вклали відповідно до українського законодавства. То чи можна підписувати їх без жодної задньої думки? Спойлер: ліпше не треба.

Традиційно українські суди вважають NCA й NSA формою обмеження права на працю, яке гарантує Конституція, і погіршенням становища працівника, що забороняє КЗпП. Однак у разі, якщо NCA або NSA укладено відповідно до іноземного закону, то вони можуть бути дійсними, оскільки є легальними і їх застосовують у правовій системі, праву якої належить цей договір. Наприклад, французькі працівники будуть зв’язаними NSA/NCA, якщо їх передбачено в колективній угоді.

Заразом не слід скидати з терезів також інші особливості:

Територію, на яку поширено вимогу неконкуренції (перевага надається території населеного пункту або його частини, але водночас не слід плутати договір про неконкуренцію з дистриб’юторськими договорами, які теж часто містять обмеження території).
Період часу, протягом якого слід утримуватися від конкуренції або переманювання (американські суди в низці штатів зазвичай допускають період від кількох місяців до року або двох, водночас наполягаючи на додаткових обмеженнях заборони).
Оплата або відшкодування наданих послуг чи виконаних робіт, які отримував підрядник або працівник за час співпраці (деякі юрисдикції у Європі й Штатах мають нижню межу оплати праці або послуг: якщо заробітна плата або сукупний дохід були меншими за цей поріг, то вкладати з нею NCA/NSA законодавство або судова практика не заохочують).
Право ініціювати розрив угоди про неконкуренцію або непереманювання.
Право перевідступу договору про NCA (оскільки продавець, наприклад, не може перевідступати право покупцю компанії, якщо працівник не надав на це окремої згоди) тощо.

Тому ліпше ознайомитися з текстом. А якщо договір іноземний, пошукати інформацію про стан судової практики у відповідній державі.

Оплата

У працівників зарплата щомісяця (зазвичай), а в підрядника може бути по-різному. Зазвичай форми оплат діляться на категорії time-and-material, fixed price та екзотичні форми.

За умови оплати time-and-material підрядник (сейлз, дизайнер, розробник, тестер тощо) отримує оплату не як фіксовану щомісячну суму, а за результатами наданих послуг. Наприклад, її можна вимірювати в ефективних годинах: якщо на новий дизайн або цикл тестування підрядник витратив у сумі орієнтовно двісті годин, то йому оплатять кількість цих годин (помножену на погодинну ставку). Тобто оплачують не вартість проекту, а певну кількість витраченого на надання послуг часу (а також витрати на купівлю матеріалів: програмного забезпечення й техніки, послуги хмарного зберігання тощо). Їх можна розбивати на оплату кількості годин, які витратили за певний період. Водночас слід уважно відстежувати, чи несе відповідальність, наприклад, компанія-аутстафер за результати послуг, чи ж просто надає послугу: години послуг своїх працівників або підрядників. Тоді як для підрядника-аутстафера важливо з’ясувати:

чи оплачуватимуть йому простій (бенч), у якому розмірі й хто — компанія-аустафер чи замовник;
чи діє на нього умова про buyout (так званий викуп), якщо підрядник захоче працювати не з компанією-аутстафером, а з клієнтом напряму (buyout також зацікавить, наприклад, сейлзів з уже напрацьованою базою: він дасть можливість залишити свої контакти й перейти з ними до іншої компанії, продовжуючи співпрацю без порушення договорів про неконкуренцію, непереманювання або конфіденційність);
які потрібні знання, досвід, кваліфікація й рівень володіння фреймворками (оскільки до них часто прив’язують гарантії щодо якості фінального продукту: такий підхід поширений, наприклад, у Штатах, де від розробника, системного адміністратора або тестувальника конкретного рівня залежать сподівання щодо результату наданих ним послуг або реальність виконання ним implied warranties компанії щодо фінального продукту);
кому належать розроблені права інтелектуальної власності (програми, винаходи тощо) і якої миті ці права переходять до замовника — відразу після створення (що вигідно замовникові) чи оплати (що вигідно підрядникові).

Інша умова — fixed price: увесь проект оцінюють у єдину суму, водночас оплату здійснюють не за кількість залучених спеціалістів або витрачених на роботу годин, а за виконання конкретного завдання й передавання результатів замовникові. Зазвичай у такому разі підрядник несе відповідальність не за кількість витраченого часу (окрім, звісно, дедлайну проекту), а за кінцевий результат послуг (щоб він відповідав наданому замовником ТЗ).

Водночас найбільше суперечок під час обговорення умов співпраці зазвичай виникає через:

дедлайни (звісно ж);
оплату частинами (milestone schedule — попри те, що фінальну вартість уже узгоджено, сторони поділяють її на кілька платежів, які прив’язано до часових інтервалів або інтервалів передавання замовникові вже готових результатів);
передавання інтелектуальної власності (як і в попередньому абзаці);
додаткові послуги й прив’язку до ТЗ (оскільки зазвичай завдання, як-от кількість user stories абощо, узгоджують у повному переліку й оцінюють у певний кост;
якщо в процесі треба додати нові послуги або прибрати частину з них, сторони можуть домовлятися про переоцінку проекту з огляду на те, що його вартість падає або зростає);
порядок прийняття-передання результатів робіт і послуг.

Однак є й інші способи. Є абонентські тарифи (коли передбачено стандартне навантаження за певну вартість, і платежі за такої умови є щомісячними, щоквартальними тощо) і капи (тобто як буде досягнуто певну вартість або кількість годин, сторони можуть укласти новий договір, просто передати вже розроблені до цієї миті об’єкти й розійтися або узгодити інші умови чи встановити новий ліміт годин). Можна використовувати будь-яку систему оплати послуг, головне переконатися, що вона охоплює передавання об’єктів інтелектуальної власності (а якщо ні, то скільки підрядник або працівник отримуватимуть додатково за кожну програму, малюнок чи модуль?).

Права інтелектуальної власності

Пул запитань виникає відразу:

Кому належать права інтелектуальної власності (авторові, замовникові, роботодавцеві, клієнтові чи всім порівну?)

Це питання ліпше прописувати в договорі чітко: автор може опинитися в незручній ситуації, коли він як підрядник створить у вільний час на бенчі програму, а потім виявиться, що оскільки він використовував обладнання замовника, то останньому й належать усі майнові права на цей твір. Або ж навпаки: замовник вважатиме, що йому перейшли всі права на створений бренд-бук, а насправді підрядник-дизайнер не прописав чітко цей пункт і права їм належать у рівних частинах (50 на 50%). Якщо ж цей малюнок, програму чи інший матеріал створив працівник у межах службових обов’язків, то ці результати, найімовірніше, належатимуть роботодавцеві.

Що передають у межах цього договору?

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

Ці об’єкти оплачують окремо чи разом з іншими послугами?

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

Чи можу я потім використовувати шматочки коду або намальовані бренд-буки для свого портфоліо?

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

Якщо договір описано з урахуванням усіх тонкощів, то сторона, що складала договір, може мати перевагу в суді: просто тому, що договори складають з метою якщо не уникнути судового розгляду, то принаймні зробити його мінімально витратним і складним для сторони, що складала договір. І якщо підрядник або працівник не намагатиметься зменшити кількість зв’язків між розробленим ним сайд-продуктом і його замовником чи одним із замовників (через використання власної техніки й особистих облікових записів у SaaS-софті, у час, вільний від надання послуг, без оплати замовником витратних матеріалів чи потрібних даних та без використання інтелектуальної власності замовника), то цілком імовірно, що в разі успіху йому доведеться позмагатися в суді з озброєним логами, чеками й виписками колишнім замовником.

Дедлайни і строк надання послуг

Цілком логічно боятися ексклюзивності: може статися, що замовник наполягатиме, щоб ви відмовилися працювати з його прямими конкурентами або займатися іншими проектами під час дії договору. Це може бути обмеженням свободи торгівлі й практикою порушення конкуренції, але завжди є ризик того, що договір підлягатиме правопорядку, де таке обмеження є цілком законним.

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

Ліпше передбачити ці ризики й залишити собі можливість відкласти дедлайн.

Порядок розірвання договору

Зауважте, що безстрокові договори з іноземними партнерами викликають (часто обґрунтовану, з огляду на досвід) підозру вітчизняних податківців і банків. Тому виникає потреба встановити ліміт часу надання послуг: наприклад, стандартом часто встановлюють рік і пролонгацію (продовження договору) за умови виконання певних формальних умов. Інший спосіб — укладати генеральний рамковий договір і погоджувати його продовження додатковими угодами до нього (які, наприклад, фіксують конкретний проект і склад команди).

Інколи життєво важливо прописати порядок виходу з договору:

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

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

Продуктивність

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

Також ліпше чітко передбачити відповідальність, скажімо, хто має надавати ідеї: замовник (а підрядник — шляхи реалізації) чи підрядник? Чи повинен потім підрядник створювати прототипи, чи відразу готовий об’єкт? Як довго може тривати погодження ідеї в компанії замовника (і хто з його боку відповідає за погодження результатів послуг)? До якого етапу реалізації замовник може вносити чи пропонувати зміни?

А головне: хто оплачує брак креативності чи спад продуктивності? Що робити, якщо агентство створило прототипи чітко за ТЗ замовника, але не отримало обґрунтованої відмови: покинути неуспішний проект, надати інвойс за фактично надані послуги й сконцентруватися на пошуку нових замовлень чи працювати на гонорар успіху без сподівань будь-коли відшкодувати хоча б витрачений час і матеріали? А що як перспективний замовник узяв розроблену схему чи архітектуру проекту й замовив реалізацію іншим підрядникам?

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

На десерт: відповідальність

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

Головне не панікувати і вчасно оцінити свої можливості. І звісно, внести правки в люб’язно наданий замовником договір.

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

Інколи для справедливого розподілу оплати й відповідальності використовують систему авансу та розрахунку: попередній платіж може слугувати водночас і як частина оплати, і як відповідальність підрядника в разі його нездатності виконати договір незалежно від причин.

По-друге, не беріть на себе відверто несправедливий обов’язок компенсувати чужі помилки: якщо потім інші програмісти змінюватимуть частину розроблених об’єктів або інхауз-маркетологи підтримуватимуть чи переналаштовуватимуть маркетингові кампанії, то ліпше відразу обговорити відмову від відповідальності в разі, якщо вони припинять діяти або порушуватимуть права й інтереси (чи законодавство загалом) іншої країни. Кому хочеться нести відповідальність за рекламу (чи пропагування) алкоголю й контенту для дорослих у країнах, де вони під забороною, оскільки внаслідок цього підготований для реалізації на цій території тираж ігор залишився незапитаним або його конфіскували на митниці?

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

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

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

Підсумки

Однак це не применшує важливість і тих положень, про які ми говорили раніше. Отже, чеклистом на сьогодні може бути:

Переконатися, чи впливають NDA й NCA на можливість приймати інші, потенційно цікавіші офери та замовлення.
Передбачити, яку частину оплати й до якої дати слід чекати та чим погрожує затримка оплати послуг чи праці.
Подбати про свою інтелектуальну власність: робити пет-проекти на власній техніці, поза офісом роботодавця або замовника й у позаробочий час.
Скласти собі графік дедлайнів і підготувати шлях виходу з договору, що став забирати забагато часу.
Пам’ятати, що кожен запис у логах і кожна авторизація може бути чудовим аргументом замовника/роботодавця проти вас у суді.

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