V poslednej časti seriálu o riadení požiadaviek, ktorého cieľom je priblížiť to, ako doviesť IT projekty do úspešného konca, sa budeme venovať ďalším dvom prístupom k riadeniu projektov zo schémy, ktorú sme predstavili v minulom čísle časopisu. Ostávajú nám prístupy 3 (kooperácia a zdieľanie) a 4 (komplexný prístup) z našej schémy:

                                             Obr. 1: Základné prístupy k riadeniu rozsahu projektov

Ostáva nám teda objasniť prístupy:

  • kooperácia a zdieľanie,
  • komplexný prístup.

Prístup 3: kooperácia a zdieľanie

Ak stojíme pred úlohou riadiť rozsah v rámci relatívne jednoduchého projektu, avšak s celým radom zainteresovaných osôb, musíme sa zamerať hlavne na otázku komunikácie a zdieľania informácií. V takom prípade pre nás bude kľúčové podporiť sledovanie zmien, schvaľovací proces a verziovanie. Skrátka v tomto prípade MS Word s tak obľúbenými revíziami a komentármi neustriehneme a neuriadime. Avšak – stále nezabúdajme na to, že musíme držať rozsah projektu pohromade ako celok. Uvedomme si, že na rozdiel od prvej situácie (kedy sme sa zamerali na jednoduchosť a efektivitu), máme iba viac zainteresovaných osôb, ale zložitosť projektu je stále nízka. A tak iba vyberieme vhodnejší nástroj, ale spôsob a štruktúra spracovania požiadaviek môžu (a mali by) zostať veľmi podobné spomenutému prvému variantu.

Požiadavky

Pre požiadavke je teda vhodné zvoliť nejakú platformu, ktorá ponúka ľahké zdieľanie obsahu a pomôže s riadením komentárov a pripomienok. Zo skúsenosti môžem odporučiť napríklad Confluence Wiki s pluginom Talk. Wiki zabezpečí ľahkú tvorbu obsahu, jeho verziovanie a zdieľanie. Talk umožňuje vkladať komentáre priamo do textu, podobne ako MS Word (takže pre bežné zúčastnené osoby z oblasti biznisu nie je problém toto riešenie efektívne používať). Ak by sme sa rozhodli pre výraznejšie používanie modelu (hoci to nie je v tomto prípade nevyhnutné), existujú modelovacie nástroje so silnou podporou práve vo fáze schvaľovania a pripomienkovania (napríklad nástroj CaseComplete).

Nech už zvolíme akýkoľvek nástroj, rovnako ako vo všetkých ostatných prípadoch platí, že musíme mať na jednom mieste vymedzený celý rozsah projektu (na high-level úrovni), voči ktorému následne posudzujeme každú jednotlivú požiadavku, či je alebo nie je súčasťou dodania. 

 

Riadenie požiadaviek

Z pohľadu procesov riadenia požiadaviek je vhodné zaviesť sledovanie stavu pripomienkovania a schvaľovania jednotlivých dokumentov či požiadaviek podľa zvoleného prístupu. Vzhľadom na to, že do projektu vstupuje celý rad zainteresovaných osôb, je to pomerne kritická aktivita pre minimalizáciu rizika neskorších zmien. V tomto prípade nám bude možno stačiť iba Excel, avšak zrejme nám bude chýbať jednoduchá možnosť nejakého zdieľania. Ak sme sa vydali cestou Wiki, nie je nič ľahšieho ako taký Excel uverejniť práve tam, prípadne vytvoriť tabuľku monitorujúcu stav priamo prostriedkami Wiki.

Nemenej dôležitou radou je mať jasne definovanú komunikačnú maticu, hlavne jednoznačne identifikovať osoby oprávnené predkladať požiadavky. Predíde sa tak nepríjemnej situácii, keď sa v neskorej fáze projektu objaví s novou požiadavkou osoba, s ktorou sme do tej doby o požiadavkách nekomunikovali. Rozhodne nám tiež pomôže mať vopred nadefinované eskalačné procedúry, keďže pri vysokom počte zainteresovaných subjektov výrazne stúpa pravdepodobnosť vzniku protichodných požiadaviek. 

Agilita

Ako sa postaviť k agilným prístupom v tomto prípade? Agilné postupy nám rozhodne budú komplikovať vysoký počet zainteresovaných osôb o to viac, ak budú fyzicky v rôznych geografických lokalitách a navyše v rôznych časových pásmach. Aj napriek tomu však považujem za možné agilné prístupy aplikovať. Je však nevyhnutné jasne vymedziť komunikačnú stratégiu a nastaviť jednoznačné zodpovednosti, aby sme predišli situáciám, keď máme agilne vyvinuté, ale iná skupina zainteresovaných osôb začne s výsledkom nesúhlasiť (pozri tiež odsek vyššie). Situáciu nám môže čiastočne zlepšiť i to, ak sa nám podarí časť aktivít zadávateľskej roly presunúť dovnútra dodávateľského tímu, čo výrazne uľahčí komunikáciu, a tým pádom i umožní rozsiahlejšie nasadenie agilných metód a techník.

Ak sa teda dostávame s relatívne jednoduchým projektom do prostredia s mnohými zainteresovanými osobami, majme na pamäti primárne komunikáciu, zdieľanie a jasne vymedzené zodpovednosti. Pokúsme sa vymaniť z nekonečného kolotoča konsolidácie a vybavovania wordových komentárov a využime vhodnejšiu technickú platformu. 

Prístup 4: komplexný prístup

Najväčšiu výzvu (nielen) z pohľadu riadenia požiadaviek a rozsahu projektu predstavuje situácia, keď na jednej strane máte riešiť zložitý projekt a na strane druhej ste konfrontovaní s celým radom zainteresovaných osôb. Toto je kategória projektov, ktoré sa nezriedka dostávajú do štatistík spomenutých v úvodnom článku (v IT Systems 3/2017)  – bývajú to projekty, ktoré často nedopadnú úspešne hlavne kvôli neuriadeniu rozsahu projektu a nezvládnutých požiadaviek.

O úspechu či neúspechu v oblasti riadenia požiadaviek rozhoduje celý rad faktorov. Primárne je to samotná vyzretosť dodávateľa i odberateľa, starostlivosť pri spracovaní požiadaviek i pri ich revízii a schvaľovaní, dôsledné dodržiavanie a sledovanie celého životného cyklu požiadaviek a riadenia zmien atď. Na projektoch takého charakteru väčšinou nikomu nenapadne ísť inou cestou ako dôslednou a precíznou správou na úrovni jednotlivých požiadaviek, čo je určite dobrá správa. 

Zlou správou je, že v dôsledku sústredenia sa na jednotlivé požiadavky často uniká celkový obraz. Jednotlivé požiadavky sú síce medzi sebou previazané, ale to nestačí. Nesmie chýbať ucelený výstup vymedzujúci (ako pozitívne, tak aj negatívne) úplný rozsah dodania, resp. jeho hranice či mantinely. Je jasné, že taký výstup nebude obsahovať úplný detail, ale to v úvodnej fáze projektu, v ktorej by taký popis mal vznikať, nie je potrebné. Voči tejto definícii sa potom posudzuje každá jednotlivá požiadavka, či má, alebo nemá byť (a prípadne, v akej podobe) súčasťou projektu.

Inými slovami: zatiaľ čo som v úvodnej časti seriálu spomenul, že pre zjednodušenie budem v tomto texte chápať pojem „požiadavka“ v jeho najširšom význame podľa BABOK Guide, na takto zložitých projektoch považujem takmer za nevyhnutné pozrieť sa na jednotlivé úrovne požiadaviek osobitne a zvážiť, ako sa k tej ktorej úrovni postaviť (inak budeme pracovať s business requirements, inak so stakeholder requirements, inak so solution a transformation requirements). 

Ako sa teda v takto komplexnej situácii postaviť k riadeniu požiadaviek? Popis vhodného prístupu by zabral nejeden samostatný článok a v zásade každá lepšia kniha o riadení požiadaviek sa touto problematike do detailov zaoberá. Skúsme sa teda zamerať iba na možnú systémovú podporu. 

Požiadavky

Pre samotné požiadavky platí to isté, čo sme spomínali pri predchádzajúcom variante. Kľúčovými heslami sú zdieľanie, sledovanie, správa verzií, schvaľovanie a hlavne modelovanie. Problém nastáva, keď potrebujeme vybrané výstupy z modelu nazdieľať, pripomienkovať a schvaľovať. Záleží na tom, v čom projektová zložitosť spočíva. Ak však ide naozaj o najkomplexnejšiu situáciu (projekt je zložitý nielen z pohľadu biznisových procesov, biznisových pravidiel a integrácie), nie som si istý, že nejaký jeden vhodný integrovaný nástroj existuje. Ako vyhovujúcu (nie však veľmi pohodlnú) kombináciu nástrojov možno využiť Enterprise Architect (EA) doplnený o Wiki. CASE nástroj poskytne silné nástroje pre tvorbu a údržbu previazaného modelu, Wiki už spomenuté publikovanie, zdieľanie a podporu pripomienkovania. Bohužiaľ, nejaký jednoduchý recept na integráciu obsahu EA na Wiki, čo viem, tak neexistuje. K dispozícii je síce množstvo rozšírení EA (pre integráciu s JIRA, pre export dokumentácie na Wiki alebo do HTML), ale každý má svoje úskalia a obmedzenia. 

Riadenie požiadaviek

Proces riadenia požiadaviek je v takto komplexnom variante úplne kľúčový. Nevhodne navrhnutý proces alebo nedostatočná starostlivosť pri jeho realizácii končia v každom prípade rovnako – stratou kontroly nad stavom projektu a neschopnosťou ho ďalej riadiť. Každý člen tímu je zodpovedný za svoju fázu spracovania požiadaviek a nevyhnutnou súčasťou tejto zodpovednosti je aj sledovanie stavu ním realizovanej aktivity. Z tohto dôvodu je nutné nasadiť nejaký silný task tracking systém (napr. JIRA), ten sprístupniť všetkým zainteresovaným stranám a všetkým vysvetliť ich úlohu v celom procese riadenia požiadaviek. Dôležitou súčasťou takto nastaveného procesu riadenia požiadaviek je previazanosť task tracking systému so systémom, ktorý sa používa na zaznamenávanie samotných požiadaviek. Čiže ak sa realizuje riadenie požiadaviek v task tracking systéme JIRA, mali by sme zabezpečiť previazanie na obsah konkrétnych požiadaviek, napríklad na Wiki.

Úplnou nevyhnutnosťou je jasná komunikačná matica s vyznačenými zainteresovanými osobami, ktoré sú oprávnené zadávať požiadavky. Vzhľadom na to, že takto rozsiahle projekty trvajú väčšinou pomerne dlhú dobu, je extrémne dôležité udržiavať túto maticu neustále aktuálnu. Predídeme tak situáciám, keď pre projekt doposiaľ neznáme zainteresované osoby začnú zadávať nové požiadavky alebo sa budú pokúšať už skôr odsúhlasený rozsah projektu predefinovať. S tým tiež súvisí nutnosť definície eskalačných mechanizmov – na veľkom projekte s mnohými zainteresovanými stranami je iba otázkou času, kedy narazíme na vzájomne si odporujúce požiadavky. 

Agilita

Ako sa postaviť k agilite v takto komplexnej situácii? Skúsenosť mi zatiaľ neukázala, že by bola silná agilita pre takéto prostredie vhodná a prinášala rýchlejšie a spoľahlivejšie kvalitné výsledky. Podľa mojich skúseností je pri takýchto projektoch kľúčové dobré a pomerne detailne špecifikované a odsúhlasené zadanie. Avšak časť aktivít zadávateľskej úlohy môžeme (rovnako ako v predchádzajúcom variante) v určitých prípadoch presunúť dovnútra dodávateľského tímu, čo významne uľahčí komunikáciu, a tým pádom aj umožní rozsiahlejšiu aplikáciu agilných metód a techník. 

Dobrou správou je, že sa v poslednej dobe začínajú objavovať prvé lastovičky integrovaných nástrojov, ktoré sa snažia výrazne pomôcť nielen s procesom definovania požiadaviek, ale aj s ich riadením (napr. Jama alebo blueprint). Primárna motivácia je totiž reagovať na neustály tlak agilných prístupov, ktoré v oblasti projektov realizovaných najväčšími korporáciami, tzv. enterprise sfére stále narážajú práve na zložitosť nielen organizačnú, ale aj projektovú. Navyše fakt, že doteraz v zásade neexistuje integrovaná systémová podpora, ktorá by všetko mohla sprehľadniť a zjednodušiť, zabehnutý (teda málo agilný) stav vecí skôr podporuje. Tieto nové nástroje tak v sebe integrujú na jednej strane pomerne sofistikované nástroje pre štruktúrované riadenie požiadaviek, poskytujú viac či menej bohaté prostriedky pre vyjadrenie samotného obsahu a v neposlednom rade často veľmi elegantne podporujú netriviálny proces pripomienkovacieho a schvaľovacieho riadenia. 

Efektívne a s rozumom – znižujeme riziko neúspechu projektu

Ako teda v praxi naplniť tézu, ktorú sľubuje nadpis tejto série článkov? Tu uvedené je skutočne iba usmernením, ktoré nemožno aplikovať dogmaticky za každých okolností. Tak ako vždy v projektovom riadení, aj tu platí, že zvolené postupy a nástroje budú významne ovplyvnené zrelosťou dodávateľskej a odberateľskej organizácie, a to nielen v oblasti projektového riadenia. Všeobecne sa dá asi povedať, že použitie o stupeň sofistikovanejšieho prístupu a nástrojov veľa nepokazí, ale je nevyhnutné vyvarovať sa použitia povestného „kanóna na vrabce“, lebo v tom momente často dôjde k zahlteniu zdrojov neproduktívnymi a nepotrebnými činnosťami a dramaticky rastie riziko neúspechu projektu.

Je potrebné si uvedomiť, že úspešne riadený rozsah projektu a požiadaviek, a teda úspešne dodaný projekt, nebude nikdy zásluhou zvolených nástrojov. Je to výsledok vhodne vyváženej kombinácie procesov, ľudí a skúseností, ktoré podporíme voľbou vhodnej metodiky a vhodných nástrojov.

Autor: Jan Pacovský