B/CZ/Úkol

---

• Zanalyzujte projekt elektronické dálniční známky EDAZ z pohledu pěti hlavních projektových zásad. Ke každé z nich napište, do jaké míry byla podle vás daná zásada dodržena. Pokud zjistíte, že nějaká zásada dodržena nebyla, napište, jaké kroky byste podnikli k tomu, aby v takovém projektu dodržena být mohla. Zde malá poznámka – nenechte se zmást mediálním obrazem, že projekt EDAZ je pouze předražený e-shop na dálniční známky. V projektu se toho dělo mnohem více. Podklady najdete v interaktivní osnově, abyste nemuseli složitě hledat.

Řešení:

Projekt EDAZ tímto zkusím zhodnotit dle hlavních zásad projektu v praxi, jimiž jsou: zacílenost, reálnost, účelnost, systémovost a efektivita.

Zacílenost si myslím, že je zaručena poměrně dobře. Cílová skupina je v případě dálničních známek hrozně široká, neboť se jedná o uživatele dálnic, ale vzhledem k rozsahu systému je asi celkem jasné, na co se cílí. V konceptu je navíc zapracovaná i kamenná síť prodejen, takže je myšleno na „necílovku“, tedy na lidi, kteří si budou chtít kupovat známky na benzínkách apod. Zároveň je existující problém cílovky jasně čitelný: nemáme možnost elektronického zajišťování služeb.

Reálnost se mi trochu špatně hodnotí, neboť nemám až takový vhled do technologických věcí, a pokud bych se chtěl vyhnout podceňování kreativity, musel bych napsat, že „sky is the limit“. Ale např. podle prezentace, kde je shrnuto, co je třeba zajistit a taktéž je přiložený model, si myslím, že projekt reálný je. Nepodařilo se mi dostatečně hluboce nastudovat, jak fungují jiné systémy v zahraničí, ale na obdobné bázi systémy asi pracovat budou a nezdá se mi na něm nic extra inovativního. Možná by šlo uvažovat o reálnosti v určeném časovém horizontu projektu, zda veškerá kompatibilita a napojení na okolní systémy šly dobře zvládnout v harmonogramu bez ztráty kvality. Případné zlepšení by podle mého názoru mohlo vést na úpravu harmonogramu.

Účelnost je nejlépe naplněná zásada projektu. Služby musí v desátých letech 21. století prostě existovat v digitálním světě, tam se nedá nic dělat. A i když tam jsou, tak je vždy důležité je udržovat, modernizovat a držet krok s technologickým vývojem. Dovolím si říct, že i kdyby se projekt zpozdil o 5-6 let, tak stejně bude účelný, a pokud by do té doby existovala již jiná služba, mohly by se uchytit i paralelně.

Systémovost. Podle mého uspokojivě naplněna zásada. V dokumentech je celý propracovaný model systému s vyznačenými externími komponenty, tyto jsou pak v tabulce popsány v kapitole Technické vymezení služeb. V kapitolách dále jsou komponenty blíže rozvedeny. Co se mi nepodařilo najít v dokumentech je, zda byly na programu i nějaké testy uživatelů, service design, estetický design, UX apod. Jako student KISKu bych tyto aspekty měl na mysli a směřuji tedy toto jako výtku. Technické věci jsou v návrzích popsány dostatečně, ale onen lidský uživatelský aspekt? Zároveň je pro systematičnost k dobru, v souladu s výukovým materiálem, schopnost zapracovat měnící se požadavky a vlivy zvenčí, což bych viděl v ochotě vedení pracovat se systémy z hackatonu, které se zdály být pro projekt užitečné (pokud ale k takové implementaci skutečně došlo).

Efektivitu zhodnotím na základě přiložených článků v osnově, které odkazují na zpětné zhodnocení projektu. Podle dostupných informací se tento aspekt až tak skvěle naplnit nepodařilo. Vzhledem k tomu, že byl jako reakce na projekt uspořádán celý hackaton ve snaze ukázat, jak to může jít lépe (i když nešlo), se mi zdá, že se o efektivitě celkově pochybovalo v průběhu celé zakázky. Hned po spuštění se podle článků z echo24 objevovaly nikam nevedoucí odkazy a někdy byl obsah založen na wordpressu. Projekt podle mého tedy efektivitu nesplňuje.

Jaké bych navrhoval zlepšení? Asi by bych musel vědět, kdo – jaká firma a jací lidé – na projektu pracoval a proč bylo v projektu tolik chyb. Byla to firma špatné kvality? Nebo byly šibeniční termíny? Když jsem se díval na tabulku harmonogramu z přílohy 1 smlouvy, přišlo mi, že struktura vývoje je spíše waterfall s prvky agile (v částech implementace?). Možná se celý projekt měl dělat více podle agile metodiky a iterativně zdokonalovat služby. Průběžněji by se pak vidělo, co a proč nefunguje dobře.

• TENTO ÚKOL VÁS BUDE PROVÁZET CELÝM PŘEDMĚTEM, VĚNUJTE MU PROTO NÁLEŽITOU POZORNOST. Vžijte se do této situace: Ve společnosti, kde pracujete. jste byli pověřeni zavedením nové inovace formou projektu. Projekt musí být koncipovaný minimálně na 3 měsíce. Horní časovou hranici nechám na vás, ale doporučuji nejít přes 1 rok.

a. Sami si zvolte, čeho se má inovace týkat. Nejlepší bude, pokud vám téma bude blízké. Pokud si nevíte rady, nabízím pro inspiraci oblasti:

i. produktu, který firma nabízí

ii. zastaralého interního procesu

iii. zavedení něčeho úplně nového, s čím dosud firma jako taková nepracovala (např. doplnění portfolia firmy, která dosud pouze prodávala zboží, o software, který může firma dále prodávat v synergii se svým zbožím)

iv. nebo něčeho jiného

Pozn.: Pokud máte jiný nápad a nechcete projekt koncipovat jako firemní inovaci, napište mi na e-mail svoji myšlenku a já vám potvrdím, zdali to bude pro účely předmětu fungovat.

Řešení:

Napadl mne následující projekt: Jako pracovník MUNI jsem byl pověřen vypracováním projektu na zavedení digitálního repozitáře věnující se kurátorství moderního digitálního umění prostřednictvím kreativního kódování.

b. Napište zadání takového projektu z pohledu ředitele/manažera oddělení, pod nějž projekt spadá (zpravidla vlastník projektu). Do specifikace promítněte i své dosavadní znalosti o projektovém managementu. Tj. ve specifikaci zohledněte důležité výstupy předprojektové fáze a jednotlivé složky trojimperativu. Nechám zcela na vás, zdali složky trojimperativu definujete v zadání, nebo tento požadavek jako ředitel oddělení přenesete na projektového manažera. Každopádně je ale nutné, abyste se všemi třemi složkami v zadání NĚJAK naložili. Délku zadání nechám na vás – je jasné, že někteří zatím nemáte tolik projektomanažerských dovedností. Ale to často ani vlastník projektu, který projekt donesl.

Řešení:

Osvěžil jsem si již nabyté znalosti a zkusil jsem zadání projektu zpracovat podle šablony, kterou jsme využili k popisu projektu ve třetím ročníku, předmět se jmenoval Řízení organizací. Zadání posílám jako samostatný dokument.

c. Z pohledu projektového manažera se zamyslete nad třemi konkrétními věcmi (riziky), které by vám mohly projekt potopit. Sepište je a zkuste svými slovy dle nejlepšího uvážení popsat, jak byste s takovými riziky naložili. Uvědomuji si, že jsme zatím neprobrali téma řízení rizik, ale může pro vás být zajímavé se na daná rizika podívat před absolvováním tématu a po něm a porovnat si, zdali se vaše postupy liší.

Řešení:

První riziko vnímám v oblasti „politické“ podpory projektu. Vzhledem k tomu, že se má digitální repozitář týkat celkem nové formy umění, která není zavedená, tak může narážet na nepochopení ze strany vedení.

Tento nedostatek bych se snažil vyřešit jasně definovanou vizí, sepsanými a dobře rozebranými argumenty podložených studiemi (pokud možno) se kterou budou srozuměni zaměstnanci a taktéž určitou rozhodností ve vyjednávání. Ale klíčovou složkou by podle mne byla schopnost networkingu projekťáka.

Druhým rizikem podle mne bude špatně zvolený tým. Pokud bude na projektu pracovat interdisciplinární tým, nemusím mít schopnost správně odhadnout, zda je člověk kompetentní. Pokud budu mít na specializované pozice unikátní osobu a tu ztratím (třeba jazyk SuperCollider moc lidí neovládá), mám problém.

               Tento nedostatek vyžaduje něco jako průběžné mapování talentů a dostupných lidí, popřípadě           mít alespoň mlhavou představu o alternativních „cestách“ v projektu.

Třetím rizikem v mnou navrhovaném projektu bude chaos z nedostatečně zvládnuté komunikace. Bavili jsme se, že zejména s pracovníky IT musí být zvolen specifický způsob komunikace. V mém projektu by takových specifických tónů muselo být povícero (i když asi v každém projektu to bude podobné).

               Tento nedostatek bych se snažil mírnit vlastní iniciativou ve snaze se dozvědět a nastudovat diskurzy a naslouchat pak všem stranám. Asi by stálo za to se pravidelně explicitně na způsob komunikace samotné dotazovat.

d. DOBROVOLNÝ ÚKOL: Zamyslete se nad tím, zda byste projekt chtěli řídit agilně nebo jako waterfall (vodopád) a z jakého důvodu byste volili kterou z možností.

Řešení:

Projekt půjde dobře vést agilní metodologií. Respektive bych si z Waterfallu v úvodní fázi vybral dva stupně kaskády „požadavky“ a „návrh“, které bych udělal pro začátek velmi lineárně a důkladně. Další patra „vývoj“ a „testování“ bych ale prováděl agilně v iteracích a prvotní návrh jen zdokonaloval podle potřeby v rámci malých sessions.