Mesto Trenčín - nový web


#41

Prieskum toho, čo je kto ochotný urobiť za určitú sumu vs. určenie toho čo je potrebné urobiť vzhľadom na moje potreby a čo by bolo najvhodnejšie urobiť pri určitom rozpočte.

Prečo to nemôže byť štandardný projekt ? Prečo nie je možné najprv stanoviť akú “stoličku” klient chce. Na základe čoho a kto rozhodol že sa bude vyvíjať takto ?

Jasne z toho vyplýva že následný proces tvorby bude agilný, len či si všetky strany uvedomujú riziká ? Mimo iné jedným z hlavných rizík je, že nie je možné určiť ako presne bude vyzerať výsledná stránka a čo všetko z toho čo bolo pôvodne v pláne sa stihne zrealizovať. Uvedomuje si tu niekto aký je toto sakra veľký filter aj na kvalitné spoločnosti ? Ono bude stále asi viac tých čo by to vodopádom dali s predvídatelnejším výsledkom.

Ak sa mýlim prosím oboznámte ma prečo je vhodnejšie použiť práve agilný spôsob vývoja pre tento projekt.
A prosím, neberte to ako kritiku len chcem pochopiť aký rozhodovací proces predchádzal sútaži v takomto znení.

A možno by ma ešte po prečítaní článku https://dennikn.sk/blog/ako-sa-da-robit-moderne-statne-it-priklad-gov-uk/ zaujímalo, prečo si myslíte (alebo máte skúsenosť) že práve táto miera (ne)identifikovania potrieb klienta na začiatku projektu je zvolená správne ?


#42

ano. A podobne definicie predsa platia pre kazdy projekt. V podstate hovoris, ze ked pre zleho klienta robi zly dodavatel, tak to dopadne zle. S tym sa neda nesuhlasit :slight_smile:


#43

uvaha za tym bola nasledovna: klient ma relativne limitovany rozpocet. Zvazovali sme aj moznost rozdelenia projektu na 2 casti: analyza a vyvoj. Tento postup sa nezvolil prave koli cenovemu obmedzeniu (nechceli sme kupovat analyzu za 10k, ktora by povedala, ze idealne riesenie bude stat dalsich 50k - taka analyza nepomoze, lebo 50k budget nie je). Zaroven bola obava, ze ak analyzu a vyvoj robia 2 firmy, mohlo by dojst k strate znalosti medzi fazami.

Preto sme isli logikou: chceme najlepsi MOZNY web za rozpocet aky je na stole. Kedze v tomto momente slovo “najlepsi mozny” vieme definovat ramcovo, je aj sutaz nastavena tak, aby sa hladal schopny dodavatel, ktory ramec pochopi a prevedie klienta cez projekt tak, aby z toho vzniklo skutocne najlepsie mozne riesenie za dany budget.


#44

Nerozumiem preco niekedy je neziaduca strata znalosti medzi fazami (rozdelenie analyzy a vyvoja) a inokedy to nie je problem. A preco niekedy setrime peniaze a snazime sa efektivne vyuzit budget a inokedy si doprajeme aj studie co mozu navrhnut drahe idealne riesenie.


#45

nie je prave oddelenie tychto dvoch faz to co presadzuje SK Digital?


#46

no, tak trochu racia: ako sukromny obstaravatel si necham predviest par rieseni, vyberem dvoch troch potencialnych dodavatelov a s nimi preberiem scope, ak sa viem rozhodnut na zaklade prace s nimi tak vyjednam zmluvu a idem do toho. pri projekte takejto velkosti ziadne predbezne analyzy netreba, naopak to zvysuje naklady a oddaluje dodavku. ak som verejny obstaravatel tak to nejde, to co by som spravil je definovat scope, sutazit na cenu a referencie, 30 percent si necham ako rizikovy budget na nasledne prk a mozne zmeny.


#47

Ale to nie je komplikovany informacny system, ale web stranka, kludne sa tu mohla spravit jednoducha analyza anavrh dizajnu samostatne. Okrem toho ten argument “by mohlo dojst k strate znalosti medzi fazami”, ked sa taky argument pouzije pri tvorbe webu, tak potom tazko moze SK Digital argumentovat pri velkych IT systemoch, kde je previazanie medzi analyzou a vyvojom ovela vacsie a hlavne komplexnejsie.


#48

studia pri velkych projektoch nie je analyza, ta sa robila vzdy aj tak. pri takto malom projekte je to nezmysel,


#49

Ano, a zaroven presadzujeme agilny vyvoj. A nic z toho nepresadzujeme ako vseliek pre kazdy projekt. Vzdy zalezi na okolnostiach.

Moja skusenost je, ze Agile ma zmysel pri F/E veciach (proste tam kde potrebujes vela interakcie s pouzivatelom). Na druhej strane, ak by som robil komplexny projekt v radoch milionov EUR, tak by som zvazil ci pojdem agilne, alebo radsej waterfall (HL analyza/studia, potom Proof of Concept, potom detailna analyza a nasledne vyvoj). S tym, ze firmu co robila analyzu najmem ako QA na dalsie fazy. Mam pocit, ze ak mam na stole 25k, tak rozdelovanie, QA a pod. trochu stracaju zmysel.


#50

Rozumiem co pises, ale citam z toho len kritiku a nepocujem co je vlastne navrh… A tiez ma prekvapuje, preco toto vsetko prichadza teraz. Po asi 6 mesiacoch verejnej pripravy toho zadania :slight_smile:


#51

ano, to je sialeny overhead. ale uprimne takto postavene vo ma malu sancu na uspech, bud to zase niekto spravi ako marketing alebo to skonci zle. preco sa skutocne nesnazite spravit obecne pouzitelny template na weby, to by bola skutocna pomoc


#52

to znie skoro ako keby sme to robili zamerne :slight_smile: Jasne, ze sa snazime postavit dobry template. Ja som toho nazoru, ze pri rozpocte 25k je toto najlepsie mozne nastavene VO, ktore dava priestor sikovnym firmam, aby ukazali, ze vedia dodavat agilne. Lessons learned z SND je taka, ze sa potrebujeme viac zapojit do projektu a usmernovat ho tak, aby sa ustrazil scope a zaroven spokojnost zakaznika. A to sme robili uz pri samotnej priprave toho zadania.


#53

Ja si pamatam casy kedy web za 20 000 bol kritizovany s tym ze student ho urobi za tisic EUR.

Agile vs. waterfall je asi tema na inu diskusiu osobne si myslim ze v prostredi ISVS, kde sa legislativa moze menit bez toho aby to urad, alebo resp. projetkovy team ovplyvnil je agilny pristup nevyhnutnostou, nech ide aj o komplexny projekt.


#54

moj nazor je ze sa snazite robit to co ide v komercnej sfere a to podla mojho nazoru nejde. ale rad pockam na vysledok


#55

S tymto suhlasim. Ale otazka v kontexte s projektom vs. agile: prezradil to niekto klientovi? Bol niekto z TN na skoleni alebo si kupil knihu a tusi do coho idu? Preco o tom nie je zmienka v podkladoch ani v zmluve? Zatial mi to vychadza, ze platia rizika, ktore pomenoval @IvanK a dalsi prispievatelia.
K tomu commentu preco sa ozyvaju ludia az teraz: dlhu dobu od startu to vyzeralo, ze sa kreuje zadanie s definiciou poziadaviek na funkcionality/moduly+dizajn a zakony. Tak mozno preto.


#56

Nekritizujem. Kritizoval som v prvom pripade s pomocou prikladu o psikovi a macicke. Teraz sa snazim porozumiet. Ci prvy pripad priniesol poucenie ze delba faz v takomto pripade nie je az tak dobry napad. Alebo skusate fazy spojit ci to nahodou nakoniec nebude vlastne lepsie a lacnejsie riesenie pre takyto typ projektu a rozpoctu. Co si pamatam tak v prvom pripade si vsetci riesenie a delbu pochvalovali vratane zadania. Preco to vlastne takto neslo teraz ? Lebo budget ? Lebo klient nevie co chce ? Nie je riziko pustit klienta spravit sutaz s nizkym rozpoctom, velkymi ocakavaniami a nejasnym zadanim? Nebolo lepsie mu radsej jasne pomenovat rizika tejto situacie ?


#57

OK, uz sa zaciname chapat, mozno len nedorozumenie. Pri TN ideme rovnakym pristupom ako pri SND. T.j. jedno obstaravanie v ramci ktoreho je aj analyza aj vyvoj. Zadanie sme vylepsili po konzultaciach s UVO (hlavne ujasnenie toho co su minimalne poziadavky, co su hodnptiace kriteria, atd.). Ale v tej podstatnej veci - pristup k projektu - ideme rovnakym stylom ako pri SND.

Lesson learned z SND je taka, ze bude potrebne aby porota ostala v kontakte s projektom ako “QA”. Takze to sa budeme snazit teraz vylepsit.


#58

Ale porota ako qa nebude asi systemove riesenie do buducnosti. Jednak to asi nikto kvalifikovany nebude robit zadarmo, jednak to v nejasne postavenom zadani dava prilis vela priestoru qa, ktory v extremnom pripade moze vlastne upravovat zadenie a ohybat ho. A ked to prezenie, tak s vyslekdom bude spokojny akurat tak qa. Ano, vi idealnom pripade by mal pomoct spresnit a harmonizovat predstavy klienta, zosuladit ich s budgetom a strazit ich technicku realizaciu. Ale kto bude taketo qa robit zadarmo?

Prihovaram sa skor za to, aby sa takto postavene sutaze a rozpocty radsej nepustili do realizacie. Idealnny by bol checklist projektovych rizik, ktory by sa klientovi jasne odkomunikoval. Proste nech si je klient vedomy ze z projektu moze dostat to co ani vlastne moc nechcel. Parcialny alebo aj majoritny fail. Som zvedavy ci by aj tak chcel spravit sutaz.


#59

@janhargas neviem ako mozes povedat, ze vsetka kritika prichadza teraz. Od zaciatku je poukazovane na to, ze je nevhodne spojit dizajn + analyzu s realizaciou projektu.
Velky problem vidim v zmluve a vminam velmi kriticky to, ze sa od nej snazite distancovat. Pokial niekto do toho pojde s takouto zmluvou, tak bez suhlasu trencina moze zabudnut na akykolvek marketing, prispievanie spat do open-source komunity, cize pre vacsinu firiem straca zmysel ist do takejto spoluprace.
Takisto je v zmluve jasne definovane ze sa cely projekt ma vyvijat waterfallom, na riziko dodavatela az do poslednej chvile a dodavatel moze vypovedat zmluvu ak s nim nesuhlasis a neodklepnes mu jeho poziadavky.
QA a porota? Toto radsej neskusajte, nemam pocit ze by niekto v porote vedel objektivne zhodnotit kvalitu kodu pre kazdy mozny CMS.
@vliv2 u nas vo firme bola snaha spravit z tohto webu vseobecne pouzitelny template na weby v statnej sprave, bohuzial zmluva to totalne zabija.


#60

Miro, to bola reakcia na Ivana. Čo sa týka diskusie o rozdelení, stále sa
vraciam k tomu, že som nevidel návrh ktorý by v rámci daného budgetu
dosiahol rovnaký efekt ako je snaha dosiahnuť v tomto VO.

Čo sa týka zmluvy, predpokladám že ste dali oficiálnu žiadosť o vysvetlenie
tých ustanovení, ktoré spomínaš v rámci procedúry VO. Ak áno, z Trenčína
príde odpoved.