Klasická zmluva o dielo počíta s tým, že na začiatku je jasné, čo sa má postaviť: pevný rozsah, pevná cena, na konci odovzdanie a akceptácia celku. Agilný vývoj stojí na opaku — rozsah sa tvorí za pochodu podľa priorít v backlogu a softvér vzniká po inkrementoch, ktoré sa nasadzujú priebežne. Kto natiahne šablónu zmluvy o dielo na sprinty, dostane zmluvu, ktorá nezodpovedá ničomu, čo strany reálne robia — a pri prvom spore sa ukáže, že nekryje ani jednu z nich.
Kde sa zmluva o dielo so sprintmi rozchádza
Podľa § 536 ods. 1 Obchodného zákonníka sa zhotoviteľ zaväzuje vykonať určité dielo a objednávateľ zaplatiť cenu za jeho vykonanie. Pri agilnom projekte však na začiatku nikto nevie opísať výsledný systém tak, aby opis vydržal do konca; vie sa len, ako sa bude pracovať. Druhý rozpor je v riadení:
Pri vykonávaní diela postupuje zhotoviteľ samostatne a nie je pri určení spôsobu vykonania diela viazaný pokynmi objednávateľa, ibaže sa výslovne zaviazal plniť ich. — § 537 ods. 3 zákona č. 513/1991 Zb.
Agilný projekt pritom stojí práve na pokynoch objednávateľa — product owner určuje priority každý šprint. Ak sa dodávateľ v zmluve na pokyny výslovne nezaviaže, zákonný základ hovorí proti tomu, čo si objednávateľ myslí, že si kúpil.
Rámcová zmluva a objednávky
Spoluprácu možno upraviť na dvoch úrovniach: rámcová zmluva určí pravidlá spolupráce — sadzby, roly, proces zadávania, akceptáciu, práva ku kódu, dôvernosť a ukončenie — a jednotlivé objednávky či šprinty sa zadávajú podľa nej, typicky cez projektový systém, v ktorom vzniká aj dôkazová stopa. Právne ide o kombináciu zmluvy o dielo a nepomenovanej zmluvy podľa § 269 ods. 2 Obchodného zákonníka, ktorá vyžaduje splnenie tejto podmienky:
Účastníci môžu uzavrieť aj takú zmluvu, ktorá nie je upravená ako typ zmluvy. Ak však účastníci dostatočne neurčia predmet svojich záväzkov, zmluva nie je uzavretá. — § 269 ods. 2 zákona č. 513/1991 Zb.
Predmetom rámca preto nie je hotový systém, ale presne opísaný proces: kto zadáva, kto schvaľuje odhad, čo je výstupom šprintu. Odmena býva time & material — sadzba krát vykázaný čas — čo zákon pripúšťa, lebo stačí dohodnúť spôsob určenia ceny (§ 536 ods. 3). Bez dohodnutej sadzby by hrozila cena obvyklá (§ 546 ods. 1), teda dokazovanie namiesto faktúry. Ochranou objednávateľa je rozpočtový strop na obdobie alebo objednávku, po ktorého dosiahnutí práce bez nového schválenia nepokračujú; ochranou dodávateľa pravidlo, že vykázaný a akceptovaný čas je splatný aj vtedy, keď objednávateľ projekt predčasne zastaví.
Akceptácia po inkrementoch a definícia hotového
Pri sprintoch nemožno čakať s akceptáciou na koniec projektu. Akceptuje sa každý inkrement: zmluva určí akceptačné kritériá — definíciu hotového vrátane testov a dokumentácie — krátku lehotu na vyjadrenie a fikciu akceptácie, ak sa objednávateľ v lehote nevyjadrí ani nevytkne vady. Inak sa nasadené inkrementy hromadia v právnom vzduchoprázdne. Prečo je mlčanie pri preberaní nebezpečné aj bez fikcie, ukazuje poradňa nepodpísaný preberací protokol a cena diela. Osobitne treba upraviť vady: akceptácia inkrementu sa týka funkcií daného šprintu, nesmie však zbaviť dodávateľa zodpovednosti za integračné vady a regresie, ktoré sa prejavia až v súhre s neskoršími inkrementmi. Zodpovednosť za celok preto beží od nasadenia poslednej časti, nie od prvej akceptácie.
Zmena rozsahu bez dodatkov
Výhodou rámcovej zmluvy je, že pri zmene rozsahu netreba meniť samotnú zmluvu. Backlog je živý zoznam, ktorý product owner bez dodatkov dopĺňa aj preskupuje — zmluva len určí, ako sa položka stane záväznou: dodávateľ predloží odhad, objednávateľ ho schváli, až potom sa pracuje. K tomu patrí dohodnutá tolerancia prekročenia odhadu; nad ňu dodávateľ nesmie pokračovať bez nového súhlasu, inak nadpráce znáša sám. Sporné body rieši eskalačný rebrík — najprv projektové roly, potom štatutári — aby jeden neschválený ticket nezastavil celý projekt.
Kód, ukončenie a odovzdanie repozitára
Práva k softvéru vytvorenému na objednávku upravuje § 91 zákona č. 185/2015 Z. z.; pri vývoji cez dodávateľskú firmu nemožno bez ďalšieho predpokladať, že objednávateľ získava výkon majetkových práv autora. To však nevylučuje nevýhradnú licenciu vyplývajúcu z dohody strán a účelu zmluvy (§ 65 a § 66). Výslovné dojednanie dáva istotu o jej rozsahu, najmä pri úpravách, sublicenciách a odovzdaní zdrojového kódu. Podrobne to rozoberá poradňa autorské práva k softvéru na objednávku. V rámcovej zmluve je kľúčový časový rozmer: práva a prístup ku kódu majú prechádzať priebežne s akceptáciou každého inkrementu, nie až po zaplatení poslednej faktúry. Prakticky to znamená vývoj v repozitári pod kontrolou objednávateľa alebo povinnosť kód a dokumentáciu po každom šprinte odovzdať. Na ukončenie musí rámec pamätať vopred: výpoveď bez udania dôvodu s primeranou lehotou, dokončenie alebo vysporiadanie rozbehnutých objednávok, odovzdanie repozitára, dokumentácie a prístupov, súčinnosť pri prechode na nového dodávateľa. A ak má dodávateľ po nasadení držať pohotovosť, treba ju oceniť osobitne — či sa platí aj bez zásahu, vysvetľuje poradňa platí sa pohotovosť bez zásahu?.
Pre obe strany
Dobre napísaný rámec chráni objednávateľa pred nekonečným rozpočtom a dodávateľa pred prácou, ktorú nikto neschválil. Pripravíme alebo zrevidujeme zmluvu na IT dielo a agilný vývoj pre ktorúkoľvek stranu, k nasadeniu cudzieho systému implementačnú zmluvu, práva ku kódu ošetríme v softvérovej a licenčnej zmluve a pri klasických dodávkach s pevným rozsahom pripravíme zmluvu o dielo.
Článok je všeobecná právna informácia k stavu ku dňu 6. 9. 2026 — nie je právnou službou ani radou k vašej konkrétnej veci. Právne predpisy sa menia a vaša situácia sa môže v detailoch líšiť; pred rozhodnutím si postup overte alebo sa nám ozvite.
