V prvej časti seriálu sme načrtli najdôležitejšie faktory, ktoré určujú najvhodnejší prístup k riadeniu rozsahu projektu. Týmto nasledujúcim článkom na danú tému nadviažeme a zameriame sa na to, ako rozsah projektu a požiadavky efektívne riadiť a uriadiť, aby sme projekt mohli zadávateľovi úspešne odovzdať.

Existuje celý rad faktorov, na ktorých základe možno vybrať najvhodnejší nástroj requirement engineeringu (organizačná štruktúra projektu, skúsenosti s podobnými projektmi, zrelosť organizácie zákazníka a dodávateľa v oblasti requirement engineeringu a celkovo projektového riadenia atď.). Za primárne označme nasledujúce dva faktory:

  • počet participujúcich zainteresovaných osôb,
  • zložitosť projektu.

Nielenže sme tieto faktory schopní pomerne ľahko vyhodnotiť, ale predovšetkým patria medzi tie vplyvy, ktoré sú úplne určujúce pre správny výber prístupu k riadeniu rozsahu projektu. Zložitosť projektu možno v tomto zmysle chápať v dvoch rovinách – biznisovej a technickej.

Biznisovú zložitosť realizovaného systému určujú najmä:

  • Počet a/alebo zložitosť biznisových procesov, ktoré má systém podporovať alebo v nich participovať.
  • Počet a/alebo zložitosť biznisových pravidiel – ich logiku musí systém implementovať.
  • Predpokladaný biznisový dopad nasadenia dodávaného riešenia (napr. zmeny procesov vyvolané novým systémom).

Technickú zložitosť realizovaného riešenia potom obvykle určujú:

  • Vnútorná architektúra dodávaného riešenia (napr. monolitické riešenie vs. súbor integrovaných subsystémov).
  • Miera integrácie dodávaného riešenia na okolie.
  • Architektúra cieľového prostredia, kde bude systém nasadený a prevádzkovaný.
  • Predpokladaný technický dopad nasadenia dodávaného riešenia na okolie (napr. úpravy naviazaných systémov tretích strán).

Takto vnímaná zložitosť projektu nám vymedzuje vhodné výrazové prostriedky pre popis obsahu požiadaviek, minimálnu potrebnú úroveň detailu dokumentácie požiadaviek a v neposlednom rade i súbor dimenzií, do ktorých je zmysluplné požiadavky kategorizovať.

Počet a povahu participujúcich zainteresovaných osôb môžeme vnímať ako pokrytie „soft“ faktorov projektu. Ak má projekt málo zainteresovaných strán (vrátane členov samotného implementačného tímu), môžeme počítať s výrazne ľahšou (internou i externou) komunikáciou, jednoduchším zdieľaním informácií, rýchlejším schvaľovaním alebo menším rizikom kultúrnych rozdielov.

Keď si premietneme tieto dva faktory do matice, získame štyri základné prístupy, ako sa k riadeniu rozsahu projektu môžeme postaviť:

  • jednoduchosť a efektivita,
  • konzistencia a detail,
  • kooperácia a zdieľanie,
  • komplexný prístup.

Popíšme si jednotlivé prístupy, na čo sa zamerať a aké nástroje je vhodné zvoliť. Budeme sa venovať prístupu 1 (jednoduchosť a efektivita) a 2 (konzistencia a detail), v ďalšej časti potom zvyšným dvom.

Prístup 1: jednoduchosť a efektivita

Ak je zložitosť projektu relatívne nízka a ak nepočítame realizačný tím spoločne s ďalšími zainteresovanými osobami na veľa desiatok ľudí, je dôležité prístupom k riadeniu požiadaviek hlavne všetkých nezahltiť a nebrzdiť projekt. Mali by sme preto voliť skôr jednoduchšie nástroje a čo najjednoduchší proces.

Požiadavky

Môžeme používať generické nástroje typu textových editorov (napr. MS Word) a v nich udržiavať štruktúrovaný text doplnený vybranými grafmi s vhodne zvoleným jazykom. V najjednoduchších prípadoch môže vyhovovať i jeden dokument na celý projekt, avšak väčšinou vznikne určitá skupina takých dokumentov – štruktúrovaná napríklad po jednotlivých oblastiach biznisu. Aj v tomto prípade by však mal vzniknúť jeden zastrešujúci popis vymedzujúci na najvyššej (high-level) úrovni celé dodanie.

Pokiaľ textovému editoru príliš neveríte, pozrite sa po štruktúrovanejších a sofistikova­nejších nástrojoch, napríklad RequirementOne.

Agilita

Ak to prostredie dovolí, určite zvážte nasadenie silno agilného prístupu. Netreba popísať kopu strán a definovať požiadavky do úplného detailu, lebo agilný prístup bude v tomto prípade oveľa rýchlejší a s vyššou pravdepodobnosťou nakoniec zabezpečí spokojnosť zákazníka. Nesmieme však zabudnúť na tri základné veci:

  • Vymedziť hranice každej oblasti (čo sa má alebo nemá ešte riešiť).
  • Zaznamenať identifikované požiadavky do backlogu.
  • Definovať nefunkčné požiadavky (hlavne požiadavky na výkon – performance), ktoré môžu byť ľahko zanedbané.

Riadenie požiadaviek

Podporu riadenia požiadaviek možno tiež riešiť pomocou generických nástrojov typu tabuľkového procesora (napr. MS Excel). Riadenie ďalšieho spracovania požiadaviek, keď už ich máme identifikované, možno realizovať často popísanými metódami a technikami riadenia agilného backlogu (whiteboardy, flipcharty ap.). Zjednodušene povedané: v tejto situácii je potrebné držať sa čo najviac známeho pravidla KISS (Keep it simple, stupid!). Minimalizujme overhead generovaný nastaveným procesom a používanými nástrojmi.

Prístup 2: konzistencia a detail

Ak sa ocitneme v situácii, že máme komplikovaný projekt realizovaný v menšom tíme s menším počtom zainteresovaných osôb, mali by sme pozornosť smerovať predovšetkým ku konzistencii a detailu.

Požiadavky

Opäť platí na prvom mieste pravidlo, že je nevyhnutné mať na high-level úrovni vymedzený celý rozsah dodania, aby sme mohli posudzovať, či jednotlivé požiadavky do projektu patria a či nie. Samostatné identifikované požiadavky tak musíme udržať „pohromade“, musíme veľmi obozretne riadiť všetky zmeny a identifikovať všetky potenciálne dopady a v neposlednom rade musíme zabezpečiť detail práve v tých oblastiach, ktoré zložitosť projektu vytvárajú.

  • Ak máme podporiť zložitý proces, je potrebné ho detailne poznať a popísať.
  • Ak je procesov veľa, musíme venovať veľkú pozornosť ich vymenovaniu a previazanosti.
  • Ak máme extrémne zložité biznis pravidlá, je potrebné ich do detailov pochopiť a zaznamenať.
  • Ak má byť dodávaný systém významne integrovaný v rámci IT prostredia zákazníka, je nutné cieľovú architektúru podrobne znázorniť atď.

Uvedené podklady sú tým správnym „lepidlom“, ktoré udrží rozsah projektu pohromade. Ak by sme taký „spojovací materiál“ nemali k dispozícii, v určitom momente zistíme, že sa mnoho tisícdielne puzzle rozsypali a budeme ich iba veľmi ťažko dávať dokopy.

Ako teda pristúpiť k výberu nástrojov a výrazových prostriedkov? Pre vyjadrenie obsahu požiadaviek je maximálne vhodné siahnuť k špecializovaným výrazovým prostriedkom (a súvisiacim nástrojom, ktoré ich podporujú), napríklad BPMN a UML (napríklad v nástroji Enterprise Architect), a vytvárať ucelený a previazaný model (minimálne v tých oblastiach, ktoré určujú zložitosť projektu).

Agilita

Znovu platí, že môžeme využiť agilné postupy a prístupy, avšak odporúčam opatrnosť pri výbere oblastí, kde, kedy a s akou intenzitou ich nasadiť. Zložitý biznis proces, ktorý má systém podporovať, je potrebné najprv pomerne detailne zmapovať, identifikovať na jeho základe požiadavky, ktoré majú byť vyvinuté, popísať a dohodnúť základnú logiku každej požiadavky, aby v kontexte celého procesu dávali zmysel. Až v tomto momente si môžeme byť istí vymedzením hraníc natoľko, že sa môžeme pustiť do agilných vôd.

Kľúčovou osobou bude (nielen v prípade nasadenia agilného prístupu) osoba biznis vlastníka či vlastníka produktu (product owner). Vzhľadom na to, že požiadaviek na zložitom projekte môže byť celý rad a budú spolu veľmi často súvisieť a vzájomne sa ovplyvňovať, je dôležité zvážiť nasadenie nejakého nástroja na task management (napr. JIRA), ktorý okrem sledovania požiadaviek v priebehu ich vzniku zabezpečí i podporu riadenia agilného zapracovania projektového backlogu. Na zváženie je zároveň vytvorenie modelu požiadaviek.

Riadenie požiadaviek

Ak sa rozhodneme kvôli obsahu zavádzať v širšom rozsahu systém task managementu, určite ho odporúčam využiť aj pre celý proces riadenia požiadaviek ako taký. Avšak vzhľadom na to, že predpokladáme menší počet zainteresovaných osôb, môžeme taký systém používať takmer výhradne pre interné potreby dodávajúceho tímu, informácie smerujúce von z tímu tak môžeme poskytovať na základe ad hoc reportov či exportov.

V tomto prípade musíme mať bez debaty pevne pod kontrolou proces riadenia zmien. Nie je možné akceptovať nedokumentované zmeny, keďže môžu dramaticky ovplyvňovať výslednú kvalitu celého dodania. Každú zmenu je potrebné posúdiť v celom kontexte a identifikovať všetky možné dopady. Tomu pomôže jednak vyššie spomenutý ucelený a previazaný model a v neposlednom rade i používaný systém task managementu, do ktorého je viac ako vhodné tiež premietnuť proces zmien.

Postup pri ďalších dvoch prístupoch si rozoberieme v poslednej časti troj-seriálu o riadení IT projektov.

Autor: Jan Pacovský, Managing Consultant, Adastra

Jan sa vyše 12 rokov venuje oblasti riadenia požiadaviek, biznis analýze a systémovej analýze. Pôsobil nielen na strane dodávateľov IT riešení, ale aj ako zadávateľ IT projektov na strane zákazníka. Skúsenosti zbieral na projektoch v Českej republike i v zahraničí, kde viedol veľké medzinárodné projekty a pracoval v skutočne multikulturálnom prostredí (Čína, Kazachstan, Vietnam atď.).

Zdroj: IT Systems, 4/2017 alebo na systemonline.cz