Agilné zmluvy: termíny, akceptácia a zodpovednosť v IT projektoch

Agilná zmluva zaznamenáva spoluprácu, v ktorej konečný výsledok nie je vopred stanovený, takže musí regulovať, kto stanovuje priority, kedy je výsledok sprintu akceptovaný a či sú termíny dodania záväzné. Podľa holandského práva nie je termín dodania v agilnom projekte automaticky striktným termínom: súd sa posudzuje na zmluvu, pracovnú metódu a to, ako strany skutočne spolupracovali, a ani zmeškaný striktný termín nie vždy odôvodňuje odstúpenie od zmluvy.

V agilnom vývoji pracujú strany v krátkych šprintoch a upravujú produkt podľa postupu projektu. Tento článok vysvetľuje, ako kvalifikovať záväzok dodávateľa, ako štruktúrovať zmluvu, čo hovorí nedávna judikatúra o termínoch a čo by si mali klienti a dodávatelia skontrolovať.

Prečo agilná práca potrebuje inú zmluvu?

Pretože výsledok je pohyblivý cieľ. V tradičnom IT projekte strany stanovia funkčný a technický návrh a dodávateľ sa zaväzuje dodať ho v stanovenom termíne; v agilnom vývoji každý sprint dodáva funkčnú časť a klient upravuje kurz na základe demonštrácií.

Zmluva preto musí upraviť štyri témy, na ktoré tradičná špecifikácia sama odpovie:

• kto určuje špecifikácie a priority: vlastník produktu na strane klienta;
• ako sa spracovávajú zmeny v backlogu (zoznam priorít funkcií, ktoré je ešte potrebné vytvoriť), plánovanie a cena;
• kedy sa diel považuje za dokončený, na základe definície dokončenia a merateľných kritérií prijatia;
• či sú dohodnuté dodacie lehoty prísne alebo orientačné.

Agilný spôsob práce je ťažké kombinovať s verejnou súťažou, v ktorej je rozsah vopred pevne stanovený. Verejný obstarávateľ, ktorý chce agilný vývoj, by mal v súťažných podkladoch nechať priestor na rámcovú dohodu s flexibilne definovanými zadaniami zákaziek.

Je to povinnosť vynaložiť maximálne úsilie alebo dosiahnuť výsledky?

V agilných projektoch sa záväzok dodávateľa často kvalifikuje ako záväzok maximálneho úsilia (inspanningsverbintenis), pretože nebol dohodnutý žiadny pevný konečný výsledok. V rámci záväzku výsledkov (resultaatsverbintenis) dodávateľ sľubuje konkrétne opísaný výsledok.

Označenie v zmluve nie je rozhodujúce: súd sa zameriava na obsah dohôd a na to, ako strany skutočne pracovali. V rámci záväzku výsledkov je otázkou, či bol výsledok dosiahnutý; v rámci záväzku vynaložiť maximálne úsilie, či dodávateľ preukázal starostlivosť primerane kompetentného a primerane konajúceho IT profesionála.

Článok 6:74(1) holandského Občianskeho zákonníka (BW) je základom pre náhradu škody za pripísateľné neplnenie, ale neuvádza, kedy ide o neplnenie; to závisí od kvalifikácie záväzku. Podľa článku 6:248(1) BW má zmluva aj dôsledky, ktoré vyplývajú z primeranosti a spravodlivosti, čo ponecháva priestor na zohľadnenie agilnej povahy spolupráce.

Ako štruktúrujete agilnú zmluvu?

Zvyčajne v dvoch vrstvách. Rámcová dohoda stanovuje všeobecné pravidlá: platné podmienky, zodpovednosť, dôvernosť, duševné vlastníctvo a spôsob spolupráce. Pre každé zadanie alebo uvoľnenie vykonávacia dohoda stanovuje rozsah, plánovanie, tím, cenu a kritériá prijatia.

Konkrétne, merateľné kritériá akceptácie pre každý sprint sú dôležitejšie ako samotné označenie povinnosti. Bez nich nie je s čím overiť výsledok a rýchlo vznikajú spory o tom, či bol sprint úspešný. Zahrňte definíciu hotového, ktorá zahŕňa nielen funkčnosť, ale aj kvalitu kódu, dokumentáciu a prenositeľnosť.

Predčasné ukončenie si zaslúži väčšiu pozornosť ako v tradičnej zmluve, pretože agilný projekt nemá pevný koncový bod. Dohodnite sa, kedy môže každá strana ukončiť projekt, čo sa stane s dodanými komponentmi a zdrojovým kódom a ako sa práca odovzdá inému dodávateľovi.

Štandardné IT podmienky, ako napríklad NLdigital Terms, upravujú agilné aspekty len v obmedzenom rozsahu. Skontrolujte, ktoré vydanie sa uplatňuje, a zaznamenajte agilné dojednania vo vykonávacej zmluve.

Čo hovorí judikatúra o lehotách?

Neexistuje všeobecné pravidlo, že dátum v agilnom projekte nie je nikdy striktný. Dva nedávne rozsudky ukazujú, ako súd zvažuje zmluvu a spoluprácu.

Okresný súd Midden-Nederland, 2023: prísna lehota, ale bez možnosti zrušenia

V rozsudku s číslom ECLI:NL:RBMNE:2023:5936 bol softvér pre vážiaci systém vyvinutý pomocou metódy scrum s dohodnutou dodacou lehotou približne 24 týždňov a neskôr s pevnými kalendárnymi dátumami. Súd rozhodol, že tieto dátumy boli prísne termíny, takže dodávateľ bol v omeškaní bez oznámenia o omeškaní po ich uplynutí.

Odstúpenie klienta napriek tomu nebolo úspešné. Vzhľadom na agilnú povahu projektu, spoločnú zodpovednosť oboch strán a skutočnosť, že zostal už len jeden pracovný blok, toto zlyhanie neodôvodňovalo odstúpenie podľa článku 6:265 BW. Nároky na vrátenie peňazí a náhradu škody boli zamietnuté.

Okresný súd Amsterdam, 22. apríla 2026: orientačné dátumy

V dokumente ECLI:NL:RBAMS:2026:3930 klient tvrdil, že vývojár dodal novú aplikáciu neskoro, prekročil rozpočet a nedostatočne udržiaval existujúce aplikácie. V cenovej ponuke boli použité dvojtýždňové scrum sprinty a orientačný dátum spustenia.

Súd nezistil žiadne prísne termíny: dátum spustenia a plánovanie sprintu boli orientačné a prístup scrum si vyžadoval úzku spoluprácu. Bez prísneho termínu klient potreboval platné oznámenie o omeškaní a jeho oznámenia neviedli k omeškaniu vývojára. Všetky žaloby boli zamietnuté.

Ponaučenie: ak chcete, aby bol dátum presne stanovený, výslovne ho uveďte v zmluve. Dátum v cenovej ponuke alebo e-maile zvyčajne nestačí.

Čo by ste si mali ako klient overiť?

• Kto je vaším produktovým vlastníkom a má táto osoba mandát meniť backlog vo vašom mene?
• Sú kritériá akceptácie a definícia hotového zaznamenané pre každý sprint alebo vydanie?
• Uvádza zmluva výslovne, ktoré dátumy sú prísne termíny?
• V akej lehote musíte otestovať a odpovedať na doručenie a čo sa stane, ak tak neurobíte?
• Kedy získate prístup k zdrojovému kódu a dokumentácii?
• Čo sa odovzdáva pri predčasnom ukončení a za akú cenu?

Čo by ste si mali ako dodávateľ overiť?

• Je jasné, že dátumy v cenových ponukách a plánovaní sú orientačné, pokiaľ nie je dohodnuté inak?
• Zaznamenávate rozhodnutia vlastníka produktu a zmeny v backlogu písomne?
• Zaznamenávate, kedy klient neposkytne včas vstupy, neoverí kapacitu alebo neprijme rozhodnutia? Môže to predstavovať zlyhanie veriteľa (článok 6:58 BW).
• Je platobný základ jasný: za šprint, za hodinu, za funkčný bod alebo za výsledok?
• Obmedzili ste svoju zodpovednosť a vylúčili ste následné škody v rámcovej zmluve?

Čo pre vás môžeme urobiť s agilnými zmluvami?

Naši IT právnici pomáhajú IT dodávateľom a klientom s agilnými projektmi. Vieme:

• vypracovať alebo preskúmať rámcovú dohodu a vykonávacie dohody pre agilný projekt;
• formulovať kritériá prijatia, definíciu hotového a jasné termíny;
• vypracovať dohodu o predčasnom ukončení zmluvy a prechode k inému dodávateľovi;
• posúdiť, či je dodávateľ v omeškaní a či je možné odstúpenie od zmluvy;
• vypracovať oznámenie o omeškaní alebo odpoveď na oznámenie a viesť konanie o omeškaní alebo ukončení zmluvy.

Prečítajte si viac o tom, čo robí IT právnik.

zhrnutie

• Agilná zmluva zvyčajne pozostáva z rámcovej dohody a implementačných dohôd pre každú úlohu.
• Záväzok dodávateľa je často záväzkom vynaložiť maximálne úsilie; označenie v zmluve nie je rozhodujúce.
• Merateľné kritériá prijatia a definícia hotového procesu zabraňujú sporom o tom, či bol sprint úspešný.
• To, či je dátum dodania prísnym termínom, závisí od zmluvy a spolupráce, preto ho výslovne uveďte; ani zmeškanie prísneho termínu automaticky neoprávňuje na odstúpenie od zmluvy (ECLI:NL:RBMNE:2023:5936).
• Vopred regulujte predčasné ukončenie, zdrojový kód a odovzdanie inému dodávateľovi.

Často kladené otázky