facebook LinkedIN LinkedIN - follow
IT SYSTEMS 3/2017 , Projektové řízení

Jak dovést IT projekty do zdárného konce

1. část: Snižujme riziko neúspěchu projektu – efektivně a s rozumem

Jan Pacovský


AdastraOcitli jste se v situaci, že projekt, na kterém jste v uplynulých měsících intenzivně pracovali, nedopadl úplně podle vašich představ? Hledáte příčiny tohoto stavu? Pak nepřestávejte číst a věnujte svou pozornost třídílnému seriálu, ve kterém se budeme zabývat tím, jak IT projekty dovést do zdárného konce. Dovíte se, na co si při práci dát největší pozor z pohledu řízení požadavků.


Internet a odborné publikace jsou plné nejrůznějších analýz a statistik vyjmenovávajících nejčastější důvody neúspěchu IT projektů. Tyto materiály se pak následně často používají v argumentaci podporující tu či onu metodiku životního cyklu dodávky softwaru, která má zvýšit pravděpodobnost úspěchu. Jen okrajově však bývá diskutován nějaký konkrétnější recept na řešení nejvážnějších příčin, na kterých se většina z autorů průzkumů a statistik až překvapivě shoduje: nekontrolovaný rozsah projektu (tzv. scope creep) a požadavky obecně (ať už z pohledu jejich obsahu, tak i z hlediska samotného procesu jejich zpracování a souvisejícího řízení).

Mezi nejčastější důvody neúspěchu IT projektů patří:

  • 38 % – nepřesně definované požadavky
  • 30 % – nedostatečná komunikace
  • 25 % – nedostatečné řízení změn

Zdroj: www.wrike.com

„One-size-fits-all“ řešení neexistuje

Selský rozum napovídá a zkušenost ukazuje, že neexistuje „one-size-fits-all“ řešení. Co může být pro jeden projekt po právu označováno za „neřízené požadavky“, může být v jiné situaci na jiném projektu naprosto postačující přístup. Nicméně na projektech se čím dál tím častěji bez uvážení kontextu hodiny a hodiny řeší, jaké nástroje se použijí, jak a zda a co budeme modelovat a jaké další atributy by se alespoň teoreticky mohly hodit do vybraného nástroje pro řízení požadavků dokonfigurovat (neboť jsme o nich četli někde v nějaké knize).

Nadefinujte skutečné potřeby a ne možnosti a přání

Netvrdím, že tyto diskuse nejsou důležité. Určitě je potřeba je vést. Nicméně úplně v úvodu těchto diskusí vnímám jako podstatnější pragmatický pohled na skutečné potřeby, které má proces správy požadavků v kontextu daného projektu plnit a jak toho s nejmenším úsilím dosáhnout. Přestěhování nové sedací soupravy z prodejny nábytku domů jistojistě zvládneme s mnohatunovým kamionem pro dálkovou přepravu – určitě bude velikostí a nosností stačit. Otázkou ale zůstává, jestli by nám nestačila postarší dodávka nebo dokonce jen přívěsný vozík za naším automobilem.

V této lehce úsměvné analogii nikdo o vhodném řešení nezapochybuje ani na okamžik. V realitě IT projektů jsem se ale opakovaně setkal s pokusy přepravovat jídelní stůl kamionem nebo, možná ještě hůře, přepravovat nadměrný náklad v dodávce. V prvním případě to stojí „jen“ zbytečné úsilí (nejen) projektových zdrojů, ve druhém případě se vám dříve či později váš rozsah projektu rozsype pod rukama.

Využijte možnosti Requirement Engineeringu

Řízením a definicí rozsahu projektu se zabývá disciplína Requirements Engineering. Zjednodušeně se jedná o zastřešující termín pro procesy získávání, tvorby a řízení požadavků. Hlavní účely této disciplíny jsou:

  • Poskytnout prostředky pro řízení rozsahu dodávky projektu (scope) a ten mít v každý okamžik pod kontrolou, a to zejména s ohledem na podporu a realizaci změnového řízení.
  • Zajistit jednotný pohled na předmět dodávky a jeho jednotné porozumění všemi zainteresovanými stranami.
  • Poskytovat reálný obraz o stavu realizace.
  • Zajistit, že předmět dodávky pokrývá skutečnou potřebu zákazníka.

Je zřejmé, že všechny aktivity vedoucí k zajištění výše uvedených cílů se zaměřují na „opečovávání“ požadavků (pozn.: pro zjednodušení budu v tomto textu nadále chápat požadavek v jeho nejširším možném významu, tak jak jej definuje Business Analysis Body of Knowledge (BABOK) Guide). V tomto textu se nechci dále zaměřovat na způsoby získávání a tvorby požadavků. Za důležitější v kontextu řízení rozsahu projektu považuji dvě věci:

  • samotný požadavek včetně souvisejících řídicích atributů a vazeb
  • a proces řízení požadavků.

Různé metodiky mají různé přístupy k procesu, jak se dostat k popisu samotného obsahu požadavku – tedy toho, co se má dodat/zajistit/vyvinout. Od vodopádových přístupů „nejdříve vše zanalyzujme a popišme a pak naprogramujme“ až po silně agilní „pojďme programovat průběžně, rovnou na základě diskusí se zadavateli“.

 

Nejčastější příčiny neúspěšně zrealizovaných projektů. Zdroj: wrike.com
Nejčastější příčiny neúspěšně zrealizovaných projektů. Zdroj: wrike.com


Zaměřte se na obsah a detail i při agilním přístupu

Ať už zvolíme jakýkoli postup, je nezbytné, aby vždy (opravdu vždy) vznikl nějaký popis toho, co se má vlastně dodat. Spíš než uvědomění si toho, že je potřeba mít požadavky sepsané a schválené zadavatelem, bývá kamenem úrazu volba výrazových prostředků (UML, BPMN, strukturovaný text, …), použitých nástrojů a volba správné (= dostačující) úrovně detailu. Na to neexistuje žádná poučka a vhodný přístup závisí nejen na složitosti samotného systému, ale i na prostředí, ve kterém vzniká a pro které je určen. U nejjednodušší aplikace nebo v případě drobného rozvoje realizovaného agilně malým týmem ve známém prostředí bude stačit mnohem méně a mnohem menší detail popisu, než v případě dodávky komplexního silně integrovaného systému v mezinárodním prostředí.

V neposlední řadě je ale potřeba mít na paměti skutečně celý životní cyklus dodávky softwaru. To, že programátoři v rámci agilního přístupu nepotřebují nijak zvlášť detailní popis toho, co se má vyvinout, ještě neznamená, že to nebude nezbytné pro potřeby testování či pro tvorbu dokumentace. Zdrojový kód za nejlepší formu dokumentace dle mého názoru nelze z mnoha důvodů považovat.

Úroveň detailu popisu požadavku, nejvhodnější (ideální) nástroje a výrazové prostředky by se tedy měly lišit podle složitosti dodávky a prostředí.

Stanovte si metadata požadavků

Stejně důležitou součástí požadavku, jako je samotný obsah, jsou i řídicí atributy (metadata) požadavku, které (nejen) determinují a umožňují realizovat proces řízení požadavků. Zatímco výrazové prostředky a nástroje pro zpracování obsahu požadavku se diskutují v úvodu všech projektů skutečně hojně, to, jak se budou požadavky řídit (proces), jaké dodatečné atributy kvůli tomu musíme bezpodmínečně sledovat, jaký bude životní cyklus požadavku a jaké jeho fáze je vhodné sledovat, se již tak často nediskutuje.

Zaveďte roli hlavního analytika

Ono se ani není příliš čemu divit. Drtivá většina analytiků zvládá velmi dobře „analytické řemeslo“ a tímto směrem se intenzivně dále vzdělává. Znají UML, BPMN, umí se vyjadřovat velmi přesně psaným textem, umí vést interview, znají nejrůznější metody sběru požadavků atd. Jinými slovy zdokonalují svou expertizu směrem k obsahu požadavku, jak ho získat a precizně zpracovat. Ale jen ti zkušenější z analytiků cítí a chápou svůj významný podíl odpovědnosti na samotném procesu řízení požadavků (ke kterému nezbytně potřebují určitou sadu řídicích metadat) – jinými slovy role analytiků (přesněji hlavních analytiků či podobných rolí) je v oblasti řízení rozsahu projektu naprosto klíčová. Navíc, stejně jako v případě obsahu požadavků, není ani v tomto případě příliš mnoho pouček, jak požadavky efektivně řídit, neboť rovněž i zde je silná závislost na složitosti řešení a prostředí, pro které vzniká. Rychle dostupné rady jsou poskytovány většinou s minimálním kontextem, a tak je zde velké riziko implementace přístupu, který v dané situaci celé věci moc neprospěje (vzpomeňme na analogii se stěhováním zmíněnou v úvodu). Správná volba tak v drtivé většině případů závisí na zkušenostech realizačního týmu a schopnosti tyto zkušenosti správně aplikovat v dané situaci.

Určete, kdo za řízení požadavků odpovídá

Často tedy zůstává odpovědnost za nastavení procesu řízení požadavků (a tedy řízení rozsahu projektu) jen a pouze na bedrech projektového manažera, protože ten má přece rozsah projektu jako jeden z bodů trojimperativu projektového řízení. Jsem přesvědčen, že samotný projektový manažer (bez silné podpory analytické role) může úspěšně uřídit rozsah projektu jen zřídka. Důvod je dvojí:

  1. Schopnost pojmout kompletní businessovou problematiku dodávky a všechny provázanosti navrhovaného řešení je u projektového manažera omezená (často ne nutně schopnostmi, ale spíše kapacitními možnostmi (když už pomineme fakt, že to k roli projektový manažer prostě tak úplně nepatří)) a 
  2. čím komplexnější je nastaven proces řízení požadavků, tím více zdrojů je potřeba na jeho údržbu a provoz a dramaticky vzrůstá nutnost aktivního zapojení většiny participujících rolí.

Jak bylo řečeno v úvodu, „one-size-fits-all“ recept na řešení problematiky řízení rozsahu projektu neexistuje. Vždy záleží na okolnostech, prostředí, povaze projektu a zkušenostech klíčových členů realizačního týmu. To samozřejmě není nic moc objevného a hlavně nám to neposkytuje žádné konkrétnější vodítko, kterým se při nastavování podpory pro řízení rozsahu projektu řídit. V následujících dílech seriálu se pokusím zobecnit své zkušenosti z reálných projektů a zformulovat je do jednoduchého modelu, který může na startu projektu s nastavováním procesů kolem požadavků pomoci.

Jan Pacovský Jan Pacovský
Autor článku se více než 12 let věnuje oblasti řízení požadavků, business i systémové analýze. Působil nejen na straně dodavatelů IT řešení, ale i jako zadavatel IT projektů na straně zákazníka. Zkušenosti sbíral na projektech v České republice i v zahraničí, kde vedl velké mezinárodní projekty a pracoval ve skutečně multikulturním prostředí (Čína, Kazachstán, Vietnam a další). Nyní je Managing Consultantem ve společnosti Adastra.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.