Smlouva na jednu A4: Proč je to recept na katastrofu

V IT světě existuje nebezpečná iluze, že smlouvy jsou byrokracie a že "my si přece věříme." Za léta praxe jsme viděli, kam tahle důvěra vede — a většinou to nekončí dobře. Tady jsou příběhy, které nám daly tu nejcennější lekci: dobrá smlouva chrání obě strany.

"Udělejte aplikaci" — a to je celá smlouva

Převzali jsme projekt od klienta, který se soudil se svým předchozím dodavatelem. Když jsme se zeptali na smlouvu, ukázal nám dokument na jednu A4. Celý text zněl přibližně takto:

"Dodavatel vytvoří webovou aplikaci dle požadavků objednatele. Cena: 200 000 Kč. Termín: 3 měsíce."

To bylo všechno. Žádná specifikace. Žádný popis funkčnosti. Žádné akceptační kritéria. Žádné milníky. Žádné ustanovení o změnách požadavků.

Co se stalo? Klient chtěl e-shop s pokročilým CRM, věrnostním programem a napojením na sklad. Dodavatel dodal základní e-shop se statickými stránkami. Oba měli svou pravdu — protože smlouva neříkala nic konkrétního. Soud trval déle než původní projekt a stál víc než samotná aplikace.

Gentleman's agreement a paměť rybičky

Další oblíbený scénář: klient a dodavatel si vše domluví na schůzce, potřesou si rukou a jdou pracovat. Žádná smlouva, žádný zápis, žádné e-maily potvrzující, co bylo dohodnuto.

Pracovali jsme s firmou, kde se takhle dohodli na vývoji mobilní aplikace. Na schůzce se bavili dvě hodiny. Dodavatel začal pracovat. Po dvou měsících klient řekl: "Kde je integrace s naším účetním systémem? To jsme přece řešili." Dodavatel odpověděl: "Ne, to nebylo součástí dohody." Klient tvrdil, že ano. Dodavatel tvrdil, že ne.

Kdo měl pravdu? Nikdo neví. Protože neexistoval žádný dokument, na který by se dalo odkázat. Lidská paměť je nespolehlivá, zvlášť když jde o peníze a termíny. Co si dva lidé zapamatují ze stejné schůzky, se může diametrálně lišit.

Výsledek? Tři měsíce hádek, narušený vztah a aplikace, kterou nakonec předělával někdo jiný (my).

Dodavatel, který zmizel uprostřed projektu

Tenhle příběh je bohužel častější, než by se zdálo. Firma najala freelancera na vývoj webové aplikace. Zaplatila zálohu 50 % — sto tisíc korun. Freelancer dodal první verzi, která víceméně fungovala. Pak přestal odpovídat na e-maily. Telefon nezvedal. Na LinkedIn změnil status na "Open to Work" v jiné zemi.

Smlouva? Existovala, ale neobsahovala žádné ustanovení o tom, co se stane v případě nedokončení projektu. Žádné sankce. Žádné milníky s částečnými platbami. Žádné escrow. Záloha byla pryč a firma měla v ruce nedokončený kód, ke kterému neměla ani přístup do repozitáře.

Když jsme ten kód nakonec získali (přes poskytovatele hostingu), zjistili jsme, že polovina funkčnosti byla natvrdo napojená na freelancerovy osobní účty — jeho AWS, jeho Firebase, jeho API klíče. Odpojení od jeho infrastruktury trvalo déle než celý původní vývoj.

Kdo vlastně vlastní ten kód?

Otázka duševního vlastnictví je v IT smluvních vztazích jedna z nejkritičtějších — a nejčastěji opomíjených.

Přišla k nám firma, která pět let platila měsíční paušál dodavateli za správu a rozvoj své webové aplikace. Když se rozhodli přejít k jinému dodavateli, původní firma řekla: "Jasně, ale kód je náš. Vy jste platili za službu, ne za kód."

A měli pravdu. Ve smlouvě nebylo jediné slovo o převodu autorských práv. Podle českého autorského zákona vlastní dílo autor — tedy dodavatel — pokud smlouva neříká jinak. Firma platila pět let za produkt, který jí právně nepatřil.

Tohle je situace, kde se vyplatí investovat do právníka, který rozumí IT. Licenční ujednání, převod majetkových práv, právo na zdrojový kód — to všechno musí být ve smlouvě explicitně.

Změny bez dodatku? To se nevyplatí

Software se během vývoje mění. To je normální a zdravé. Ale pokud nemáte proces pro řízení změn, skončíte v chaosu.

Viděli jsme projekt, kde klient průběžně přidával požadavky — "ještě tuhle maličkost" a "tohle bude rychlé" — bez jakékoli formální změny smlouvy nebo rozpočtu. Po šesti měsících byl projekt dvojnásobně rozsáhlý oproti původnímu zadání, ale rozpočet zůstal stejný. Dodavatel nakonec odmítl pokračovat, klient odmítl platit víc. Oba byli frustrovaní a projekt skončil nedokončený.

Jednoduchý change management proces by tomu zabránil: změna požadavků → odhad dopadu na čas a cenu → schválení → dodatek ke smlouvě. Zdá se to byrokratické, ale ušetří to měsíce hádek.

Co má obsahovat dobrá smlouva na vývoj softwaru

Po všech těch hrůzách pojďme k praktické části. Dobrá smlouva na zakázkový vývoj by měla obsahovat minimálně:

Specifikaci díla. Co přesně se dodává. Ne "aplikace," ale konkrétní seznam funkcí, technických požadavků a akceptačních kritérií. Ideálně jako příloha smlouvy.

Harmonogram a milníky. Rozčlenění projektu na etapy s konkrétními termíny a dodávanými výstupy pro každou etapu.

Platební podmínky navázané na milníky. Platby vázané na dokončení a akceptaci etap, ne jednorázová záloha předem.

Proces řízení změn. Jak se řeší změny oproti původní specifikaci — postup, schvalování, dopad na cenu a termín.

Duševní vlastnictví. Kdo vlastní kód, design, dokumentaci. Kdy přecházejí práva — při dodání, při zaplacení, průběžně?

Přístup ke zdrojovému kódu. Kde je kód uložen, kdo má přístup, co se stane s kódem při ukončení spolupráce.

Záruční podmínky. Co se děje po dodání — záruční doba, oprava chyb, podpora.

Ustanovení o ukončení. Co se stane, když jedna strana chce spolupráci ukončit předčasně. Jaké jsou povinnosti obou stran.

Mlčenlivost a ochrana dat. Obzvlášť důležité, pokud dodavatel pracuje s citlivými daty klienta.

Smlouva chrání i dodavatele

Důležitý bod: dobrá smlouva nechrání jen klienta. Chrání i dodavatele. Bez jasné specifikace nemůže dodavatel prokázat, že dodal to, co bylo dohodnuto. Bez procesu řízení změn nemůže odmítnout nekonečné rozšiřování projektu. Bez platebních milníků nemá jistotu, že za svou práci dostane zaplaceno.

My sami máme zkušenosti z obou stran — a víme, že dobře napsaná smlouva je základ zdravého obchodního vztahu.

Poučení na závěr

Smlouvy nejsou projevem nedůvěry. Jsou projevem profesionality. Dobrá smlouva zajišťuje, že obě strany mají stejné očekávání, a poskytuje rámec pro řešení problémů, které nevyhnutelně nastanou.

Morál příběhu: Smlouva na jednu A4 je pozvánka ke katastrofě. Investujte čas a peníze do pořádné smlouvy na začátku — je to zlomek toho, co vás bude stát spor na konci. A pokud vám někdo řekne "nepotřebujeme smlouvu, my si přece věříme" — právě proto ji potřebujete.