Ми в IPStyle майже впевнені, що у вашого бізнесу вже є розроблений на замовлення веб-сайт, чи навіть бот на основі штучного інтелекту або власний додаток.
Сьогодні діджиталізація бізнесу, незалежно від галузі, має значний вплив на його успіх і може стати вирішальним фактором для максимізації прибутку. Однак для досягнення цього недостатньо лише замовити розробку софту. Оскільки будь-який програмний продукт та/чи його частини є об’єктами права інтелектуальної власності, критично важливо вчасно подбати про правову сторону процесу розробки.
Нижче ми розкажемо про те, як правильно побудувати та оформити відносини між замовником та розробником для успішного запуску вашого діджитального продукту.
Відносини “замовник” – ”розробник”
Відносини між замовником та розробником зазвичай базуються на договорі про виконання робіт чи надання послуг із розроблення програмного забезпечення або ж на договорі щодо консультування у сфері інформатизації.
При цьому, розробником може бути:
а) компанія, яка наймає фізичних осіб-підприємців (ФОП) для виконання ваших робіт, і по суті виступає для ФОПів замовником;
б) компанія, яка використовує найманих працівників у своєму штаті;
в) безпосередньо ФОП.
Сьогодні ми розглянемо основні аспекти, на які потрібно звертати увагу при укладенні договорів між замовником та розробником-ФОП. А на відносинах між замовником та компанією, яка використовує найманих працівників, ми зупинимося у наших наступних матеріалах.
І. Способи організації роботи за договором
Є два варіанти роботи за договорами між замовником та розробником — waterfall та agile.
Waterfall — це лінійний процес організації робіт за договором. Він полягає у наявності закріпленої договором чіткої послідовності етапів та вимог до них, строків виконання кожного етапу та їх перевірки.
Позитивною стороною waterfall є можливість чітко передбачити ключові питання, встановити вимоги до кожного з етапів, що означає наявність у замовника повного розуміння того, що і на якому етапі він очікує від розробника. Водночас негативною стороною waterfall є неможливість внести суттєві зміни до вже розробленого софту згідно встановлених етапів. Проблеми із софтом можуть не виникнути при його прийнятті згідно етапу, а проявитися пізніше.
Модель waterfall не підходить замовникам, які на момент підписання договору до кінця не розуміють свій кінцевий продукт і не можуть сформувати чіткі вимоги до нього, розрахувати наявний бюджет чи строки виконання.
Agile — це менш суворий за waterfall процес організації робіт за договором. Він не вимагає від замовника чітко передбачати етапи розробки софту і вимоги до них, а дозволяє лише окреслити загальну сферу та мету взаємодії. Agile передбачає наявність маленьких проміжних етапів і постійну взаємодію сторін. Це означає, що після виконання однієї задачі, розробник погоджує її результати із замовником та погоджує наступний проміжний етап.
Agile — це про постійний взаємозв’язок замовника та розробника і постійне погодження між ними проміжних етапів для створення кінцевого продукту. Розробник має певну свободу за таким договором та може ґрунтовніше зрозуміти бажання замовника, а інколи допомогти йому сформувати їх. Замовник так само може визначати більш пріоритетні напрямки розробки, сфери, які потребують покращення тощо.
Суттєвим плюсом agile є можливість швидко та ефективно реагувати на необхідність внесення будь-яких змін (у софті, у задачах замовника тощо). Проте це означає, що складно наперед визначити бюджет розробки, а процес погодження між розробником та замовником може займати багато часу, призводити до конфліктів через відсутность чітких етапів та вимог.
Вибір між waterfall чи agile буде залежати від конкретних потреб замовника і можливостей розробника. У договорі на розробку софту повинні бути всі істотні умови, чітко виражено модель організації роботи і взаємодії між замовником та клієнтом, їх права та обов’язки. Оскільки недотримання може призвести до затягування розробки, конфліктів, а інколи і судових спорів.
ІІ. Предмет
Предмет — це основа будь-якого договору.
Замовнику та розробнику потрібно погодити, чи предметом будуть роботи, послуги, чи буде розробка пов’язана із простим створенням і переданням результатів, чи, можливо, вимагатиме тестування, технічної підтримки уже після передачі.
ІІІ. Комунікації
Яким чином сторони між собою взаємодіють та які засоби для цього використовують, на перший погляд, є не таким важливим та істотним елементом договору. Проте від його включення у договір інколи залежать важливі результати, особливо при обранні моделі agile.
Типова ситуація, коли замовник виплачує розробнику передплату, а пізніше через незадовільне виконання хоче ці кошти повернути. Він не може цього зробити, оскільки договором та додатковою угодою не було чітко визначено модель організації роботи, встановлено вимоги для розробника, що ускладнює доведення неналежного виконання.
У таких ситуаціях як доказ часто можна використати листування електронною поштою, месенджерами між сторонами. Суди по різному оцінюють такі докази, а тому необхідно в самому договорі передбачати можливість взаємодії між замовником та розробником в електронному форматі.
Також сторонами можуть використовуватись різноманітні програми для управління процесом розробки софту, як то Jira, Trello, Slack, GitLab, про що теж потрібно згадувати у договорі із посиланням на ідентифікаційні дані сторін (ім’я користувача, електронна пошта, номер телефону тощо).
Таким чином, навіть якщо замовник обрав модель agile, він завжди зможе довести причинно-наслідковий зв’язок між договором та листуванням із розробником і відповідно неналежність робіт. Розробник навпаки зможе показати, що софт розроблено відповідно до вказівок замовника.
ІV. Оплата винагороди розробника
Якщо при виборі waterfall очевидною є можливість зафіксувати у договорі ціну за весь проект (підхід fixed bid), то при agile доцільним є оплата за витрачені години роботи розробника (підхід time & materials).
Проте сторони можуть встановити й інший формат оплати, наприклад, за кожен окремий етап чи окрему частину програми, що розробляється, встановити додаткові бонуси за виконання робіт раніше визначеного терміну. Також сторони можуть погодити наявність попередньої оплати у формі авансу.
V. Інтелектуальна власність
Софт може виступати об’єктом авторського права, а тому у договорі необхідно передбачити положення щодо переходу усіх прав на софт від розробника до замовника, щоб останній міг фактично його використовувати. При цьому доцільним буде підписання щодо кожної окремої чи самостійної частини коду відповідного акту приймання-передачі. Способи передачі коду також можуть різнитися: це може бути завантаження коду на GitHub чи використання електронної пошти.
Для додаткової охорони прав замовника можна отримати реєстрацію авторського права. Така реєстрація здійснюється на підставі договору про відчуження прав. Тож додатково до договору підряду чи надання послуг, за яким зазвичай працює ФОП, потрібно укласти договір щодо передачі авторських прав.
VІ. Конфіденційність
У більшості випадків на вимогу замовника розробник підписує окрему угоду про нерозголошення отриманої конфіденційної інформації. Часто такі угоди передбачають види інформації, або носіїв, які передаються та належать замовнику, але відносяться до конфіденційної інформації.
Розробник при підписанні угод повинен детально аналізувати кожне положення, кожен вид інформації, щоб така угода пізніше не обмежила можливість його діяльності як фахівця. Замовник же навпаки — повинен якнайбільш конкретно та неабстрактно визначити перелік інформації, яка є конфіденційною, а також визначити розміри штрафів за порушення.
Висновок
Відносини між розробником та замовником можна будувати за різними моделями, які будуть залежати від мети замовника та можливостей розробника. Основою таких відносин буде виступати договір, який повинен детально відображати те, щодо чого сторони дійшли згоди, описувати увесь процес організації робіт, права та обов’язки, момент передачі прав та відповідальність.
Якщо ви замовник софту, який все ще не визначився зі способом ефективної побудови роботи із розробником, або розробник, який отримав договір з незрозумілими для себе умовами, ви завжди можете звернутися до IPStyle і ми вам допоможемо. Ми проаналізуємо відносини “замовник” – ”розробник”, підберемо оптимальне рішення для вашої ситуації та подбаємо про те, щоб ваша інтелектуальна власність працювала на максимізацію прибутку.
***
У наступній статті ми розповімо про правильне оформлення відносин “інвестор” – ”розробник”: коли інвестор вкладає свої ресурси у софт розробника для повернення коштів із процентом або ж для отримання частини бізнесу розробника, що заснований на такому софті. Stay tuned!