Po mnoha letech vývoje softwaru mj. pro státní správu a po několika dalších letech práce ve státní správě jsem se rozhodl shrnout svoje zkušenosti s příčinami předražování softwaru a závislosti na dodavateli. Opatření, která byla státní správou přijata, totiž nevedou a ani nemohou vést k nápravě. S vývojem softwaru mám zkušenosti od roku 1974, od roku 1994 jsem členem ACM (professional member) a do letoška jsem také vyučoval na katedře Softwarového inženýrství FIT ČVUT. Domnívám se, že mám zkušenosti, vzdělání i kvalifikaci k tomu, abych se k problému mohl vyjádřit. Problém jsme prodiskutovali s kolegy a kamarády, kteří moje prvotní názory kriticky zhodnotili a přišli s řadou nápadů. To, co zde uvádím, je výsledkem diskuse, nicméně jsou to moje názory, které zde vyjadřuji a budu hájit.

Tímto vyjádřením se snažím přispět k řešení problému. Když jsem však hledal, komu bych měl vyjádření předat, nenašel jsem nikoho (žádnou instituci ani žádného člověka), kdo by mohl a chtěl změnit současný stav k lepšímu. Po pár neúspěšných pokusech jsem se tedy rozhodl, že svoje názory na problém a jeho řešení předložím k veřejné diskusi. Doufám, že až se zase někdy příště bude ve státní správě řešit předražování softwaru, bude problém dostatečně pochopen a nebude možné ignorovat veřejně známé možnosti jeho řešení.

Proč bývá software ve státní správě stále předražený a proč ne zcela splňuje skutečné potřeby zadavatele?

(a) Zadání zpracovává řešitel, zadavateli je jen předloží ke schválení

Čí problém si asi zadá k řešení řešitel? Důsledkem je závislost zadavatele na dodavateli. Tato vada se dá odstranit, když zadavatel bude mít mezi svými pracovníky nejen experty na řešený problém, ale také odborníky na analýzu požadavků. Jde

o co nejvýstižnější a nejpřesnější stanovení
- řešeného problému (co komu vadí?)
- účelu (komu a k čemu má požadovaný software sloužit?)
o výčet a vymezení
- uživatelských rolí
- rolí požadovaného softwaru vůči uživatelům
o kontrolu rolí proti celkovému účelu
o výčet požadovaných funkcí, omezení, pravidel apod.
- + o jejich kontrolu
a konečně také o konstrukci konceptuálního modelu požadovaného řešení.

I tak bude první verze zadání nepřesná a vágní, protože experti vymezují vágně nejen problém a účel, ale i pojmy v oboru (v rámci oboru to tak stačí). Dělají logické chyby a neuvažují kriticky, takže pak nevědomky žijí v předpojatostech, sebeklamech a omylech, které sice možná trochu usnadňují (nebo trochu komplikují) mezilidskou komunikaci, ale na mizerné užitné hodnotě (tj. nekvalitě) požadovaného softwaru se to vše projeví v plné síle. Role analytika požadavků by se rozhodně neměla přenechávat řešiteli!

(b) Výběrové řízení na vývoj softwaru se nedá vyhlásit s kompletním zadáním požadavků a termínu dokončení

Takové výběrové řízení se hodí k volbě sériového automobilu nebo konfekčních pracovních oděvů, maximálně k rekonstrukci vodovodu nebo topení. Tímto způsobem lze zadat nákup hotových softwarových balíků (kancelářský balík, účetnictví, personální systém, spisová služba, helpdesk…), ale nelze tak zadat vytvoření autorského díla, jakým je nový softwarový systém „na míru“. Vytvoření díla je založeno na nápadech, které nevyrábíme, nýbrž dostáváme, příp. nedostaneme – nedají se plánovat. Na počátku je zadavatel schopen nanejvýš nějak vágně vyjádřit účel (k čemu má systém sloužit) a pár uživatelských rolí. To všechno se musí průběžně opravovat, zpřesňovat a doplňovat. I jenom samotná proveditelnost se musí ověřovat průběžně (aby se dal projekt v případě neproveditelnosti zastavit co nejdřív – než do něj zadavatel nainvestuje víc peněz, než bylo nutné). Částečným řešením je rozdělit vývoj systému na řadu dílčích iterací. Výběrové řízení nelze vyhlašovat na každou iteraci zvlášť v rychlém sledu. Jsou-li iterace dlouhé, zákonitě musí docházet k neplnění termínů nebo k odevzdávání nedokončeného softwaru (ať si to otestuje zákazník – chyby se pak opravují a odhalené nedodělky dokončují až po odevzdání iterace, zpravidla na úkor iterace následující). Pokud se chyby a nedostatky v zadání řeší pomocí řady navazujících samostatných zakázek, celková cena se nepřiměřeně navyšuje, práce na zakázce se protahuje a výsledný software je předražený. S chybami (nejen v zadání) je potřeba počítat a pracovat s nimi (protože lidi dělají chyby). Cena za chyby se dá minimalizovat, když se chyby odhalují a opravují co nejdříve. Toho se dá dosáhnout agilními vývojovými procesy s rychlým sledem krátkých iterací (ideálně po týdnu, maximálně tak asi po měsíci). V komerčním vývoji se už léta agilní metody úspěšně používají. Součástí agilního vývoje bývá zejména

rychlé prototypování
- slouží nejen k navržení uživatelského rozhraní, ale především k ujasnění účelu a rolí a ke zpřesnění a doplnění požadavků; není škoda prototyp vyhodnotit, zamítnout a zahodit
vtažení zadavatele do práce vývojového týmu
- práce na zadání, průběžné i přejímkové black-box-testy, psaní příruček apod.
- to se týká jak expertů na řešený problém, tak analytiků
zkrácení iterací na týden až měsíc
- nikoli na půl roku nebo na rok
jednotkové testy, automatizace testování atd.

Na jednotlivé týdenní iterace se předpisová výběrová řízení asi vyhlašovat nedají. Zákon 134/2016 Sb. o zadávání veřejných zakázek (dále jen Zákon) však obsahuje zvláštní ustanovení pro výzkum a vývoj – jde přece o analýzu problému a vývoj řešení. Zvláště pak „inovační partnerství“ se mi zdá být dobře použitelné. Kromě toho je v každém případě potřeba: najmout do orgánů státní správy kvalifikované zadavatele velkých softwarových systémů na zakázku (tj. výše zmíněné experty a analytiky – je to vhodné pro externisty i pro vysloužilce z oblasti komerčního vývoje, podobně jako v bodu c).

K agilnímu vývoji:

Po konzultaci s kolegy a kamarády jsem dospěl k názoru, že výše uvedené návrhy v zásadě neodporují Zákonu, ale bylo by potřeba podrobněji promyslet a vyzkoušet metodický postup. Problém je totiž v tom, že kdo by postupoval sice v souladu se Zákonem, ale nezvyklým způsobem, může narazit v případě kontroly nebo auditu na podezření, že za neobvyklým metodickým postupem se skrývá buď pokus o korupci, podvod nebo přinejmenším zanedbání péče řádného hospodáře – a to jsou trestné činy. Pro takový případ je potřeba např.:

mít v ruce vypracovaný a schválený metodický postup včetně návodu, jak vytvářet auditní stopu, která by zajistila průhlednost a prokazatelnost správnosti vývojového procesu; alternativou k návodu by mohl být vzorový pilotní projekt
zvláštní organizace pověřená mj. analýzou požadavků a řízením agilních softwarových projektů (ať už by to byla firma, která by byla vybrána ve výběrovém řízení, nebo státní organizace analogická např. k NAKIT, s.p.)

V případě, že by byla vypracována metodika nebo vzorový pilotní projekt, bylo by třeba

přijmout interní odborníky na analýzu požadavků a řízení projektů do jednotlivých organizací státní správy, kterých se vývoj softwarových systémů týká
nebo na analýzu a řízení jednotlivých projektů najímat externí analytiky nebo firmu (ve zvláštním výběrovém řízení), aby analyzovali požadavky a řídili projekt. Experty na problém by ovšem měla vyčlenit do řešitelského týmu organizace státní správy ze svých zaměstnanců – jsou to totiž znalci skutečných poměrů.

Zmíněná zvláštní organizace by mohla také např.:

ohlídat, aby se stejný problém neřešil duplicitně
ohlídat, aby se nevyvíjel na zakázku software, který je možné koupit hotový (a v případě potřeby jen konfigurovat nebo nastavit předvolby požadovaným způsobem)
pro potřeby analýzy požadavků zpracovat a sjednotit názvosloví a metodiku ve státní správě, které by odpovídaly platné legislativě
vytvořit jakýsi „Government Office“, tj. softwarový balík specifický pro běžné potřeby státní správy (třeba jako doplněk ke standardním kancelářským balíkům, které pokryjí hodně z těchto potřeb, ale ne všechno – nejsou specifické pro státní správu ČR)

Fakt je, že ve státní správě analytici ani metodici softwarových projektů nejsou, snad až na výjimky, které potvrzují absurdní pravidlo (že zadání si zpravidla vypracovává řešitel). Může to být tím, že je organizace státní správy ani nehledají (viz inzerce volných pracovních míst).

K inovačnímu partnerství:

Inovační partnerství podle mého názoru umožňuje omezit projekt buď penězi, nebo časem, aniž by byly zadány konkrétní požadavky na výsledný produkt. Zadavatel může ve výběrovém řízení buď nabídnout částku, kterou proinvestuje, a zájemci nabídnou, kolik práce za tuto částku mohou udělat a kolik času na to budou přibližně potřebovat. Nebo zadavatel předem stanoví cílový termín a zájemci nabídnou, kolik práce a za jakou cenu vykonají. Konkrétní požadavky bude ovšem stanovovat zadavatel postupně vždy při vyhodnocení iterace (např. jednou týdně). Fakticky se jedná o výzkum a vývoj, což je přesně analýza, návrh a implementace softwaru.

(c) Chybějí vlastní síly na drobný vývoj

Státní instituce (typicky OSS) by měly mít na drobný vývoj vlastní síly – skriptování dávek, psaní maker v aplikacích kancelářského balíku, získávání a analýza dat z databází, tvorba a správa intranetu a příp. i webových stránek pro veřejnost (pouhé vyvěšování dokumentů do hotových webových stránek nestačí). Bylo by to zaměstnání vhodné např. pro pokročilé uživatele nebo pro vývojáře před důchodem, když už mají zaopatřené děti a zaplacené hypotéky a když už nechtějí nebo nedokážou se neustále přizpůsobovat dalším a dalším módním vlnám v komerčním softwaru. Státní správa může takovému člověku nabídnout poklidné a slušně placené zaměstnání v denních směnách s volnými víkendy a svátky. Pár takových lidí znám.

Nároky na zaměstnance ve státní správě by měly být větší – dnes už patří ke všeobecnému vzdělání nejen zpracování textu textovým procesorem a čísel tabulkovým kalkulátorem. Pro absolventy středních a vysokých škol by neměl být problém zacházet s analytickými nástroji typu MS Power BI nebo SAP BusinessObjects a jestli neumějí skriptovat makra v kancelářském balíku, dokážou se to naučit sami (třeba metodou copy-paste ze StackOverflow). Ale nemělo by se šetřit ani na dobrých školeních, která se musí vyplatit tím, že nebude nutné na každou maličkost shánět drahého odborníka. V současné době si pracovníci státní správy o nějakých školeních tohoto typu mohou nechat tak leda zdát…

Čas od času by se měl dělat audit, který by zjišťoval, které procesy, formuláře, výkazy a agendy nejsou k ničemu potřeba. To je problém i v soukromých firmách a takovéto audity mívají překvapivé výsledky – ušetří se tak spousta zbytečné práce. Ve státní správě (pokud vím) se takové audity nedělají – což znamená, že právě tímto způsobem by se dalo hodně ušetřit, aby úředníci mohli dělat smysluplnou práci, na kterou dnes nezbývá čas ani síla.

Pozor:

Závislost na dodavateli a předražování softwarových zakázek se nedá řešit posloupností výběrových řízení pro jednotlivé vývojové přírůstky podle Zákona.

Poznámky ze Zákona:

§60: …součástí zakázky je návrh řešení nebo inovativní řešení… (nepoužitelné kvůli lhůtám; nepočítá se s účastí zadavatele na práci na předběžných nabídkách – jde např. o analýzu problému a účelu).
Hlava VII, §70 až 72: Řízení o inovačním partnerství vypadá použitelně např. takto: zadavatel v zadávací dokumentaci předběžně analyzuje problém a účel, uvede předběžný seznam známých uživatelských rolí, pravidel a omezení; součástí nabídky by mohl být předběžný konceptuální model – to vše se pak bude společně podrobně analyzovat a postupně zpřesňovat, aby se dospělo k seznamu funkčních požadavků a k prvním prototypům; pak začnou převažovat vývojové práce na softwarovém systému. Předběžné požadavky nejsou závazné, závazná by byla buď cena, nebo termín. Financování inovačního partnerství se naplánuje podle §23, (2).
§29, r) „Zadavatel není povinen zadat veřejnou zakázku v zadávacím řízení…“ jsou-li předmětem zakázky služby ve výzkumu a vývoji, pokud cenu hradí zadavatel a výsledky využije výhradně ke své činnosti. (To by se dalo využít u zakázek na vývoj softwaru pro vlastní potřebu zadavatele – to je typický případ vývoje na zakázku.)

Kromě Zákona 134/2016 Sb. o zadávání veřejných zakázek je třeba dodržet také ustanovení jiných zákonů, např. Zákona č. 111/2009 Sb., o základních registrech nebo Zákona č. 365/2000 Sb. o informačních systémech veřejné správy a o změně některých dalších zákonů.

Poděkování

Děkuji za laskavé konzultace, připomínky a nápady kolegům a kamarádům, jmenovitě panu Věnkovi Herynkovi stejně jako ostatním, kteří si přáli, abych je nejmenoval.

Prosím čtenáře o příspěvky do diskuse.