Розробка програмного забезпечення — ключовий напрямок в IT-індустрії, який одночасно є і її основою, адже уявити інформаційні технології без девелопменту важко та чи й можливо взагалі? При цьому, створенням програм зазвичай займаються нішеві IT-компанії на запит клієнтів під конкретні задачі з певним бюджетом, вимогами тощо, тож йдеться про необхідність укладення контракту на таку співпрацю сторін.
Як і сама сфера інформаційних технологій, договірні відносини в ній також модифікуються та підлаштовуються під нові реалії. Станом на зараз типовий договір на розробку програмного забезпечення, з одного боку, вже набув низку “класичних” елементів, а з іншого — постійно змінюється в інших частинах. Тож пропонуємо розглянути актуальні положення, які станом на 2025 рік часто включають до цього виду договорів.
Задля встановлення продуктивних зв’язків між замовником ПЗ та розробником, така взаємодія оформлюється окремим письмовим договором між сторонами — договором на розробку програмного забезпечення, який в українській традиції часто іменується договором про надання послуг з розробки ПЗ, англійською - Software Development Agreement (SDA). Цей документ покликаний чітко врегулювати низку ключових питань.
Зазвичай на практиці, незалежно від трендів, у договорі на розробку сторони погоджують наступні умови:
Звертаємо увагу, що у більшості юрисдикцій, включаючи Україну, передача майнових прав інтелектуальної власності можлива лише за письмовим договором між сторонами, а отже договір на розробку програмного забезпечення, частиною якого є, як правило, і розділ про передачу IP прав, укладається в письмовій формі.
Класична каскадна модель розробки ПЗ (waterfall), за якою співпраця за договором на розробку відбувається за чітко та детально описаним технічним завданням, часто з фіксованим бюджетом та “жорсткими” строками поступово втрачає свою актуальність. Це можна пояснити тим, що клієнти часто вже самі розуміються на софті, мають змогу більш активно формулювати вимоги та змінювати своє бачення. Водночас девелопери зі своєї сторони готові більш активно взаємодіяти із замовниками в процесі розробки, підлаштовуватися під зміни та корегувати хід розробки “на ходу”.
Тож, на зараз на заміну Waterfall поступово приходить модель Agile (від англ. - гнучкий, рухливий). Вона передбачає поділ процесу розробки ПЗ на певні стадії (ітерації, sprints), у межах яких сторони можуть відходити від старих та погоджувати нові деталі співпраці. Таким чином процес розробки гнучко регулюється при цьому без необхідності внесення змін до підписаного договору чи технічних завдань до нього.
Перш за все “гнучкий” Software Development Agreement являє собою контракт на розробку, в якому прямо встановлюється поетапність та враховано можливість постійних змін до технічного завдання. Співпраця зазвичай ділиться на спринти, кожен з яких складає фіксований період, зазвичай до місяця. При старті кожної послідовної ітерації замовник та розробник погоджують завдання на такий етап та вартість послуг. Таким чином сторони мають змогу постійно корегувати хід співпраці без необхідності внесення змін через додаткову угоду чи перепідписання цілого контракту на нових умовах.
Описане вище стає можливим завдяки включенню до SDA положень про засоби комунікації між сторонами, зазвичай електронних: email, таск-менеджери, месенджери тощо. А що у ваших договорах на розробку передбачено з цього приводу? Якщо це досі виключно письмові листи, то радимо задуматися над додаванням можливості спілкування та погодження певних умов з використанням месенджера, що є більш зручним та швидким способом.
Одночасно з цим, до положень, що можуть корегуватися сторонами у форматі комунікації, додаються примітки, як то “якщо інше не погоджено сторонами з використанням встановлених засобів комунікації” або “у порядку, що визначається сторонами з використанням встановлених засобів комунікації” тощо. При цьому важливо чітко визначити, які саме аспекти можуть таким чином погоджуватися, а які тільки через внесення змін до договору, інакше може виникнути спірна ситуація. Рекомендовано також чітко фіксувати перелік електронних засобів та ідентифікатори сторін, що будуть використовуватися для цілей договору.
Фінансові умови також не передбачають жорсткої фіксації, сума до оплати може визначатися окремо для кожного етапу на підставі, наприклад, погодинної вартості послуг розробника. Звісно, необхідно також чітко прописати порядок відстежування, погодження та звітності щодо витраченого часу. А для того, щоб замовник міг спати спокійно, сторони можуть встановити ліміт загальної вартості послуг чи кількості витрачених годин, перевищення якого можливо лише за окремою письмовою згодою.
Отже, трендом 2025 року для договору на розробку ПЗ є загальне прагнення сторін відійди від жорстких фіксацій технічних завдань та інших основних умов. Натомість замовник та розробник прагнуть до співпраці, що заснована на гнучкості та взаємодії з можливістю модифікувати та корегувати роботу в процесі.
Фактично сучасний SDA на практиці є рамковим договором щодо поетапної розробки, технічне завдання та зміни до якого фіксуються в письмовій комунікації сторін. Складення якісного Software Development Agreement за такою моделлю — непросте завдання для юриста, адже вимагається знання тонкощів та вміння знаходження правильного балансу між визначеністю на папері та необхідною гнучкістю в реальній роботі над проєктом. Щодо інших нюансів складення та застосування договору на розробку юристи Legal IT Group писали в цій статті.
Мабуть, зараз AI чи не найгарячіша тема не тільки у сфері інформаційних технологій, а й на рівні людства в цілому. Штучний інтелект дуже швидко та непомітно пронизав наше життя і продовжує набирати оберти, звісно не оминувши й індустрію розробки програмного забезпечення. Не секрет, що девелопери активно використовують ШІ в роботі, а тому пропонуємо розглянути питання його врегулювання на рівні Software Development Agreement.
Створення програмного продукту може передбачати як написання вихідного, об’єктного коду, створення дизайну, написання текстового контенту, тестування, і все це може відбуватися за допомогою штучного інтелекту як напряму, так і опосередковано. І хоча добросовісні прогресивні компанії-розробники ПЗ активно запроваджують власні політики для співробітників щодо можливостей та меж використання AI в роботі, це не застраховує замовника від можливих негативних наслідків користування продуктом до якого включено контент, згенерований штучним інтелектом.
З огляду на сучасні тенденції, ми завжди радимо сторонам договору на розробку чітко погодити можливість використання ШІ, межі, відповідальність та інші важливі моменти у першу чергу для уникнення можливих спорів. Сторони мають чітко усвідомлювати свої права та обов’язки в контексті ШІ. Якщо договором використання AI ніяк не передбачено, розробник може активно на власний розсуд використовувати ШІ, а замовник за підсумками, отримавши ПЗ у розпорядження, вважати його неякісним, невідповідним погодженому ТЗ тощо. Або ж взагалі бути позбавленим можливості його використовувати/розпоряджатися через можливі порушення прав інтелектуальної власності, спричинені таким використанням ШІ розробником.
Перш за все, зазначимо, що питання щодо дозволу/заборони використання ШІ при розробці, чи прямого включення згенерованого контенту до результатів розробки софту, головним чином залежить від домовленостей із замовником за договором розробки ПЗ. Саме замовник має чітко розуміти для себе, наскільки прийнятним для нього буде ПЗ, розроблене з такими елементами. Звісно, що багато чого залежить також від порядності та професійності розробника та його команди. Отож, пропонуємо поглянути на можливі нюанси включення положень щодо дозволу та заборони використання штучного інтелекту в SDA.
При забороні все просто — необхідно правильно встановити чіткий обов’язок для розробника утримуватися від певних дій в ході надання послуг за договором. На практиці важливо чітко окреслити, що буде вважатися ШІ для цілей договору, які саме дії не допускаються, які наслідки у випадку, якщо порушення допущено. Не зайвим буде все ж додати можливість окремого погодження використання ШІ між сторонами, наприклад в письмовій комунікації без зайвої бюрократії, якщо виникне термінова необхідність.
Якщо ви обираєте дозвіл, то дозволити використання штучного інтелекту бажано також напряму в договорі, фіксуючи, які саме AI сервіси, у яких межах та порядку може застосовувати розробник. Але це ще не все, бо всім відомий такий негативний аспект використання ШІ як неякісний/неточний результат, особливо якщо він додатково не був перевірений людиною на предмет недоліків. Тож, важливо покласти на розробника обов’язок здійснювати відповідне тестування та нести відповідальність при наявності недоліків. Не забуваємо також про гарантії того, що такий контент не буде порушувати права третіх сторін, що також рекомендовано прописувати в договорі на розробку ПЗ.
Не зайвим буде також звернути увагу на інші аспекти співпраці за Software Development Agreement в сучасних реаліях.
Для прискорення розробки й оптимізації ресурсів девелопери доволі часто можуть послуговуватися матеріалами з відкритим кодом (open source): бібліотеками, фреймворками та інструментами, що вільно розповсюджуються та можуть легально використовуватися будь-ким з дотриманням умов відповідних ліцензій. Отже, програмне забезпечення, що створюється на замовлення може частково або повністю базуватися на таких компонентах, що викликає необхідність дотримуватись ліцензійних умов як розробником, так і замовником при подальшому використанні.
Тож в контексті формулювання умов договору на розробку ПЗ важливо прямо заборонити чи дозволити використання open source матеріалів, покласти відповідальність за порушення відповідних ліцензій та розподілити ризики на випадок виникнення проблем.
Останнім часом все більше компаній, особливо орієнтованих на західний ринок, запроваджують у свої процеси стандарти якості та безпеки, що розробляються та публікуються Міжнародною організацією зі стандартизації (International Organization for Standardization, ISO). Відповідно й ПЗ, що розробляється для таких компаній має відповідати цим стандартам, у зв’язку з чим набуває актуальності питання включення умов щодо дотримання ISO з боку розробника ПЗ у відповідний договір.
Тож, на практиці сторони визначають відповідний обов’язок для розробника дотримуватися ISO. Важливо чітко ідентифікувати, які стандарти застосовуються та в яких межах, які наслідки недотримання. Можливо також окремо передбачити процедуру перевірки відповідності результатів.
Тренди 2025 року у сфері договорів на розробку програмного забезпечення відображають поступовий перехід від жорстких фіксованих моделей до гнучких, ітераційних підходів, що дає змогу сторонам ефективніше взаємодіяти та швидко реагувати на зміни вимог і ринку. Особливістю сучасних SDA є також значна увага до питань інтелектуальної власності, використанню ШІ та open source, а також впровадженню стандартів якості.
Водночас оформлення актуально договору на розробку програмного забезпечення потребує глибокого розуміння нюансів галузі девелопменту, уміння знаходити правильний баланс між визначеністю на папері та гнучкістю у співпраці. Належне врахування бажань сторін та нюансів співпраці за таким договором дозволяє уникнути можливих спорів та інших негативних наслідків, успішно взаємодіяти з контрагентами задля реалізації проєктів у сфері IT.
Protocol.ua є власником авторських прав на інформацію, розміщену на веб - сторінках даного ресурсу, якщо не вказано інше. Під інформацією розуміються тексти, коментарі, статті, фотозображення, малюнки, ящик-шота, скани, відео, аудіо, інші матеріали. При використанні матеріалів, розміщених на веб - сторінках «Протокол» наявність гіперпосилання відкритого для індексації пошуковими системами на protocol.ua обов`язкове. Під використанням розуміється копіювання, адаптація, рерайтинг, модифікація тощо.
Повний текстПриймаємо до оплати
Copyright © 2014-2025 «Протокол». Всі права захищені.
