Proč vládní softwarové projekty selhávají — a co skutečně funguje

Dodali jsme produkční systémy pro čtyři česká ministerstva. Než každý z těchto projektů začal, věnovali jsme čas tomu, abychom pochopili, co předchozí dodavatel postavil — a co je důležitější, proč to nefungovalo. Příčiny byly pozoruhodně shodné.

Požadavky psané právníky zaměřenými na veřejné zakázky, nikoli lidmi, kteří měli systém používat. Akceptační kritéria zaměřená na formální soulad dokumentace, a ne na funkční kvalitu. Dodavatelé, kteří nacenili nabídku tak, aby vyhráli zadávací řízení, ne aby dodali udržitelné řešení. A předání, po kterých nebylo jasné, jak dodaný systém provozovat.

Nejde o problémy specifické pro Českou republiku. Jsou to strukturální rysy toho, jak zadávání veřejných zakázek na IT funguje téměř všude. Otázkou není, zda se na vašem projektu objeví — ale jak svůj projekt navrhnete tak, abyste se s nimi vyrovnali.

Český zákon o zadávání veřejných zakázek vyžaduje hodnotit nabídky podle cenových a kvalitativních kritérií. V praxi se „kvalita“ často převádí na držené certifikace a vyjmenované referenční projekty — obojí přitom dodavatel dokáže optimalizovat, aniž by byl skutečně schopný.

Nejlevnější nabídka vyhrává častěji než ne, zvlášť u menších zakázek. A nejlevnější nabídka je téměř vždy levná z nějakého důvodu: osekaný rozsah, juniorní tým nebo plán dohnat marži skrz vícepráce poté, co je smlouva podepsaná.

Dodavatelé, kteří této dynamice rozumějí, na ní postaví celý svůj obchodní model. Vyhrají zadávací řízení, dodají smluvní minimum a poté generují tržby skrz nevyhnutelné změny rozsahu, které následují. Zadavatel dostane systém, který technicky projde akceptací — ale ve skutečnosti neunese scénář použití, pro který byl postaven.

Nejúspěšnější vládní projekty, kterých jsme byli součástí, začaly ještě před formálním procesem zadávání zakázky. Zadavatel měl skutečného technického partnera, který mu pomáhal definovat, co potřebuje, strukturovat požadavky a pochopit, jak vypadá dobré dodání.

Tomu se v českém právu zadávání veřejných zakázek říká předběžné tržní konzultace a jsou výslovně povolené. Dodavatelé, kteří se této fáze účastní, rozumějí skutečnému problému. Dodavatelé, kteří se objeví až u zadávacího řízení, ne.

Zadavatelé, kteří do tohoto procesu investují, dostávají lepší zadávací řízení, lepší nabídky a lepší systémy. Ti, kdo ho přeskočí, obvykle dostanou standardní výsledek.

WCAG 2.1, NIS2, GDPR, ISO 27001 — to jsou minimální požadavky, ne to, čím se odlišíte. Systém, který je splňuje, plní jen základní úroveň. Systém, který skutečně funguje pro lidi, kteří ho používají, dělá něco navíc.

Vídáme spoustu vládních systémů, které jsou technicky v souladu s předpisy a prakticky nepoužitelné. Akceptační testování prováděl tým, který spustil automatické kontroly proti checklistu. Skuteční uživatelé nebyli nikdy zapojeni. Přístupnost prošla auditem, ale neprošla skutečnou zkouškou.

Náprava není složitá. Testujete se skutečnými uživateli. Do testování zapojíte lidi se zdravotním postižením. Ke kritériím WCAG přistupujete jako k návrhovým vstupům, ne jako k dodatečným filtrům. To ale vyžaduje dodavatele, který tak uvažuje — a proces zadávání zakázek, který takového dodavatele vybere.

Problém předání systému bývá podceňovaný. Dodavatel systém dodá, předá dokumentaci, které nikdo plně nerozumí, a ukončí angažmá. Po osmnácti měsících je třeba nasadit bezpečnostní záplatu a není jasné, jak postupovat. Objeví se výkonnostní problém a není na koho se obrátit.

Vše, co postavíme, také provozujeme v rámci dlouhodobých servisních smluv. Ne proto, že je to víc tržeb — často je to víc práce, než bychom si přáli — ale protože je to jediný způsob, jak uzavřít smyčku mezi tím, co jste postavili, a tím, jak se to chová v reálném světě.

Nejlepší vládní systémy, které jsme viděli, jsou ty, u kterých dodavatel zůstal. Nejhorší jsou ty, u kterých byl dodavatel smluvně zavázán odejít.