НА ПРАВАХ РЕКЛАМИ
Після запуску продукту початкове технічне завдання рідко залишається незмінним. Користувачі просять нові функції, з’являється необхідність підключити платіжну систему, змінити інтерфейс або додати новий модуль.

Розглянемо типову ситуацію. Компанія замовила розробку CRM, а через два місяці вирішила додати особистий кабінет та інтеграцію з сервісом оплати. Розробник готовий приступити до роботи відразу, але виникає питання: чи потрібно підписувати новий договір на створення програмного забезпечення?

В більшості випадків ‒ ні. Якщо проєкт продовжується, достатньо правильно оформити зміни.

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

Коли новий договір не потрібен

Для українських договорів загальний принцип закріплено в статтях 651 та 654 Цивільного кодексу України: сторони можуть змінити договір за взаємною згодою, а зміни зазвичай оформлюються у тій же формі, що і основний договір.

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

Тому ще на етапі підготовки договору варто заздалегідь визначити:

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

Такі положення економлять більше часу, ніж подальше узгодження кожної зміни з нуля.

Що використовувати замість нового договору

Вибір документа залежить від того, що саме змінюється.

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

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

Кейс: чому зміни повинні оформлятися письмово

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

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

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

Кому належать права на доопрацювання

Нова функція ‒ це не лише додаткові витрати, але і питання інтелектуальної власності.

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

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

В Європейському союзі комп’ютерні програми охороняються авторським правом відповідно до Директиви 2009/24/ЄC. В свою чергу, конкретні правила розподілу прав між замовником та розробником визначаються не лише законодавством відповідної країни, але і умовами договору.

В США оплата роботи незалежного розробника само по собі не означає автоматичного переходу авторських прав. Доктрина work made for hire застосовується лише за умови дотримання встановлених законом умов, тому договір зазвичай доповнюють письмовим відступленням прав на код та інші результати розробки.

Тому перед узгодженням нової задачі варто переконатися, що договір визначає:

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

Саме ці питання інвестори перевіряють під час due diligence.

Висновок

Розвиток IT-продукту неможливо заздалегідь описати в одному технічному завданні. Тому задача договору ‒ не заборонити зміни, а встановити зрозумілий порядок їх оформлення.

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

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

Автор: Валерій Сталіров, CEO компанії IT-юристів Stalirov&Co