Smlouva o dílo na vývoj software / aplikace: jednoduchá, ale může přinést i starosti

STRUČNÁ ODPOVĚĎ NA HLAVNÍ OTÁZKU

Smlouva na vývoj software nebo aplikace upravuje vztah mezi objednatelem, který požaduje vytvoření konkrétního řešení, a zhotovitelem, který jej vyvíjí.

Vedle samotného předmětu díla je potřeba řešit zejména specifikaci, harmonogram, cenu a změny zadání, testování a akceptaci, vady, další podporu a práva k vytvořenému software.

Zaplacení vývoje samo o sobě neznamená, že objednatel automaticky získává všechna myslitelná práva ke kódu a může s ním bez omezení nakládat.

Dobrá smlouva proto musí propojit technickou realitu projektu s právními pravidly spolupráce.

MOŽNÁ SI ŘÍKÁTE…

„Nestačí mít podrobnou technickou specifikaci?“

„Když vývoj zaplatím, není software automaticky můj?“

„Co když během vývoje zjistíme, že potřebujeme další funkce?“

„Kdy je aplikace vlastně hotová?“

„Co když po spuštění začnou vyskakovat chyby?“

„A co když se s vývojářem rozejdeme a budu potřebovat, aby projekt převzal někdo jiný?“

CO JE PROBLÉM V PRAXI (ODLIŠNOST OD TEORIE)

Na začátku projektu mají obě strany zpravidla stejný cíl.

Vytvořit software, který funguje.

Jenže během vývoje se projekt mění.

Objednatel zjistí, že potřebuje další funkci. Vývojář narazí na technické omezení. Ukáže se, že původní řešení je dražší, než se předpokládalo. Změní se externí API. Přidá se platební brána. Uživatelé při testování odhalí problém, se kterým původní zadání nepočítalo.

A právě tady začíná být smlouva důležitá.

Měla by umět odpovědět například na otázky:

• co přesně je předmětem vývoje,
• která dokumentace určuje zadání,
• kdo a jak může zadání měnit,
• co je ještě součást původní ceny a co už je vícepráce,
• kdo rozhoduje o technickém řešení,
• kdy se jednotlivé části předávají,
• podle čeho se testují,
• kdy je dílo považováno za akceptované,
• jak se řeší chyby a vady,
• jaká práva objednatel k výsledku získává.

Software totiž nevzniká jedním okamžikem.

Je to proces.

A smlouva musí počítat s tím, že se během tohoto procesu něco změní.

NEJVĚTŠÍ RIZIKA A CHYBY

U smluv na vývoj software se v praxi zaměřuji zejména na:

• příliš obecné nebo rozporné zadání,
• chybějící hierarchii smlouvy, specifikace a dalších dokumentů,
• neexistující proces změn zadání,
• nejasné rozlišení mezi opravou vady a novým požadavkem,
• pevnou cenu bez jasného rozsahu projektu,
• harmonogram bez pravidel pro součinnost objednatele,
• nejasnou akceptaci,
• neurčité požadavky typu „bezchybný software“,
• nedostatečnou úpravu autorských práv a licence,
• neřešené použití open-source nebo jiných komponent třetích stran,
• závislost objednatele na jediném dodavateli,
• neřešené předání zdrojového kódu, dokumentace a přístupů,
• předpoklad, že vývoj automaticky zahrnuje také dlouhodobou údržbu a podporu.

Typická chyba?

Objednatel si myslí:

„Tohle přece bylo součástí zadání.“

Vývojář si myslí:

„Tohle je úplně nová funkcionalita.“

Pokud smlouva nemá mechanismus, jak tuto hranici určit, technická debata se velmi rychle změní ve spor o peníze.

JAK POSTUPOVAT (REALITA, NE IDEÁL)

U smlouvy na vývoj software doporučuji nezačínat otázkou „jaký vzor použijeme“, ale tím, jak má projekt skutečně probíhat.

1. Určete, co má vzniknout

Nestačí „mobilní aplikace“ nebo „informační systém“.

Je potřeba vědět, kde je konkrétní zadání a kdo odpovídá za jeho vytvoření a schválení.

2. Nastavte způsob vývoje

Jinak bude fungovat projekt s pevně stanoveným výsledkem a cenou a jinak průběžný agilní vývoj.

Smlouva musí odpovídat realitě, nikoliv předstírat pevné zadání tam, kde se ve skutečnosti bude průběžně měnit.

3. Vyřešte změny

Kdo může změnu požadovat?

Kdo ji nacení?

Musí být předem schválena?

Jak ovlivní termín?

4. Nastavte předání a akceptaci

Je potřeba vědět, podle čeho objednatel pozná, že dodaná část odpovídá tomu, co bylo sjednáno.

5. Oddělte vývoj od následného provozu

Vývoj, opravy vad, maintenance, hosting, aktualizace a další rozvoj nejsou automaticky jedna služba.

6. Vyřešte práva k výsledku

Kód, grafika, databáze, dokumentace, externí komponenty – u každé části může být právní situace odlišná.

PŘÍKLADY Z PRAXE

👉 „Tohle jsme mysleli od začátku“

Objednatel požaduje během vývoje další funkci.

Tvrdí, že bez ní aplikace nedává obchodní smysl a byla tedy samozřejmou součástí zadání.

Vývojář namítá, že ve specifikaci vůbec není a její vytvoření zabere dalších 80 hodin.

Spor nevznikl kvůli tomu, že by jedna strana nutně jednala nepoctivě.

Každá jen od začátku chápala rozsah projektu jinak.

👉 Software funguje, ale objednatel jej nechce převzít

Vývojář předá aplikaci a vystaví fakturu.

Objednatel při testování najde několik chyb a odmítne dílo akceptovat.

Vývojář tvrdí, že jde o drobnosti, které nebrání používání.

Pokud smlouva nemá jasná akceptační kritéria a pravidla pro jednotlivé kategorie vad, začíná spor o samotný význam slova „hotovo“.

👉 Rozchod s dodavatelem

Po několika letech chce objednatel změnit vývojářskou společnost.

Teprve při předávání zjistí, že nemá kompletní zdrojové kódy, technickou dokumentaci, některé administrátorské přístupy ani jasně nastavená práva k části řešení.

Dokud spolupráce fungovala, nic z toho nebyl problém.

Ve chvíli, kdy měla skončit, se z toho stal problém zásadní.

PROČ OPATRNĚ S „UDĚLÁM SI SÁM“

Na internetu najdete smlouvu na vývoj software během několika minut.

Problém není získat text.

Problém je, že univerzální vzor neví, jak bude váš projekt skutečně fungovat.

Neví, zda máte pevné zadání nebo agilní vývoj.

Neví, zda cenu určujete za celý projekt, milestone nebo hodinu.

Neví, kdo vytváří specifikaci.

Neví, jak kritické jsou termíny.

Neví, zda bude software závislý na externích službách.

Neví, zda objednatel potřebuje možnost projekt kdykoliv převést k jinému dodavateli.

A neví ani to, jaká práva k výsledku skutečně potřebuje.

U software proto bývá nebezpečný nejen příliš krátký vzor.

Stejně nebezpečná může být dvacetistránková smlouva, která podrobně upravuje právní fráze, ale neodpovídá způsobu, jakým vývojový tým ve skutečnosti pracuje.

DOPORUČENÍ ADVOKÁTKY + CHECKLIST

U smlouvy na vývoj software doporučuji udělat jednoduchý test:

Kdyby se zítra projekt zastavil a obě strany se rozešly ve zlém, dokážu ze smlouvy zjistit, co mělo být hotové, kolik se má zaplatit, co se musí předat a co s dosavadním výsledkem může objednatel dál dělat?

Pokud ne, smlouva pravděpodobně neřeší některou z klíčových oblastí.

Rychlý checklist

• Je jasně definován předmět a rozsah vývoje.
• Je určeno, která specifikace je závazná.
• Existuje mechanismus změnových požadavků.
• Cena odpovídá zvolenému způsobu vývoje.
• Jsou nastaveny termíny a součinnost obou stran.
• Existuje jasný proces testování a akceptace.
• Je rozlišena vada a nový požadavek.
• Jsou vyřešena práva k software a dalším výstupům.
• Je řešeno použití komponent třetích stran.
• Je jasné, co bude předáno – včetně kódu, dokumentace a přístupů.
• Je oddělen vývoj od následné podpory a dalšího rozvoje.
• Smlouva počítá i s ukončením spolupráce.

FAQ

Je vývoj software smlouvou o dílo?

Vývoj software může být podle konkrétního nastavení vztahu řešen smlouvou o dílo, v praxi však smlouva často obsahuje také licenční, servisní a další prvky. Rozhodující není pouze její název, ale skutečný obsah spolupráce.

Když zaplatím vývoj software, patří mi automaticky zdrojový kód?

Samotné zaplacení vývoje neznamená automaticky, že objednatel získává všechna myslitelná oprávnění ke zdrojovému kódu. Práva k software a způsob jeho dalšího použití je potřeba ve smlouvě nastavit výslovně a s ohledem na konkrétní projekt.

Co je akceptace software?

Jde o proces, při kterém se ověřuje, zda dodané řešení odpovídá sjednaným požadavkům. Dobře nastavená smlouva určuje způsob testování, lhůty, postup při zjištění vad a okamžik, kdy je výstup považován za převzatý.

Jak řešit změny zadání během vývoje?

Smlouva by měla obsahovat změnový mechanismus – kdo může změnu navrhnout, jak se posoudí její dopad na cenu a termín a kdy se stává závaznou. U dynamických projektů je právě tento proces často důležitější než původní specifikace.

Jaký je rozdíl mezi vadou a víceprací?

Zjednodušeně: vada znamená, že výsledek neodpovídá tomu, co mělo být dodáno. Vícepráce představuje požadavek na něco, co součástí původně sjednaného rozsahu nebylo. V praxi je rozhodující kvalita původního zadání a změnového procesu.

Má smlouva řešit i servis a údržbu?

Pokud má dodavatel po dokončení software zajišťovat podporu, aktualizace, SLA, hosting nebo další rozvoj, je vhodné tyto služby výslovně nastavit. Samotné vytvoření software automaticky neřeší celý jeho budoucí životní cyklus.