Slovensko minie milióny na aplikáciu, ktorá padne hneď po spustení. Expert vysvetlil, v čom štát zlyháva (ROZHOVOR)

Štátne aplikácie sľubujú menej návštev úradov a jednoduchšie vybavovanie každodenných vecí. Keď však občan pri prvom použití nenájde službu, ktorú potrebuje, alebo sa mu nepodarí dokončiť nákup či registráciu, výška rozpočtu ho nezaujíma. Chce vedieť, prečo riešenie, ktoré mu malo ušetriť čas, ešte nefunguje tak, ako očakával.

Najnovšie sa tieto otázky objavili pri štátnej službe Cyril, ktorá má spojiť nákup lístkov na vlak, autobus a MHD. Pri jej júlovom štarte bola dostupná webová verzia, no mobilné aplikácie nepribudli súčasne; verzia pre iPhone sa v App Store objavila až neskôr. Cestujúci zároveň upozorňovali na problémy pri používaní služby. Dnes už je Cyril dostupný pre Android aj iPhone, otázky o pripravenosti jeho spustenia tým však nezmizli.

Varovanie pritom prišlo ešte pred jeho uvedením. Útvar hodnoty za peniaze v hodnotení z júla 2024 upozornil, že plánovaný termín spustenia nemusí byť pri zdržaní dosiahnuteľný, a odporučil spresniť harmonogram aj náklady projektu. Príbeh Cyrila tak otvára širšiu otázku: kde sa pri štátnych aplikáciách rozhoduje o tom, či budú pre ľudí užitočné a pripravené na reálnu prevádzku?

O tom, prečo niektoré štátne digitálne služby sklamú už pri štarte, kto má kontrolovať ich kvalitu a či vysoká cena zaručuje dobrý výsledok, sme sa rozprávali s Tomášom Lodňanom, CEO digitálneho štúdia GoodRequest.

Tomáš Lodňan

Prečo podľa vás niektoré slovenské štátne aplikácie nefungujú spoľahlivo, hoci ich vývoj stojí veľké peniaze? Kde sa problém zvyčajne začína?

Problém sa vo väčšine prípadov začína už na úplnom začiatku a to v zlej produktovej validácii a pri nereálnych termínoch. Často príde projekt, ktorý má pevne daný termín spustenia, no chýba mu jasná produktová stratégia a dôkladná príprava. Pri veľkých komerčných projektoch a zavedených firmách sa vynechanie kľúčových fáz vývoja zvyčajne nepripúšťa.

Pri štátnych produktoch sa zvyknú podceniť záťažové testy, end-to-end integračné testy či fázy uzatvoreného a postupného testovania. Výsledkom je potom kolaps hneď v prvých minútach po spustení, keď produkt narazí na reálnu záťaž a odhalí sa každá zanedbaná fáza vývoja.

Viete pomenovať konkrétnu slovenskú štátnu aplikáciu, pri ktorej ste si všimli vážny problém?

Nedávnym príkladom je aplikácia Cyril, ktorá mala od 1. júla priniesť jeden lístok pre 39 dopravcov. Ukázali sa pri nej dva typy problémov: technologický a produktový. Technologicky chýbala pri štarte verzia pre iPhone, ľudia boli odkázaní na web a cestujúci sa sťažovali, že personál dopravcov nevedel lístok overiť.

Presnú príčinu výpadkov verejne nepoznáme, no pri systéme, ktorý sa napája na desiatky dodávateľov a dopravcov, typicky zlyhávajú integračné a záťažové testy: stačí drobná zmena na strane jedného rozhrania a celý reťazec padne. Produktovo však vzniká otázka, či vôbec riešime reálny, pálčivý problém cestujúceho.

Bežný človek skôr rieši to, aby vlaky nemeškali a fungovala v nich klimatizácia či Wi-Fi, než to, aby si kúpil jeden kombinovaný lístok.

Cyril/ChatGPT

Je hlavnou príčinou zlyhaní technológia, alebo skôr spôsob, akým štát projekt zadá a riadi?

Jednoznačne spôsob zadania, riadenia a produktového uvažovania. Technológia je len nástroj. V komerčnom svete si banka alebo veľký produktový hráč presne prepočíta takzvanú business value a nastaví kľúčové ukazovatele výkonnosti (KPI) – prečo produkt robíme, komu pomôže a akú hodnotu prinesie.

V štátnej sfére sa mnohokrát stáva, že sa veci robia spätným inžinierstvom: „Máme alokované peniaze, poďme ich minúť,“. Ak chýba poctivý výskum, používateľské testovanie a jasná produktová vízia, ani najlepšie technológie vás nezachránia. Štát pritom nástroje má, štúdie uskutočniteľnosti a hodnotenia Útvaru hodnoty za peniaze, len ich často obchádza.

Stáva sa, že štát objedná aplikáciu bez toho, aby mal jasno v tom, čo cez ňu má občan vybaviť? Ako sa taká chyba prejaví vo výsledku?

Áno, a prejaví sa to presne tým, že občan v aplikácii nenájde pridanú hodnotu. Vznikne z toho zložitejší a niekedy dokonca drahší proces než ten, ktorý existoval doteraz. Ak nepoužijeme používateľský výskum a nenavrhneme produkt okolo reálnych potrieb cieľovej skupiny, vznikne riešenie, ktoré síce na papieri spĺňa nejaké zadanie, no v praxi spôsobuje len frustráciu.

Keď je použiť aplikáciu komplikovanejšie než starý spôsob, občan nemá dôvod ju používať.

Akú úlohu zohrávajú politické termíny? Môže tlak na rýchle spustenie dostať prednosť pred upozorneniami vývojárov, že služba ešte nie je pripravená?

Stanovenie pevného dátumu dokončenia je legitímnou požiadavkou objednávateľa a bežnou praxou aj v komerčnej sfére. Dodávateľ, ktorý považuje termín za nereálny, by to mal povedať otvorene ešte pred podaním ponuky. Ak sa termín zmeniť nedá, je na ňom, či sa do tendra zapojí.

Problémom však býva, keď sa termín nastaví bez dostatočnej časovej rezervy na neočakávané zdržania či poctivú prípravu. Na to upozornil Útvar hodnoty za peniaze už v júli 2024 pri projekte Národného integrovaného cestovného lístka, dnes aplikácie Cyril: termín jún 2026 podľa neho nemusel byť pri akomkoľvek zdržaní dosiahnuteľný.

Okrem toho pri úplne novej aplikácii síce obchody neumožňujú percentuálny rollout, ten funguje len pri aktualizáciách. Postupný nábeh sa však dá urobiť inak: uzavretým testovaním cez TestFlight a Google Play alebo pilotom v jednom kraji či s niekoľkými dopravcami. O to dôležitejšie je dodržať poctivé fázované testovanie a schvaľovacie procesy v App Store a Google Play.

Ak sa kvôli stíhaniu pevného termínu vynechajú akceptačné či záťažové testy, prvé spustenie a okamžitý nápor reálnych používateľov novú službu s veľkou pravdepodobnosťou zhodí.

Prečo štát niekedy prevezme a zaplatí aplikáciu, ktorá občanom spôsobuje problémy? Kto má rozhodnúť, že výsledok ešte nie je dostatočne dobrý?

V štátnom sektore chýbajú jasne nastavené, transparentné míľniky a podmienené vyplácanie financií nezávislou kontrolou kvality. Dielo by sa nemalo preberať len na základe formálnej správy na papieri.

O tom, či je aplikácia pripravená, musia rozhodovať tvrdé metriky: výsledky záťažových testov, miera chybovosti a reálna úroveň použiteľnosti. Kým produkt nespĺňa stanovené parametre kvality, nemal by sa zaplatiť v plnej výške ani spustiť do ostrej prevádzky.

Má štát dosť vlastných odborníkov na to, aby dokázal skontrolovať prácu dodávateľa a nebol odkázaný len na jeho uistenia?

Nie, na úradoch chýbajú ľudia, ktorí by vedeli prácu dodávateľa kvalifikovane skontrolovať. Štát musí byť kompetentným objednávateľom s vlastným produktovým a architektonickým tímom a mal by zverejňovať projektovú dokumentáciu, aby ju mohla preveriť odborná verejnosť.

Tá na Slovensku existuje: napríklad občianske združenie Slovensko.Digital, ktorého sme členom, hodnotí štátne IT projekty v rámci iniciatívy Red Flags. Problém teda nie je v tom, že by chýbala odbornosť, ale v tom, že sa štát jej odporúčaniami často neriadi.

Keď aplikácia zlyhá, kto za to v praxi nesie zodpovednosť: dodávateľ, úrad, ktorý ju objednal, alebo nikto konkrétny?

Zodpovednosť býva rozdelená. Dodávateľ zodpovedá za technologickú kvalitu kódu a architektúru. Úrad ako objednávateľ však zodpovedá za produktové zavedenie, správne definovanie cieľov a nastavenie podmienok.

Ak úrad akceptuje nekvalitné dielo bez riadneho testovania, berie na seba zásadnú časť viny. V konečnom dôsledku však najväčšiu škodu nesie občan, ktorý stráca dôveru v to, že štát dokáže digitalizovať svoje služby kvalitne.

Znamená vysoká cena aspoň vyššiu šancu, že aplikácia bude fungovať? Ako môže vzniknúť drahý projekt so slabým výsledkom?

Vo vývoji softvéru neplatí priama úmera, že vyšší rozpočet automaticky prináša funkčnejší produkt. Drahý projekt so slabým výsledkom vznikne veľmi ľahko: nafúknu sa rozpočty na licencie a viacročnú prevádzku, no podcenia sa základné procesy riadenia, architektúra a testovanie.

Náklady na opravu chýb a dodatočný redizajn po spustení môžu byť až násobne drahšie ako samotné priebežné používateľské testovanie počas vývoja. Prevencia je vždy tá najlacnejšia investícia.

Keby ste mali vybrať jednu systémovú príčinu, ktorú musí Slovensko odstrániť, aby sa tieto zlyhania neopakovali, ktorá by to bola? Čo konkrétne treba zmeniť?

Musíme zmeniť prístup k obstarávaniu a tvorbe digitálnych produktov. Projekt treba poctivo pripraviť a posúdiť ako celok, so štúdiou uskutočniteľnosti a zverejnenou analýzou. Dodávať ho však treba po funkčných častiach: najprv funkčné minimum, ktoré sa potom rozvíja na základe spätnej väzby z reálnej prevádzky.

Predtým, než sa napíše prvý riadok kódu, sa musí spraviť poctivý výskum a validácia s používateľmi. Podľa Jakoba Nielsena odhalí jedno kolo testovania s piatimi používateľmi približne 85 % problémov s použiteľnosťou. Potrebujeme digitálne služby postavené na overených postupoch z komerčnej sféry a na reálnych potrebách ľudí.

Čítajte viac z kategórie: Novinky