Mně se moc nechce přijmout argumentaci, že ausgerechnet česká veřejná správa je jednorožec, který na světě nemá obdoby, a proto se pro ni musí ohýbat fyzikální zákony. Jak jsem psal, iterativní vývoj v jiných veřejných správách funguje (UK, US), vydali jsme k tomu překlad pěkné příručky z amerického prostředí. To, co se musí změnit, je zažitá praxe fungování naší veřejné správy, nikoliv fyzikální realita vývoje softwarových systémů.
2 Likes
Zrovna Prince 2 je metodika, která byla vytvořena ve Velké Británii pro potřeby řízení projektů ve veřejné správě.
Já jsem to nemyslel tak, že když něco pochází z Anglie nebo Ameriky, tak to bude fungovat. Spíš jsem se snažil říct, že iterativní vývoj v jiných veřejných správách ověřeně funguje, takže to není tak, že by byl s prostředím veřejné správy principiálně neslučitelný.
3 Likes
I já jsem to myslel trochu jinak - nevím o jediném core systému (ať už u nás nebo kdekoli ve světě), který by nebyl vrcholově vyvíjen vodopádem. Hybridní model se používá, ale čistě agilní - o tom nevím.
Něco jiného jsou podpůrné systémy, které neslouží jako podpora konkrétní legislativy - tam se agilní přístup použít dá, ale u core systémů jsem o tom nikde neslyšel a dost pochybuji, že takový příklad existuje.
ČR v určitém smyslu jednorožcem je - bojovníci proti korupci tak dlouho prosazovali svou, až nakonec prosadili taková pravidla pro veřejné zakázky, která skoro vylučují použití agilních metodik. Ale to je zase úplně jiný příběh, i když má stejného jmenovatele - aktivisty, kteří sice nerozumí problému, ale nahrazují to planoucím srdcem.
1 Like
Hodně lidí si podle mě agilní vývoj představuje tak, že uživatelé dostanou nehotový systém a následně se to dodělává za běhu. Odtud pak ta obava dodávat tímhle stylem něco „důležitého“, co nemůže „být nehotové“.
Realita je ale podle mě trochu jiná. Jednak ta definice hotového stavu není a nemůže být jasná, dokud se software nepotká s koncovými uživateli v reálném provozu, a jednak není černobílá, jednobitová. V reálu jde o to, abychom systém co nejdřív konfrontovali s praktickým provozem, a následně ho nasadili naostro ne až bude „hotový“, ale až ta pozitivní hodnota, kterou přináší, převáží negativa.
(Triviální příklad: Lidi si často představujou, že agilně dodané auto bude mít jen tři kola, takže se s ním nebude dát pořádně jezdit. V reálu by dobře agilně dodané auto jezdilo, ale nemusí být dostatečně pohodlné, nemusí mít dostatečný dojezd, etc. Ale řada cestujících se radši projede takhle „nehotovým“ autem, než aby chodili pěšky.)
Úplně souhlasím s tím, že systém veřejných zakázek není – eufemisticky řečeno – agilnímu vývoji nakloněný. To je ale přesně věc, která se musí změnit. A plně souhlasím i s tím, že to není vhodné místo na nějaký idealismus nebo aktivismus, je to extrémně pragmatická disciplína.
PS. Přesunul jsem tuhle diskuzi do staršího vlákna o agilním vývoji, ať můžem v klidu pokračovat a nerozbouráme tu debatu o digitalizaci stavebního řízení. Doufám, že je to tak v pohodě.
1 Like
Nejsem si jistý, jestli si rozumíme. Možná bude lepší příklad. Někde tu bylo zmíněno EET, zůstaňme u finanční správy.
Základní pravidla pro fungování EET stanovil zákon. Říká co to je, čeho se to týká, jaké jsou povinnosti firem a co to znamená pro finanční správu. A také to od kdy začíná platit. Zadání je naprosto jednoznačné a k danému datu prostě musí všechno fungovat tak, jak to vyžaduje zákon. Nic víc, nic méně. Tam pro nějaké přidávání funkcí není prostor a celý projekt musí být postaven tak, aby v danou dobu byl k dispozici plně funkční systém. To je přesně princip vodopádu.
Vedle toho tu je portál Moje daně - což je služba veřejnosti ze strany Finanční správy, která zákonem definovaná není a proto má Finanční správa mnohem volnější ruce v tom, co bude dodáno a kdy. Pro podobné se dá použít i agilní vývoj, pokud se povede vysoutěžit dodavatele a pokud to není placeno (alespoň částečně) z grantu.
Už jen tendr není úplně snadný, protože u agilního vývoje není úplně jasné, co přesně bude na konci. Takže smlouva musí být pružná, ideální je rámcová smlouva. Jenže to je zrovna ten druh smlouvy, který úředníci a politici nemají moc rádi, protože jsou snadno napadnutelné konkurencí nebo bojovníky proti korupci.
A u grantů to je už vůbec neprůstřelné, protože v žádosti musí být přesně popsán výstup. A ten je pak i kontrolovaný. A pokud jste se někdy setkal s kontrolou přiděleného grantu, pak víte, že se jde bod za bodem a pokud je něco odlišně od smlouvy, je to velký průšvih. Nevadí, že jako celek to je nefunkční, pokud to splňuje formální podmínky smlouvy o grantu. Průšvih ale je, pokud se výsledek od smlouvy liší a to i v případě, že užitná hodnota je vyšší než předpokládala žádost o grant/smlouva.
Pokud to shrnu - i ve veřejné správě mohou některé věci být vyvíjeny agilně, v žádném případě se to ale netýká klíčových systémů.
1 Like
Je ještě jeden aspekt, na který by se nemělo zapomínat. Počty uživatelů u většiny systémů používaných ve veřejné správě, u centrálních to platí sto procentně, začínají na vysokých tisících až milionech uživatelů.
Tyto uživatele potřebujete proškolit. Což se jednorázově udělat dá, ale není dost dobře možné školit je s každou změnou stále dokola. A je potřeba mít na paměti, že pro drtivou většinu uživatelů je jejich zaměření úplně jiné, než IT. Informační systémy jsou pro ně nutné zlo. Pokud jim budete měnit systém pod rukama, rozhodně si tím jejich podporu nezískáte. S pravděpodobností hraničící s jistotou jejich naštvanost naopak celý projekt utopí.
Toto je jeden z mnoha příkladů “měkkých důvodů”, které velmi limitují použití agilních metodik ve veřejné správě.
To jsme zpátky u toho mýtu o jedinečnosti naší veřejné správy. Software pro miliony uživatelů vzniká zcela běžně. Často jsou to uživatelé, pro které je software nutné zlo, a co víc – často je výrobce toho softwaru ani nezaměstnává, naopak oni za ten software platí a pokud je namíchne, tak za něj můžou přestat platit a přejít ke konkurenci. To je teprve oříšek! A přesto se ten software nějak rozvíjí.
Tu situaci s EET neznám, ale pokud bude chtít, může reagovat @mwenisch, který na EET podrobně koukal z té druhé strany, jako autor klienta.
1 Like
To není totéž. Software, o kterém mluvíš, lidé používají dobrovolně a proto, že ho používat chtějí. A sám víš, že i pak dost často “novinky a vylepšení” vzbudí spíš vlnu nevole než nadšení.
U IS ve veřejné správě to je jinak - ten software uživatelé používat MUSÍ. A potřebují, aby fungoval stabilně a beze změn, které by se museli učit. To je z jejich strany úplně jiná motivace a jiný přístup. Už tak mají svých problémů dost a ještě aby se otravovali s nějakým softwarem.
To je ale přesně moje pointa. Když se vrátím k digitalizaci stavebního řízení, kterým jsme začali, tak z toho našeho rozhovoru s panem tajemníkem dost jasně vyplývá, že stát na úřady ten nový systém seslal jako morovou ránu, se kterou oni se musí nějak vyrovnat. To je zdaleka nejčastější model a je to špatně.
Součástí agilního vývoje je právě design pro uživatele a s uživateli (viz tu zmiňovanou příručku). Když ten vývoj probíhá takhle a uživatelé se na něm podílí, je naopak větší šance, že ten systém přijmou – koneckonců jeho hlavní úkol je usnadnit jim práci.
Změny budou vždycky, nedá se jim vyhnout. Můžeme zalézt pod kámen a doufat, že to přejde, anebo můžeme změny pragmaticky přijmout jako životní fakt a pracovat s nimi tak, aby to uživatele bolelo co nejmíň.
To ale mluvíš o fázi vývoje. Jakmile ale má systém požadované vlastnosti, pak se by so do něj pokud možno nemělo rýpat. Pak následuje fáze testování, migrace, adopce. Řada po sobě jdoucích kroků a teprve pak je připraven k nasazení.
To nijak nevylučuje, že ve fázi vývoje jde dělat některé kroky agilně - jde to a dělá se to, ale to jsou právě ty hybridní modely řízení projektů.
V agilním vývoji se ty fáze vývoje a údržby tolik nerozlišují, prostě se iteruje, dokud má zákazník zájem něco měnit nebo zlepšovat. Ale navrhuju dočasný klid zbraní na víkend 
Můžem si to nechat trochu projít hlavou a vrátit se k tomu později.
EET je vedle ISSŘ hádám 100x jednodušší - jen pár scénářů, jen jeden nebo dva úřady (celníci na kontrolách), relativně jednoduché API. Ale i tam jde iterovat a vylepšovat, např. seznam účtenek může chodit jednou za měsíc emailem vs. online klikací rozhraní s filtry v reálném čase (teď fakt nevím, co přesně bylo popsané v zákoně), UI jde vždycky udělat o něco lepší a příjemnější…
Nutnost průběžného školení je zajímavý pohled - na druhou stranu, dneska se průběžné změny dějou úplně všude, počínaje telefonem v ruce, přes PC s Windows, aplikace v chytré tv, bankomat na rohu až po všechny aplikace dostupné online. Tj. uživatelé změny aplikací z reálného života znají. Ale ano, určitě to zvyšuje požadavky na zaškolení, plánování změn předem apod. (v korporátu chodí každý týden interní “newslettery”, co všechno a kde se zrovna mění).
Myšlení “IT je nutné zlo” je potřeba měnit v pohled “IT nám pomáhá být efektivnější”, od toho jsme i právě tady. Za tohle už ale nemůže samotná aplikace
Soutěžení na cenu je české specifikum, to se musíme naučit - jinak budou vyhrávat ti bez zkušeností, co podcení délku realizace. Detailní kritéria dotací si taky z velké části vypisujeme sami 
(taky už jsem potkal, že dotované auto pro neziskovku musí být nové - protože to tak vyžadujou podmínky dotace, i když to “řádnému hospodáři” nedává smysl)
1 Like
V této diskusi se nám míchají tři pohledy a díky tomu je to celé těžko uchopitelné a srozumitelné:
- pohled metodický
- pohled legislativní
- pohled uživatelský
Metodický pohled. Existuje celá řada metodik pro řízení projektů a každá z nich je určena pro něco jiného. Samozřejmě se dají použít i pro jiné účely než pro jaké byly navrženy, ale je to už trochu o drbání za uchem.
Agilní metodiky jsou efektivní tam, kde existuje jen volné zadání a to se v průběhu projektu upřesňuje. A, a to je zásadní podmínka, tam, kde je sponzor projektu současně aktivním členem týmu a určuje priority. Jinými slovy, agilní tým vyvíjí to, co si přeje ten, kdo sedí na měšci s penězi.
To je u velkých projektů ve veřejné správě nesplnitelný požadavek. Sponzoři těchto projektů sedí příliš vysoko než aby se mohli aktivně účastnit práce týmu. A ve skutečnosti ani nechtějí, protože to sebou přináší přímou odpovědnost za výsledek projektu.
Legislativní pohled. Existuje zásadní rozdíl mezi privátní sférou a veřejnou správou. Pro privátní sféru platí, že co není zakázáno, je povoleno. Pro veřejnou správu naopak platí, že co není výslovně povoleno je zakázáno.
V praxi to znamená, že u agendových informačních systémů, je jejich návrh a implementace svázána spoustou legislativy. Procesní, jako je Správní řád nebo zákon o archivnictví a spisové službě. Agendově specifické zákony (Stavební zákon, Daňový řád, apod.). A technické - typicky Zákon o informačních systémech veřejné správy, NSESSS a pod. A pak je tu samozřejmě Zákon o zadávání veřejných zakázek. Tohle všechno vytváří prostředí, které velmi přesně definuje požadavky na finální řešení a to jak z pohledu chování systému jako takového, tak z pohledu klíčových termínů pro zprovoznění jednotlivých funkcionalit. Zadání co a kdy je jednoznačné a nedá se s ním pohnout. Výhoda agilních metodik - tedy jejich pružnost - se za takových okolností stává spíš přítěží.
A je potřeba vzít v potaz ještě jednu věc. Žádný centrální systém veřejné správy není izolovaný. Všechny vyžadují integraci s dalšími IS, ať už jde o různé registry nebo o IS jiných resortů. A to je docela oříšek, protože naplánovat a zrealizovat takovou integraci je běh na dlouhou trať a s partnerem je potřeba jednat dlouho dopředu. Prostor pro agilitu tam je minimální.
Pokud jde o legislativu, tak v ní Piráti VELMI pokulhávají. Dokonce i v té, kterou by měli znát nebo kterou dokonce prosazovali. Dokladem toho je právě ISSŘ, který je na štíru snad s každou legislativou, se kterou se potkal.
Uživatelský pohled. To je asi hlavní důvod, proč se “aktivistické” nápady tak míjí s realitou. Veřejná správa je svým způsobem korporát, velmi velký korporát a platí v ní pravidla, jako v každém korporátu. (a) Každý má vyhrazenu svou hromádku písku na které je svým pánem. (b) Základem úspěšného přežití je zajistit, aby člověk v případě problémů nenesl odpovědnost - to je ten okřídlený popis: “Mít oplachovanou pr*el”. (c) Být úspěšný ve vnitrokorporátních politických hrách.
Co to v praxi znamená? Projektový tým na straně zákazníka nebude chtít nést žádnou zodpovědnost za externího dodavatele. To je ve sporu se základním pravidlem agilních přístupů, kde se předpokládá, že sponzor se bude aktivně účastnit činnosti týmu. Proto tolik mnohohlavých jednání (za kolektivní rozhodnutí nenese nikdo konkrétní odpovědnost). Proto tak přesná definice výstupů a termínů - dá se snadno zkontrolovat a není potřeba nic zdůvodňovat. A tak mohu pokračovat. U významných projektů zákazník prostě nepřipustí externí agilní vývoj, protože to v korporátu znamená profesní sebevraždu (něco jiného jsou interní projekty, kde je naopak agilní přístup žádoucí).
Pokud jde o uživatele. U centrálních systémů jich je fakt hodně - spíš desítky tisíc než jednotky tisíc (a občas i o řád víc). Proškolit takovou masu je extrémně náročný a nákladný proces. Zvlášť v okamžiku, kdy uživatelé mají svých problémů dost a ještě se otravovat s nějakým školením pro IS. Přitom podpora koncových uživatelů je pro tyto IS kriticky důležitá - pokud se šprajcnou, pak jakýkoli systém utopí (což je příklad ISSŘ). A co hůř, existuje naivní představa o nějaké hierarchii. Např. že když si nechám nanominovat “klíčové uživatele” a s nimi se domluvím, že to bude platit. To může, ale nemusí být pravda. Stejně tak sice existuje formální struktura rozhodovacích pravomocí, ale ta nemusí mít nic společného s faktickou strukturou. Tohle všechno jsou věci, které není možné u projektů ve veřejné správě ignorovat, protože jinak to skončí průšvihem (viz ISSŘ).
Největším omylem, kterého se nezkušení IT lidé dopouští, je představa o významu jejich IS. Je na to krásný termín: “fachidiocie”. 95% lidí ve veřejné správě bere IT jako nutné zlo. Mají svůj píseček na kterém pracují a tam jsou zase “fachidioti” oni. Člověk z IT firmy možná nechápe, proč má úředník tak odtažitý přístup k IS, který firma vyvinula. Úředník nechápe, jak je možné, že IT firma nezná zákony, vyhlášky a směrnice a že to, co vytvořila nesplňuje požadavky zákona XY, par. ABC odstavec 4b ve smyslu judikatury ÚS č. blflmpsvz. Speciálně u velkých systémů musí mít úředníci pocit, že mluví s někým na své úrovni, protože jinak se s dodavatelem odmítnou bavit a projekt odepíší dřív než začal. Tohle opravdu není jednoduché. A pokud bych měl použít něco, s čím se setkávají lidé v IT firmách, pak je to školení o Bezpečnosti práce - také ho berou jako nutné zlo a přitom pro školitele BOZP je to alfa a omega a bez toho (podle jejich pohledu) firma nemůže existovat.
Shrnu to - agilní přístupy uznávám a často je využívám, pro velké projekty ve veřejné správě se FAKT nehodí. Objektivně jsou specifika veřejné správy a způsobu zadávání zakázek ve veřejné správě v hrubém rozporu s podmínkami, které předpokládá agilní vývoj.
2 Likes
Tohle vše si víc či míň umím představit. Jen nesouhlasím s tím, že zrovna v ČR to nejde - když jinde to umí nebo se aspoň snaží Naučily se to velké korporáty, naučily se to jiné státy. UK a USA už jsme probírali, tady třeba Austrálie Australia adopts agile digital government solutions. Tady je pěkná studie o Německu https://www.tandfonline.com/doi/full/10.1080/14719037.2024.2354776, obojí je vč. popisu problémů, které implementace mezi úředníky přináší a možných cest, jak je řešit - změny organizační struktury, změna mindsetu lidí okolo, i ty zákony jde určitě napsat tak, aby to víc vyhovovalo realizaci (zrovna tohle jsem od Pirátů čekal lepší - ale taky právě na stavební řízení nebylo moc času). Ale ano, nejde přijít s projektem “od zítřka to děláme jinak”, je třeba dlouhodobě pracovat na změně - už jen proto, že ta změna mindsetu se týká tisíců lidí, kteří jsou zvyklí pracovat jinak (úplně stejně je na tom libovolná změna ve školství - změnit mindset ~200 tisíc učitelů je aktivita klidně na 10 až 20 let )
Established bureaucratic structures are reluctant to embrace change, which presents an ongoing obstacle. Frequently, conventional systems have inflexible hierarchies and processes that can be challenging to modify.
…
Some individuals, accustomed to traditional methods of working, may find it challenging to adapt to this shift. Giving proper attention to the importance of sufficient training and resources is key. Staff must have a strong understanding of these new practices in order to effectively implement agile methodologies. Abbouchi emphasises the importance of providing continuous training and development to ensure that all team members have the necessary skills. Insufficient training can lead to a lack of clarity and decreased productivity.Additionally, organisations must undergo a cultural shift in order to successfully transition to agile governance. Leaders must provide strong backing in order to cultivate this fresh mindset. …
1 Like
Mně přijde, že spolu do velké míry souhlasíme. Ty překážky, které zmiňuje Rorrin, jsou určitě relevantní a do velké míry se na nich všichni shodneme. Lišíme se asi jen v tom, co z nich plyne.
Pro mě z nich plyne to, že se veřejná správa musí v mnoha ohledech změnit. Zatím hrozně často slýcháme variace na větu „takhle to ve veřejné správě nejde“. Nejsou lidi, není kultura, nedovoluje to legislativa, etc. Chápu, že než měnit takhle složitý systém, řada lidí zevnitř i zvenčí se radši přizpůsobí. Tak ale podle mě principiálně nemůžeme dostat to, co chceme – veřejnou správu, která efektivním využíváním technologiím zlepšuje život lidí u nás. Proto se to musí změnit.
A každý příklad dobře udělaného systému v naší či jiné veřejné správě ukazuje, že je to v principu možné.
5 Likes
Narazil jsem na zajímavý zdroj z prostředí americké veřejné správy, konkrétně GAO, Government Accountability Office (taková analogie našeho NKÚ?). Vydali celou publikaci nazvanou Agile Assessment Guide: Best Practices for Adoption and Implementation (pozor velké PDF).
2 Likes
zrovna jsem to chtěl taky přidat, narazil jsem na to v tomhle vlákně Waldo Jaquith: "I'm reading the GAO's report on the Department of…" - Mastodon, kde je další “hezký” příklad jak to jednou zas nedopadlo
2 Likes
Tohle je krásný doklad toho, že žádná metodika nebude fungovat, pokud se ignorují její základní principy. Žádná.
Nemyslím, že by tato diskuse měla být v duchu agile vs. waterfall. Jsou různé metodiky, které se více či méně hodí pro různé typy projektů. A pokud mají být projekty řízené úspěšně, pak by vedení projektu a i projekťáci měli velmi dobře znát principy té, které metodiky a její silné a slabé stránky. To sice rizika neodstraní, ale výrazně je minimalizuje.
A mimochodem, je zajímavé, že vývoj vede k prolínání různých přístupů. Krásným příkladem Prince 2 - 7th edition, který do značné míry propojuje oba přístupy. Doporučuji ji Vaší pozornosti.
Já jsem v tomhle radikální: vývoj softwaru vodopádem podle mě ověřeně nefunguje.
Není to otázka správného nebo špatného použití té metody – snažit se vyvíjet software vodopádem je jako snažit se umývat okna motorovou pilou. Bez ohledu na to, jak dobře to s ní kdo umí, to může dopadnout dobře jen zázrakem.
Protože samotná ta představa, že jsme schopni pro jakýkoliv netriviální kus softwaru napsat požadavky předem, je iluzorní a pomýlená. Respektive opakovaně se to děje, ale opakovaně, desítky let (!) na základě takto sepsaných požadavků vznikají systémy, které nenaplňují potřeby uživatelů, jsou dodávané pozdě a jsou mnohonásobně předražené.
Samotná myšlenka v jádru vodopádu je chybná a nepomůže tomu žádné rigoróznější popisování požadavků ani jiná pokročilá formalizace nebo certifikace toho procesu.
4 Likes