При укладенні договору на програмне забезпечення виникає безліч питань і нюансів, не врахування яких призводить до проблем на проєктах та фінансових втрат. Щоб уникнути негараздів, ІТ-юристи Starilov&Co діляться мастхевами розробки договорів про надання послуг з програмного забезпечення.
1.Простій
Перший лайфхак, який допоможе зберегти кошти та час компанії, стосується розробки розділу “Простій” у контракті. За загальним правилом, простій виникає протягом часу, коли команда не може надавати послуги з розробки ПЗ у зв’язку із затримками з боку замовника. До таких затримок відносять ситуації, коли:
- замовник не надає доступ, матеріали та інформацію, необхідні для реалізації проєкту;
- замовник не відповідає на запити та листи команди проєкту;
- замовник не ставить та не оновлює завдань, тощо.
У таких випадках, компанія не несе відповідальності за порушення дедлайнів. Термін закінчення проєкту автоматично продовжується, а час простою оплачується за ставкою проєктної команди, передбаченої в ТЗ.
2. Процедура виправлення помилок
Ще одним завданням юриста під час створення кастомізованого авторського договору на розробку програмного забезпечення є встановлення у ньому гарантійного терміну, протягом якого компанія виправляє помилки. Окрім того, важливо розмежувати поняття помилок та додаткових змін.
Зокрема, якщо замовник виявить помилки у створених об’єктах протягом 45 днів з моменту повної оплати наданих послуг, інша сторона зобов’язана виправити їх власними ресурсами . Строк тестувального періода, для кожного проєкта, встановлюється індивідуально.
Якщо помилки та баги у програмному коді виникли після внесення додаткових змін третіми особами, наприклад розробником або програмістом компанії-замовника, IT-компанія не зобов’язана безкоштовно усувати дефекти.
До помилок, які мають бути виправлені, відносять ті, які не були й не могли бути виявлені на момент прийняття результатів та оплати наданих послуг, а також ті, що виникли внаслідок явної помилки програмістів, що призвела до невідповідності ПЗ технічним характеристикам, визначеним у попередньо погодженим ТЗ.
Якщо проблеми виникли внаслідок дефектів у вихідних матеріалах клієнта, втручання до програмного коду третіх осіб або взагалі є додатковими вимогами замовника, це не буде кваліфікуватися як помилка. Такі виправлення чи зміни повинні бути додатково оплачені замовником.
3. Політика змін
Під час реалізації проєктів, ІТ-компаніям доводиться оновлювати та переглядати ТЗ за ініціативою клієнтів, тому важливо заздалегідь встановити процедуру для внесення змін, яка включає наступні кроки:
- Подання запиту на внесення змін та визначення його змісту. Звертаючись із запитом, клієнт повинен надати детальний опис додаткових робіт та їх технічну специфікацію, очікувані терміни виконання, референси тощо.
- Оцінка запиту. Компанія здійснює оцінку запиту, в результаті чого погоджує або відмовляє в подальшому внесенні змін. Якщо інформації для здійснення оцінки недостатньо, виконавець може просити додаткові матеріали, які, в свою чергу, замовник зобов’язується надати.
- Встановлення результатів оцінки. Виконавець надає свій висновок щодо можливості внесення змін у вигляді оцінювальної таблиці з зазначенням відомостей про додаткову оплату та дедлайни. Замовник може вносити додаткові пропозиції чи зауваження протягом встановленого сторонами терміну.
- Підготовка документації. Якщо обидві сторони погоджують внесення змін, створюється нове ТЗ або ж вносяться зміни до вже існуючого.
Така процедура забезпечує прозорість співпраці та уникнення непорозумінь між сторонами договору.
Автор: Валерій Сталіров, CEO компанії IT-юристів Stalirov&Co
Партнерський матеріал
