Jako vystudovaného vývojáře softwaru s 15 lety komerční praxe jednak v samotném vývoji, tak ve vedení softwarových vývojových týmů jsem se zájmem četl zprávy o tom že digitalizace stavebního řízení je zpackaná. Chtěl jsem se dozvědět co se na tom systému údajně nepovedlo a zde jsou k tomu mé poznámky. V tomto článku sepisuji co jsem se dozvěděl a zda dané informace skutečně vypovídají o tom, že systém jako takový je opravdu špatný. Předem můžu říct, že to tak totiž při detailním pohledu vůbec nevypadá, a celá “aféra” je zjevně uvařená z vody.
Asi nejblíže nějakým konkrétním problémům se dostal článek Úředníci: Digitální stavební řízení zmačkat, vyhodit a začít úplně znovu ze Seznam Zpráv.
V článku, a především na jeho začátku, je značné množství subjektivních hodnocení systému samotnými úředníky, zde se budu věnovat pouze tvrzením faktickým či nějak kvantifikovaným.
Portál stavebníka propustí prý i nevalidní nebo neúplné žádosti.
Toto není z pohledu vývoje software žádný zásadní problém. Validace vstupů uživatele je triviální funkcionalita, kterou každý programátor je schopen přidat do informačního systému velice rychle a snadno. Absence validace některých údajů nevypovídá nic o celkovém stavu systému jako takového.
Nepomůže ani to, že se někdo přihlásí přes bankovní identitu. Očekávala bych, že se jméno, datum narození, adresa, datovka a tak dále automaticky vygenerují, ale to se neděje. Všechno tam musím dopsat ručně a nesmím udělat chybu, protože to pak nejde opravit
Portál zjevně je integrován s bankovní identitou, jen tato integrace zřejmě zatím nezkopíruje některé údaje na patřičná místa. To opět není zásadní chyba, naopak skvělou zprávou je že je portál již v základní verzi integrován s moderními a užitečnými technologiemi jako je bankovní identita. Dokopírování údajů ze systému se kterým je systém zjevně již integrován zcela jistě lze přidat a nejedná se o zásadní problém, ta těžší část práce je evidentně již hotova.
tak jsem řízení odložila. Paní mi pak sama volala s tím, že ona má v systému napsáno vyřízeno
Těžko soudit co konkrétního se v této situaci stalo, ale lze na ni nahlížet i pro systém velmi pozitivně. Zjevně pomohl oběma stranám rychle vyřešit problém tím, že ten hlavní uživatel – občan – dostal skrz něj okamžitě informaci o tom že se něco stalo, a mohl to tak bez prodlení začít osobně řešit.
Nový příkaz je na dvou stranách A4 a není tam žádný specifický symbol
Toto vyznívá jako skutečný problém, protože pokud úřadu přicházejí platby bez jakýchkoliv identifikátorů, tak to je jistě složitá situace a přiřazování plateb musí hodně komplikovat. Jenže po přečtení komentáře MMR to vypadá že jde spíše o chybu úředníka. Systém je záměrně navržen tak, aby si identifikátory plateb do systému vkládali úředníci sami podle toho jak jim je generuje který jejich ekonomický systém – ty doposud nejsou na stavebních úřadech nijak sjednocené a každý generuje identifikátory plateb jinak. Vypadá to tedy že úředník vůbec žádný identifikátor platby do systému nezadal, no a tak se platební příkaz vygeneroval bez identifikátoru. To zřejmě není chyba systému, ale chyba úředníka.
Teď ke každému dokumentu musím ručně zadat, kdo to má schvalovat, kdo podepisovat … Musím dojít na konec chodby, podívat se, jestli tu je pan nebo paní vedoucí, vrátit se, zadat jejich jméno do systému, odeslat jim žádost o podpis, opět za nimi dojít a říct jim, aby mi to ihned zkontrolovali,
Úředník si zde stěžuje, že si musí vybrat, kdo mu jeho práci zkontroluje, a následně musí počkat, až to jeho kolega udělá. Není vůbec jasné proč je tohle problém, jestli předtím postupy úředníků nepodléhaly žádné kontrole, nebo jak tohle souvisí s novým systémem. Tato připomínka se jeví jako zcela absurdní. Systém nemůže za to, že jeden člověk musí počkat na to až jiný člověk udělá svou práci.
Vy něco podepíšete a ono se vám to vrátí třeba až za hodinu nebo za dvě, že je to zkontrolované a podepsané … Nejraději pracuje ráno, kdy je systém nejrychlejší.
Budu předpokládat že zde již nejde o stížnost na pomalost kolegů, kteří ráno pracují a podepisují rychleji. Předpokládejme, že se systém jako takový během dne zpomalí když s ním pracuje více a více lidí. I to nepoukazuje na žádný zásadní problém. Optimalizace výkonnosti systému je něco, co se vždy dá udělat dodatečně. Je časově a finančně poměrně náročné výkonnost systému důkladně otestovat už během vývoje – uměle simulované zatížení systému nikdy nebude tak vypovídající, jako zatížení systému skutečnými uživateli. Teprve až je systém v plném provozu tak lze s jistotou identifikovat které operace nefungují dostatečně rychle a ty lze pak zoptimalizovat. Takzvaná “předčasná optimalizace” je častou chybou nezkušených vývojářů. Zkušení vývojáři optimalizují teprve až je něco prokazatelně pomalé.
Úředníkům chybí tlačítko „zpět“.
To snad ani nepotřebuje komentář. Toto opravdu neříká vůbec nic o celkové kvalitě systému.
Ale ono to řadí podle křestního jména nebo podle titulu, ne podle příjmení.
Toto je zjevně chyba, ale dodělat do systému řazení podle nějakého jiného údaje je zcela triviální. Opět, tento nedostatek nevypovídá naprosto nic o celkové kvalitě systému.
Hlásí mi „zetko“ z jejího dokumentu, ale já ho nemohla najít v systému. Až když jsem všechno vyfiltrovala, tak jsem našla jiné „zetko“ a říkám jí: Napište si toto moje ‚zetko‘, protože pod ním vás tu mám uloženou. To je fakt strašné
Že jeden dokument může mít v určité situaci dva identifikátory je známý a popsaný fakt a je pro to důvod.
Prostě to ztuhlo, napsalo to hlášku ‚nelze se připojit‘, ačkoliv k internetu jsem připojená byla
Jedna úřednice zde popisuje jednu jedinou situaci kdy systém přestal reagovat. Z toho lze usuzovat že se tak asi neděje opakovaně, to by jinak jistě stálo za zmínku. Pokud by byl systém ve špatném stavu, tak bych očekával že velké množství úředníků bude hlásit že něco takového se děje opakovaně a pravidelně, nic takového v článku ale není. Opět to tedy nevypovídá o (ne)kvalitě systému nic, spíše je pozitivní že systém už i v takto čerstvých verzích je relativně stabilní.
Je to chaos a systém nesplňuje podmínky zákona, jako například nahlížení do spisu
Nerozumím tomu proč toto úředník vidí jako problém. Potýkají se s žádostmi občanů o nahlížení do spisu? Předpokládám že občané jsou rádi že mohou konečně v online portálu přehledně sami vidět co se s jejich žádostmi děje, a nepotřebují tedy “nahlížet do spisu”. Přidat funkcionalitu k zobrazení dat která už v systému jsou by opět neměl být žádný problém, a to že to systém momentálně neumožňuje není žádný zásadní neopravitelný nedostatek.
Zároveň do médií unikla takzvaná “analýza” systému vyhotovená jinými ministerstvy. V ní jsou konkrétní nedostatky zmíněné tyto:
Chybí business architektura a business analýza, není jasné jak má vypadat výsledné řešení; minimální funckionalita byla definována bez účasti uživatelů
Není jasné proč je toto vykládáno za chybu. Minimální funcionalita je přece dána zákonem – ten stanoví, co nutného (minimálního) se ve stavebním řízení musí udát. V této počáteční fázi, kdy vzniká hlavní základ celého systému není proto potřeba se žádných uživatelů ptát na to, co by měl systém dělat. Teprve až systém existuje, lze ho úspěšně používat na základní úkony, si mohou uživatelé utvořit velmi konkrétní a relativně přesnou představu o tom co by tam ještě mělo být, aby to bylo z jejich hlediska kompletní. Snažit se předem všechno do detailu zanalyzovat, vyspecifikovat a naplánovat je ve vývoji softwaru dávno překonaný přístup.
Neexistuje sjednocený plán vývojových prací
Netuším co se tímto myslí, proč by toto měl být problém. Backlog jakéhokoliv softwarového projektu je vždy neúplný a při iterativním vývoji se neplánuje vše najednou.
Neprobíhalo dostatečné testování aplikace
Tvrzení je subjektivní a nekvantifikované – kolik testování je dostatečné je vždy sporné. Jak každý více zkušený tester ví, nikdy nelze otestovat všechno, protože i ve velmi jednoduchých systémech množství různých kombinací vstupů a scénářů je příliš vysoké na to, aby šlo v konečném čase vše otestovat. Lze předpokládat, že kvůli komplikacím vyvolaným ÚOHS, které způsobily nedostatek času, na testování moc prostoru nezbylo, a to je zcela pochopitelné a není to sám o sobě zásadní problém se systémem samotným.
Provoz nepodléhá standardnímu automatizovanému monitoringu
Opět něco, co se dá vždy dodatečně k systému snadno přidat. Monitoring je vhodné mít v každém systému od počátku. Jednak je ale pochopitelné, že kvůli časové tísni toto nebylo zatím přidáno, především ale absence monitoringu sama o sobě nezpůsobuje nefunkčnost systému, tedy toto tvrzení nijak nedokládá že by byl systém nepoužitelný.
Chybí dokumentace a komentáře v kódu
Jsou programátorské školy, které tvrdí, že dokumentace a komentáře vždy automaticky zastarávají a psát by se tak měli jen ve velmi výjimečných případech, kdy sdělují něco skutečně velmi informativního. Analýza navrhuje přidat komentáře ke každé třídě a veřejné funkci, to by byl v komerčním světě požadavek velmi maximalistický a ve spoustě firem by to bylo pokládáno za mrhání časem (a tedy penězi). Především ale dokumentace ani komentáře nemají na funkčnost systému vliv.
Chybí automatizované testy
Jsou programátorské školy, které tvrdí, že automatizované testy by měly být v softwarovém díle přítomny od samého začátku. Já sám se k tomu přikláním, zároveň jsem ale pracoval na mnoha úspěšných projektech, kde tomu tak nebylo. Absence automatizovaných testů ale sama o sobě nic nevypovídá o tom že by systém byl nefunkční. Správně udělané testy jsou na systému zcela nezávislé.
Technologický dluh
Nikterak nekvantifikované sdělení. Technologický dluh obsahuje prakticky úplně každý softwarový projekt na světě. Navíc existují automatizované nástroje, které umějí technologicky dluh změřit strojovou analýzou kódu. Je spodivem, že zde nebyla tato možnost využita, a mohli bychom si tak o technologickém dluhu utvořit nějakou konkrétní představu. Není tedy jasné, proč je tento neurčitý vůbec bod zmíněn. Zní to jako že si někdo vzpomněl že existuje pojem technologický dluh, a tak ho prostě bez dalšího do “analýzy” napsal.
Chybí některé funkcionality…
Laickým pohledem (nejsem stavař) na seznam tří funkcionalit které chybí, mi připadá, že nejde o zásadní funkcionality nezbytné k základnímu používání systému. Především ale není nikde uvedeno, že by existoval nějaký technický problém tyto funkcionality do systému kdykoliv přidat.
V prezentaci se nachází ještě několik odrážek k technickým věcem které chybí, ale jedná se vždy o dílčí věci, které jsou buďto velmi diskutabilní nebo nemají na funckionalitu žádný vliv, nebo je lze velmi jednoduše přidat.
Celkově: Na to, jak málo času nakonec na vývoj systému kvůli průtahům s ÚOHS zbylo, je systém zřejmě přesně v takovém stavu v jakém by měl v nejlepším možném případě být. Uživatelé ho mohou používat, je relativně stabilní, a nejsou žádné známky toho že to, co v něm momentálně chybí, by nešlo velmi snadno velmi brzy dodělat.
Závěrem: Digitalizace stavebního řízení je v hlavách mnoha lidí zpackaná. Jak je v politické a mediální “realitě” obvyklé, není totiž důležité jaká je skutečnost, příběh se dá vyrobit a dostatečně mnohokrát opakovat, až je přijat jako pravda.
Spíše než o vadný systém jde o souhru politiky (Pirátům klesla podpora voličů pod kritickou mez, jsou politicky velmi slabí), a mediálně je velmi atraktivní psát o tom, že ti, kdo tvrdili, že jsou na digitalizaci experti, mají nakonec s digitalizací nějaké údajné problémy.