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