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

v skratke, prisli s napadom ze ked takyto velky projekt rozdelia na kusky tak bude obstarany lacnejsie a skoncili s 35 dodavatelmi, zakaznik zacal menit predstavu co chce a potom sa im cely projekt rozsypal. a tak to stalo o 3 mld viac a o 8 rokov dlhsie. A k tomu sudne spory, neplatenie faktur. no skoro ako na slovensku. Nehovorim ze to delenie bolo jedinym dovodom ale zvysilo riziko a tu sa to nevyplatilo.

JA ten nezmysel, ze 1 robi analyzu a iny programovanie, vidim tak, ze nova zalozane firma s programatormi nema analyticke schopnosti a chce mat vlastny biznis, tka nech niekto urobi analyzu a ked porozumeju biznisu, tak uz to dopracuju so zakaznikom. Proste ucel svati prostriedky, ale rad by som sa mylil, pretoze ten nezmysel hlavne v suvislosti s agilitiou, zatial nikto nevysvetlil.

Na margo agilinosti a delenia zakazok:

Nerozumiem potrebe v argumentacii vzdy pouzivat extremne priklady ci uz waterfall alebo agilnosti a takisto extremne priklady delenia zakazok pomaly na microservice - ani jeden extrem nieje spravny.

K deleniu zakazok - mali by sme si veci povedat narovinu ani zdaleka nie sme v takom stave ze by sa uz zachadzalo do nezmyselneho delenia zakazok na granularitu ktora sa neda beznymi kapacitami na strane zakaznika ustražiť. Prave naopak podla mna sme vstave ze sa zakazky stale extremne spajaju bez dovodne - uvediem priklad a nebudem chodit daleko do minulosti ( budem abstrahovat od poznamok typu ci sme to potrebovali alebo nie a ceny za projekt)

  1. projekt https://www.crz.gov.sk/zmluva/5053015/ - hodnota cca 17m - dodavetal interway
  • zmluvu uzatvoril jeden dodávateľ - má evidentných subdodávateľov a velkých -

  • delenie je zrejmé niekto dodá licencie niekto prácu a tá práca sa dá tiež delit nakonci dna ide len o popridávanie imagov do ICO a nakonfigurovanie, kludne sa to dalo rozdelit do minimálne 4 súťaží - licencie, Natívne PaaS, Licenčné PaaS, Dev OPS - a kludne aj v case a podla potreby sa to mohlo obstarat - cize onebostoji ani argument že v prípade že jedno obstarko zlyhá dostaneme sa do sklzu

  1. projekt https://www.crz.gov.sk/zmluva/5049685/ - dodavatel Anasoft - cena diela cca 5m
  • v rámci diela sa dodáva agendový systém pre podporenie agendy IS KaSP
  • ERP - čisto vnútorná správa takmer vôbec neprepojená na agendový systém - obsahuje mzdy, presonalistiku, evidencie majetku a pod
  • podporné systémy - zmeska rôzny aplikácií z ktorý by sa taktiež dali vyselektovať samostatné zákazky nesúvisiace alebo minimálne súvisiace hlavným IS KaSPnapr archív, reporting a DWH

a takto sa dá ísť rad radom projekt za projektom. a argument že treba velkého systémového integrátora neobstojí lebo tia jednotlivé časti spolu takmer ani nesúvisia

K agilnosti podľa mňa ak budú zákazky správne rozdelené tak v rámci každej dodávky je možné rôzna variabilita stupna agilnosti, a za posledne roky som sa nestretol teda s projektom ktory by bol striktne waterfall ze tu je DFS a co tam nieje napisane neplati a musi to byt len presne co je napísané (takýto posledný dodávateľ ktorý to robil bol Ditec a NESS). Každý dodávateľ bez problémov a vo vlastnom záujme komunikuje so zákazníkom a snaží sa mu vyjsť v ústrety aby bol spokojný, otázka je len tá miera že dokedy vychádzať v ústrety dokedy projektovemu manažerovi dovoli budget projektu ? a tu nastupuje otazka ake su marze projektu a kam by mohli jednotlive firmy az zajst v rámci agilnosti ? (a na to si na slovensku vo verejnej sprave nech kazdy odpovie sam. :D:D)

Zaver za mna - stale axistuje velky priestor pre uplatnovanie vačšej granularity zakazok, a takisto pri tych government cenach je podla mňa možná aj velká miera agilnosti práve v časti scopu.

1 Like

Problemom je VO, ktore na Slovensku nefunguje a kazda druha sutaz nekonci zmluvou, niektore trvaju 100 dni a neiktore aj 800dni. Nuz a ked rozdelite zakazku na casti a na samostatne obstaravania a jedna cast nema zmysel bez druhej casti, tak potom delenie je kontraprodktivne. pretoze napr. nebudete vediet dodat svoju cast bez niecoho co neexistuje. Takze aj tento problem je potrebne brat v uvahu (hlavne kym mame VO ake mame). A ten priklad s berlionskym lletiskom si je potrebne tiez precitat. inak, ale nemam nic na delenie na castio ak sa to naozaj rozumne urobi, nebude sa delite tak, ze jedno bez druheho da neda odovzdat alebo pouzivat.

Este si je potrbne uvedomit, ze urobit 4 VO napr, na 1,5m EUR je pracnejsie ako jendo na 6M EUR a dtto schvalit v Bruseli 4 proejkty meisto jedneho (ak to bude z EU fondov), bdue to takisto viacej
kontrol atd. atd.

K agilnosti podľa mňa ak budú zákazky správne rozdelené tak v rámci každej dodávky je možné rôzna variabilita stupna agilnosti,…ze tu je DFS a co tam nieje napisane neplati

presne tak. Nevierim, ze niekto z praxe moze mat na to iny nazor. Jedinou (tazkou) otazkou je, ako tu agilnost premietnut/sformalnit aj do VO a realizacie projektu. Opakujem sa asi…aby to nebolo len o profesionalnej cti dodavatela/realizacneho teamu. Bez urcitej miery agilnosti sa neda uspesne (nemusim rozvadzat, ze sa tym nemysli vyfakturovanie) realizovat ziaden trochu komplexnejsi projekt.

1 Like

Myslim, ze to @Joz vysvetlil. Akademicky. Tam, kde je prirodzena vysoka miera kohezie konkretnych kompenentov, nema zmysel delit zakazku. Tam, kde medzi nimi neexistuje ziadne previazanie alebo sa praveze ocakava volne je ziaduce oddelit aj z hladiska VO. Nasilne delenie zakazky(popri tom vsetkom, co bolo spominane vyssie pri priklade z nemecka) povedie popri vsetkom aj k ovela vyssej komplexite. Naopak, ak sa oddelenie ocakava rozdelenim zakazky sa lahsie vynuti volne previazanie. (samozrejme netvridim, ze volne previazanie nema zmysel (s rozumom a v primeranej forme) aj v ramci ucelenej dodavky, pre istotu…)

…a zase len povzdychnutie pri vsetkej skromnosti, ze kde su ti architekti, ktori toto budu strazit. Matne si spominam napr. na jeden “stratetegicky” dokument na temu “microservices”, ktory bol velmi zlym prekladom/plagiatom a autor zjavne nerozumel tomu, co preklada.(pochopil som o com pise, az ked som sa dostal ku vykradanemu zdroju) A takto to tu funguje roky, bolo treba nieco konecne vyproduktovat, akvizovat nejaky “buzzword”, tak sa to urobilo. Miesto sirenia osvaty, postupneho zavadzania principov, budovania autority, ku ktorej bude clovek vzhliadat a chodit po rozumy, moze IT trh/dodavatelia vzhliadat akurat ku zlym plagiatorom.

este k tej agilnosti moj osobny postoj - pri pevne stanovenej cene radsej budem dodavat agilne zakaznikovi to co chce a ukazovat to stale, dodrziavat neake zasady CI/CD - a dovolim mu to az do takej miery ze radsej ako robit DFS so stanovenym scopoma ist strikne podla nej, tak radsej ked uz nebude budget sa budem so zakaznikom hadat aby pochopil ze aj on to musi cutnut poziadavky lebo budget je uz na konci - a mam na to jednoduchu vyhovorku komu sa chce robit v dnesnej dobe robustna DFS ? - radsej spravim kvalitnu prevadzkovu a pouzivatelsku dokumentaciu ale DFS bleeee -

a tu je prave priestor na to ako dostat agilnost do VO aj eurofondovych projektov - mame zakladne ciele ktorych si je vedomy ziadatel aj dodavatel a treba ich plnit v zmysle ZoNFP - ale ani v Studii ani ZoNFP nie je detailne povedan ze ako sa to ma spravit. Jediny problem preco sa robia komplikovane DFS je ze je v ZoNFP uvedena faza Analyza a Dizajn a tvrdohlave QA bude vyzadovat komplexne robustne vystupy z tejto fazy. Aby sa mohla premietnut aj vyssia miera agilnosti do eurofondových projektov je ze treba zmenit postupy QA (napríklad že nebudú hodnotiť prces tvorby, procesy pripominekovania a schvalovanie DFS ale budú v zmysle princípov agilnosti hodnotit či sa doržiavaju sprinty, ako sa zadávajú a poťty kolko sa realizuje taskov v rámci šprintov, dodržanie zapojenia zákazníka do procesu development a spôsob schvalovania taskov, hodnotili by pokrytie kody testami - proste nastavenie CI/CD. Zaver: vidim priestor aj v súčasných existujúcich nástrojoch SORO práve v úprave metodiky QA

Bolo by dobre aby to niekto najprv pilotne par razy overil, skor ako to zacnu aktivisti natlacat do povinnych metodik.
Osobne to vidim mierne odlisne, hlavne tu agilnost :slight_smile: Ale veci sa daju menit, ale nie tak ako dnes. Verba movent, exempla trahunt

suhlasim a netvrdim ze v metodike QA to musi byt ako povinnost lebo to je tiez blbost, kazdy projekt je iny na kazdy je vhodne nieco ine a tomu by sa mal prisposobit aj to mnou spominane QA - lebo teraz je to nastavene ze sa skontroluje strikne dodana dokumentacia DFS, prirucky, testovacie scenare a pod - a pritom DFS vsetci vedia ze uz je neaktualna v dobe schvalovania RV, proste cela QA a kontrola je nastavena na waterfall.
Ja uvediem striktny priklad kontroly QA a kontroly na mieste v casoch OPIS z osobnej skusenosti cca 2010/2011 - jeden z prvych odovzdavanych projektov OPIS - mali sme vystavene rozhrania - aby sme naplnil ciel musi byt sluzba - rozhranie sme mali REST/JSON, to boli neskutocne hadky z mojej strany ked mi QA vysvetlovalo ze som mimo standardov a mam mat SOAP a wsdl popis k rozhraniu a ze to mame prerobit.
A kludne nech si projekt tailrojue metodiku, len proste nech nieje len jeden must pre všetky projekty, lebo vzdy narazime na vynimku a extrem a potom sa budeme dohadovat ze to nie je dobre vseobecne, pritom to nebolo dobre len pre ten jeden pripad.

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:

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?

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.

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.

“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 ?

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.

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:

1 Like

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 )

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.

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.

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.