Rámcová smlouva o dílo není smlouva o agilním vývoji

Autor: JUDr. Tomáš Šetina, advokát 

Trendem v oblasti IT je agilita, resp. agilní vývoj, který má vícero podob. Jak ale různé formy agilního vývoje podchytit smluvně? Problém je v tom, že smlouva o agilní spolupráci není smluvním typem upraveným v zákoně, na právnických fakultách její pravidla nikdo neučí (resp. prozatím neučil). Při jejím vytváření se pohybujeme v multioborovém prostředí, kde kromě právních znalostí je třeba i znalost pravidel agilní spolupráce. 

Agilní vývoj má svá pravidla. Podstatou agilní spolupráce je kontinuální komunikace a operativní řízení projektu. Agilita, ve smyslu pružnosti, umožňuje v podstatě kontinuální řízení procesů změn při řešení projektu. Podstatná ve smlouvě je tedy úprava samotných procesů, na které by měl být kladen největší důraz, nikoli detailní popis finálního výsledku, protože výsledek v okamžiku začátku vývoje je ze své podstaty nejasný. Pokud na kreativní prostředí začnu násilně roubovat institut smlouvy o dílo, nastanou obvykle dvě situace: a) zadělám si na problém, kdy obvykle pláče ta důvěřivější strana nebo b) smlouva se stane funkčně (nikoli právně) obsolentní, neboť dojde k roztržce mezi formálním zněním smlouvy a reálným životem smluvního vztahu.

Ve své praxi se setkávám s několika přístupy:

1. Agilní spolupráce nepotřebuje žádné smlouvy, na všem se domluvíme. Možná se jedná o předzvěst světa bez smluv a právníků, kde všichni budou nezištně spolupracovat. Nevím, nicméně setkávám se s tím, že někde tento přístup opravdu funguje. Alespoň do okamžiku, než se objeví první neshody.
2. Agilní spolupráce je jen forma smlouvy o dílo. To bohužel určitě není, jak je zdůvodněno výše. Kromě právních hledisek je zde i hledisko faktické - jakmile nastavíme pevnou cenu díla, přesune se kreativita stran k tomu, jak se co nejsnadněji dostat k nasmlouvané odměně.
3. Agilní spolupráci upravíme formou rámcové smlouvy. Uzavřeme rámcovou smlouvu a jednotlivé části procesu vývoje, kterým se nejčastěji říká sprinty, budeme řešit formou dílčích smluv (objednávek). Problém tohoto řešení je opět v tom, že pokud použijeme klasickou smlouvu o dílo a pouze ji budeme modifikovat pomocí dílčích smluv (objednávek), jsme stále v režimu klasické smlouvy o dílo. Zasmluvňování sprintů formou objednávek či dodatků má jeden důsledek - budeme dělat úplně zbytečnou práci. Fakticky se tak budou do dílčích objednávek přepisovat zápisy z porad, aktuální záznamy z product backlogů, či jiných dokumentů. Nehledě na to, že každá činnost generuje množinu chyb a nejlepší prevence chyb je prostě určité věci nedělat. Lze namítnout, že případná modifikace smluvního vztahu formou dílčích objednávek, resp. často fakticky dodatků ke smlouvě, umožňuje právě onen flexibilní přístup a přizpůsobování smluvního vztahu aktuálním potřebám stran. Nicméně, jak jsem uvedl výše, je to možné, někdy to může fungovat, ale neustálé změny základů smluvního vztahu formou dodatků v týdenních - čtrnáctidenních intervalech považuji za zbytečné, administrativně náročné a právně rizikové.

Jaké jsou tedy doporučení k tvorbě smluv o agilním vývoji?

1. Smlouvu o agilním vývoji považuji zejména za smlouvu o "pravidlech spolupráce", podstatou smlouvy je popsat procesy a postupy. Tyto procesy však musejí být nastaveny v důsledku kontraktačního procesu obou stran ideálně pod vedením osoby obeznámené s agilním řízením spolupráce. Úkolem právníka je toto srozumitelně popsat, nicméně hlavní těžiště a výhoda je v procesu domluvy a nastavení pravidel mezi účastníky. V tomto kontextu určitě nedoporučuji podpisy "šablonovitých" či "vzorových" smluv, smlouva se v tomto případě musí přizpůsobit potřebám klientů a ne naopak. U "vzorových" smluv zcela odpadá klíčový proces domlouvání a tvoření. Mimochodem, proces domlouvání a tvoření pravidel/smlouvy je výborná příležitost ke vzájemnému otestování stran.
2. Ve smlouvě o agilním vývoji doporučuji věnovat pozornost definování pojmů. Z agility známe termíny jako např. owner, product backlog, scrum, scrum master apod., nicméně vzhledem k určité živelnosti aplikace agility (alespoň v našich podmínkách), si pod těmito slovy může každá ze smluvních stran představit trochu něco jiného.
3. Nastavení rytmu a procesů. Minimálně doporučuji nastavit přesné intervaly schůzek a sprintů, a to v rozmezí týden až čtrnáct dní. Bez pravidelného rytmu nemůžeme mluvit o agilitě, nahodilost a anarchie nejsou agilita. Pokud v agilní smlouvě klást v něčem důraz a trestat sankcemi, tak především to, že na schůzku nepřijde ten, kdo tam přijít má.
4. Nastavení rolí, komunikace, řešení sporů. Pokud je z hlediska právníka v něčem výhoda agilních spolupráce, tak v tom, že umožňuje identifikovat problém v zárodku a řešit jej v době, kdy to má smysl. Smlouva o agilním vývoji neznamená, že nemůže dojít ke sporu, příp. k soudnímu sporu. Může a stává se to. Smlouva o agilním vývoji by ale měla stranám umožnit zavčas identifikovat problém a "donutit" je tento problém zavčas řešit.

Není ovšem smyslem tohoto článku popsat podrobně smlouvu o agilním vývoji. Smyslem tohoto textu bylo především zdůraznění rozdílu mezi smlouvou o dílo, resp. rámcovou smlouvou o dílo a smlouvou a agilním vývoji, uvedení výhod smlouvy o agilním vývoji a konečně několik doporučení pro přípravu agilní smlouvy.

Článek byl publikován dne 14. 7. 2020 na webu Právní prostor.cz