Online diskusia: Fáza realizácie IT projektov - jej úskalia a ako sa im tentokrát vyhnúť

Čo je nové v Slovensko.Digital
121

T.j. vraciame sa cca 10-20 rokov spat a oplieskame dalsiu cca miliardu tak, ako doteraz, t.j. bez vyraznych prinosov pre obcana s obrovckym technickym dlhom na dalsie roky az desatrocia. Podebatili sme si, vec uzavreta. :slight_smile:

Ale vazne, dali ste dobre otazky a pointa (ak chapem spravne) je taka (a s nou aj suhlasim) ze nech na na MF, UPVII, NASES, MIRRI akolkolvek zmenilo osadenstvo, org. struktura, mandaty, rozpocet, nazvy, sidla, politicke strana z ktorej je hlavny nominant, atd., v zasade stale robia poslednych 10-20 rokov veci tak isto a teda zle.

Pre mna su dve nadeje: 1) ze tu na platforme dokumentujeme co je zle a (zvycajne) sa tam pripletu aj dobre napady na zlepsenie a 2) ze ti “aktualni novi” nominanti a ich poradcovia uz maju urcite zablesky “chcenia” to robit lepsie a maju aj “platformu” (zriadene MIRRI s urcitim budgetom a pravomocai, to pred tym v zasade nebolo). Ostava teda “len” prekonat tu obrovsku zotrvacnost VS a teda bonusovy bod 3) podobne ako Jano ci Lubor dokola opakovat tych par dobrych rad, nech uz ich koncerne tentoraz MIRRI aj realne spravi. (Alebo ist po vzore @janhargas a realne “ist do tej VS” menit veci.)

Su dobre ako priklady a na opisanie extremnych stavov a na zvyraznenie vyhod a nevyhod. S tym, ze v SR mame bohate realne a casto negativne skusenosti s “extremnym waterfall”, ale takmer nulove realne skusenosti s “extremnym agile” (ktory by ale IMHO zlyhal tiez).

Podobna debata prebieha okolo opensourcovania vystupov eGov: doteraz je zvycajne vsetko extremne zavrete (aj ked pod kapotou je kopa Opne Source) a argumentom za zotrvanie v tejto extremnej pozicii je konstatovanie, ze opacny extrem (=vsetko Open Source) by nefungoval. Duh! ved ano!

Pointa pri oboch tychto debatach o dvoch protikladnych extramoch je teda ta, ze mame tu jeden existujuci extremny stav a nie sme s nim spokojni. Opisujeme teda (pre nazornost) iny opacny extremny stav, ale samozrejme nechceme to preklopit do opaku, chceme to “od extremu” posunut “do stredu”. S tym, ze veci sa menia kontext je indfividualny a teda aj ten “posun do stedu” ocakavame postupne a na viac krokov s tym, ze po kazdom kroku sa bude pozorovat a hodnotit a nasedujuce kroky su korekcia na zaklade spatnej vazby.

Pouzitelnym zaverom vsetkych debat tu naozaj NEmoze byt to, ze “alternativa nie je (sa tvarime ze nie je) a budeme to robit tak, ako sa to robilo doteraz”. Miliardy odtekaju, vysledky zalostne.

IMHO mi aktivisti sme to uz prakticky videli dost vela krat a dost casto aj “dobre”, aby sme take tlacili do metodik s cistym svedomim. :slight_smile: [ Ja som inak na par malych projektoch agilne robil a vzdy to bolo o tom, ze nastudovanu teoriu ci predchadzajuce skusenosti trebalo prisposobit konkretnemu timu, firme, produktu. Bolo potom silno vidiet, ze ci to ludia robit chcu a hladaju funkcny model alebo to len dostali nejako prikazom a trapia sa ci dokonca sabotuju pri kazdej prilezitosti. ]

Ale Jano sa myslim snazil opakovane vysvetlit, ze netlacime “vzdy a vsade 100% pure agile” a “delenie az na microsevices vzdy a vsade”. Len teda aktualne mame “extremny waterfall” a prudko prevazuju nedostatky, t.j. chceme “menej weaterfall, viac agile, s ohladom na specificke okolosti”.

Hej, pekny nazorny priklad, ked sa islo “podla napisaneho (bez rozmyslu)” a ignoruje sa “zamyslane/realne chcene”. :slight_smile:

122

Hej, pekny nazorny priklad, ked sa islo “podla napisaneho (bez rozmyslu)” a ignoruje sa “zamyslane/realne chcene”. :slight_smile:

Ako vieme, ze realne chcene nebolo to SOAP? Co ak maju cely ESB postaveny na tom?

123

Problem ako ho vnimam je ten ze jedna stranka je co si myslite a druha ako sa to prejavi. Cokolvek co dostane do metodiky alebo nedajboze zakona nasledne vykonavaju ludia co neberu a ani nemozu brat do uvahy “to takto nebolo myslene”. A to co sa dostalo do metodiky ako je napriklad to ze sa maju projekty odovzdat po castiach a tak aj platit vedie k tomu ze sa zhorsi stav kde sa vzdaluje projektova realita od vykazovanej. Rigidne pravidla k tomu vzdy ciastocne vedu ale taketo dobre napady to zhorsuju.
Viac agile je fajn, ale cesta pritvrdzovania metodiky je cesta presne opacnym smerom. Neda sa na jednej strane neverit v dobre umysly a zaroven verit ze agile bude uzitocne. Samotna filozofia agilnych pristupov je o budovani dovery medzi dodavatelom a zakaznikom a v nasom pripade aj s kontrolnymi organmi. A sucasne otvaranie priestoru na vyuzitie tejto dovery co znamena MENEJ metodiky, MENEJ prikazov, VIAC prikladov, VIAC podpory.

124

co to realne chce vie urcite lepsie dodavatel a zakaznik ako kontrola z MIRRI. A toto je priklad v podstate dobrej myslienky, ktora sa stala standartom a tak sposobila zbytocne problemy. Ked sa zacali pisat metodiky pre OPIS, tak predpisali SOAP ako standart pre komunikaciu medzi systami, kazdy akadamik s tym suhlasil, co by na tom mohlo byt zle, ved presne na to SOAP je. Ale v praxi to neplati, tam kde ide o jednoduche ziskavanie informacie tam je REST jednoduchsi a rychlejsie sa implementuje aj prevadzkuje. A predpkladam ze toto bol tento pripad, neslo o komunikaciu medzi existujuci systemami ale o vystavenie sluzby.

125

“Moderné” ESB by malo podporovať aj REST / OpenAPI (alebo API Gateway?). Možno bolo podstatné, aby bolo rozhranie zdokumentované a contract-first. Nech je to aj gRPC keď to má schému a dokumentáciu a môžem vygenerovať clienta :slight_smile: či ?

126

Ale ak maju cely ekosystem na SOAP? A nemaju kapacitu/chut riesit nejake REST/gRPC, ked SOAP poznaju, a funguje im ako potrebuju?

Ja by som to nechal na zakaznikovi. V pripade ze vidim, ze to nedava zmysel, tak si to aj tak necham najskor podpisat ako change request.

127

Historicky tam bol SOAP, lebo to bol v tej dobe jediny standard co vtedy ako tak bol vsade v enterprise sw akceptovany a podporovany. Samozrejme odvtedy sa doba zmenila, REST ma okolo seba uz aj nejaky ten tooling a standardizaciu.

Samozrejme to, ze sa REST podarilo oficialne “povolit” ovela neskor ako by sa patrilo je druha vec.

Ani SOAP v standardoch vsak nezabranil uplne sialenym znasilneniam pointy toho celeho.

Z coho vychadza filozofia agile mozno lepsie pozriet sem:
https://agilemanifesto.org/principles.html

1 Like
128

plus

Tento “pattern” argumentacie som uz videl u niektorych uradnikov vramci Strandardizacnej komisie. Pointa je v tom, ze teda zhodneme sa na tom, ze nieco je zle a to nas vedie k tomu, ze teda konsenzualne doplnime Vynos/Vyhlasku. Potom je aj tak nadalej zle, pricom uz teda padne aj argument “je to [Vynos/Vyhlaska] zlozite”. Suhlasime, ale akekolvek uvolnovanie/zjednodusovanie naraza na to, ze “robia to ludia a ti idu len podla napisaneho”. Opat sulasim, ale to uz sa potom tozime dokola a medzicasom je stale zle a “dobre bude” je v nedohladne. A teda rovno pisem, ze riesenie vidim v obstarani kvalitnych ludi (vid napr. tu: Seminár na tému: Ľudské zdroje IT vo verejnej správe a ich vzťah k eGov v SR - #6 by Matus_Kollar )

Kym sa tocime v kruhu, plati status-quo, kedy tecu miliardy na hluposti. Co s tym? Nuz jedna z moznosti je to, co pisete:

Velke +1, len teda to je TODO najma na MIRRI. Co si pamatam, tak im to tam hovoril uz nejeden clovek za ostanych X rokov (“im” = pocnut standardizaciou na MF, neskor informatizaciou ako takou na UPPVII a MIRRI konciac).

Dam konkretny aktualny priklad, ako by som si “ten support” predstavoval v teme Open Data:

To je nieco, co dokonca mozeme “odpisat a len prelozit so slovenciny”, len je nutne, aby to nebolo na opendata.sk ci slovensko.digital, ale niekde pod .gov.sk . Nic zlozite. Tipujem vsak, ze to konci na uz spominanych ludskych zdrojoch: ze teda oddelenie MIRRI, ktore by toto mohlo a malo spravit nema dost ludi na to, aby zvladli este aj toto. Vysledkom je teda to, ze sice mame dokumenty, strategie, metodiky atd. (a pisemedalsie), ale mame len velmi nizku uroven realnej podpory od realnych ludi.

129

len k "ze “robia to ludia a ti idu len podla napisaneho” . To je pravda len ciastocne, v celom procese je plno roli a taketo generalizacie skryvaju podstatu. Na zaciatku su ludia zo statnej spravy co nieco chcu ( a ti nejdu podla napisaneho, ale zase nemaju predstavu co to presne znamena a ako to zapada do komplexneho obrazu. ) potom su tam konzultanti co vedia nieco celkovom obraze ale nie su uplne zorientovani v domene. A vysledok tak je sice podla toho co je napisane ( metodika ziadosti, CBA a pod. ) ale nikto nie je uplne spokojny. A kvalitni ludia sice pomozu vzdy ale nemyslim ze ten problem je hlavne v nekvalitnych ludoch. Alebo ze dobre zaplateni ludia to zazrakom zmenia.
A potom raz pride faza realizacie, kde mas aj kvalitnych ludi ( u dodavatela) co maju snahu nieco spravit ale narazia na metodiky, procesy a po case to vzdaju. Pretoze kontrolu robia ti co nemaju znalosti o domene a tak im nic ine ako kontrolovat formu a procesy neostava. A keby boli kvalitnejsi tak by zrejme este stav zhorsilo, vyborne napady v case ked je projekt rozbehnuty su malo vitane.
Ale inak, cestu zlepsovania metodiky sme teda vyskusali a vysledok je zasadne spomalenie pripravy projektov a to este nezacala implementacia. Ake su KPI zlepsovania metodiky a kedy bude jasne ze toto nebola dobra cesta ? (alebo ze naopak bola). Kazda zmena procesu ma totiz rovnako svoju tabulku prinosov a nakladov, len sa o nej nehovori.

130

Dá sa len súhlasiť. To čo chýba, sú praktické paterny a príklady “dobrej praxe” v slovenskom IT.

Druhou vecou pri VO by som riešiť súčasťou ponuky jasne prezentované návrhy vo forme prototypov, t.j. aby reálne dodávatelia ponúkali výstupy, s ktorými majú skúsenosti. nemusia to byť doménové znalosti, môžu to byť aj príklady dobrej implementácie (princípy microservisov, biznis analýzy, integračné skúsenosti, dátový manažment a pod.)

zo skúseností by som skôr ako doménovo (agendovo) rozdeloval projekty na dodávateľov podľa ich skúseností s implemenáciou “generických” funkčností, samozrejme ideálne nad open source.

ďalšou vecou je naozaj masívna podpora štátu v poskytovaní centrálnych služieb či už IaaS (vrátane podpory implementácie nad), PaaS, SaaS ako aj dostupnosť bodyshop kapacít pre potreby projektu špecialistov štátu - architektov, analytikov, dátových architektov, portálových špecialistov - hlavne UX, SEO, DevOPSákov, Security manažérov…

Treba sa pozrieť na to, preto sa tvoria niekedy striktné pravidlá a centralizácia nasilu ako princíp, a neberú sa príklady dobrej praxe s komerčného svete. Začína sa štátne IT vzdaľovať komerčnému IT, čo neviem či je OK.