Не кожен договір на програмне забезпечення можна назвати дійсно ефективним, бо відсутність певних умов може суттєво ускладнити процес розробки і погіршити взаємини між замовником і компанією. Тому, редакція UAEU запитала у IT-юристів Stalirov&Co яких помилок краще уникати, щоб створити сприятливі умови для виконання завдань замовника та розробки ПЗ.
Встановіть відповідальних на стороні замовника
Перед стартом проекту у менеджера мають бути контакти осіб, які відповідають за комунікацію з клієнтом під час розробки програмного продукту.
По-перше, людина, яка виставляє технічні завдання. Юристи радять детально описати алгоритм формування технічного завдання, а саме в ньому мають бути визначені перелік послуг та завдань, процес погодження та надання завдань, строки, протягом яких має розпочатися їх виконання.
По-друге, людина, яка надає матеріали та доступи. Юристи радять визначити у договорі про надання послуг з програмного забезпечення, строки для надання необхідної інформації, контенту та доступів. Якщо ж термін настав, а замовник чи його уповноважені особи не виконали зобов’язання, дедлайни подовжуються на строк, який визначений у технічному завданні, а час простою оплачується.
По-третє, людина яка приймає остаточне рішення щодо наданих результатів розробки. Так само необхідно встановлювати строки розгляду результатів роботи, щоб не довелося чекати місяцями на фідбек від замовника.
Погодьте що вважається багом
Багато договорів про створення програмного забезпечення включають умову про зобов’язання розробників усунути баг, але його визначення та вид договори не містять. Це помилка, бо за таких умов будь-які забаганки замовника можна назвати багом і команда згідно з договором повинна буде їх виконувати.
Тож, визначити види та об’єм багів можна як дефект, помилку в результаті надання послуги, яка суттєво негативно впливає на зовнішній вигляд, роботу та функціональність ПЗ. Важливо, що через дефект, ПЗ не відповідає вимогам технічного завдання. За таких умов баг має бути усунений. Всі інші неточності вважатимуться доповненнями до технічного завдання і повинні додатково оплачуватися.
Пункт зі схожими умовами має бути і у договорі підряду з програмістом, бо саме він буде усувати помилки.
Зафіксуйте строки оплати інвойсів
Недостатньо прописати зобов’язання замовника оплатити акт (інвойс), важливо, щоб був визначений конкретний строк. Наприклад, 10 днів з моменту підписання. Зі спливом строку починають діяти санкції, а саме нараховуватися пеня. Така умова у договорі допоможе запобігти затримці оплати та забезпечить справедливі умови для сторін.
Визначте момент переходу прав інтелектуальної власності
Не підписуйте договір, у якому передача прав відбувається з моменту створення об’єктів інтелектуальної власності, наприклад коду, дизайну, зображень та інших об’єктів. За такої умови замовник стає власником навіть тоді, коли він не сплатив роботу команди. Тож такий пункт потрібно змінити на наступний: перехід прав інтелектуальної власності від виконавця до замовника відбувається у момент оплати інвойсу у повному обсязі.
Попередьте про використання попередніх винаходів компанії
Попередні винаходи — це код, макети, прототипи та мокапи, які створені у попередніх проектах, і можуть використовуватися для пришвидшення розробки у наступних. У договорі важливо попередити, що права інтелектуальної власності на такі об’єкти не переходять до замовника. Крім того, юристи радять додати у договір пункт, що компанія залишає за свою право використовувати отримані знання, підходи та методологію розробки і у інших проектах.
Такі пункти у договорі допоможуть посилити захист прав IT-компанії та зробити умови більш прозорими для обох сторін угоди.
Автор: Валерій Сталіров, CEO компанії IT-юристів Stalirov&Co