Jak dovést IT projekty zdárně do konce - 2. část: Rozsah a požadavky projektu I.

V první dílu seriálu jsme si nastínili nejdůležitější faktory, které určují nejvhodnější přístup k řízení rozsahu projektu. Aktuálním a následujícím článkem na tuto problematiku navážeme a zaměříme se na to, jak rozsah projektu a požadavky efektivně řídit a uřídit, abychom projekt mohli zadavateli úspěšně předat.

Existuje celá řada faktorů, na jejichž základě lze vybrat nejvhodnější nástroj Requirement Engineeringu (organizační struktura projektu, zkušenosti s podobnými projekty,vyspělost organizace zákazníka a dodavatele v oblasti Requirement Engineeringu a projektového řízení vůbec, atd.). Za primární označme následující dva faktory:

• Počet participujících zainteresovaných osob
• Složitost projektu

Nejenže jsme tyto faktory schopni poměrně snadno vyhodnotit, ale především patří mezi ty vlivy, které jsou zcela určující pro správný výběr přístupu k řízení rozsahu projektu. Složitost projektu lze v tomto smyslu chápat ve dvou rovinách – businessové a technické.

• Počet a/nebo složitost business procesů, které má systém podporovat nebo v nich participovat.
• Počet a/nebo složitost business pravidel, jejichž logiku musí systém implementovat.
• Předpokládaný businessový dopad nasazení dodávaného řešení (např. změny procesů vyvolané novým systémem).

• Vnitřní architektura dodávaného řešení (např. monolitické řešení vs. sada integrovaných subsystémů).
• Míra integrace dodávaného řešení na okolí.
• Architektura cílového prostředí, kde bude systém nasazen a provozován.
• Předpokládaný technický dopad nasazení dodávaného řešení na okolí (např. úpravy návazných systémů třetích stran).

Takto pojatá složitost projektu nám determinuje vhodné výrazové prostředky pro popis obsahu požadavků, minimální potřebnou úroveň detailu dokumentace požadavků a v neposlední řadě i sadu dimenzí, do kterých je účelné požadavky kategorizovat.

Počet a povahu participujících zainteresovaných osob můžeme vnímat jako pokrytí „soft“ faktoru projektu. Jestliže má projekt málo zainteresovaných stran (myšleno včetně členů samotného implementačního týmu), můžeme počítat s výrazně snazší (interní i externí) komunikací, jednodušším sdílením informací, rychlejším schvalováním nebo menším rizikem kulturních rozdílů.

Promítneme-li si tyto dva faktory do matice, získáme čtyři základní přístupy, jak se k řízení rozsahu projektu můžeme postavit:

• Jednoduchost a efektivita
• Konzistence a detail
• Kooperace a sdílení
• Komplexní přístup

Popišme si nyní jednotlivé přístupy, na co se zaměřit a jaké nástroje je vhodné zvolit. Nyní se budeme věnovat přístupům 1 (jednoduchost a efektivita) a 2 (konzistence a detail), v následujícím dílu pak dalším dvěma.

Pokud je složitost projektu relativně nízká a stejně tak, pokud nepočítáme realizační tým společně s dalšími zainteresovanými osobami na vysoké desítky lidí, je důležité přístupem k řízení požadavků hlavně všechny nezahltit a nebrzdit projekt. Měli bychom tudíž volit spíše jednodušší nástroje a co nejjednodušší proces.

Můžeme používat generické nástroje typu textových editorů (např. MS Word) a v nich udržovat strukturovaný text doplněný vybranými diagramy vhodně zvoleného jazyka. V nejjednodušších případech může vyhovovat i jeden dokument na celý projekt, avšak většinou takových dokumentů vznikne určitá sada strukturovaná například po businessových oblastech. I v tomto případě by nicméně měl vzniknout jeden zastřešující popis vymezující na nejvyšší (high-level) úrovni celou dodávku.

Pokud textovému editoru příliš nevěříte, poohlédněte se po strukturovanějších a sofistikovanějších nástrojích, například RequirementOne.

Jestliže to prostředí dovolí, rozhodně zvažte nasazení silně agilního přístupu. Netřeba popisovat stohy papíru a definovat požadavky do úplného detailu, neboť agilní přístup bude v tomto případě mnohem rychlejší a s vyšší pravděpodobností zajistí finální spokojenost zákazníka. Nesmíme přesto zapomenout na tři základní věci:

• Vymezit hranice každé oblasti (co se má nebo nemá ještě řešit).
• Zaznamenat identifikované požadavky do backlogu.
• Definovat nefunkční požadavky (zejména požadavky na výkon – performance), které mohou být snadno opomenuty.

Podporu řízení požadavků lze rovněž řešit pomocí generických nástrojů typu tabulkového procesoru (např. MS Excel). Řízení dalšího zpracování požadavků, když už je máme identifikováno, lze realizovat mnohokrát popsanými metodami a technikami řízení agilního backlogu (whiteboardy, flipcharty apod.). Zjednodušeně řečeno: v této situaci je potřeba držet se co nejvíce známého pravidla KISS (Keep It Simple, Stupid!). Minimalizujme overhead generovaný nastaveným procesem a používanými nástroji.

Ocitneme-li se v situaci, kdy máme komplikovaný projekt realizovaný v menším týmu s menším počtem zainteresovaných osob, měli bychom pozornost směřovat především ke konzistenci a detailu.

Opět platí na prvním místě pravidlo, že je nezbytné mít na high-level úrovni vymezený celý rozsah dodávky, abychom mohli posuzovat, jestli jednotlivé požadavky do projektu patří, či nikoliv. Samostatné identifikované požadavky pak musíme udržet „pohromadě“, musíme velmi obezřetně řídit veškeré změny a identifikovat všechny potenciální dopady a v neposlední řadě musíme zajistit detail právě v těch oblastech, které složitost projektu vytváří.

• Jestliže máme podpořit složitý proces, je potřeba ho detailně poznat a popsat.
• Jestliže je procesů hodně, musíme věnovat velkou pozornost jejich výčtu a provázanosti.
• Pokud máme extrémně složitá business pravidla, je potřebné je do detailu pochopit a zaznamenat.
• Má-li být dodávaný systém významně integrován v rámci IT prostředí zákazníka, je nutné cílovou architekturu podrobně znázornit atd.

Uvedené podklady jsou tím správným „lepidlem“, které udrží rozsah projektu pohromadě. Jestliže bychom takový „spojovací materiál“ neměli k dispozici, v jistý okamžik zjistíme, že se mnohatisícidílkové puzzle rozsypaly a budeme je jen velmi těžko dávat dohromady.

Jak tedy přistoupit k výběru nástrojů a výrazových prostředků? Pro vyjádření obsahu požadavku je maximálně vhodné sáhnout ke specializovaným výrazovým prostředkům (a souvisejícím nástrojům, které je podporují), například BPMN a UML (například v nástroji Enterprise Architect), a vytvářet ucelený a provázaný model (minimálně v těch oblastech, které určují složitost projektu).

Znovu platí, že můžeme využít agilní postupy a přístupy, avšak doporučoval bych opatrnost při výběru oblastí, kde, kdy a s jakou intenzitou je nasadit. Složitý business proces, který má systém podporovat, je potřeba nejprve poměrně detailně zmapovat, identifikovat na jeho základě požadavky, které mají být vyvinuty, popsat a dohodnout základní logiku každého požadavku, aby v kontextu celého procesu dávaly smysl. Teprve v tento okamžik si můžeme být jisti vymezením hranic natolik, že se můžeme pustit do agilních vod.

Klíčovou osobou bude (nejen v případě nasazení agilního přístupu) osoba business vlastníka či vlastníka produktu (product owner). S ohledem na to, že požadavků na složitém projektu může být celá řada a budou spolu velmi často souviset a vzájemně se ovlivňovat, je důležité zvážit nasazení nějakého task management nástroje (např. JIRA), který kromě sledování požadavků v průběhu jejich vzniku zajistí i podporu řízení agilního zpracovávání projektového backlogu. Ke zvážení je zároveň vytvoření modelu požadavků.

Rozhodneme-li se kvůli obsahu zavádět v širším měřítku task management systém, určitě doporučuji využít jej i pro celý proces řízení požadavků jako takový. Nicméně vzhledem k tomu, že předpokládáme méně zainteresovaných osob, můžeme takový systém používat téměř výhradně pro interní potřeby dodávajícího týmu, informace směrem ven z týmu pak poskytovat na základě ad hoc reportů či exportů.

Naprosto bez debat musíme mít v tomto případě pevně pod kontrolou proces změnového řízení. Není možné akceptovat nedokumentované změny, jelikož mohou dramaticky ovlivňovat výslednou kvalitu celé dodávky. Každou změnu je nutné posoudit v celém kontextu a identifikovat všechny myslitelné dopady. Tomu pomůže jednak výše zmiňovaný ucelený a provázaný model a v neposlední řadě i používaný task management systém, do kterého je více než vhodné změnový proces promítnout také.

Postup u dalších dvou přístupů budeme diskutovat v příštím díle článku.

Jan 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ší).