Projekt mal trvať štyri mesiace
Na kick-off mítingu bolo všetko jasné. Rozsah, termín, rozpočet. Vedúci projektu ukázal harmonogram a povedal: nasadenie je naplánované na október.
Nasadzovalo sa v marci nasledujúceho roka. Ak by ste sa spýtali tímu, čo sa stalo, každý by mal iné vysvetlenie. Zákazník zmenil priority. Pribudli bezpečnostné požiadavky. Vedenie chcelo pridať jedno rozhranie navyše. Každá zmena znela rozumne. Spolu znamenali päť mesiacov sklzu a podstatne vyšší rozpočet.
Toto nie je výnimočný príbeh. Je to príbeh väčšiny IT projektov. A dôvod nie je zlý tím ani nekompetentný zákazník. Dôvod sa volá scope creep, teda plíživé rozširovanie rozsahu, a patrí k najčastejším príčinám oneskorení v IT.
Čo je scope creep a prečo ho nikto nevidí
Scope creep nastáva postupne a nenápadne. Nie naraz. Nie dramaticky. Ale každý týždeň trochu.
Jeden stakeholder povie: mohli by sme pridať aj export do PDF? Druhý chce notifikáciu e-mailom. Tretí navrhuje, aby systém pamätal históriu zmien za posledné tri roky. Štvrtý zistí, že by sa to dalo prepojiť so systémom, ktorý mám vedľa. Každá požiadavka znie ako detail. Spolu tvoria niekoľko týždňov práce navyše, o ktorých nikto neviedol evidenciu.
Problém nie je, že sa objavujú nové požiadavky. Problém je, že ich nikto neregistruje ako zmenu rozsahu. Pridávajú sa potichu, bez posúdenia dopadu na čas, peniaze a iné priority. Tím pracuje na veciach, ktoré neboli v pôvodnom pláne, ale nikto o tom oficiálne nerozhodol.
Zmena nie je nepriateľ. Tichá zmena áno.
Dôležité je jedno rozlíšenie: zmena požiadaviek počas projektu nie je automaticky problém. Je to realita. Biznis sa vyvíja. Vedenie sa dozvie nové informácie. Zákazník vidí prvé ukážky a uvedomí si, čo vlastne potreboval. To, čo platilo v januári, nemusí byť správne riešenie v júni.
Analytik pracujúci podľa agilných princípov s týmto počíta. Projekt nie je zákon. Je to živý dokument, ktorý sa prispôsobuje realite. Zmena požiadaviek je v agilnom prostredí súčasťou procesu, nie jeho narušením.
Ale aj v agilnom prostredí platí jedno pravidlo: zmena musí byť vedomá. Tím musí vedieť, čo sa mení, prečo a čo si to vyžiada. To je rozdiel medzi riadenou zmenou, kde tím prijme rozhodnutie a zohľadní dôsledky, a nekontrolovaným rastom, kde projekt pomaly prehráva zápas s realitou bez toho, aby to niekto pomenoval.
Ako IT biznis analytik drží projekt pri uzde
Biznis analytik pri riadení zmien plní úlohu, ktorú by som prirovnala k stavebnému dozoru. Stavebný dozor nevyberie, aký dom sa postaví. Nehovorí zákazníkovi, čo môže a čo nesmie chcieť. Ale sleduje, či to, čo sa stavia, sedí na výkresoch a či každá zmena, ktorú zákazník navrhne, je zahrnutá do projektu so všetkými dôsledkami.
V IT projekte to znamená evidovať všetky požiadavky a dokumentovať každú zmenu. Na každú zmenu sa opýtať: čo to znamená pre termín? Čo to znamená pre rozpočet? Čo z doterajšieho rozsahu sa prípadne odloží, aby sme mohli toto zaradiť?
Nie je to o tom byť brzdou alebo kontrolórom. Je to o tom, aby tím a zákazník mali v každom okamihu spoločné pochopenie toho, kde projekt je a kam smeruje. A to pochopenie sa bez aktívnej správy zmien rýchlo stráca.
Príbeh zmeny, ktorá zachránila projekt
Na jednom projekte prišla v polovici vývoja požiadavka na nové rozhranie s externým systémom partnerského makléra. Zákazník to prezentoval ako malú vec. Tím odhadol, že to bude šesť týždňov práce navyše.
Namiesto tichého zaradenia zmeny do fronty sme urobili analýzu dopadu. Ukázalo sa, že šesť týždňov navyše ohrozuje termín nasadenia, ktorý bol zmluvne viazaný na koniec kvartálu. Zákazník si mohol vybrať: buď nasadenie v termíne bez tohto rozhrania, alebo posun termínu s ním.
Vybral si nasadenie v termíne. Rozhranie prišlo v druhej verzii systému. Projekt skončil včas, v medziach rozpočtu a zákazník vedel presne, prečo a čo to znamenalo pre jeho plány. Táto transparentnosť bola možná len preto, že sme zmenu zachytili, analyzovali a priniesli rozhodnutie zákazníkovi, namiesto toho aby sme ho zanedbali.
Keď zmeny prichádzajú z vonku: externé faktory, ktoré projekt zmenia
Nie každá zmena pochádza od zákazníka alebo od tímu. Niektoré zmeny prichádzajú zvonku. Legislatíva sa zmení a projekt musí splniť nové požiadavky na ochranu dát. Regulátor vydá nové usmernenie. Partner, s ktorým sa integrácia plánovala, zmení svoje API. Tím sa dozvie, že platforma, na ktorej sa stavia, mení licenčné podmienky.
Tieto externé faktory sú súčasťou každého dostatočne dlhého projektu. Analytik, ktorý sleduje prostredie, v ktorom projekt existuje, dokáže odhaliť tieto riziká skôr a pomôcť tímu reagovať proaktívne. Nie každú zmenu sa dá predvídať, ale mnohé sa dajú zachytiť skôr, ako sa stali problémom.
