Proč některé projekty, na nichž jste v uplynulých měsících intenzivně pracovali, nedopadly zcela podle vašich představ? První díl třídílného seriálu, ve kterém se dočtete, jak dovést IT projekty zdárně do konce, připravil Jan Pacovský, Managing Consultant Adastry. Zjistěte, nač si dát při práci největší pozor z pohledu řízení požadavků.
Na internetu a v odborných publikacích naleznete plno nejrůznějších analýz a statistik, které vyjmenovávají nejčastější důvody neúspěchu IT projektů. Ty pak slouží jako argumenty na podporu té či oné metodiky životního cyklu dodávky softwaru, která má zvýšit pravděpodobnost úspěchu. Jen málokdy se ale diskutuje konkrétnější recept na řešení nejvážnějších příčin, na kterých se většina 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í).
Nehledejte „one-size-fits-all“ řešení
Selský rozum napovídá a zkušenost ukazuje, že neexistuje jedno univerzální řešení pro všechny potřeby. 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. Na projektech se však čím dál tím častěji a bez uvážení kontextu hodiny a hodiny řeší, jak a zda a co budeme modelovat, jaké nástroje se použijí a jaké další atributy by se alespoň teoreticky mohly hodit do vybraného nástroje pro řízení požadavků dokonfigurovat (právě proto, že jsme se o nich dočetli v nějaké knize).
Nadefinujte skutečné potřeby
Uvedené diskuze je potřeba vést, netvrdím opak. Avšak v jejich úvodu vnímám jako důležitě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 či dokonce jen přívěsný vozík za naším automobilem? Tato analogie je úsměvná, nicméně 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. Nadefinujte tedy skutečné potřeby a ne možnosti a přání.
Zapojte Requirement Engineering
Tato disciplína se zabývá řízením a definicí rozsahu projektu. 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 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ů (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 však 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 také proces řízení požadavků.
Všechny metodiky přistupují k procesu rozdílně, co se týče docílení popisu samotného obsahu požadavku (tedy toho, co se má dodat, zajistit či 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“.
Obsah a detail: zaměřte se na ně i při agilním přístupu
Zvolíme-li jakýkoliv postup, je potřebné, aby vždy (!) vznikl určitý popis toho, co se má dodat. Kamenem úrazu spíše než uvědomění si toho, že je potřeba mít požadavky sepsané a schválené zadavatelem, bývá volba výrazových prostředků (UML, BPMN, strukturovaný text a další), použitých nástrojů a volba správné, tedy dostačující úrovně detailu. Na to neexistuje žádná poučka. Vhodný přístup závisí i na prostředí, ve kterém vzniká a pro které je určen, nejen na složitosti samotného systému.
U nejjednodušší aplikace či v případě drobného rozvoje realizovaného agilně malým týmem ve známém prostředí stačí 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 nicméně nutné mít na paměti skutečně celý životní cyklus dodávky softwaru. Ačkoliv programátoři v rámci agilního přístupu možná nepotřebují nijak zvláště detailní popis toho, co se má vyvinout, neznamená to, že takový popis nebude nezbytný pro potřeby testování či pro tvorbu dokumentace. Dle mého názoru nelze zdrojový kód považovat za nejlepší formu dokumentace z mnoha důvodů. Ú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í.
Určete si metadata požadavků
Řídicí atributy (metadata) jsou stejně důležitou součástí požadavku, jako je samotný obsah. Determinují (nejen) 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
Není se ani příliš čemu divit. Převážná 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ů a jiné. Jinými slovy zdokonalují svou expertizu směrem k obsahu požadavku, jak ho získat a precizně zpracovat.
Nicméně jen ti zkušenější z analytiků vnímají 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. Pokud to řekneme jinak, role analytiků (tedy 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 odpovědnost za řízení požadavků
Mnohdy zůstává odpovědnost za nastavení procesu řízení požadavků (a tedy řízení rozsahu projektu) pouze na projektovém manažerovi. Ten má přeci rozsah projektu jako jeden z bodů trojimperativu projektového řízení, nebo ne? 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í business 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, pomineme-li fakt, že to k roli projektový manažer prostě tak úplně nepatří)
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 ro lí.
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. Nejde samozřejmě o 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, jenž vám může být nápomocný při startu projektu a nastavování procesů kolem požadavků.