Blockquote na zaciatku je uprimna snaha dodat co najlepsie riesenie
Jasne, ze snaha tam je, ziaden majitel nechce pruser, len tam moze chybat uz na zaciatku predpoklad (personalne zazemie) 
Blockquote zvysi rizika a problemy. Vynimka su excesy ked su vo uplne nesuvisiace projekty spojene
suhlas
Suhalsim, moj nazor je ze delenie system predrazi, nebude ho lahke zintegrovat, casti sa musia zavadzat paralalene a jedna bez druhej casto nema zmysel (uz dnes mame UPVS, ktore ma moduly a dodavatelia nevedia odovzdat pretoze “nezavisle moduly UPVS” nemaju pod kontrolou, nie su funkcne atd.), este viacej sa zvysi zavislost a odovzdat nieco bude nerealizovatelne. Takze velmi opatrene a logicky rozdelovat. Pre Agule v Gevernmente doiporucujem si precitat cely material od Delloitu, co som vyssie dal link (co vsetko by museli urobit a zmenti aby mohli to urobit, delenie on to suvis aj s Agile troska .- na velkom projekte robi vyse 50 ludi, vediet rozdelit pracu medzi nich a anvzajom koordinovat nie je jednoduche, napriklad ked ma system z 20 modulov (jedno ci je to jeden dodavatel (aj tak ma subdodavatelov a ti riessia neiktore moduly) alebo je ich viacej, je ejdno, ale musia robit paralelne na vsetkch 20 moduloch (pretoze len 10 nezabezepci vsetky end-to.end biznis procesy (malo by sa implementovat podla biznis procesov, ak nie podporeny cely 100%, ale len z 50%, tak aky ma to zymsel zaviest, povedia, ze zymsle ma len ak je podporeny cely!, teda z mojho pohladu by sa malo zavadzat po procesoch, 1.roll.out /preberat to co nejde do roll-out je na co dobre, zakaznika sa tomu seriozne nebude venovat ak to nema ist do prevazdky) -prva sada procesov v rpvej verzii, dalsi niekolko novych procesov a niektore vylepsene (na zaklade poznatkov s realneho zavedenia/neico moze byt aj naplanovane. Moj navrh je zavies procesny princip aj pre postup tvorby a zavadzania IS (ono s atu hovori o sluzbach, ale to nie je end.to.end proces, nie je to iste)
este k tomu plateniu, na pozadi je zasadne obmedzenie ktore sa vola finacny mechanizmus. A bez toho aby som siel do detailov tak su dve moznosti bud zalohove platby a tie maju definovane velkosti a lehoty na ich zuctovanie alebo platby za uhradene faktury. lenze rezorty nemaju vo vacsine pripadov tolko volnych penazi aby to zvladli prefinancovat a tak realne inu moznost ako ist cestou postupneho platenia ani nemaju. a tam jednoducho lehoty urcuju kedy platit aby to fungovalo a nema to nic spolocne s realitou na projekte. A preto na zaciatku sa harmonogram prisposobi finacnym poziadavkam. tato vyhlaska uplne abstrahuje od tychto problemov a tak sa bude inkrementom nazyvat vselico. A na vine nie su zli dodavatelia ci neschopni uradnici ale nezmyselna vyhlaska.
vies toto rozvinut viac?
v com vidis byrokratizaciu?
minimalne prakricke prinosy - ktore to su? a ktore teda podla teba chybaju?
dakujem
realita dňa je, že agilný vývoj v slovenskom eGOV pre národné projekty je halucionovanie. Ani firmy ani úradníci nie sú na takúto zmenu pripravený. Maximálne, čo sa dá urobiť je Agile pre portál. Pre ostatné veci je agilný vývoj nesplnený sen.
Ale o inom som chcel písať, moja otázka je, kedže nová vyhláška očakáva, že pre VO bude mať štátna organizácia úrobenú Zber požiadaviek, Analýzu a DNR:
- kto v štátnej organizácii (napr.na nejakom ministerstve) takéto niečo niekedy robiť?
- predpokladám, že si to teda budú objednávať od externých firiem, asi konzultačky, pre tých to bolo do zákona dané. Lebo IT firmy to nebudú, aby sa nevyfaulovali s “veľkého VO” - konflikt záujmov. teda ak si nebude Zber požiadaviek, analýzu a DNR robiť in house štátna organizácia, jedna firma externá bude robiť zadanie po DNR a druhá bude realizovať - rozumej kodiť, testovať a nasadzovať.
- viete ako to bude na konci vyzerať? aká bude zodpovednosť tých dvoch firiem medzi sebou? no tá druhá bude sa vyhovárať na tú prvú, ved “oni to navrhli” a tá prvá na tú druhú “ved to bolo dobre navrhnuté, oni to zle urobili”.
Ďalšou vecou je spôsob, ako si MIRRI predstavuje riadenie z ich strany? Aktuálne sú partnerom na národných projektoch (vzali si myslím 3% z podporných aktivít), pričom dosť veľkú časť s týchto penazí MIRRI plánovali použiť na PUBLICITU, teda vytváranie spotov a priestor v médiách. Tým odčerpali peniaze na kapacity určené pre riadenie projektu a postavili sa len do úlohy QA projektu. Kontrolovanie štátneho IT im ale vyplýva predsa z kompetencií, ktoré majú zo zákona a dostávajú na to peniaze zo ŠR, alebo?
3 Likes
Blockquote realita dňa je, že agilný vývoj v slovenskom eGOV pre národné projekty je halucionovanie
Myslim, ze takyto zaver bol zrejmy aj z toho mojho prispevku.
Tie ostatne otazky, velmi trefne, presne koresponduju s mojimi, ktore som tu formuloval.
technicky, peniaze na publicitu su ine, na tie MIRRI este len siahne.
Povazujem za uplny nezmysel aby 1 firma robila detailnu specifikaciu a 2. to implementovala, to nemoze zafungovat (to je taky waterfall, ze predpoklada, ze detailny navrh sa nebude menit, ale to predsa nebude pravda, o zodpovednosti a vyhovarani sa jeden na druheho ani nehovoriac)
Da. Prva zbali prachy a vypadne. Druha zbali prachy a vypadne.(naimplementuje to presne podla krivajucej detailnej analyzy), Nie je to smiesne, existuju ludia, ktori si myslia, ze takto to naozaj moze fungovat.
To vieme, že nefunguje už z EVS. (vieme aj bez toho, ale keby niekto chcel príklad)
Ale ja tu nevidím niečo nedosaihnuteľné. Aj niektoré štátne projekty sa riadili dosť agilne, aj keď áno nevie ti product owner z ministerstva prisť každé ráno na 15 minútovú schôdzku. Ale dôležité je že taqm ten product owner bol a je , že dvíha telefóny a nebojí sa robiť kľúčové rozhodnutia. Že je vtiahnutý do tímu nielen formálne, ale aj neformálne (spločné pivo občas a tď…).
V Čechách zase všetky IT tendre obsahujú vypracovanú detailnú špecifikáciu. Neviem či ju robia interne , alebo si platia externé konzultačky, alebo sú to samostatné tendre … ale implementačné veľké projekty sú na základe Detailen špecky, ktorá je súčasťou tendrových podkladov.
Čiže aspoň pár takých vecí keď sa dosiahne, je to pokrok.
A … teraz napriklad robím na veľkom projekte v sukromnej sfere …45 ľudí pre obrovskú elektrárensku spločnosť. A robí sa agilne. Ale chapete že ani tá najväčšia firma u nás nemá voľných 45 ľudí so špeci kvalifikáciou. Tak na projekte je veľa externistov a subcos. A už aký rozdiel je v manaťovaní takéhoto tímu (reálne 6 subdodávateľov, ale navovonok veľká IT firma veľkému energo odberateľovi. Podľa mňa žiaden. Keby ten istý project manager robil to isté len v prostredí štátneho odberateľa tak môže rovnako manažovať 6 subdodávok … a áno vliv2 máa pravdu jednotlivé subdodávky suú samé o sebe nanič, funguje to len všetko spolu.
ten rozdiel je v tom ze na vsetkych externistov a subodododavatelov ma dosah prime. Vybral si ich a vie ich pripadne zmenit a doplnit. Nemusi robit VO a ked u neho padne rozhodnutie tak ho vie zrealizovat. V prostredi statu to nejde, zmenit jedneho znamena urobit nove VO a projekt skoncil. A ked sa zacnu hadat medzi sebou tak ich moze len zmierovat ale tie realne paky nema. A navyse ked mu takto zhavaruje projekt tak vsetkych ostatnych musi zaplatit, ziadny sud nepresvedci ze to bola ich vina.
A k detailnej specifikacii, mozes dat priklad ? Detailne sa robia RFP ale nie DFS. Ale na slovensku sa robili detailne specifikacie pre stavby s vysledkom ze vzdy sa vyznamne navysil rozpocet koli zmenam. Ale asi je potrebne vyskusat vsetky cesty ktore nikam nevedu.
ja som videl detailnu špecku ked cesi obstaravali monitorovaqci system na obdobie 2014-20. Obsahoval detailnú špecku s rozpisom všetkýchj požadovaných funkcionalít. Robil som v Prahe na ponuke, tak som to musel nastudovat.
to co vravis, je ozaj nebezpecie v pripade uz fatalnych zlyhani. Ale projektak na projekte musí vedieť vyhodiť, alebo vymeniť , alebo motivovať jednotlivcov. A vtedy tie projekty funguju, ked sa k ludom pristupuje ako k jednotlivcom. A ked povis dodavatelovi ze bud mi tohto chclapa vymenis, alebo ideme riesit nove obstarko, tak ver ze ho vymeni. To ze pri fakturacnych milnikoch firmy vystavia faktury, neovlyvni fungovanie timu.
v tom priklade ktory som uvadzal nema pravdu, proste da sa to tak urobit. v zasade hovoris ze daju robit iba monolity, nie? lebo inak by to nefungovalo? a preco teda by to nefungovalo. ako by nefungovali elektornicke sluzby OR bez backendu na spracovanie?
hmm, ja tiez vidim vela prikladov z inych firiem a odvetvi ze to funguje. to neznamena ze to bude fungovat len preto ze to inde funguje, pretoze u nas nefunguje ani waterfall a nie je to chyba waterfall.
to znie pekne ale su aj problemy ktore su spojene s tym ze treba nieco spravit a stoji to peniaze. a kto ma niest naklad? ked mas prima tak je to on ale v takomto pripade to je velmi tazke vyjednavanie
Kolko inak chceme skusat este waterfall? Ved snad uz mame minimalne dekadu skusenosti, ze na nejake typy projektov sa to proste nehodi (na ine ano). Alebo kolko budeme sami seba klamat, ze problem urcite nie je ten waterfall, ale vsetko ostatne.
Len blázon robí stále a znovu dokola to iste a zakaždým očakáva iné výsledky.
trochu miesame veci ktore suvisia volne, monolit je vec architektury nie toho ci je dodavka delena alebo nie. aj monolit sa da rozdelit na casti a obstaravat po castiach aj volne viazane riesenie sa da obstarat ako celok. cim su vazby tesnejsie, tak to len meni potrebu komunikacie teamov. Ale pokial vysledok bude fungovat len po uspechu vsetkych casti tak ta komunikacia nikdy nebude nulova.
a moja namietka k deleniu je teda nie technologicka ale procesna, zvysuje to riziko a navyse ho v prostredi statnej spravy nie je mozne dobre mitigovat.
a k or, nesuhlasim ale to je nazor nie pravda ktora sa da dokazat.
lebo kolko budeme sami seba klamat, ze problem urcite nie je ten waterfall, ale vsetko ostatne.
Waterfall je problem.(utopia) Primerana miera agilnosti je ziaduca. Musi vsak existovat mechanizmus, ako priestor pre nu premietnut do VO.(nepocul som jediny navrh ale o tomto ma zmysel sa bavit)
To co ja osobne odmietnam su rozne extremisticke agile nazory, ktore su len druhou stranou tej istej utopitickej mince.(odvodene od toho, co sa hodi na produktovy in house vyvoj v sukromnej sfere bez akejkovek snahy a zjavne ani skusenosti zrealnit to v prostredi eGov a premietnut do dodavatelskeho vztahu)