fb
IT Systems 6/2017 Projektové řízení ITSM (ITIL) - Řízení IT 3. 8. 2017 9:52

Praktický pohled na přípravu a řízení IT projektu

AlzaUž z definice projektu vyplývá, že se jedná zpravidla o unikátní počin, který je zakončený výstupním produktem. V případě IT projektů, např. u internetových portálů, to jsou typicky nové zákaznické služby. Projekt by však neměl být ukončen při spuštění nové služby do produkce, ale až v momentě, kdy má vedoucí jistotu, že je služba perfektně odladěná.

Na začátku je vždy nápad, myšlenka. Ta se postupně rozpracovává do podrobnějšího zadání pro vývojáře. Následně se vypracuje odhad pracnosti, který je nezbytnou proměnnou v byznys plánu. Pokud business case vychází zajímavě, začne debata o možnostech realizace. Ať už přitom realizujeme projekt inhouse, nebo s externí firmou, vždy potřebujeme realizační tým, zadání, předpokládaný termín realizace a posloupnost úkolů ke splnění. Velice častým rysem v praxi je tlak na brzký termín realizace. To nutí projektové manažery osekávat zadání až na dřeň a hledat zjednodušení tak, aby nebyl v ohrožení samotný business case. Velice doporučuji využívat vývojáře k tomu, aby sami hledali způsoby k uspíšení realizace. Nebraňte se dát vývojářům volnost, aby sami přišli s řešením. Namočte je do projektu tak, aby chápali jeho cíl a co má být výsledkem. Cestu vám pomohou nalézt sami.

Paretovo pravidlo v praxi

Uplatňování Paretova pravidla je dnes již standardní poučkou v manažerských příručkách. Podle Vilfreda Pareta platí, že 80 % výsledků plyne z 20 % úsilí. Pokud vztáhneme toto pravidlo na realizaci IT projektů, vychází nám jednoduchá trojčlenka. Za 20 % časových nákladů můžeme docílit 80 % dokončenosti projektů.

Praxe ovšem ukazuje, že si lidé (jak vývojáři, tak projektoví manažeři) interpretují dokončenost po svém. Hodně častým nešvarem je chápání dokončenosti jako rozpracovanosti. Je totiž velký rozdíl mezi tím, když máme 80 % funkčnosti, která funguje na 100 %, nebo 100 % funkčnosti, která funguje na 80 %. Druhá ze zmíněných variant je špatně (tomu říkáme rozpracované).

Vhodné je celý rozsah projektu rozdělit na 2 části: must-have a nice-to-have. V sekci must-have si držet úkoly, které musí být splněny, ať se děje, co se děje. Nice-to-have by pak měly být věci, které typicky nebudou zahrnuty do prvních 20 % času vývojářů, ale budou spíše pomáhat ladit výsledný produkt později k dokonalosti.

Příprava na spuštění

Co neměříš, neřídíš – toto základní manažerské pravidlo je dobré si zapamatovat, protože je pravdivé. U projektů a služeb platí dvojnásob. Už na začátku definice služby projektový manažer vytvořil business case, kde definoval základní KPI (key performance indicators) pro projekt. Může to být například počet platících zákazníků, obrat, konverzní poměr, atd.

V případě už zmíněného projektu spuštění nové služby internetového portálu bývá dobrým zvykem hlídat si také konverzní funnel (trychtýř), tedy průvod procesem nákupu služby či objednávky. Na funnelu je krásně vidět, která část procesu je nejhorší co do konverze. U e-shopu je klasickým funnelem nákupní košík, kde se od košíku 1 (definice zboží k nákupu) přechází na krok výběru dopravy, platby, fakturační a doručovací adresy, atd. až na sumarizační stránku, potažmo „succcess“ stránku po úspěšném dokončení celého procesu. Díky funnelu lze dělat tzv. drilldown, tedy dívat se na chování zákazníků podrobněji a soustředit se na místa, kde se chovají jinak, než je zamýšleno.

Spouštíme! A začíná fáze péče o službu

V případě rychlého iterativního vývoje je dobrým zvykem spouštět projekty v režimu AB testu, tedy ověřit funkčnost na části a zjistit, zda nová služba splňuje očekávání a KPI. Pro realizaci AB testů je dnes na trhu spousta hotových a velice propracovaných řešení. U specifických projektů ale není na škodu ani realizace AB testů „po svém“, tedy naprogramování vlastního AB testovací frameworku na míru pro potřebu firmy. Takový přístup je nutný, zejména pokud se AB test vyhodnocuje na základě dat z interního systému, kam online nástroje „nevidí“.

V případě AB testů je nutné dát pozor na správné vyhodnocování. Málokdo tuší, co je statistická průkaznost, tedy kdy vlastně můžeme výsledek AB testu považovat za relevantní a tzv. průkazný. Pokud AB test prokazatelně ověřil, že je služba životaschopná a dává smysl, na řadě je spuštění. Nyní začíná fáze péče o službu. Teprve nyní přijdou na řadu chyby, které neodhalili testeři, případně překvapí chování návštěvníků na webu.

V této fázi většinou projektový manažer sleduje vývoj KPI projektu a také se dívá do analytických nástrojů. Zde se hlídá konverzní poměr, průchod funnelem a odhalují se slabá místa. Je velice důležité být v této fázi agilní a opravy chyb dělat rychle. Logicky je proto třeba počítat pro tuto fázi s dostatečnou alokací zdrojů, tedy mít „v Ganttu“ místo i na opravy a adhoc požadavky.

Na detailech záleží

Při vylepšování služeb je žádoucí zaměřit se i na nepatrné drobnosti, které se možná zdají nepotřebné, ale praxe ukazuje, že na detailech skutečně záleží. Jeden příklad za všechny – u formulářů, do kterých má zákazník zadávat svou e-mailovou adresu, je vhodné předvyplnit znak zavináče. Proč? Překvapivě hodně lidí neví, jak tento speciální znak na klávesnici zadat zejména při objednávání služby na cizím počítači (na pobočce obchodu), ve škole, v práci. A podobných drobností je celá řada, zkušený webdesigner by je měl znát.

Kdy si projekt můžeme odškrtnout?

Jak poznat, kdy je služba ve 100% stavu? Horko těžko, na to neexistuje žádný osvědčený recept. Je to hodně o zkušenosti projektového manažera. Dobrým indikátorem může být srovnání s relevantní konkurencí. Ne vždy je to snadné zjistit, ale hodí se sledovat konkurenční blogy, chodit na konference, kde jsou zástupci ostatních firem z oboru jako spíkři. Často mluví o svých službách a mnohdy zmiňují i nějaká ta čísla. Pozor ale na srovnávání „hrušek s jablky“. Ne každá konkurenční služba je stejná jako ta vaše.

Kdy se má služba naopak zrušit?

Rušení služeb není nikdy jednoduché rozhodnutí a mělo by mu předcházet poctivé zhodnocení celého business case, všech možných příčin neúspěchu. Je nutné brát v potaz, že se mění nejen trh, ale i chování a očekávání zákazníků. To, co bylo „in“ před 2 lety, dnes už nemusí platit. Pokud není možné službu přetransformovat do podoby vyhovující trendům současnosti, je lepší ji zrušit.

Odladění je velmi důležité

Co říct závěrem? IT projektů se ve firmách realizuje nespočet, doba je uspěchaná a tlak na rychlé výsledky značný. Fáze péče o produkt a jeho další rozvoj je však velmi důležitá. A pouštět mezi zákazníky hotové produkty, ne rozpracované, také – protože ty generují jen operativu, chyby a špatné PR. Pokud je firma zaměřená na menší portfolio služeb, měla by se soustředit na „vymazlení“ těchto služeb k maximální dokonalosti – jen to ji pomůže odlišit od konkurence.

Vladimír Dědek Vladimír Dědek
Autor článku je ředitelem webového a mobilního vývoje společnosti Alza.cz, a. s.

Kalendář akcí
Konference - Semináře - Školení
Časopis IT Systems/Speciál
Aktuální číslo časopisu IT Systems Aktuální číslo časopisu příloha #1
Archív časopisu IT Systems
IT Systems 1-2 IT Systems 12 IT Systems 11 IT Systems 10
Archív časopisu IT Systems Special
Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1