Nechci být cynický, ale vypsat tipovačku na to, která firma/firmy to budou znovu dodělávat (za delší čas a vyšší rozpočet), tak se většina asi trefí…
Já musím přiznat, že jsem zatím viděl hodně PR zpráv, relativně nesmyslnej PowerPoint a podobně, ale existuje vlastně technický audit včetně code review toho kódu vůči nějaké zadávací dokumentaci a zákonu? 
Nejblíž tomu je ta odkazovaná PDF příloha k tiskovce z MMR. Tam třeba sekce 2.4 Zvolená architektura vypadá konečně jako něco, o co se dá opřít kolo. Zároveň velká řada z těch technických věcí, co tam popisujou, by se určitě dala a měla řešit iterací, nikoliv restartem. („Neprobíhá standardní monitoring řešení obou systémů pomocí nástrojů APM?“ Přesoutěžíme! „Chybí automatizované testy na všech úrovních?“ Přesoutěžíme! Etc.)
Zejména doporučuji kapitolu 2.6. Autoři odignorovaly požadavky prakticky všech zákonů, které se takového projektu týkají.
Tomu systému chybí kvalitní business analýza a business architektura. V tom případě je kvalita kódu naprosto irelevantní informace. Je to jako kdybyste chtěli diskutovat o zábradlí ve třetím patře budovy, u které ani neexistuje představa kolik bude mít pater.
U tohoto projektu je opravdu nejlepší začít úplně od začátku a až bude jasná architektura a nějaká strategie, tak teprve pak bude možné se zamyslet, jestli se něco z toho, co bylo vytvořeno dá použít.
V našem právním prostředí prakticky neexistuje systém, na kterém by se nějaký nesoulad s platnou legislativou nenašel, zejména pokud vezmu v úvahu pružnost možných právních názorů. Každopádně i v téhle sekci většina věcí vypadá tak, že by se daly normálně dodělat ex post.
Pokud máš špatně navrženou architekturu pro ukládání písemností, tak to žádnou iterací nespravíš. A zrovna tohle je jedna z částí, které musí být FAKT robustní.
Pokud integrační paterny nejsou napsané tak, aby zvládly zátěž, tak je neopravíš. Musí se přepsat.
A pokud datová struktura neodpovídá komponentám používaným uživateli, tak se to iterací taky opravit nedá. Musíš to předělat.
A co Ti z toho systému zbylo? Bižuterie, která se sice u nového systému použít možná dá, ale rozhodně to na ní nemůžeš stavět.
Ten nesoulad vzniká díky tomu, že si jednotlivé předpisy odporují. Ignorování požadavků ZÁKLADNÍCH zákonů, to není nesoulad. To je fatální chyba!
Za mě je to hodně komplexní problém - zažil jsem u větších komerčních přepisů jak refactoring, tak kompletní rewrite a vždycky řešíš kromě kvality kódu spoustu dalších věcí. Tím chci říct, že tu právní stránku nechci moc komentovat, protože jí odborně nerozumím, nicméně položil bych technickou/business otázku, zda by šly snadno ty funkcionality upravit tak, aby to plně vyhovovalo v další itiraci? Pokud ano, za jaký čas/peníze.
Když vezmu sekci 2.5 Použité technologie, tak:
Použití Javy/Kotlinu se Springem a Reactu
To, že dodavatel použil svůj framework, aby si ušetřil práci (chápu, že mohlo jít o věci jako cachování, routing, auth a podobně), což je problém a může to být vnímáno jako částečný vendor lock in
Chybějící standardy kódu, koordinace mezi dodavately, chybějící technický design
Samozřejmě asi všichni vidíme, že se podcenila analytická část - business analýza, user flows, existující systémy, napojení na ně atd. nicméně jen na základě tohoto dokumentu nevnímám to, že kompletní rewrite je nejlepší cestou kupředu a šlo by to nejspíš zachránit refactoring, dokončením business analýz, user flows, testováním z čeho by se dal aktualizovat product backlog a do té doby udělat částečný bypass, kde by šlo fungovat podle starého systému.
Ale jak říkám, nerozumím té právní stránce a implikacím některých těch věcí, co výše zmiňuju.
Honzo, to jsou dobré postřehy. Myslím, že spousta nedorozumění vzniká z toho, že si většina lidí neumí ani představit, jak rozsáhlé a komplikované takové projekty jsou. A snaží se to napasovat na projekty, se kterými mají zkušenosti.
Tady se ale bavíme o systémech, na jejichž vývoji, provozu a údržbě se podílí stovky lidí, kde počty uživatelů jsou v desítkách tisíc, které jsou propojeny s desítkami různých jiných institucí a kde se počty písemností pohybují ve vyšších stovkách milionů až jednotek miliard stran. Kdo se s tím nesetkal osobně si to vůbec nedokáže představit.
Pokud jde o product ownera. Ten se v těchto případech obvykle ve smlouvách neřeší. Jsou uvedeny až v komunikační matici, která vzniká hned na začátku realizace. Je to z praktických důvodů. Jednak by ty smlouvy byl moc dlouhé a komplikované a mimo to změnit smlouvu nebo k ní připsat dodatek je ve veřejné správě docela oříšek. Takže je lepší, pokud jsou ve smlouvě jen jasně definované požadavky, které se v průběhu projektu nebudou měnit.
U DSŘ je navíc většina smluv napsaná jako bodyshopping přes DNS, takže tam už vůbec není důvod uvádět konkrétní osoby. Už proto, že dodavatel za nic neodpovídá.
Jinak k penězům. Odpovědnost za budget může být rozložena různě. Umím si představit i organizaci, ve které product owner nebude mít vlastní rozpočet a může fungovat celkem dobře. V každém případě ale musí existovat role někoho, kdo spravuje budget konkrétního projektu a nemůže to být vedení firmy - to na to nemá čas. Klidně to může být i project owner. Nicméně musí být někdo, kdo na denní bázi sleduje náklady projektu. Bez toho je riziko, že náklady vyletí neřízeně do nebes. A minimálně polovina projektů, které jsem kdy přebíral ve fázi krizového řízení, měla přesně tento problém.
Řídit ve veřejné správě projekt není úplně jednoduché. A ten, kdo ho na straně úřadu řídí nemá úplně pod kontrolou všechny věci, které mohou mít na projekt vliv. Při rozhodování, jestli má být smlouvy typu fix time/fix price nebo time and material hraje hlavní roli ro, kdo nese odpovědnost za výsledek. A pak také to, z jakého pytlíčku peníze pochází a jak je nastavené financování. Proto jsou preferovány smlouvy typu fit time/fix price. Odpovědnost za dodávku nese dodavatel a je jasný harmonogram placení. To, že se Bartoš pustil do modelu s bodyshoppingem jasně ukazuje, jak málo věděl o fungování veřejné správy.
Jistě u modelu fix time/fix price je v ceně započítaná i “riziková přirážka”. A právě z ní se hradí změnové požadavky menšího rozsahu. Problém je v Zákoně o zadávání veřejných zakázek. Tak dlouho se v něm šťourali různí bojovníci proti korupci, až ho zmršili tak, že ani jiná možnost není. Jak je jednou něco vysoutěžené, tak je velký problém to změnit. A i když se dodatek ke smlouvě udělá, tak vždycky hrozí, že se někde objeví nějaký pomatený aktivista a začne vykřikovat něco o korupci a tak. Proto ta riziková přirážka. Neušetřilo by se ani v případě modelu time and material. Jde totiž o tak komplikované věci, že je dost těžké objektivně rozhodnout jestli čas strávený na zakázce odpovídá skutečnosti. Takže se “nafukují hodiny”. Ostatně kdyby se to nedělo, pak by těžko byly tendry s hodinovou sazbou 130 Kč/hod.
Obávám se, že se stále nejste schopni odpoutat od jednoho chybného předpokladu. Samotný kód je v případě podobných projektů sice důležitá součást, ale jen jedna z mnoha. A ještě ne ta nejdůležitější a nejdražší. Dokonce v seznamu důležitosti bude až za polovinou.
Je mnohem levnější a efektivnější napsat kód znovu, než se snažit ohnout ty důležitější věci tak, aby odpovídaly kódu. Samotný kód představuje u podobných projektů tak maximálně 10% rozsahu zakázky.
Tohle myslím nejvíc odpovídá stavu digitalizace našeho státu: všichni to chtějí, všude kolem to dělají, tak budeme taky - ale odpovědnost za výsledek prodáme za miliardu externí firmě 
Mj. tady je dneska pohled bývalé ministryně informatiky Bérová: Tlak na úspory v digitalizaci vede do slepých uliček, které jsou ve výsledku dražší • mujRozhlas . Zajímavá je finanční motivace v Nizozemí - když zjistili, kolik desítek miliard můžou ušetřit na chodu státu, fakt se o digitalizaci snažili.
Ad owner - pokud jsou v (příloze) smlouvy kontakty na lidi u dodavatele jako UX designér nebo security, proč by tam neměl být nejdůležitější kontakt u zadavatele? 
Tím spíš u toho bodyshoppingu, protože on bude nejčastěji objednávat lidi?
Nj, finance je třeba hlídat taky (my jsme na to měli celé oddělení). I tohle mi přijde hodně škoda outsourcovat a dát tu miliardu ven v podstatě předem celou.
Odpovědnost za dodávku má stejně stát, ministr, ředitel úřadu - oni to budou vysvětlovat občanům-zákazníkům (ať už přímo nebo v dalších volbách). Externímu dodavateli je to fakt jedno - na své peníze si víc či míň přijde i při neúspěchu, ani v příští zakázce nejde hodnotit, že kdysi něco nezvládli. Outsourcovat odpovědnost za výsledek je myslím taky velká chyba. Za ty miliardy může mít stát hromadu interních lidí, kteří to uřídit zvládnou. Jen je musí chtít a umět zaplatit
To určitě ano, v tom si myslím, že se tady shodneme.
Tady si nedovolím to kvantifikovat v rámci času/peněz, nicméně to dle mě pořád neodpovídá na otázku refactoring vs. rewrite.
Tady se úplně neshodneme. Efektivnější z hlediska IT rizik (jak píše i ta zpráva) určitě ano, protože se začne na zelené louce a nový dodavatel nemusí brát nic v potaz. Efektivnější z hlediska peněz/času? To je za mě něco, čím se nikdo moc nezabýval popravdě, což mě mrzí.
I když se podcenila analytická stránka, tak si myslím, že kromě kódu samotného (řekněme XY repozitářů někde na GitHubu) můžou existovat další náležitosti, které by se měly dle mého využít při doplnění těch user journeys, uživatelského mapování, legislativním návaznostem atd. Může se jednat o nastavení infrastruktury, technickou specifikaci, zadání a komentáře k němu, detaily implementace atd. Nechci si dělat iluze, že existuje vše, ale určitě je zde více k analýze než jen kód ve smyslu řádků kódu.
Zahodit a začít kompletně znovu je určitě snažší z hlediska IT rizik, ale přijde mi, že tohle černo-bílý vidění vývoje v rámci digitalizace státní správy nás posouvá tak 10+ let zpět a je škoda, že analýza nešla více do hloubky, jak to celé:
Myslím, že se náš pohled sbližuje.
Podobný systém je jako velké puzzle. Spousta kostiček, které do sebe musí nějak zapadnout.
Dosavadní přístup bych popsal jako výrobu jednotlivých kostiček, aniž by se všichni u stolu shodli na tom, jak má vypadat výsledek, Nejspíš v hlavě každý nějakou představu má, hlavně v okolí té své kostičky, ale ten velký obrázek, co je nalepený na krabici neexistuje.
To, co teď chtějí udělat je to, že se v prvním kroku vytvoří ten velký obrázek. Popíše se, co to musí dělat, s čím se musí počítat, jaké jsou podmínky a požadavky a pod. (a to bude nějakou dobu trvat).
Až to bude hotové, pak bude ta správná chvíle zamyslet je nad tím, jestli je možné již vytvořené nebo rozpracované kostičky nějak využít. Pokud to půjde (klidně i po úpravách), pak není důvod to neudělat. Pokud to nepůjde, je lepší je zahodit. Na mrtvé kobyle se daleko nedojede.
Politik (stát je reprezentovaný politiky) má jen politickou odpovědnost a z toho krev, jak známo neteče. A úroveň politické kultury u nás je taková, že si na politickou odpovědnost moc nehrajeme.
Vedoucí pracovníci úřadu mají už i hmotnou zodpovědnost, ale Ti si dají zatracený pozor na to, aby jim Černý Petr nezůstal v ruce.
Smlouvy typu fix time/fix price jsou obvykle ve veřejné správě napsané dost jednoznačně, pokud jde o odpovědnost dodavatele. Souvisí to s tím, že každá taková smlouva je dostupná v Registru smluv a pokud by byla moc vstřícná vůči dodavateli, okamžitě by to někdo vytáhl.
Něco jiného je vymahatelnost a tam je problém v tom, že stát se svými zdroji těžko může konkurovat elitním právníkům velkých nebo nadnárodních firem, které už mají dost zkušeností na to, aby dělaly hloupé chyby. V takových sporech pak stát tahá za kratší konec provazu. Většinou to odnesou malé a střední firmy a nebo firmy, které jsou v oboru nováčky a neohlídají si základní věci.
Není ani pravda, že by externímu dodavateli mohlo být všechno šuma fuk. Problém je v tom, že po celou dobu projektu platí práce ze svého. A peníze ve finále dostane až za velmi dlouhou dobu. Klidně i za rok. Protahování projektu a jeho komplikování nejsou ani v zájmu dodavatele.
Ani u outdourcingu se zadavatel vrcholové odpovědnosti nezbaví, ale má možnost, jak požadovat po dodavateli úhradu škod za vadnou práci.
A je tam ještě jeden aspekt, o kterém jsme nemluvili - SLA. U outsourcingu je podpora systému obsažena už v úvodní smlouvě a obvykle bývá něco kolem 4 let. Ve finančním objemu to je obvykle kolem 40% z ceny projektu. Záleží na typu projektu, na požadavcích SLA a pod. Nevýhodou bodyshoppingu je to, že odpovědnost za zajištění podpory zůstává na zadavateli. Zajistit to není úplně easy. Dá se to ousourcovat jako služba (dělá to např. Unicorn), ale jsou to další náklady, protože ten, kdo poskytuje podporu musí do detailu systém znát. Tady nestačí jen zajistit first level support. Musí být rutinní znalost celého systému až na úroveň detailní znalosti architektury a každého řádku kódu.
Netvrdím, že nemohou být projekty, které si stát zajistí sám prostřednictvím bodyshoppingu a svých lidí. Ale je potřeba pečlivě zvážit a započítat veškerá rizika s tím spojená a náklady, které ani na první pohled nemusí být vidět.
Onehdy jsme v našich regionálních novinách natočili o digitalizaci stavebního řízení díl podcastu s tajemníkem boskovického městského úřadu a šéfem stavebního odboru, teď jsme ještě dotočili díl, ve kterém se bavíme o celém tématu souhrnně a obecněji, tak nabízím k poslechu:
(Říkám tam vesměs věci, které už zazněly v tomhle vlákně, ale může to hezky fungovat jako stručné shrnutí.)
Ano, politik má být první ten, který úkol “vezme za svůj”, tlačí jej úřadem, vysvětluje občanům… (to se Ivanovi docela dařilo, ale nikdo jiný to aktuálně neumí, ani nechce). Úředník-produkťák stejně nemůže mít hmotnou odpovědnost třeba za miliardovou smlouvu - navíc vždycky je to rozhodování okolo dodávky kolektivní. Ale má mít jako hlavní pracovní náplň znalost produktu, uživatelů, řízení dodavatelů, dodání služby i následný rozvoj (fakt to dneska někdo dělá?). Externímu dodavateli už je pak dost jedno, jestli dodaná služba “uspěje” - např. tady jsem pochopil, že bylo špatně už detailní zadání k realizaci - tj. firma dodá požadované zadání a projde akceptačními testy a odměnu dostane. Ale že aplikace v praxi nefunguje, je stejně zase problém úřadu-státu-zadavatele(-produkťáka). Dodavatele netrápí, že stavební řízení pojede další 4 roky postaru
SLA jde přece poptat úplně stejně jako výrobu, ideálně od stejného dodavatele, je to i ve smlouvách tady (ale 40% z miliardy je dost nereálná částka). Pokud je kód napsaný podle obvyklých standardů a je k němu i kvalitní dokumentace, není onboarding nových lidí-dodavatelů zase až tak nereálný, dělají to tisíce jiných projektů a je to pořád lepší než vendor-lock na jediného možného dodavatele Ale know-how okolo projektu musí mít zadavatel, ne dodavatel.
Jinak tady je dneska rozhovor s Evou Pavlíkovou (Expertka: Stát zatím neřekl, jak se poučil z digitalizace | iROZHLAS - spolehlivé zprávy) - má dost stejný pohled jako já se Zoulem tady (aktivně to tlačit, design zaměřený na uživatele, produkťák, agilní techniky, digitalizaci státních procesů FAKT potřebujeme…), naopak tady Pro a proti: Kupka a Černohorský ke zpožděné digitalizaci | iROZHLAS - spolehlivé zprávy nic zajímavého-užitečného nezaznělo.
To ne. Problém je v tom, že většina smluv byla o bodyshoppingu, tj. dodavatel dodá kapacitu vývojáře a co si s ní zákazník udělá je věc zákazníka. Když zákazník pověří vývojáře, aby stokrát napsal “Hello World”, tak je to zákazníkova volba a jeho problém.
Dodavatel žádnou specifikaci k realizaci nedostal (a nebyl k tomu ani důvod). Měl jen dodat lidi. Byla tam jedna výjimka, ale to je zase jiný příběh.
Jinými slovy, Dodavatel při modelu “Time and Material” nemá na výsledný produkt vůbec žádný vliv.
Problém je, že na straně zadavatele (tj. v tomto případě státu) musí být kvalitní kapacity, které budou schopné takový projekt odřídit. A takoví lidé tam dlouhodobě chybí. Ostatně DSŘ nebyl za posledních 5 let jediný totálně neúspěšný projekt, který se stát pokoušel dělat “vlastními silami”. A nebyl ani největší.
Stále se potýkáme s tím, že se hrubě podceňuje rozsah a složitost takových systémů. Obávám se, že vycházíte ze zkušeností s projektů o řád nebo dva menších a jednodušších.
U tendrů tohoto typu je běžné, že nový dodavatel potřebuje půl roku na to, aby jeho tým mohl poprvé zvednout telefon. A když říkám tým, pak se bavíme o vyšších desítkách členů. Zkuste si představit, kolik by stálo, pokud by např. 60 lidí půl roku někde něco zkoumalo a s něčím si hrálo, aby vůbec mohli začít něco produkovat.
Jistě dá se to vysoutěžit s i dodavatelem, ale výsledná cena bude mnohem vyšší, než pokud by byla jako součást úvodního tendru, protože autor projektu si je dobře vědom nákladů spojených s předáním podpory někomu jinému.
Tohle fakt není malý eshop. A je úplně jedno, jak kvalitně je zpracovaná dokumentace (a předesílám, že řada věcí v dokumentaci ani být nesmí). Půl roku pro vycvičení nového týmu je minimum.
Tyto systémy mají extrémní požadavky na spolehlivost a dostupnost. Pokud dojde k chybě (a to je velmi zřídka) je to vždycky velký problém a je neskutečný tlak na její odstranění. Osobně jsem zažil jeden incident, kdy jedna v veřejných služeb přestala fungovat. Vypadlo spojení mezi různými systémy veřejné správy - jen na začátku nebylo jasné, kde je příčina. Kritická chyba, podle SLA workaround o jedné hodiny, odstranění do 24 hodin.
Problému si všimli si toho novináři (vypadla jedna z veřejných služeb) a do půl hodiny volal osobně ministr rozpálený do běla, postavil všechny do latě a každý, kdo udržel v ruce tužku nechal všeho ostatního a řešil se ten problém. Ve finále na tom pracovalo před 400 lidí ze tří resortů. Nakonec se ukázalo, že problém byl u dodavatele infrastruktury jiného resortu, kterému se zbláznil směrovač. To ale jen dokládá, jak dobře je potřeba celý systém a hlavně jeho technické i procesní souvislosti ovládat. To není jen tak o tom “vysoutěžit někoho jiného”.
A rozhodně to není levné. Těch 40% je dáno mj. i tím, že v ceně je (z dobrých důvodů) kromě samotné technické podpory i “rozvoj systému”, což znamená implementaci legislativních změn.
Mimochodem, pro představu - u nás se každá sebemenší úprava nebo nová funkcionalita nejprve testovala na interním prostředí. Pokud to prošlo, testovala se na testovacím prostředí, které mělo ověřit, že se dá nasadit na test. Pokud to prošlo, testovala se na testovacím prostředí s náhodně vygenerovanými sety dat. Pokud to uspělo, následoval test na prostředí s subsetem reálných dat a teprve potom se nasazovalo na provoz.
Srovnejte si to s tím, jak to dělal Bartoš na DSŘ.
Eva Pavlíková v tom rozhovoru prokázala jen to, že vůbec netuší, která bije. Spousta obecných pravd (aktivně to tlačit, design zaměřený na uživatele, produkťák, agilní techniky, digitalizaci státních procesů FAKT potřebujeme…), ale nulová představa o možnostech a omezeních při jejich nasazení. Chce peníze na digitalizaci, ale vůbec netuší, že ročně jdou, např. v rámci dotačních programů, na digitalizaci miliardy. Stěžuje si, že neexistuje hloubková analýza. Očividně ji nikdy nedělala - pokud by ji někdy dělala, pak by věděla, že je to tak na 2-3 měsíce tvrdé práce, ne na dva týdny.
Ve skutečnosti jsou tito aktivisté s planoucím srdcem (a minimem reálných zkušeností z praxe) největším nebezpečím a brzdou jakéhokoli rozvoje. DSŘ zkrachovalo především proto, že právě takoví amatéři, v čele s I. Bartošem, dostali příležitost to předvést v praxi. Nemohlo to dopadnout jinak než katastrofou.
Já teda v hlavní smlouvě k DSŘ vidím většinu dodávek s fix price (příloha č. 2, odkaz někde výše), za MDs je jen další rozvoj. Tj. zaplaceno dostali-dostanou, i když to v praxi nefunguje
Ano, detailnější řízení ze strany úřadu-zadavatele vyžaduje jako nutnou podmínku schopné lidi na jeho straně. Za tu miliardu jich můžou mít fakt hodně, kdyby chtěli
V podstatě každý projekt jde rozdělit na více menších Ale zase to vyžaduje to kvalitní řízení na straně zadavatele, které nejde vynechat, ani outsourcovat.
Extrémní požadavky má kdejaký bankovní nebo telekomunikační core software. A taky to obvykle nestojí miliardu a víc (jestli 400 lidí neumí odhalit rozbitou síťovou konektivitu, pak nevím, co tam hledali? mj. tohle by měl hlídat monitoring…)
Eva, Ivan i další mají řadu zkušeností a nemyslím, že je ok je takhle shazovat - aniž víte, jaké projekty mají za sebou (DIA, Česko.digital, https://creativebureaucracy.cz/, https://www.byro.works/, https://spolecneadigitalne.cz/…). Těch lidí, co se aktivně snaží ve státním IT něco změnit, je obecně málo, z vládních politiků aktuálně nikdo, ostatní na to kašlou nebo jdou dokonce aktivně proti změnám (“nemáme lidi na projektové řízení, doporučujeme poptávat fix price na 3 roky” ?!). I zkušenosti ze zahraničí ukazujou, že bez změny myšlení a přístupu to v úřadech nepůjde (viz taky Digitalizace veřejné správy: I přes dílčí problémy jsme...), jen Češi pořád chtějí ten svůj specifický trh, kde nic nového nejde…