Objednat software a nespálit se? Položte si tyto 3 otázky.

Máme jasno v tom, o jaký software jde? 

První otázka zní triviálně. No samozřejmě, že víme, co chceme za software. Navíc jsme se o tom s dodavatelem před uzavření smlouvy přece bavili! 

Společné porozumění před zahájením vývoje je samozřejmě důležité, ale nemusí stačit. Co když jste se v něčem nepochopili? Nebo jste prostě jen něco zapomněli řešit? 

Jsou prakticky dvě cesty, kterými se můžete vydat. Modrá nebo červená pilulka. 

(🔵 Modrá pilulka) Ve smlouvě si buď dostatečně podrobně vymezte, o jaký software jde.  

(🔴 Červená pilulka) Anebo si stanovte přesný proces toho, jak budete toto vymezení software řešit dál v rámci už placené spolupráce. 

Autor tohoto článku by si stejně jako Neo u většiny software vybral spíše červenou pilulku. Zvlášť u složitějšího software totiž výběr té modré znamená poměrně velký tlak na to, aby vymezení bylo skutečně důkladné a je lepší jít procesní cestou. Obě řešení však mohou mít svoje výhody. 

Přesné vymezení? Ano, ale… 

První postup, tedy co nejpřesnější vymezení požadavků na software, odpovídá spíše tradičnější a starší waterfall metodě vývoje software. Ta je založená na tom, že v úvodu spolupráce máte velmi přesně vymezeno a naceněno, co je předmětem vývoje. U software, který neobjevuje Ameriku, může být takový postup zcela legitimní. 

Při standardním waterfall vývoji a přesném vymezení software však mějte na paměti, že vkládáte velkou důvěru v dodavatele a v kvalitu zadání software. Nezřídka se vyplatí, si toto zadání nechat zpracovat také externě (viz tip #4).  

Tip #1 Věnujte popisu software dost času a trvejte na průběžném testování a kontrole dílčích částí.  

Nenechte dodavatele, ať se se software zavře na dva roky do jeskyně! Na konci můžete být nepříjemně překvapení. 

Tip #2 Spolu s průběžnou kontrolou myslete na to, že člověk míní a život mění. Stanovte si tedy ve smlouvě postup toho, jak se může vymezení software a zadání měnit (tzv. change management) a jaký to bude mít vliv na povinnosti dodavatele, cenu a termín dodání. 

Vymezení procesu může být cesta. 

Jsou však situace, kdy třeba máte základní představy o daném software. Ale nedokážete nebo ani nechcete vymezit software přesně. K jeho finální podobě dojdete až spoluprací s dodavatelem a neustálým iterováním a zlepšováním software. Tento agilní přístup má svoje výhody tam, kde chcete rychleji mít základní funkční software nebo kde se jedná o unikátní produkt.  

Případně se může hodit i tam, kdy máte zájem dlouhodobější postupný rozvoj a pravidelnou kontrolu toho, jestli vývoj směřuje správným směrem. Jedním se základním požadavků „správné“ agility je totiž neustálá kontrola toho, jestli vývoj přináší zákazníkovi stále hodnotu. Tento level péče u waterfall vývoje někdy není možný, protože ten někdy bohužel stále počítá s dlouhými nerušenými úseky vývoje a menší komunikací dodavatele a zákazníka. 

Tato kontrola probíhá pravidelně díky tomu, že vývoj probíhá v krátkých úsecích. Ty například nejznámější agilní metodika SCRUM nazývá „sprinty.“ Neznamená to, že úseky trvají 9.58 sekundy jako rekordní sprint Usaina Bolta na světovém šampionátu v roce 2009 v Berlíně. Ale běžně jsou skutečně velmi krátké – řadově v týdnech. 

Další tipy, které vám pomůžou si tuto otázku zodpovědět a snížit riziko 

Tip #3 Vymezte software ideálně z více úhlů pohledu. 

Když už se rozhodnete pro vymezení předem (přístup spíše odpovídající waterfall metodě), opravdu dbejte na to, aby bylo vymezení co nejkomplexnější. Uvést pouze účel, na co software chcete, je spíš nedostatečné. Doplňte to popisem jednotlivých funkcí. Uveďte konkrétní příklady toho, co musí software umět. Stanovte základní výkonností parametry, které musí být splněny. Uveďte požadavky na kompatibilitu.  

Prostě a jednoduše nespoléhejte na to, že bude jako vymezení ve smlouvě stačit: 

„Objednatel má zájem o vytvoření software, který bude sloužit pro správu marketingových kampaní objednatele“ 

Takový popis by mohl s odřenýma ušima stačit ve chvíli, kdy bude smlouva jasně upravovat proces, kterým dojde k upřesnění tohoto vágnějšího požadavku. To ale běžně „waterfall“ smlouvy spoléhající na popis software už v úvodu spolupráce neřeší. 

Tip #4 Investice do úvodní analýzy se vám může bohatě vrátit! 

Stanovit přesněji požadavky na software lze tím, že necháte vývojáře zhotovit analýzu požadavků a návrhu řešení. Jedná se o další krok před zahájením vývoje, náklady na něj se vám však můžou násobně vrátit díky hladšímu vývoji. Kdo je připraven, není překvapen! Tuto analýzu je také vhodné řešit kratší smlouvou. 

Tip #5 Pokud se místo konkrétních požadavků na software rozhodnete jít agilnější variantou, kdy vaše požadavky na software budou vznikat postupně, myslete na popis celého procesu.  

Měli byste popsat například: 

• Jak probíhá tvorba seznamu úvodních požadavků (někdy také tzv. backlog požadavků)? Vytváříte ho vy sami jako zákazník nebo chcete úvodní vymezení požadavků na software nechat na dodavateli?  
• Chcete tasky v backlogu rovnou orientačně nacenit? Nebo se bude naceňovat konkrétní sprint? Anebo se pojede jenom hodinovkou a výkazy? 
• Jak musí být požadavky v backlogu formulovány? 
• Kdo a jak může přidávat a měnit požadavky? 
• Jak se rozhodne, které požadavky mají prioritu a zařadí se na program vývoje do určitého sprintu? 
• Co se bude dít, pokud se daný požadavek během sprintu nestihne vyvinout nebo je potřeba v průběhu vývoje změnit jeho zaměření? Tady můžeme doporučit, aby se taková změna nebo nový požadavek řešily ve sprintu novém a stávající dohoda na sprintu současném se neměnila. 

Tip #6 Pokud se vydáváte agilní cestou, ujasněte si už v úvodu vývoje ve smlouvě, co vady. 

Vzhledem k tomu, že u agilního vývoje chybí v úvodu konkrétnější vymezení software, je vhodné na to myslet i při vymezení vad. Co je totiž vada (tj. rozpor se zadáním), když konkrétní vymezení software chybí? I u agilního vývoje se ale dají vady nebo prostě postup řešení chyb nějak vymezit. Ideální je například: 

• Stanovení nějakých kvantifikovatelných požadavků, které musí SW vždy splňovat. Například už výše zmíněné požadavky na kompatibilitu nebo výkonností požadavky (rychlost načítání webu, maximální kapacita v zátěži, počet operací za minutu). 
• Zakotvení společné schůzky nebo testovacích postupů, které v krátké lhůtě po předání části software zajistí jeho testování. Cokoli zjištěné během testu může být vyhodnoceno buď jako vada nebo návrh na novou feature do dalšího sprintu. S tím souvisí, že je dobré vymezit, co vada je a co není (např. chyba způsobená zákazníkem nebo třetí stranou či subjektivní nespokojenost zákazníka nezohledněná v zadání by vadou být neměly).  
• Doplnění smlouvy o vývoji i servisní smlouvou / SLA, které zajistí, že i chyby co nejsou vadami a nebudou bezplatně odstraňovány budou i tak včas řešeny. 

Tip #7 Vykašlete se na záruku za jakost, je to nesmysl. 

Velkou chybou je naopak spoléhat se při vývoji software na záruku. Dodavatel vám dá 24 měsíců záruku na to, že software je při předání i později úplně tip top a bez chyby, prostě nejlepší software na východ od Silicon Valley. To zní dobře ne? Na první poslech možná, ale záruka je z mnoha důvodů u software nevhodná a vede spíše ke sporům. Proč? 

• Záruka je právní institut, který je určen pro věci, které se opotřebovávají. Představte si součástku ve vašem robotickém vysavači. Software se neopotřebovává. 
• Software ale může zastarávat. Pokud si ho jen necháte vyvinout a pak na něj ty 2 roky nešáhnete, může se to stát. Může být náchylnější ke kybernetickým útokům. Některé funkce mohou přestat fungovat. To ale není něco, co může vývojář běžně ovlivnit (pokud nejste domluveni, že bude software monitorovat a rozvíjet, to je jiná). 
• V každém software je aspoň jedna chyba. Ano, i v tom, co dostanete vy. Ať jde o webovky pro e‑shop nebo řídící software Muskovy rakety. Software je komplexní produkt s hodně neznámými a záruka je dost přísný institut. 
• Software ovlivňuje jeho okolí. Vaše (potenciálně neodborné nebo omylné) zásahy. Integrace programů třetích stran, které se mohou změnit a váš software to rozhodí. Případně neoprávněné útoky nebo zásahy třetích stran, kterým nemusí někdy odolat ani sebelíp vyvinutý software (zvlášť pokud třeba lehce zastaral). Za tohle může dodavatel jen těžko odpovídat, pokud mu tedy přesně za to dál neplatíte. 
• Málokterý software je dnes vyvíjen na zelené louce. To by pak každý software stál miliony. Použití už vyvinutých komponentů třetích stran je běžné, vývoj zlevňuje a zrychluje. Ale může s sebou nést riziko. Dobrý dodavatel by měl samozřejmě vybrat například vhodný free and open source software (FOSS). Jelikož však části software nevyvíjel, proto aby vy jste ušetřili, nemusí být rozumné chtít záruku. Tady je to ale samozřejmě na hraně. Můžete určitě po dodavateli požadovat, aby tento FOSS do vašeho software správně integroval.  

Takže opakujte po nás. U software nechceme vidět záruku! Vyžadováním záruky chcete, aby váš dodavatel byl zároveň vaše pojišťovna, což si (stejně jako ony) rád nechá zaplatit.  

Co chceme se software dělat? 

Paráda. Máte vymezeno, co za software chcete. Anebo alespoň víte, jak k tomu společně s dodavatelem dojdete. 

Odpovídá ale dohoda ve smlouvě tomu, jak chcete software používat? Pokud se vidíte v některém tvrzení níže, je velká šance, že vám pomůže řešit fajfky v druhém sloupečku. A taky vyhnout se křížkům.

Co budeme dělat, až spolupráce skončí? 

Říká se, že všechno dobré jednou končí. A pokud končí dobrá spolupráce, často to je „na podání ruky“ bez problému. Je ale dobré připravit se na situace, kdy se kdykoli v průběhu – nebo například ve chvíli, kdy jedna strana oznámí zájem smlouvu ukončit – z dobré spolupráce stane špatná. 

Takový problém může vás jako zákazníka, ale i vašeho dodavatele, vést k ukončení smlouvy. I špatná spolupráce tedy naštěstí jednou končí, ale otázka je jak. 

Co v takovém případě dělat s již vyvinutým software? A jak řešit části software, které se zrovna vyvíjely? 

Odpověď existuje a říká se jí často exit plán. Co by měl obsahovat? 

• Ještě před exit plánem by už od začátku mělo být jasné, co bude se zdrojovým kódem. Pokud k němu budete mít přístup, měl by být během trvání smlouvy pravidelně aktualizován. Měl by být zhotovován v souladu s požadavky na vývoj software, komentován. Prostě připravován tak, aby na něj jednou někdo mohl navázat. 
• V rámci exit plánu by měl dodavatel zajistit, že budete mít aktuální, kompletní a popsaný zdrojový kód. Pokud to tak bude, máte z půlky vyhráno, protože nového dodavatele většinou najdete a ušetříte jemu práci a sobě peníze. 
• Chtějte po původním dodavateli zaškolení nového. A klidně si rovnou vymezte přibližný rozsah a ideálně i cenu, kterou dodavatel za tuto součinnost bude chtít. Součástí by mělo být předání a vysvětlení zdrojového kódu a dokumentace k software. 
• Tam, kde dodavatel nechce poskytnout zdrojové kódy (např. standardizovaná část software, kterou používá i pro další zákazníky), nemusíte zoufat. Řešením může být vytvoření API a manuálu k němu. 
• Nezapomeňte ani na předání přístupu k veškeré infrastruktuře, účtům a admin rozhraním nebo na export dat, pokud je potřeba.  
• Řešte, co bude s rozpracovanými částmi díla a placením za ně. Jestli je má dodavatel dokončit, anebo aktivací exit plánu už všechny práce končí. 
• Myslete i na to, že během řešení exit plánu stále můžete potřebovat podporu a servis 

Exit plán může myslet i na další situace. Chcete, aby vám původní dodavatel i pomohl najít nového? Rádi byste zajistili, že v případě ukončení činnosti dodavatele nebo skončení podpory jeho produktu se dostanete ke zdrojovému kódu?  

Pokud je pro vás software smrtelně důležitý, můžete zvážit i úschovu zdrojového kódu u nezávislé třetí strany (escrow). 

Celý exit plán by měl být spojený s jasnými lhůtami a odměnou pro dodavatele. A utvrzen smluvními pokutami. 

Závěrem 

Pokud ve smlouvě vymezíte opravdu dobře, jaký software chcete (nebo jak k tomu dospějete), k čemu máte zájem ho používat a co se bude dít, pokud skončíte spolupráci s původním dodavatelem, pak jste možná dál než většina dalších firem, co si objednávají software. 

V dalším pokračování článku se dozvíte několik dalších věcí, které pro úspěšný vývoj software můžete udělat. 

Máte k článku dotaz nebo byste potřebovali pomoct vývojem software? Ozvěte se nám na číslo 255 785 595 nebo nám napište na e‑mail napistenam@elegal.cz.