Vyberte si vhodný nástroj pro řízení rozsahu projektů (I. díl)

Který z nástrojů podporující podporujících řízení rozsahu projektu je nejvhodnější právě pro vás? Zjistěte, které řešení si ze široké nabídky stávajícího trhu vybrat.

V seriálu článků připravených pro časopis Computerworld přinášíme základní srovnání dostupných nástrojů pro řízení rozsahu projektu, které zohledňují dva klíčové faktory s největším vlivem: složitost projektu a počet zainteresovaných stran.

Jestliže tyto dva faktory promítneme do matice, získáme celkem čtyři základní přístupy k řízení rozsahu projektu:

1. Jednoduchost a efektivita
2. Konzistence a detail
3. Kooperace a sdílení
4. Komplexní přístup

Jestliže je složitost projektu poměrně nízká a zároveň nemá ani realizační tým společně s dalšími zainteresovanými osobami desítky členů, je potřeba přístupem k řízení požadavků hlavně nezahltit a nebrzdit, a tedy je vhodné volit spíše jednodušší nástroje a co nejjednodušší proces.

Takové případy umožňují z hlediska požadavků a procesu jejich řízení používat poměrně úspěšně generické nástroje typu textových editorů – například MS Word či MS Excel. Pro zjednodušení – v takové situaci je klíčové minimalizovat dodatečnou pracnost generovanou nastaveným procesem a používanými nástroji.

Je-li vlastní projekt komplikovaný a zároveň je realizován v menším týmu s nižším počtem zainteresovaných osob, je nutné věnovat pozornost zejména konzistenci a detailu. K vyjádření obsahu požadavku tedy nejlépe poslouží specializované výrazové prostředky a související nástroje, které je podporují. Takovými jsou například BPMN a UML. Díky nim je možné vytvářet ucelený a provázaný model (minimálně v oblastech, které určují složitost projektu).

Jelikož požadavků u složitých projektů bývá celá řada a hlavně spolu velmi často souvisí a vzájemně se ovlivňují, je užitečné, namísto generických nástrojů typu MS Excel, nasadit nějaký task management nástroj. Ten kromě sledování požadavků v průběhu jejich vzniku zajistí i podporu řízení agilního zpracovávání projektového backlogu (organizovaného seznamu dosud nezpracovaných úkolů). Je dobré také zvážit vytvoření modelu požadavků.

Rozhodnete-li se kvůli obsahu zavádět v širším měřítku task management systém, doporučuji využít jej i pro celý proces řízení požadavků jako takový. Avšak jelikož předpokládáme menší množství zainteresovaných osob, je možné takový systém používat téměř výhradně pro interní potřeby dodávajícího týmu. Informace vycházející směrem ven z týmu pak je lepší poskytovat na základě ad hoc reportů či exportů.

Paralelně dalším neméně důležitým procesem, jenž je potřeba mít v tomto případě pevně pod kontrolou, je pak proces změnového řízení. Všechny změny je potřeba posuzovat v celém kontextu a identifikovat všechny možné dopady. V tomto ohledu pomůže jak výše zmiňovaný ucelený a provázaný model, tak v neposlední řadě i používaný task management systém, do něhož je také nezbytné změnový proces promítnout .

Největší výzvou, a to nejen z pohledu řízení požadavků a rozsahu projektu, je situace, kdy na jedné straně je nutné řešit složitý projekt a na straně druhé existuje celá řada zainteresovaných osob. Takové projekty často vyplňují kolonky statistiky neúspěšných projektů z důvodu neuřízeného rozsahu a nezvládnutých požadavků.

Pro samotné požadavky platí to samé, co je uvedeno v předchozí variantě. Základními hesly jsou sdílení, sledování, správa verzí, schvalování a hlavně modelování. Úskalí nastává, když je nezbytné vybrané výstupy z modelu sdílet, připomínkovat a schvalovat.

Proces řízení požadavků je v tak to komplexní variantě naprosto kritický. Nevhodně navržený proces nebo nedostatečná pečlivost při jeho realizaci končí v každém případě stejně – ztrátou kontroly nad stavem projektu a neschopností jej dále řídit. Všichni členové týmu jsou rovným dílem zodpovědní za svou fázi zpracování požadavku. Nedílnou součástí této odpovědnosti je i sledování stavu jeho aktivity. Také proto je v takovém případě klíčový silný systém pro správu úkolů (task tracking systém), který je přístupný všem zainteresovaným stranám. Zároveň je neméně důležitá návaznost dílčích úkolů na samotný obsah požadavků.

Nastíněné kvadranty je možné využít k posouzení vybraných více či méně specializovaných řešení na trhu.

Takové porovnání může být v mnohém přínosné, neboť běžná hodnocení nástrojů pro řízení požadavků (například od Seilevelu) bývají sice komplexní (zda daný nástroj disponuje stanovenou funkcionalitou, a pokud ano, v jaké míře ji plní), ale naprosto bez ohledu na skutečnou potřebu potenciálního uživatele takového nástroje.

I přesto, že si zákazník sice vybere řešení nastíněného porovnání, snadno se může stát, že výsledek úplně pozitivní být nemusí. Na začátku přípravy tohoto přehledu nestála ambice kompletně zmapovat trh, zahrnout do výběru vše, co je dostupné, a vše pečlivě a detailně porovnat. Naopak cílem je spíše seznámit se s novými a moderními nástroji, které přicházejí s něčím zajímavým nebo výjimečným, a poskytnout úvodní rychlé shrnutí pro případné další individuální zkoumání trhu.

Zároveň do seznamu nejsou zahrnuty generické nástroje typu Word, Excel, Jira, Wiki a jiné podobné, jejichž vhodnou kombinací (za předpokladu jasného a zodpovědně dodržovaného souvisejícího procesu) lze pokrýt v zásadě libovolnou situaci.

V abecedním pořadí tedy do seznamu řadíme následující nástroje:

• Analyst od TopTeam
• Atlas od Micro Focus
• blueprint Storyteller od Blueprint Software Systems
• CaseComplete od Serlio Software
• Enterprise Architect od Sparx Systems
• Gatherspace.com od Gatherspace
• Jama od Jama Software
• RequirementOne od Jama Software

Trochu diskutabilním nástrojem je možná Enterprise Architect, který je takovým „švýcarským armádním nožem“. Uděláte s ním v podstatě všechno, ale máloco skutečně naplno.

Do výběru se každopádně i přesto zařadil, neboť pro určitý typ projektů je rozhodně použitelný a jeho obecná role jako modelovacího case nástroje je neoddiskutovatelná.

Nastíněná grafika zobrazuje diskutované nástroje do dílčích kvadrantů. Hodnocení nicméně nemůže být zcela a naopak může být oprávněně diskutabilní. Různé nástroje totiž kladou rozdílný důraz na jednotlivé části requirement engeneeringu nebo celého procesu řízení požadavků.

V pokračování článku si projdeme jednotlivé kvadranty a nástroje, které se v nich umístily.