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

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

Nejen že tyto faktory dokážeme poměrně snadno vyhodnotit, ale hlavně patří mezi ty vlivy, které jsou naprosto 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é. Businessovou složitost realizovaného systému vymezuje zejména:

• 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)

Technickou složitost realizovaného řešení pak obvykle určuje:

• 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. Má-li projekt málo zainteresovaných stran (myšleno včetně členů samotného implementačního týmu), pak můžeme počítat s mnohem jednodušší komunikací (interní i externí), snazším sdílením informací, rychlejším schvalováním, menším rizikem kulturních rozdílů atd.

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 (viz obrázek 1):

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

Obr. 1: Základní přístupy k řízení rozsahu projektů

Pojďme na následujících řádcích popsat 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), ve 3. dílu pak dalším dvěma.

Přístup 1: Jednoduchost a efektivita

Je-li složitost projektu relativně nízká a stejně tak realizační tým společně s dalšími zainteresovanými osobami nepočítáme na vysoké desítky lidí, je potřeba, abychom přístupem k řízení požadavků hlavně všechny nezahltili a projekt nebrzdili. To znamená, že bychom měli volit spíše jednodušší nástroje a co nejjednodušší proces.

Požadavky

Z pohledu požadavků lze v takových případech 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 úplně nejjednodušších situacích může vyhovovat i jeden dokument na celý projekt, nicméně obvykle takových dokumentů vznikne určitá sada strukturovaná například po businessových oblastech. Nicméně i v tomto případě by měl vzniknout jeden zastřešující popis vymezující na nejvyšší (high-level) úrovni celou dodávku. Pokud ale textovému editoru příliš nevěříte, můžete se poohlédnout po strukturovanějších a sofistikovanějších nástrojích, jako je například RequirementOne.

Agilita

Pokud to prostředí dovolí, je rozhodně vhodné zvážit nasazení silně agilního přístupu. Nemá smysl popisovat stohy papíru a definovat požadavky do úplného detailu. Agilní přístup bude v tomto případě mnohem rychlejší a s vyšší pravděpodobností zajistí finální zákaznickou spokojenost. Přesto ale nesmíme zapomenout na tři základní věci:

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

Řízení požadavků

K podpoře řízení požadavků lze přistoupit rovněž za pomoci 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.

Přístup 2: Konzistence a detail

Pokud se ocitáme v situaci, kdy máme komplikovaný projekt realizovaný v menším týmu s menším počtem zainteresovaných osob, měla by naše pozornost směřovat hlavně ke konzistenci a detailu.

Požadavky

I v tomto případě platí na prvním místě pravidlo, že je nezbytné mít na high-level úrovni vymezený celý rozsah dodávky, abychom dokázali posuzovat, zda jednotlivé požadavky do projektu patří, či nikoli. Jednotlivé 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áří.

• Pokud máme podpořit složitý proces, je potřeba ho detailně poznat a popsat.
• Pokud je procesů hodně, musíme věnovat velkou pozornost jejich výčtu a provázanosti.
• Máme-li extrémně složitá business pravidla, je nezbytné 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 nezbytné cílovou architekturu podrobně znázornit atd.

Takové podklady jsou tím správným „lepidlem“, které udrží rozsah projektu pohromadě. Pokud bychom takový „spojovací materiál“ neměli k dispozici, v určitý okamžik zjistíme, že se mnohatisícidílkový puzzle rozsypal a budeme ho 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 více než vhodné v tomto případě sáhnout ke specializovaným výrazovým prostředkům (a souvisejícím nástrojům, které je podporují), jako je 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).

Agilita

Opět platí, že je možné sáhnout pro agilní postupy a přístupy, nicméně doporučoval bych opatrnost při výběru oblastí, kde, v jaký okamžik 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, a 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 pak bude (nejen v případě nasazení agilního přístupu) osoba business vlastníka či vlastníka produktu (product owner).

Vzhledem k tomu, že požadavků na složitém projektu může být celá řada a hlavně spolu budou velmi často souviset a budou se vzájemně ovlivňovat, je více než vhodné 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 pak i vytvoření modelu požadavků.

Řízení požadavků

Jestliže se rozhodneme kvůli obsahu zavádět v širším měřítku task management systém, rozhodně doporučuji, aby se využil i pro celý proces řízení požadavků jako takový. Nicméně vzhledem k tomu, že předpokládáme menší množství 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ů.

Bez jakýchkoli debat musíme mít v tomto případě pevně pod kontrolou proces změnového řízení. Nelze akceptovat nedokumentované změny, neboť ty mohou dramaticky ovlivňovat výslednou kvalitu celé dodávky. Každou změnu je potřeba 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é.

A jak postupovat u dalších dvou přístupů? To se dovíte v příštím čísle časopisu IT Systems.

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.