Prečo niektoré projekty, na ktorých ste v predchádzajúcich mesiacoch intenzívne pracovali, nedopadli úplne podľa vašich predstáv? Prvá časť trojdielneho seriálu, v ktorom sa dočítate, ako doviesť IT projekty úspešne do konca, pripravil Jan Pacovský, Managing Consultant Adastry. Dozviete sa, na čo si dať pri práci najväčší pozor z pohľadu riadenia požiadaviek.

Na internete a v odborných publikáciách nájdete veľa najrôznejších analýz a štatistík, ktoré spomínajú najčastejšie dôvody neúspechu IT projektov. Tie potom slúžia ako argumenty na podporu tej či onej metodiky životného cyklu dodania softvéru, ktorá má zvýšiť pravdepodobnosť úspechu. Iba málokedy sa ale pojednáva konkrétnejšie o recepte na riešenie najvážnejších príčin, na ktorých sa väčšina autorov prieskumu a štatistík až prekvapivo zhoduje: nekontrolovaný rozsah projektov (tzv. scope creep) a požiadavky všeobecne (ako z pohľadu ich obsahu, tak aj z hľadiska samotného procesu ich spracovania a súvisiaceho riadenia).

Nehľadajte „one-size-fits-all“ riešenie

Sedliacky rozum napovedá a skúsenosť ukazuje, že neexistuje jedno univerzálne riešenie pre všetky potreby. Čo môže byť pre jeden projekt oprávnene označované za „neriadené požiadavky“, môže byť v inej situácii na inom projekte úplne postačujúci prístup. Na projektoch sa však čím ďalej, tým častejšie a bez zohľadnenia kontextu hodiny a hodiny rieši, ako, či a čo budeme modelovať, aké nástroje sa použijú a aké ďalšie atribúty by sa aspoň teoreticky mohli hodiť do vybraného nástroja pre riadenie požiadaviek dokonfigurovať (práve preto, že sme sa o nich dočítali v nejakej knihe).

Definujte skutočné potreby

Nepopieram, že o uvedených veciach je potrebné diskutovať. Avšak na ich začiatku vnímam ako dôležitejší pragmatický pohľad na skutočné potreby, ktoré má proces správy požiadaviek v kontexte daného projektu plniť a ako to s najmenším úsilím dosiahnuť. Presťahovanie novej sedacej súpravy z predajne nábytku domov iste zvládneme s kamiónom pre diaľkovú prepravu – určite bude veľkosť a nosnosť stačiť. Otázkou ale zostáva, či by nám nestačila staršia dodávka alebo dokonca iba prívesný vozík za naším autom. Táto analógia je úsmevná, avšak nikto o vhodnom riešení nezapochybuje ani na moment. V realite IT projektov som sa ale opakovane stretol s pokusmi prepravovať jedálenský stôl kamiónom alebo, možno ešte horšie, prepravovať nadmerný náklad v dodávke. V prvom prípade to stojí „iba“ zbytočné úsilie (nielen) projektových zdrojov, v druhom prípade sa vám skôr či neskôr váš rozsah projektu rozsype pod rukami. Definujte teda skutočné potreby a nie možnosti a priania.

Zapojte requirement engineering

Táto disciplína sa zaoberá riadením a definovaním rozsahu projektu. Zjednodušene ide o zastrešujúci termín pre procesy získavania, tvorby a riadenia požiadaviek.

Hlavné ciele tejto disciplíny sú:

  • poskytnúť prostriedky pre riadenie rozsahu dodania projektu (scope) a ten mať v každom momente pod kontrolou hlavne vzhľadom na podporu a realizáciu riadenia zmien;
  • zabezpečiť jednotný pohľad na predmet dodania a jeho jednotné pochopenie všetkými zainteresovanými stranami;
  • poskytovať reálny obraz o stave realizácie;
  • zabezpečiť, že predmet dodania pokrýva skutočnú potrebu zákazníka.

Je zrejmé, že všetky aktivity smerujúce k zabezpečeniu vyššie uvedených cieľov sa zameriavajú na „postaranie sa“ o požiadavky. Pre zjednodušenie budem v tomto texte naďalej vnímať požiadavku v jej najširšom možno význame tak, ako ju definuje Business Analysis Body of Knowledge (BABOK) Guide. V tomto texte sa však nechcem ďalej zameriavať na spôsoby získavania a tvorby požiadaviek. Za dôležitejšie v kontexte riadenia rozsahu projektu považujem dve veci: samotnú požiadavku vrátane súvisiacich riadiacich atribútov a väzieb a tiež proces riadenia požiadaviek.

Všetky metodiky pristupujú k procesu rozdielne, čo sa týka docielenia popisu samotného obsahu požiadavky (teda toho, čo sa má dodať, zabezpečiť či vyvinúť). Od vodopádových prístupov „najskôr všetko zanalyzujeme a popíšeme a potom naprogramujeme“ až po silno agilné „poďme programovať priebežne, rovno na základe diskusie so zadávateľom“.

Obsah a detail: zamerajte sa na ne i pri agilnom prístupe

Nech zvolíme akýkoľvek postup, je potrebné, aby vždy (!) vznikol určitý popis toho, čo sa má dodať. Kameňom úrazu častejšie než uvedomenie si toho, že je potrebné mať požiadavky spísané a schválené zadávateľom, býva voľba výrazových prostriedkov (UML, BPMN, štruktúrovaný text a iné), použitých nástrojov a voľba správnej, teda dostačujúcej úrovne detailu. Na to neexistuje žiadna poučka. Vhodný prístup nezávisí len od zložitosti samotného systému, ale aj od prostredia, v ktorom vzniká a pre ktoré je určený. U najjednoduchšej aplikácie v známom prostredí stačí oveľa menej a oveľa menší detail popisu ako v prípade dodania komplexného silne integrovaného systému v medzinárodnom prostredí.

V neposlednom rade je však dôležité mať na pamäti skutočne celý životný cyklus dodania softvéru. Hoci programátori v rámci agilného prístupu možno nepotrebujú nijako špeciálne detailný popis toho, čo sa má vyvinúť, neznamená to, že taký popis nebude nevyhnutný pre potreby testovania či pre tvorbu dokumentácie. Podľa môjho názoru sa nedá zdrojový kód považovať za najlepšiu formu dokumentácie z mnohých dôvodov. Úroveň detailu popisu požiadavky, najvhodnejšie (ideálne) nástroje a výrazové prostriedky by sa teda mali líšiť podľa zložitosti dodania a prostredia.

Určte si metadáta požiadaviek

Riadiace atribúty (metadáta) sú rovnako dôležitou súčasťou požiadavky ako je samotný obsah. Determinujú (nielen) a umožňujú realizovať proces riadenia požiadaviek. Výrazové prostriedky a nástroje pre spracovanie obsahu požiadavky sú prediskutované v úvode každého projektu naozaj rozsiahlo. Na druhej strane, ako sa budú požiadavky riadiť (proces), aké ďalšie atribúty kvôli tomu musíme bezpodmienečne sledovať, aký bude životný cyklus požiadavky a ktoré jej fázy je vhodné sledovať, o tom sa až tak často nediskutuje. 

Zaveďte rolu hlavného analytika

Niet sa ani čomu príliš čudovať. Prevažná väčšina analytikov zvláda veľmi dobre „analytické remeslo“ a v tomto smere sa intenzívne ďalej vzdeláva. Poznajú UML, BPMN, vedia sa vyjadrovať veľmi presne pomocou písaného textu, vedia viesť rozhovor, poznajú najrôznejšie metódy zberu požiadaviek atď. Inými slovami, zdokonaľujú svoju profesionalitu smerom k obsahu požiadavky, ako ju získať a precízne spracovať. Avšak iba tí skúsenejší analytici vnímajú a chápu svoj významný podiel zodpovednosti na samotnom procese riadenia požiadaviek, ku ktorým nevyhnutne potrebujú určitú sadu riadiacich metadát. Inak povedané, rola analytikov (teda hlavných analytikov či podobných pozícií) je v oblasti riadenia rozsahu projektu úplne kľúčová. Navyše rovnako ako v prípade obsahu požiadaviek nie je ani v tomto prípade príliš veľa poučiek, ako požiadavky efektívne riadiť, keďže rovnako aj tu je silná závislosť na zložitosti riešenia a prostredia, pre ktoré vzniká. Rýchlo dostupné rady sú poskytované väčšinou s minimálnym kontextom, a tak je tu veľké riziko implementácie prístupov, ktoré v danej situácii veci veľmi neprospejú (spomeňme si na analógiu so sťahovaním spomenutú v úvode). Správna voľba tak v drvivej väčšine prípadov závisí od skúseností realizačného tímu a schopnosti tieto skúsenosti správne aplikovať v danej situácii.

Určte zodpovednosť za riadenie požiadaviek

Často zostáva zodpovednosť za nastavenie procesov riadenia požiadaviek (a teda riadenia rozsahu projektu) iba na projektovom manažérovi. Ten má predsa rozsah projektu ako jeden z bodov trojimperatívu projektového riadenia či nie? Som presvedčený, že samotný projektový manažér (bez silnej podpory analytickej roly) môže iba zriedka úspešne uriadiť rozsah projektu. Dôvody sú dva:

  1. Schopnosť obsiahnuť kompletnú biznis problematiku dodania a všetky previazanosti navrhovaného riešenia je u projektového manažéra obmedzená (často nie kvôli schopnostiam, ale skôr kvôli kapacitným možnostiam, ak odhliadneme od faktu, že to k role projektového manažéra tak úplne nepatrí).
  2. Čím komplexnejšie je nastavený proces riadenia požiadaviek, tým viac zdrojov je potrebných na jeho údržbu a prevádzku, a dramaticky rastie nutnosť aktívneho zapojenia väčšiny participujúcich rol.

Ako bolo povedané v úvode, recept „one-size-fits-all“ na riešenie problematiky riadenia rozsahu projektov neexistuje. Vždy záleží na okolnostiach, prostredí, povahe projektu a skúsenostiach kľúčových členov realizačného tímu. Nejde, samozrejme, o veľký objav a hlavne nám to neposkytuje žiadne konkrétnejšie usmernenie, ktorým sa pri nastavovaní podpory pre riadenie rozsahu projektu môžeme riadiť. V nasledujúcich častiach tohto seriálu sa pokúsim zovšeobecniť svoje skúsenosti z reálnych projektov a sformulovať ich do jednoduchého modelu, ktorý by vám mohol pomôcť pri štarte projektu a nastavovaní procesov okolo požiadaviek.

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, 3/2017 alebo na systemonline.cz