У більшості IT-проєктів проблеми виникають не через технології, а через відсутність чітких правил: що саме має бути зроблено, коли це вважається прийнятим, кому належать права, як оплачуються зміни, що робити при зриві строків і як підтверджувати виконання. Договір розробки програмного забезпечення потрібен, щоб перетворити “домовились у чаті” на керовану модель: з прогнозованим бюджетом, контрольованими ризиками і зрозумілим результатом для бізнесу.
Що таке договір розробки програмного забезпечення
Договір розробки ПЗ — це угода між замовником і виконавцем (командою, студією, ФОП, компанією), яка визначає:
• обсяг робіт і очікуваний результат (функціонал, модулі, інтеграції)
• порядок виконання (етапи, дедлайни, звітність)
• порядок приймання (критерії, тестування, акти)
• права інтелектуальної власності на код, дизайн, документацію
• вартість і оплату (погодинно, фіксовано, milestone)
• відповідальність за порушення строків, якості, конфіденційності
• підтримку після релізу (гарантія, виправлення, SLA)
Правильно складений договір не гальмує проєкт, а навпаки — знімає конфлікти “по ходу” і дає сторонам прозорі правила гри.
Кому потрібен договір на розробку ПЗ
• компаніям, що замовляють сайт, CRM, ERP, мобільний застосунок, маркетплейс, SaaS
• стартапам із залученням інвесторів або грантів
• бізнесам, які працюють з підрядниками та хочуть контролювати результат і доступи
• командам, які роблять продукт на продаж і мають захистити IP
• підприємцям, які вже мали досвід “дорого, довго і без результату”
Навіть якщо сума невелика, договір потрібен для критичних речей: прав на код, доступів, приймання і відповідальності.
Переваги договору розробки для бізнесу
• Фіксація результату: зрозуміло, що саме має бути зроблено
• Контроль бюджету: оплата прив’язана до етапів або годин з підтвердженням
• Захист прав на код: бізнес не залежить від розробника після запуску
• Керовані зміни: зміни не “з’їдають” бюджет і строки без погодження
• Зниження ризику зриву: передбачені дедлайни, штрафи, механіка розірвання
• Прозоре приймання: є критерії якості та процедура тестування
• Збереження доступів: репозиторії, хостинг, домени, адмінки оформлені правильно
Ключові умови, які обов’язково включати в договір
1) Предмет і склад результату
Не “розробка програми”, а конкретно:
• перелік модулів, функцій, інтеграцій
• платформи (Web/iOS/Android), середовища, техстек (за потреби)
• вимоги до інтерфейсу, ролей, логіки доступів
• перелік артефактів, які передаються (код, документація, макети, інструкції)
Для складних проєктів предмет доцільно виносити в додатки: ТЗ, специфікація, беклог, прототипи.
2) Технічне завдання і порядок його зміни
Найчастіша причина конфлікту — “ми це мали на увазі”. Тому потрібні правила:
• як затверджується ТЗ/беклог
• що вважається зміною вимог
• як оформлюється change request
• як змінюється ціна і строки при змінах
• що робимо з уже виконаними задачами
3) Етапи (milestones), строки та звітність
У договорі фіксують:
• етапи, дедлайни, результат етапу
• порядок демонстрації (demo), проміжні релізи
• формат звітів, доступ до таск-трекера
• підстави для перенесення строків
Етапність дозволяє бізнесу не “вкладатися в невідомість”, а приймати результат частинами.
4) Критерії приймання (acceptance criteria)
Приймання має бути вимірюваним:
• тест-кейси або перелік перевірок
• вимоги до продуктивності/безпеки (за потреби)
• поняття “критична помилка” і строки її виправлення
• процедура повторного тестування
• строки на приймання, порядок підписання актів
Без цього приймання перетворюється на емоції, а не на процедуру.
5) Вартість і модель оплати
Поширені моделі:
• фіксована ціна за обсяг
• оплата по етапах (milestone)
• погодинна оплата з лімітами (cap)
• змішана модель (фікс + години на зміни)
Для бізнесу критично прописати:
• що входить у вартість (правки, багфікси, документація)
• порядок підтвердження годин
• умови зупинки робіт при несплаті
• повернення/утримання коштів при достроковому розірванні
6) Права інтелектуальної власності на код і матеріали
Це центральний блок для продукту:
• кому належать майнові права на код, дизайн, документацію
• коли відбувається перехід прав (після оплати/акту/релізу)
• чи має виконавець право використовувати рішення повторно
• що з open-source компонентами і ліцензіями
• право замовника на модифікацію і передачу третім особам
Якщо права не прописані чітко, бізнес може отримати лише “послугу розробки”, але не контроль над продуктом.
7) Репозиторій, доступи, хостинг і вихідні матеріали
У договорі доцільно визначити:
• де зберігається код (репозиторій), хто адмін
• порядок передачі доступів і резервних копій
• кому належать домени, акаунти, ключі доступу
• передачу UI/UX файлів, прототипів, документації
• порядок повернення доступів при розірванні
8) Гарантія, підтримка, SLA
Потрібно розділяти:
• гарантійний період (виправлення помилок без доплати)
• підтримку/розвиток (оплачувані роботи)
• SLA: час реакції, пріоритети інцидентів, канали комунікації
9) Конфіденційність і безпека
У договорі фіксують:
• що є конфіденційною інформацією
• заборону розголошення і передачі третім особам
• правила роботи з даними, доступами, ключами
• відповідальність за витік даних
10) Відповідальність і розірвання
Сильний договір завжди має “план Б”:
• штрафи/пеня за прострочення (де це доречно)
• межі відповідальності виконавця
• порядок одностороннього розірвання
• передача напрацювань і частково виконаного коду
• фінальне закриття взаєморозрахунків
Які документи варто додати до договору
• Технічне завдання або беклог
• Графік етапів і платежів
• Критерії приймання і тестування
• Перелік артефактів передачі (код, доступи, документація)
• Політика безпеки (за потреби)
• Регламент підтримки і SLA (за потреби)
Ці додатки роблять договір прикладним: ним реально користуються менеджер, бухгалтерія і технічна команда.
Типові помилки, які коштують бізнесу грошей
• немає ТЗ або є лише “листування” без статусу документа
• не визначені критерії приймання — конфлікти на фінальному етапі
• оплата без етапності — немає важелів впливу на строки
• права на код не передані або передані “частково”
• доступи до репозиторію/хостингу у виконавця — залежність після релізу
• не прописані зміни — будь-яка правка стає шантажем бюджету
• немає гарантії та правил підтримки — “все додатково”
FAQ
1) Чи можна працювати без ТЗ, якщо проєкт гнучкий?
Так, але тоді потрібні правила беклогу: пріоритезація задач, підтвердження змін, оплата по спринтах і критерії приймання.
2) Що важливіше: ціна чи критерії приймання?
Критерії приймання. Без них ви не зможете довести, що результат не відповідає домовленостям.
3) Коли повинні перейти права на код?
Найбезпечніше — після оплати та підписання акту за етап або за фінальний результат. Момент переходу прав має бути прямо визначений у договорі.
4) Чи можна заборонити виконавцю використовувати рішення повторно?
Можна, якщо це важливо для вашої конкурентної переваги. У договорі фіксується обмеження повторного використання та винятки (наприклад, загальні бібліотеки).
5) Як прописати підтримку після запуску?
Окремим блоком: гарантія (помилки без доплати), розвиток (окремі задачі), SLA (час реакції та пріоритети).
6) Що робити, якщо виконавець зриває строки?
У договорі мають бути дедлайни, механіка перенесення, санкції та право розірвання з обов’язковою передачею напрацювань і доступів.
7) Чи можна закріпити доступи на замовника з першого дня?
Так. Це найкраща практика: репозиторій, хостинг, домени, акаунти — під контролем замовника, а виконавець працює через видані доступи.
Чому обирають Юридичну компанію «Юдей»
• договір під вашу модель розробки: fixed price, time & material, спринти, milestones
• сильний блок IP: права на код, обмеження повторного використання, open-source нюанси
• акцент на прийманні і доказах: критерії, акти, порядок тестування
• контроль доступів і результату: репозиторій, документація, передача матеріалів
• зрозуміла структура договору для бізнесу та команди