Класичний договір підряду виходить із того, що від самого початку зрозуміло, що потрібно створити: фіксований обсяг, фіксована ціна, а наприкінці — передання та приймання результату як цілого. Гнучка розробка ґрунтується на протилежному: обсяг формується в процесі відповідно до пріоритетів у беклозі, а програмне забезпечення створюється інкрементами, які впроваджуються поступово. Той, хто намагається пристосувати шаблон договору підряду до спринтів, отримає договір, що не відповідає нічому з того, що сторони реально роблять, а під час першого спору з’ясується, що він не захищає жодну з них.
У чому договір підряду розходиться зі спринтами
Відповідно до § 536 ч. 1 Торговельного кодексу підрядник зобов’язується виконати певну роботу, а замовник — сплатити ціну за її виконання. Однак у гнучкому проєкті на початку ніхто не може описати кінцеву систему так, щоб цей опис залишався актуальним до завершення; відомо лише, як відбуватиметься робота. Друга суперечність стосується управління:
Під час виконання роботи підрядник діє самостійно і при визначенні способу виконання роботи не зв’язаний вказівками замовника, якщо тільки він прямо не зобов’язався їх виконувати. — § 537 ч. 3 Закону № 513/1991 Zb.
Водночас гнучкий проєкт ґрунтується саме на вказівках замовника — product owner визначає пріоритети кожного спринту. Якщо постачальник прямо не зобов’яжеться в договорі виконувати такі вказівки, законодавча основа суперечитиме тому, що, на думку замовника, він придбав.
Рамковий договір і замовлення
Співпрацю можна врегулювати на двох рівнях: рамковий договір визначає правила співпраці — ставки, ролі, процес постановки завдань, приймання, права на код, конфіденційність і припинення, — а окремі замовлення чи спринти оформлюються на його підставі, зазвичай через проєктну систему, у якій також формується доказовий слід. Рамковий договір можна укласти як непойменований договір відповідно до § 269 ч. 2 Торговельного кодексу, а замовлення — як договори підряду; для непойменованого договору діє така умова:
Учасники можуть укласти також договір, який не врегульований як окремий тип договору. Однак якщо учасники достатньо не визначать предмет своїх зобов’язань, договір не є укладеним. — § 269 ч. 2 Закону № 513/1991 Zb.
Тому предметом рамкового договору є не готова система, а точно описаний процес: хто ставить завдання, хто затверджує оцінку, що є результатом спринту. Винагорода зазвичай визначається за моделлю time & material — ставка, помножена на облікований час, — що закон допускає, оскільки достатньо погодити спосіб визначення ціни (§ 536 ч. 3). За відсутності погодженої ставки договір підряду є чинним, лише якщо сторони виявили волю укласти його і без визначення ціни (§ 536 ч. 3); тоді сплачується звичайна ціна (§ 546 ч. 1), тобто доказування замість рахунку-фактури. Захистом замовника є бюджетний ліміт на певний період або замовлення, після досягнення якого роботи без нового погодження не продовжуються; захистом постачальника — правило, за яким облікований і прийнятий час підлягає оплаті навіть тоді, коли замовник достроково зупинить проєкт.
Приймання інкрементів і визначення готовності
У разі спринтів не можна відкладати приймання до завершення проєкту. Приймається кожен інкремент: договір визначає критерії приймання — визначення готовності, зокрема тести й документацію, — короткий строк для надання позиції та фікцію приймання, якщо замовник у цей строк не висловиться і не заявить про недоліки. Інакше щодо впроваджених інкрементів залишається невизначеним, чи і коли їх було прийнято. Чому мовчання під час приймання є небезпечним навіть без такої фікції, пояснює консультація непідписаний протокол приймання та ціна роботи. Окремо слід урегулювати недоліки: приймання інкременту стосується функцій відповідного спринту, але не повинно звільняти постачальника від відповідальності за інтеграційні дефекти й регресії, що проявляться лише у взаємодії з пізнішими інкрементами. Тому гарантію на результат як ціле погодьте від упровадження останньої частини, а не від першого приймання; без гарантії про недоліки, які можна виявити лише пізніше, слід повідомити не пізніше ніж протягом двох років від передання (§ 562 ч. 2 літ. c)).
Зміна обсягу без додаткових угод
Перевага рамкового договору полягає в тому, що зі зміною обсягу не потрібно змінювати сам договір. Беклог — це живий список, який product owner без додаткових угод доповнює та перегруповує, а договір лише визначає, як окремий пункт стає обов’язковим: постачальник подає оцінку, замовник її затверджує, і лише після цього починається робота. До цього належить погоджене допустиме перевищення оцінки та правило, що понад нього постачальник без нового погодження не продовжує роботу, інакше він сам несе витрати на додаткові роботи. Спірні питання вирішує ескалаційна драбина — спочатку проєктні ролі, потім керівні органи, — щоб один незатверджений тікет не зупинив увесь проєкт.
Код, припинення та передання репозиторію
Права на програмне забезпечення, створене на замовлення, регулює § 91 Закону № 185/2015 Z. z. Правило, за яким замовник здійснює майнові права як роботодавець (§ 91 ч. 4), стосується твору, який на підставі договору підряду створив сам автор (§ 91 ч. 1). У разі розробки через компанію-постачальника права її працівників здійснює постачальник як роботодавець (§ 90 ч. 4), тому не можна без додаткових підстав вважати, що їх набуває замовник; йому потрібна ліцензія або передання права здійснювати майнові права (§ 90 ч. 5). Ліцензія може випливати й з домовленості сторін, однак без визначення способу використання — лише в обсязі, необхідному для мети договору (§ 65 і § 66 ч. 1). Пряма домовленість забезпечує визначеність щодо її обсягу, зокрема стосовно внесення змін, надання субліцензій і передання вихідного коду. Докладно це розглянуто в консультації авторські права на програмне забезпечення, створене на замовлення. У рамковому договорі ключовим є часовий аспект: права та доступ до коду мають переходити поступово разом із прийманням кожного інкременту, а не лише після оплати останнього рахунку-фактури. На практиці це означає розробку в репозиторії під контролем замовника або обов’язок передавати код і документацію після кожного спринту. Рамковий договір має заздалегідь передбачати припинення: розірвання без зазначення причини з розумним строком, завершення або врегулювання поточних замовлень, передання репозиторію, документації та доступів, сприяння під час переходу до нового постачальника. А якщо постачальник після впровадження має забезпечувати чергування, його потрібно оцінити окремо — чи оплачується воно навіть без втручання, пояснює консультація чи оплачується чергування без втручання?.
Для обох сторін
Добре складений рамковий договір захищає замовника від безмежного бюджету, а постачальника — від роботи, яку ніхто не затвердив. Ми підготуємо або перевіримо договір на IT-роботи та гнучку розробку для будь-якої зі сторін, для впровадження сторонньої системи — договір про впровадження, права на код урегулюємо в договорі щодо програмного забезпечення та ліцензійному договорі, а для класичних поставок із фіксованим обсягом підготуємо договір підряду.
Ця стаття містить загальну правову інформацію станом на 26 вересня 2026 р.. Вона не є юридичною послугою чи консультацією щодо вашої конкретної справи. Законодавство змінюється, а обставини вашої ситуації можуть відрізнятися. Перед ухваленням рішення перевірте належний порядок дій або зв’яжіться з нами.
