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

Srdečne vás pozývame na našu ďalšiu online diskusiu na tému: Fáza realizácie IT projektov…jej úskalia a ako sa im tentokrát vyhnúť.

IT projekty OPII sa postupne začínajú dostávať do realizačnej fázy. Oproti minulosti by v nej malo byť viac transparentnosti, iteratívnosti, sľubujú sa služby s pridanou hodnotou pre občanov, efektívnejšie vynakladanie s finančnými prostriedkami.

MIRRI chce podstatne silnejšie projekty riadiť aj v tejto fáze, je tu nová vyhláška aj uznesenie vlády z minulého týždňa. Riešitelia a dodávatelia majú kopec pozitívnych aj negatívnych skúseností z minulosti. Za Slovensko.Digital budeme aj v tejto fáze projekty sledovať a hodnotiť pomocou Red Flags.

Čo sú kritické miesta, na ktoré si treba dať v realizačnej fáze pozor a ako bude svoje nové kompetencie MIRRI vykonávať?

Diskutovať budú:
Andrej Kramár, vedúci oddelenie riadenia kvality, MIRRI
Emil Fitoš, prezident IT Asociácie Slovenska
Ľudovít Holbík - riaditeľ odboru IKT a EVO, Úrad verejného obstarávania
Ľubor Illek, Slovensko.Digital

Otázky je možné pýtať sa už teraz vo tomto vlákne a vybrané z nich použijeme na začiatku ako úvod do diskusie.

Diskusia bude prebiehať cez Zoom - https://zoom.us/j/92724654718… a zároveň bude streamovaná aj na našom Facebooku.

Otázky budete môcť klásť cez Slido (prihlásite sa jednoducho na stránke slido.com s kódom #SD20).
Tešíme sa na vás.

S pozdravom,

Tím Slovensko.Digital

FB event: https://www.facebook.com/events/472735106986825/

2 Likes

Nejak mi unika kto z diskutujucich za posledny rok realizoval nejaky IT projekt tak povediac “priamo na bojisku” alebo teda o com bude vlastne ta diskusia… teoria vo vyhlaske je pekna

2 Likes

Bude sa diskutovat o tomto:

trocha rozsirim obzor, preco taka selekcia a snad lepsie pochopis:

  • z OPII sa implementuje minimum projektov, ked abstrahujem od cybersec a projektov v rezime
  • Kramar reprezentuje MIRRI ako gestora vyhlasky o riadeni projektov…prave on ma nastarosti QA a metodiku a vyhlasku pre riadenie projektov, t.j. vela OVM s nim komunikuje a na tych par projektoch uz robil QA kontrolu
  • Fitos reprezentuje pohlad firiem/tradicnych dodavatelov eGov projektov a teda dufame, ze prinesie ich pohlad, skusenost a kde vidia rizika
  • Holbik reprezentuje OVM (UVO), ktore ide implementovat narodny projekt v ramci OPII Red Flags: Systém verejného obstarávania (SVO) a teda musi splnit vyhlasku o riadeni projektov, cize tiez bude zaujimavi ich pohlad, kde aktualne su, co vidia rizikovo a pod.

Co takto sa zamysliet a prispiet otazkami do diskusie? V com ty vidis rizika implementacie IT projektov v state ako by si ich mitigoval?

to je je dobra tema, suhlasim, nejako som ten bod prehliadol

Podla mna by bola zaujimava debat napr. 5 ludi z 5 roznych projektov v roznych roliach (PM, architekt, hlavny analytik, veduci vyvoja, veduci testovania…) a ako sa vysporiadali s implementaciou.

Rizika su podla mna vzdy v neznamom zadani, chybajucom biznis vlastnikovi, nedostatku kvalitnych ludi (na oboch strtanach) a zlom planovani, vacsinou top-down. Samozrejme cest vynimkam!
Rizika novej metodiky su v byrokratizacii procesu a minimalnych praktickych prinosoch, resp. bude treba ovela vacsi tym ludi, co je mozno jedna z mitigacii.
Tie mitigacie su tazke v nasom prostredi, vynasnazim sa vypocut diskusiu a nieco sa naucit :slight_smile:

2 Likes
  1. Problem prvý, akékoľvek triky riadenia nám nijako nepomôžu ak celý obsah je mimo. Dobre vieme ako vyzerajú zadania. Sústredia sa na formalizmus, podstata toho čo sa má vlastne pri sw diele dodať sa veľmi ťažko definuje. ale dobre sme v realizačnej fáze, takže toto preskočme.

  2. Biznis vstupy sú nedostatočné: sú dodané väčšinou vo forme zákonov. Nuž zákon si prečítať vieme. Problém je že potrebujeme vedieť ako ľudia konkrétne postupujú pri tej práci. čiže potrebujeme pracovné postupy, tie na úradoch neexistujú, alebo keď sú, tak sa nevenujú organizačnému zabezpečeniu práce, ale špecifickému problému ala v odovodnení bude toto a toto, lehota pri tomto je taká a taká. Nuž fajn, avšak z toho neviem čo má vidieť na obrazovke keď to píše ani neviem či to musí napísať za 10 minút pretože na neho čaká iný zamestnanec prípadne klient.

  3. systémovej analýze nikto nerozumie u zákazníka a nakoniec sa akceptuje čo sa dodá. začíname systémovou analýzou ktorá je väčšinou technologicky nezávislá=uml, teda sú tam Use case, max nejaké integračné sekvenčné diagrami, a doménový model. Tieto nemá kto čítať. Skoro vždy sme dostali biznis ľudí, rozumej úradníkov z praxe, ktorý uml nepoznajú a podstatou ich pripomienok sú nepodstatné detaily, typu tento parameter má byť 24h a nie 48h, aj keď je jasne že ide konfigurovateľný parameter.

  4. kým sa dá niečo vidieť je neskoro a ťažko sa mení. waterfall zadefinuje nejaké míľniky, ukáže sa čo sa spravilo, no ak je to úplne mimo začína boj. bolo to podľa analýzy tu ste schválili - my sme to takto nepochopili, atd. Všetci hľadajú nejakú cestu ako to dodať aspoň nejako v termíne.

  5. nedá sa meniť prvotné zadanie. prvotné zadanie bolo nesprávne-nedostatočné, treba počas projektu zmeniť scope. totálne peklo. neviete zmeniť nič bez polročného hadrkovania. ak ste mali spraviť 50 služieb, medzitým sa ale zmenil zákon a 4 nerelevatné a namiesto toho by ste radšej dodali integráciu na nejaký is pre automatizáciu niečoho tak sa začne peklo odhadovania virtuálnych implmentácii a atd. radšej sa nato vykašlete a dodáte blbosti.

  6. UAT nevie zabezpečiť kvalifikovaným personálom. - má byť testovanie u zákaznika aby si bol zákazník istý že dostáva to čo má dostať. avšak väčšinou nemá kto, tak sa napíšu testovacie scenáre, a zorganizuje sa nejaký test s brigádnikmi pod absolútnym vedením dodávateľa.

Nuž tu som zhrnul základne veci, asi sú to obecné problémy, stretávam sa s nimi aj v súkromnej sfére, teda mimo problému so menením scope, kde v súkromnej sfére radi menia všetko stále a v verejnej trvajú na všetkom doslovne.

2 Likes

Myslim, ze otazky ma zmysel davat ku nejakej koncepcii, dokumentu, inak to budu vystrely do tmy.
Obavam sa, ze to bude zase zase nejake “predstavenie” (sa, niecoho) s komparzom.

len na odlahcenie: Kto bude prezentovat nazory tych netradicnych dodavatelov? :slight_smile:

sorry, na toto musim zareagovat pri vsetkej pokore

Je uplne normalne, ze sa rozpravas s uradnikmi o pracovnych postupoch (vsetky dotknute prac. pozicie) a konfrontujes to aj so zakonmi a predpismi. Je normalne, ze s nimi stravis cast pracovneho dna/i. Neviem si predstavit analyzu bez tohoto. Nestretol som sa s uradnikom, ktory by nebol rad, ze sa naozaj zaujimas o jeho pracu a neytvoril priestor (samozrejme, ak mal priestor alebo nechcel robit zle).
A specialne ak mal zle skusenosti s dodavatelmi, tak tu hned videl v pristupe rozdiel - citil sa ako partner, nie obet experimentu.
(pekna otazka by napr. bola, co mas robit, ak zistis, ze uradnik ciastocne robi nieco v rozpore so zaknom, aj ked ma na to mozno dobry dovod a je to dlhorocna prax)

Stotoznujes analyzu s UML? Tvojou ulohou ako analytika je zabezpecit, aby zakaznik rozumel. Analyticke vystupy su/maju byt vasim spolocnym dielom, analytik ma byt pojitkom medzi vyvojovym teamom a expertom na strane zakaznika, musi si osvojit jeho jazyk (aj tie analyticke vystupy). Samozrejme, ze ak je vasim spolocnym kontraktom splet UML diagramov, tak to '“nema kto citat”(=nechce sa mu, ani mne by sa nechcelo). Co tak ponuknut mu z pohladu behavioralnej analyzy nejaky pekny strukturovany text napr. vo forme use cases (je to nieco ine ako use case diagram, aj ked to suvisi). Nic efektivnejsie ako text sa v tejto oblasti zatial nevynaslo. Ty mu ponukas komix, ktory je mozno fajn na zachytenie jednoduchych pribehov pre deti ale nie na verne zachytenie tych zo zivota. Skus mu ponuknut radsej putavu poviedku alebo roman s peknymi ilustraciami, ktore mu ten pribeh dokreslia. Mozno ziskas ine skusenosti.

2 Likes

naslo by sa aj nieco lepsie, nakreslene obrazovky v powerpointe aby bola jasna predstava co to bude robit, ale aj s UML sa da pracovat ale nie sposobom ze to dostane na pripomienkovanie. ale na stretnuti je to dobry podklad k debate. ale dobrych analytikov nie je vela ani na strane dodavatelov.

S nemym uzasom zatial sledujem tuto diskusiu. Ked v studiach uskutocnitelnosti sa bez hanby napocitali miliony eur cez UCP (na ktore treba vediet napriklad taky pocet transakcii/interakcii na urovni use-caseov) a tu sa dozvedame, ze toto sa vlastne cele zacne robit a spisovat az po vysutazeni?

ja som hovoril v tej casti uz o vystupe. Samozrejme a suhlasim, ze veci je potrebne prechadzat priebezne (tvorit) a je vela foriem/pomocok ktore v ramci toho procesu mozu pomoct. Hoc aj powerpoint, zakladne uml, visio, tabula a fixka…

Ale napadla mi otazka smerom k tej online diskusii: Ako premietnut do VO kvalifikaciu a priestor napr. pre kvalitnu analyzu. Lebo mozeme si tu pisat cokolvek ale pokym to bude len o profesionalnej cti a ked sa bude dat dodavat aj bez nej.(a asi to bude aj lacnejsie)

Nemyslim si, ze napisem nieco, comu nerozumies. Tu sa diskutuje o (detailnej) analyze, nie o “studiach” a metodach na odhadovanie pracnosti. Samozrejme, aj pri studii(inception phase v RUP) by si mal identifikovat min. ciele/potreby (nazov use case) a odhadnut pracnost na ich naplnenie.(napr. UCP) Kvalita odhadu bude umerna presnosti tej analyzy v tejto faze. Ak tam je velky rozpor, bud bol slaby vizionar autor studie alebo sa vymkla z pod kontroly realizacia …alebo cudujme sa spolu :slight_smile:

Presne tak. Studie uskutocnitelnosti “realny zakaznik” vacsinou ani nevidel a nie, ze sa s nim spracovali. Studia sa robi s inym ludmi a system s inymi (pretoze vtedy uz musia nastipit ludia co to realne robia). JA som videl niekolko studii (dalsie som radsej ano nechcel vidiet) a ked som spytal (v organizacii kde ich poznas) klucovych (co robia a vedia ako biznis ide), ze preco ako sos studiou, tak bud ani nevedeli, ze sa robi a navyse povedali, ved nacoi sa tym teraz zaoberat, ked ani neviem ci implementacia vobec bude, ked bude bude o x-rokov a mozno sa budue robit nova studia, proste ak sa bude robit realny system, tak potom sa uz o to je potrebne zacat sa zauji,at (to je je rozmyslanie aj vedenia organoizacii - na co sa zaoberat tym, co vobec nie jeasne, ze sa bude implmentovat) - talk ich to naucil zivot a dal im za pravdu za tie roky.

A este jedna vec k taj analyze - zakaznik vacsinou nema vobec predstavu co by mohol dostat elektronizaciou (tak vyzera aj navrhnuta reforma procesov ToBe), pytali so ho co chce zreformovat (ale on nemal predstavu co mu to moze priniest, tak vymyslal nejake drobnosti kde ho tlaci topanocka). A tak vzniklo, ze vo vacsine sa akurat snazili zbavit papiera (to si este vedeli predstavit), ale to ze biznis (proces) moze fungovat inak, tak to uz bnevedeli, ved zakon nepusti a ze by sa nejako zmenil a nie my zakonu prisposobovali, ale zakon potrebam, tak to uz je mimo oblast chapania

A tak sa elektronizuu procesy (aj to poriadne max. v polovici pripadoch), ktore boli aj v neelektromnickom svete. nuz ale oni optimalne v elektornickom maju vyzerat inak

takto sa dialo v celom svete, znie to krasne ze preskocme to a rovno urobme vyborne elektronicke procesy ale zjavne sa nedaju preskocit fazy. bez elektronizacie existujucich procesov nie su udaje, uzivatelia si ani nevedia predstavit co by chceli, analytici snivaju daleko od reality a po pripadnom nasadeni sa to zasekne na chybajucich inych procesoch.

btw zakaznikom studii bolo mirri a uhp, zadanie bolo spravit studiu ktoru schvalia. A uzivatelia ktori sa snazili prispiet zistili ze to nema zmysel, jazyku a logike studii nerozumeli a ich problemy boli na urovni ktora v studii nebola. A v situacii ked sa o projektoch rozprava 20 rokov a medzi tym sa vymenia 5 ministrov, 8 riaditelov a polovica uradnikov v danej oblasti sa skepse neda divit.

mal som zato, že @peter_k vyzval k tomu aby sme tu možno obsah tej diskusie pred-diskutovali, teda načo si majú dať v realizačnej fáze pri tých projektoch pozor. snažil som sa načrtnúť len také hi-level problémy v realizácii z praxe z minulosti, ktoré som zažil. je tam množstvo ďalších problémov, ako je napr. nepomenované fázy projektu, ako migrácia, školenia v zadaní, problém dodávka a špec HW, keď ani nevieš aké bude technické riešenie, a asi nájde množstvo ďalších.

Asi najväčší problém je , že ten byrokratický mechanizmus núti špecifikovať dodávku úplne presne. často sú to niekoľkoročné projekty za veľa miliónov a to nie je ľahká úloha. však skúste dopredu presne špecifikovať prácu napr. 40 ľudí. buď zoberieš 4 špecialistov ktorí rozumejú doméne a poznajú prostredie a tí teraz budú pol roka skúmať čo sa má spraviť, a potom pol roka spisovať zadanie. alebo to rozdelíš na menšie časti.

hmm toto je veľmi ťažké na začiatku robiť. dá sa to priebežne, avšak waterfall vyžaduje odovzdať formalizovanú analýzu hneď na začiatku, ak ten výstup jej aj fakturačný míľnik, tak je veľký tlak nato a je to aj veľký záväzok preto by som proste obrazovky na začiatku nedal, pretože potom na konci ak sa budú líšiť, bude to zákazník rozporovať. a ver mi líšiť sa budú.

pravda, vždy to však boli len názvy UC a je otázne ako vlastne vznikli a čo popisujú keď obsah nemajú. Ak by sa to robilo pred, ale tým myslím reálne, tak by tento problém asi nemali a situácia by sa zjednodušila, pretože dodávak IT by naozaj bola predovšetkým o IT. ale to písal aj @Jody

ale áno, len po tých skúsenostiach čo boli, si SR z toho nič neodniesla. na ministerstvách stále nevznikli oddelenia, ktoré by boli kompetentné robiť IT vývoj. a pri tom sme precedens mali na úrade podpredsedu pri ITMS.

1 Like

precenujes it, ich kompetencie a schopnosti. itms vzniklo vlastne mimo ale v beznej statnej organizacii it nema postavenie aby mohlo menit procesy, ich domena je prevadzka, bezpecnost.

@Jody Ano suhlasim, dobre postrehy. Cize ak to zovseobecnim, ideme diskutovat o “realizacii”, ale este nemame vyriesene problemy inicializacie projektov.
Ako bude zabezpecena kvalitna inicializacia projektov, priprava kvalitnych vstupov pre relizaciu a VO, ako poziadavky na kvalitu premietnut do VO, ako sledovat ich plnenie. Ak zostane jedinym kriteriom cena, nepodari sa to. Ak nezostane cena, mame ine (z minulosti zname) problemy. A potom sa mozem hrat na QA, ale na zaklade coho ju bude pozadovat, ako pise @vliv2 vyssie a komplexnejsie…na zaklade nejakej hypergalaktickej metodiky, ktora mozno vnikne pocas realizacie projektu alebo sa zmeni a nebude mozno znamenat nic viac, len nejaku administrativu navyse.
(Samozrejme, aj este sme nehovorili o tom, ze metodiky/mantinely pre inicializaciu projektov mozu vyplyvat zo zdroja financovania a to co do nich vstupuje nie je vymyslom rezortneho uradnika)