Bežná šablóna zmluvy o dielo počíta s vopred určeným rozsahom a pevnou cenou. Na konci sa celé dielo odovzdá a objednávateľ ho prevezme. Pri agilnom vývoji sa však zadanie spresňuje počas práce podľa priorít v backlogu. Jednotlivé časti softvéru sa dokončujú a nasadzujú priebežne.
Ak sa na takýto projekt použije šablóna bez potrebných úprav, zmluva nebude zodpovedať tomu, ako strany skutočne spolupracujú. Pri spore im potom neposkytne ochranu, ktorú od nej očakávali.
Prečo bežná zmluva o dielo nestačí
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 nie je možné opísať výsledný systém tak, aby sa tento opis počas vývoja nemenil. Strany vedia predovšetkým to, ako budú spolupracovať.
Zmluva musí zohľadniť aj spôsob riadenia práce. Obchodný zákonník vychádza zo samostatnosti zhotoviteľa.
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.
Pri agilnom vývoji pritom product owner určuje priority pre každý šprint. Objednávateľ teda očakáva, že dodávateľ bude postupovať podľa jeho pokynov. Ak sa na to dodávateľ v zmluve výslovne nezaviaže, toto očakávanie nebude zodpovedať zákonnej úprave.
Rámcová zmluva určí pravidlá, objednávky konkrétnu prácu
Spoluprácu možno rozdeliť na rámcovú zmluvu a jednotlivé objednávky. V rámcovej zmluve sa dohodnú sadzby, úlohy jednotlivých osôb a spôsob zadávania a preberania práce. Patrí do nej aj úprava práv ku kódu, dôvernosti a ukončenia spolupráce.
Konkrétne objednávky alebo šprinty sa potom zadávajú podľa týchto pravidiel. Spravidla sa na to používa projektový systém, ktorý zároveň uchováva záznamy využiteľné pri prípadnom dokazovaní.
Rámcovú zmluvu možno uzavrieť ako nepomenovanú zmluvu podľa § 269 ods. 2 Obchodného zákonníka a jednotlivé objednávky ako zmluvy o dielo. Aj pri nepomenovanej zmluve však musí byť dostatočne určité, na čo sa strany zaväzujú.
Úč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á.
Rámcová zmluva preto presne opisuje postup spolupráce namiesto konečnej podoby systému. Určí, kto zadáva prácu, kto schvaľuje odhad jej náročnosti a čo má byť výstupom šprintu.
Odmena sa často počíta podľa modelu time & material, teda ako dohodnutá sadzba vynásobená vykázaným časom. Zákon takýto postup umožňuje, pretože podľa § 536 ods. 3 stačí dohodnúť spôsob určenia ceny.
Ak sadzba dohodnutá nie je, zmluva o dielo obstojí len vtedy, ak strany prejavili vôľu uzavrieť ju aj bez určenia ceny (§ 536 ods. 3). V takom prípade sa platí obvyklá cena podľa § 546 ods. 1. Pri spore tak bude potrebné dokazovať jej výšku.
Objednávateľa chráni rozpočtový strop dohodnutý na určité obdobie alebo objednávku. Po jeho dosiahnutí sa bez ďalšieho schválenia nepokračuje v práci. Dodávateľ zase potrebuje dohodu, podľa ktorej dostane zaplatené za vykázaný a akceptovaný čas aj vtedy, keď objednávateľ projekt predčasne zastaví.
Kedy je časť softvéru hotová a prevzatá
Pri práci v šprintoch nemožno odkladať akceptáciu až na koniec celého projektu. Každá dokončená časť softvéru, označovaná ako inkrement, sa akceptuje samostatne.
Zmluva má určiť, čo sa považuje za hotový výstup vrátane požadovaných testov a dokumentácie. Objednávateľ má dostať krátku lehotu na vyjadrenie. Pre prípad, že sa v nej nevyjadrí ani nevytkne vady, sa dohodne fikcia akceptácie. Po uplynutí lehoty sa tak výstup považuje za akceptovaný.
Bez takýchto pravidiel môže zostať nejasné, či a kedy objednávateľ prevzal aj tie časti softvéru, ktoré už používa. Dôsledkom mlčania pri preberaní sa venuje aj poradňa o nepodpísanom preberacom protokole a cene diela.
Samostatnú pozornosť si zaslúžia vady. Akceptácia potvrdzuje funkcie dodané v konkrétnom šprinte. Nesmie však zbaviť dodávateľa zodpovednosti za integračné vady a regresie, ktoré sa prejavia až po spojení s neskoršími časťami softvéru.
Začiatok záruky na celý systém preto dohodnite až od nasadenia poslednej časti. Ak by plynula už od prvej akceptácie, nezodpovedala by postupnému dokončovaniu systému. Bez dohodnutej záruky treba vady zistiteľné až neskôr oznámiť najneskôr do dvoch rokov od odovzdania (§ 562 ods. 2 písm. c)).
Ako meniť zadanie bez dodatku ku každej zmene
Rámcová zmluva umožňuje meniť rozsah práce bez toho, aby sa pri každej zmene podpisoval dodatok. Product owner môže priebežne dopĺňať backlog a meniť poradie jeho položiek.
Zmluva však musí určiť, kedy sa konkrétna položka stáva záväzným zadaním. Dodávateľ najprv predloží odhad, objednávateľ ho schváli a až potom sa začne pracovať.
Dohodnúť treba aj prípustné prekročenie odhadu. Ak dodávateľ túto hranicu dosiahne, bez ďalšieho súhlasu objednávateľa nepokračuje. Inak znáša náklady na prácu nad dohodnutý rozsah sám.
Pre prípad nezhody má zmluva určiť, kto ju bude riešiť. Najprv sa o dohodu pokúsia osoby zodpovedné za projekt, následne štatutári. Jeden neschválený ticket tak nemusí zastaviť celý vývoj.
Práva ku kódu a odovzdanie projektu
Práva k softvéru vytvorenému na objednávku upravuje § 91 zákona č. 185/2015 Z. z. Podľa jeho odseku 4 vykonáva objednávateľ majetkové práva ako zamestnávateľ. Toto pravidlo sa však viaže na dielo, ktoré na základe zmluvy o dielo vytvoril sám autor (§ 91 ods. 1).
Ak softvér vyvíja dodávateľská firma prostredníctvom svojich zamestnancov, ich majetkové práva vykonáva dodávateľ ako zamestnávateľ (§ 90 ods. 4). Objednávateľ preto nemôže automaticky predpokladať, že tieto práva získava. Potrebuje licenciu alebo postúpenie výkonu majetkových práv podľa § 90 ods. 5.
Licencia môže vyplývať aj z dohody strán. Ak však nie je určený spôsob použitia, jej rozsah sa obmedzuje na to, čo je nevyhnutné na dosiahnutie účelu zmluvy (§ 65 a § 66 ods. 1). Výslovná dohoda preto dáva istotu najmä pri úpravách softvéru, poskytovaní sublicencií a odovzdaní zdrojového kódu. Podrobnosti rozoberá poradňa o autorských právach k softvéru na objednávku.
Dôležité je aj to, kedy objednávateľ práva a prístup ku kódu získa. Majú sa mu poskytovať priebežne s akceptáciou každej časti, bez čakania na zaplatenie poslednej faktúry.
V praxi sa to dá zabezpečiť vývojom v repozitári pod kontrolou objednávateľa. Druhou možnosťou je povinnosť dodávateľa odovzdať kód a dokumentáciu po každom šprinte.
Zmluva musí počítať aj s predčasným koncom spolupráce. Má umožniť výpoveď bez udania dôvodu s primeranou výpovednou lehotou a upraviť dokončenie alebo vysporiadanie rozpracovaných objednávok. Potrebné je dohodnúť odovzdanie repozitára, dokumentácie a prístupov, ako aj súčinnosť pri prechode k novému dodávateľovi.
Ak má dodávateľ po nasadení softvéru zabezpečovať pohotovosť, jej cenu treba dohodnúť osobitne. Otázke, či sa platí aj bez zásahu, sa venuje samostatná odpoveď v poradni.
Zmluva má chrániť obe strany
Dobre pripravená rámcová zmluva dáva objednávateľovi kontrolu nad rozpočtom. Dodávateľovi pomáha predísť tomu, aby vykonával prácu, ktorú nikto neschválil.
Zmluvu na IT dielo a agilný vývoj pripravíme alebo zrevidujeme pre objednávateľa aj dodávateľa. Pri nasadení cudzieho systému pripravíme implementačnú zmluvu a práva ku kódu upravíme v softvérovej a licenčnej zmluve. Pri dodávkach s pevným rozsahom pripravíme zmluvu o dielo.
Článok poskytuje všeobecné právne informácie podľa stavu k 26. 9. 2026. Nie je právnou službou ani radou pre konkrétnu situáciu. Právne predpisy sa menia a okolnosti vášho prípadu sa môžu líšiť. Pred rozhodnutím si preto postup overte alebo sa nám ozvite.
