Nejčastější úskalí IT smluv
Cílem tohoto příspěvku není detailně obsáhnout všechny problémy, se kterými se můžete při vývoji setkat, a které byste měli mít smluvně ošetřeny, ale upozornit jen na vybrané z nich.
Nebudu zde řešit, zda se jedná o klasický vývoj anebo agilní, protože níže uvedené problémy budete muset řešit tak jako tak.
Požadavky na součinnost
Nestačí jen uvést, že objednatel je povinen poskytnout součinnost. Vždy byste měli vydefinovat, v čem přesně je ona součinnost požadována, jak o ní má být požádáno a co přesně musí být poskytnuto, dokdy a také, co bude následovat, když daná součinnost nebude v požadované kvalitě a čase poskytnuta.
Pokud toto neuděláte, může dodavatel blokovat své plnění se zdůvodněním, že nemá dostatečnou součinnost. Rovněž byste měli do smlouvy uvést, jak se bude postupovat v případě, že se vyskytne nějaký problém a bude se muset rozhodnout o dalším postupu.
Na začátku spolupráce jsou totiž typicky smluvní strany přátelské a otevřené flexibilním dohodám, naopak na konci spolupráce již často existují zásadní obchodní a osobní spory, které velmi znesnadňují dosažení oboustranně přijatelné dohody.
Požadavky na licence a vlastnictví zdrojového kódu
Ve smlouvě byste si měli vyhradit dostatečně široká oprávnění k užívání a změnám software a dalším chráněným výstupům (včetně dokumentace), abyste mohli software užívat a rozvíjet i do budoucna. Většinou stačí mít takto široká práva pouze k části software, a to k části, která je vyvíjena pro vás na míru. Pokud software obsahuje standardní řešení (např. databázový software, samozřejmě licence k nim bude poskytována v užším rozsahu, což při správném nastavení nemusí bránit v dalším užívání a rozvoji software). Smlouva by také měla umožňovat plnění s užitím open source software a zohledňovat jeho specifika.
Ve smlouvě byste si také měli ujasnit, jaká budete mít práva na zdrojový kód, a to typicky k části software vyvíjené na míru. Protože třeba právo na přístup ke zdrojovému kódu, která je třeba uložen u notáře, ještě nemusí znamenat, že jej můžete předat třetí straně (můžete tam mít, že to je možné pouze se souhlasem autora) a že jej můžete modifikovat (můžete mít právo jen na jeho audit) a použít, aniž byste přišli o záruku nebo podporu (což také dává smysl, protože do něj můžete zanést chybu).
Dále byste měli mít ve smlouvě uvedeno, že kód bude dostatečně srozumitelně dokumentován (uveďte i v jakém jazyce, protože psát kód může kdokoli) a nebude obfuskován (možná vám to přijde zbytečné, ale není, protože nečitelný kód vám bude naprosto k ničemu).
Definice požadavků
Při klasickém vývoji bývá zpravidla definice požadavků detailnější a přesnější, ale přesto bych doporučoval, abyste jí věnovali dostatečnou pozornost. Vyhnete se pak zbytečným diskusím typu: „Mně se to nelíbí, je to pomalé, je to složité na ovládání, moc klikání.“ apod.
Čím přesnější definice požadavků bude a to nejen funkčních, ale i těch nefunkčních (user experience, rychlost odezvy, apod.), tím přesnější můžete získat odhad co do celkových nákladů a délky trvání projektu. Netřeba snad dodávat, že na odhadu nákladů a délce trvání by se měl podílet i dodavatel.
Změna poskytovatele služby
V okamžiku, kdy se rozhodnete pro přesun svého systému do cloudu anebo si už rovnou necháte danou aplikaci vyvinout v cloudu, tak zvažte, že pokud si to smluvně neošetříte, tak možnost přejít k jinému CSP může být značně omezená, a může dojít k jevu nazvaném vendor lock-in.
Dle smlouvy třeba budete mít možnost provést export svých dat, ale už nemusí být uvedeno jak, v jakém formátu, kam, a jak dlouho to bude trvat a zda se bude jednat jen o data anebo i metadata, referenční vazby, kód, nastavení, apod.
Proto by smlouva měla obsahovat povinnost poskytovatele vypracovat exitový plán se stanovenými náležitostmi, realizovat exit dle tohoto plánu, a případně poskytovat vyžádanou součinnost nad rámec exitu, placenou dle skutečného čerpání. Dle zkušeností z praxe je detailní úprava exitu často důležitější než úprava povinností při tvorbě informačního systému.
Nepředvídatelné zvýšení ceny
Je potřeba se připravit na situaci, že původní předpoklady smluvních stran při uzavírání smlouvy se během plnění mohou ukázat jako nepřesné. Měli byste mít smluvně ošetřeno, jak se bude postupovat v případě, když vám dodavatel po detailní analýze řekne, že skutečná cena bude nakonec vyšší, než jste předpokládali.
V takové situaci je vhodnější si sjednat již předem formu částečné kompenzace, která bude pro obě strany odstrašující a spíše přiměje strany nelézt shodu, protože objednateli se nebude chtít platit za něco, co mu není k užitku a zároveň dodavatel nebude spokojený, že by nedostal zaplacenu celou cenu za analytickou fázi, kterou řádně splnil.
Smlouva by samozřejmě měla umožňovat také úpravu specifikace dle nových či změněných požadavků objednatele. Mělo by tak být možné jak dohodou stran změnit, co je dodáváno, tak objednat další vývoj dodaného plnění ze strany dodavatele. Praxe ukazuje, že taková potřeba vyvstane téměř vždy.
Záruka za vady
S odstraněním nálezů v akceptačních testech zpravidla nebývá problém. Horší je to s nálezy, které jsou v rozporu s best practice, ať už z oblasti designu, user experience anebo bezpečnosti. Ovšem největší problém představují vady, na které se nepřišlo v rámci akceptačních testů, ale třeba až po několika měsících provozu.
A do kolika měsíců nebo let může objednatel požadovat nápravu? A kolik bude odstranění závady stát, do kdy od nahlášení bude závada odstraněna? I to byste měli mít ve smlouvě.
Řešení sporů
Je lepší soudním sporům předcházet a pokusit se dohodnout mimosoudně, protože soudy se mohou táhnout i několik let, stát několik miliónů a nakonec budou tratit obě strany.
Do smlouvy si dejte, že v případě sporu se spustí eskalační procedura, pokud nedojde k vyřešení, tak se pozve nezávislý konzultant, soudní znalec, mediátor či rozhodce a ten rozhodne, resp. strany se dobrovolně podvolí jeho názoru namísto vedení zdlouhavého soudního sporu. Ideálně by samozřejmě měla být celá smlouva připravena tak, aby dávala minimum prostoru pro nejasnosti a nutila strany k postupu smlouvou předvídanému.
Závěrem bych chtěl poděkovat pánům Josefovi Donátovi a Janu Tomíškovi z Rowan Legal, kteří mě k napsání tohoto příspěvku inspirovali, a na které vám doporučuji se s důvěrou obrátit, pokud byste se chtěli výše uvedeným problémům a nejen jim, vyhnout.
K článku “Nejčastější úskalí IT smluv” se zde nenachází žádný komentář - buďte první.
Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.
