facebook LinkedIN LinkedIN - follow
Tematické sekce
 
Branžové sekce
Přihlášení SystemNEWSPřehledy
 
Tematické seriály

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 
Nové!

RPA - automatizace procesů

Softwaroví roboti automatizují obchodní procesy.

články >>

 
Nové!

IoT – internet věcí

Internet věcí a jeho uplatnění napříč obory.

články >>

 
Nové!

VR – virtuální realita

Praktické využití virtuální reality ve službách i podnikových aplikacích.

články >>

 
Nové!

Bankovní identita (BankID)

K službám eGovernmentu přímo z internetového bankovnictví.

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
 
Partneři webu
IT SYSTEMS 5/2022 , IT právo

Právní aspekty agilního vývoje softwaru

Zdeněk Kučera


Rozhodování českých soudů ve sporech souvisejících s vývojem či implementací softwaru je zdlouhavé a komplikované. Většinou se jedná o spory závislé na výsledcích znaleckých posudků, bohužel znalců v této oblasti není dostatek, a navíc ne všichni jsou schopni formulovat své závěry tak, aby byly dostatečně srozumitelné pro soud. Nadto jsou závěry často ne zcela jasné, resp. mnohdy znalec dojde k závěrům, že dokumentace, která mu byla předložena, nemůže jednoznačně prokázat, která ze stran je na vině neúspěšného projektu.


Z toho důvodu klientům doporučujeme v případě takového sporu vyvinout maximální úsilí k narovnání vztahů mezi zhotovitelem a objednatelem softwaru. K narovnání vztahů může přispět jak mediátor (strany si jej mohou zvolit samy, případně jej může jmenovat soud), tak rozumný právní zástupce. Z naší zkušenosti ti advokáti, kteří se v oblasti práva ICT pohybují pravidelně, mají větší snahu hledat kompromisní řešení.

Zajímavým aktuálním rozhodnutím je rozhodnutí Okresního soudu v Opavě sp. zn. 138 C 31/2018-208. Jedná se však o rozhodnutí soudu nižší instance, nikoli soudu vyššího, které by mělo širší váhu. Rozhodnutí poutá pozornost zejména tím, že se soud zabýval agilním vývojem softwaru.

Obecně je agilní vývoj složitější na přípravu smluvní dokumentace, jelikož se na vývoji podílí několik stran živelně a je třeba podchytit primárně jejich odpovědnost a zdokumentovat dodávky kódu. Současně vždy doporučujeme ve smlouvě zakotvit možnost ukončení prací a smluvního vztahu v případě, že se ukáže, že spolupráce nefunguje. Toto ukončení musí být přitom vyvážené, tedy aby objednatel měl dostatečnou časovou flexibilitu a zhotovitel měl možnost převést vývojáře na jiný projekt.

V diskutovaném rozhodnutí soud posuzoval situaci, kdy zhotovitel softwaru požadoval po objednateli zaplacení částky, kterou objednatel s ohledem na kvalitu dodání rozporoval. Soud vycházel primárně ze znaleckého posudku, podle kterého byla cena dodaného díla zhruba třetinová oproti požadované. Nicméně znalec konsta­to­val, že využitelnost softwaru byla pro objednatele v zásadě nulová.

Soud v tomto případě žalobu zcela zamítl, a to zejména z následujících důvodů:

  • Nenalezl záznam o funkčním programu jako celku, který by byl převzat objednatelem, přičemž z neúplných částí zdrojových kódů je patrno, že byly rozpracovány dvě části budoucího programu (login a user). Toto však nelze považovat za program, u kterého by bylo možno stanovit tržní cenu.
  • V daném případě smlouva ukládá zhotoviteli povinnost upozornit na zadání, která nejsou v souladu s navrhovaným technickým řešením (nebylo přitom prokázáno, že by tak žalobkyně jako zhotovitel učinila).
  • Plnění dodané na podkladě objednávky rámcové netvoří ucelený program ani jeho části, které by mohly být uplatněny na trhu. Z tohoto důvodu nelze stanovit jeho adekvátní tržní cenu, resp. jeho tržní cena je v dodané podobě nulová.
  • Rozsah žalobkyní (jako zhotovitelem) vykázaných prací podle odevzdaného zdrojového kódu a jeho funkčnosti je výrazně nadhodnocený (minimálně 3x), zadávané služby byly sice zhotovitelem průběžně plněny, ale nedostatečné zadání a prakticky chybějící technická a datová analýza vyvíjeného programu vedly k většímu objemu práce, než by bylo potřeba v případě systematicky zadaného projektu.
  • Vzhledem k absenci dokumentace, popisu datového modelu a celkové specifikace vyvíjeného programu by naprogramované zdrojové kódy mohl k dalšímu vývoji efektivně využít pouze zhotovitel. Pro třetí stranu je využitelnost naprogramovaného zdrojového kódu prakticky nulová.

Soud současně konstatoval, že jednotlivé sprinty byly dílčími smlou­va­mi o dílo. To je přitom klíčové, protože pokud se strany nedo­hod­nou jinak, pak nárok na zaplacení vzniká předáním. V tomto případě byla tedy situace jednoduchá – fakturace za sprinty mohla probíhat až po jejich převzetí a odsouhlasení objednatelem. A k tomu nedošlo.

Soud tímto rozhodnutím připomněl, že při vývoji softwaru se nesmí zapomínat na jasné vymezení předávání dílčích částí díla. Současně je nutné zajistit, aby toto odpovídalo realitě. V praxi se často setkáváme s tím, že právníci ve shodě se smluvními stranami sice definují konkrétní postup, ale realita mezi stranami funguje jinak. Pak může nastat situace, že zhotovitel sice něco dodá, ale z pohledu smlouvy nevznikne na zaplacení nárok.

Zdeněk Kučera Zdeněk Kučera
Autor článku je partner a head of TMT v mezinárodní právní kanceláři Dentons s více než 15 lety zkušeností v oblasti práva ICT, obchodního práva a řešení sporů. Mezi jeho klienty patří globální korporace působící v IT a e-commerce, finanční instituce a společnosti z komunikačního, mediálního a obranného průmyslu.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.