5 підступних моментів у договорах на аутсорс-розробку

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

Чого прагне замовник?​

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

Як це виглядає у договорі?​

Почитавши наданий замовником договір, ви, звісно, мумію XVIII ст. до н.е. не оживите, але знайти там дещо цікаве, швидше всього, зможете. Які варіанти? Ми підготували декілька прикладів, що будуть корисними як компаніям, так і вільним птахам-фрілансерам.​

1. Все, що ти зробив, – не ти зробив.

Ви можете думати, що ви – хазяїн результатів своєї праці, свого дому і життя взагалі, але відповідно до умов договору, можете десь помилятись. Наприклад, за договором, права інтелектуальної власності на результати послуг з моменту їх створення можуть належати замовнику. Тобто, вже перші недбало накинуті вами символи коду одразу переходять у власність замовника, незалежно від того, заплатив він вам за це, чи ні. Думаєте, – це підступне ошуканство? Називайте, як вам зручно, але «що написано пером, і сокирою не вирубаєш» (читати: «що узгоджено через електронну пошту, того і #Петьою не знищиш»).​

Що з цим робити? – прописувати у договорі, що права інтелектуальної власності на результати послуг переходять до замовника, лише після повної оплати вашої роботи.​

 2. Послуги Шредінгера, які в мішку

Так іноді трапляється, що ваша компанія-замовник із США і сама аутсорсить на яку-небудь компанію із Гонконгу. Додатково, може виявитись, що всі вони працюють в одному коворкінгу по сусідству із вашим бізнес-центром на Дунаєвській 1. Якби воно не було, а кінцевий замовник за договором може мати право будь-коли змінювати свої погляди на проект. При цьому, усі такі зміни у його світогляді автоматично набирають юридичної сили і для вас. Таку методологію організації процесів можна було б назвати “extreme agile”, якщо б біда була не в тому, що ви підписували договір на waterfall-розробку (про різницю між такими договорами можна почитати тут). За таких умов, клієнт у будь-яку мить може відмовитись від попередніх завдань, або ж вигадати супер-функцію, яку потрібно додати на сайт вже вчора. І найбільша проблема у тому, що договір не визначає, яким чином це впливає на суму вашої винагороди.​

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

5 підступних моментів у договорах на аутсорс-розробку

 3. Принеси зуб дракона опівночі до гори Безсмертя – і я оплачу надані послуги.​

Ви з боєм вихопили клієнта у конкурентів, після довгих перемовин підписали договір, узгодили  список розробників, прирекли цю команду на місяць без сну, всі разом невпинно і наполегливо працювали та врешті-решт завантажили супердодаток на Play Store. Думаєте, що пройти такий тернистий шлях, – це достатньо, щоб отримати заслужену винагороду? Не поспішайте кидатись у радісний танець, можливо, ще рано відкорковувати шампанське. Від чого може залежати те, чи заплатять вам? Та від чого завгодно. Наприклад, від того, чи заплатив клієнт вашому замовнику. Або ж, чи встигли ви подати інформацію про кількість витрачених на проект годин. У вас може бути обов’язок подавати таку інформацію кожного понеділка до 10 ранку за Центральним часом. Якщо ви не зробите цього, то компанія матимете право вам не заплатити. Це ніби і нескладний фокус, але ж дедлайн – птаха привередлива, всяке у житті буває. Тож і погоджуватись на такі умови вам точно не радимо.

Що з цим робити? – ваш ідеальний варіант – це, коли оплата залежить лише від того, чи якісно ви надали послуги. Саме це і потрібно прописувати у договорі. І добре почитайте, чи не потрібно вам додатково виконати якісь абри-кадабри, аби отримати свої зароблені потом і кров’ю.​

 4. Доведи свою відданість Короні

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

Що з цим робити? – залиште у договорі лише те, що ви можете і готові надати, чи показати. Жодним аудитом більше. Все тільки під грифом «таємно».​

 5. Не пожадай розробника ближнього свого (із десяти заповідей ІТ компаніям).​

Кожна компанія турбується про своїх цінних кадрів, і замовник обов’язково напише, що у вас немає права переманювати до себе його працівників. Можливо, вам ці американські програмісти і не по кишені навіть, а от чи написано щось у договорі про ваших «безцінних ФОПів» – вам обов’язково потрібно перевірити. Адже іноді замовнику набагато вигідніше працювати напряму із вашими програмістами. До того ж, на нього не поширюються умови про непереманювання.​

Що з цим робити? – обов’язково дописати, що замовник також зобов’язується не заманювати пряниками ваших програмістів до співпраці із ним без вашої участі. Бережіть свою команду. Любіть їх. Турбуйтесь про них.​

Короткий висновок:​

Мудрі латиняни казали: «Pacta sunt servanda», що у перекладі на живу мову означає «Договори слід виконувати». Ми ж маємо лише маленьке доповнення: «Договори також слід читати. І редагувати за потреби 😉 ».

    Твоє запитання ІТ юристам


    Отримуй сповіщення про нові статті :)