Keď sa projekt tvári, že má jasno
Na začiatku projektu býva veľa energie. Ľudia sedia na meetingu, hovoria o cieľoch, termínoch, riešení a často aj o tom, čo všetko „už je jasné“. Vznikne prvý zoznam požiadaviek, niekto pripraví prezentáciu, niekto otvorí backlog a tím má pocit, že discovery má za sebou.
Práve tu vzniká jeden z častých omylov. Discovery, teda objavovanie a pochopenie problému, nie je úvodná ceremónia pred skutočnou prácou. Je to spôsob premýšľania, ktorý musí biznis analytik držať počas celého projektu.
Ak sa predpoklady overia iba raz na začiatku, projekt môže veľmi rýchlo začať riešiť problém, ktorý už medzičasom neplatí, alebo nikdy nebol správne pochopený.
Ako to v projektoch často vyzerá
V mnohých tímoch sa discovery chápe ako prvá časť projektu. Najprv sa zistí, čo zákazník chce, potom sa to zapíše a potom sa už len dodáva. Na papieri to vyzerá čisto. V realite sa však menia priority, ľudia pochopia veci inak, pribudnú obmedzenia, objaví sa nový stakeholder a pôvodné predpoklady začnú praskať.
Predstavte si, že idete variť podľa receptu, ktorý ste si napísali pred rokom. Vtedy ste mali doma iné suroviny, čakali ste iných hostí a plánovali ste iný čas podávania. Ak dnes bez rozmýšľania otvoríte starý recept a začnete variť, možno navaríte správne podľa papiera, ale nesprávne pre dnešnú situáciu.
V IT projekte sa deje niečo podobné. Požiadavka môže byť zapísaná presne, no stále môže stáť na predpoklade, ktorý už neplatí. Úloha biznis analytika preto nekončí pri zápise požiadavky. Analytik musí priebežne sledovať, či dôvod za požiadavkou stále sedí.
Predpoklad nie je fakt
Veľká časť analytickej práce stojí na rozlišovaní medzi tým, čo vieme, čo si myslíme a čo si iba domýšľame.
Stakeholder povie, že používatelia potrebujú nové tlačidlo. Tím to môže zobrať ako požiadavku. Biznis analytik by sa však mal pýtať, čo tým chce používateľ dosiahnuť, kedy to potrebuje, komu to má pomôcť a podľa čoho spoznáme, že riešenie funguje.
Toto nie je zdržovanie. Je to ochrana projektu pred prácou, ktorá vyzerá užitočne iba na začiatku.
Predpoklady vznikajú prirodzene. Manažér predpokladá, že problém je v systéme. Používateľ predpokladá, že mu pomôže ďalšie pole vo formulári. Vývojár predpokladá, že popis v user story je úplný. Product Owner predpokladá, že priorita je jasná. Každý z týchto predpokladov môže byť rozumný, ale kým ho neoveríme, stále to nie je fakt.
BABOK opisuje biznis analýzu ako prácu s potrebami, zmenou a hodnotou. Z toho vyplýva aj postoj k discovery. Analytik nehľadá iba zoznam funkcií. Hľadá pochopenie, prečo má zmena vzniknúť a ako spoznáme, že priniesla hodnotu.
Prečo jednorazové discovery nestačí
Jednorazové discovery dáva falošný pocit istoty. Tím má dokument, diagram, zápis zo stretnutia alebo prvý backlog. Všetko pôsobí upratane. Problém sa ukáže až vtedy, keď vývoj prinesie prvý výsledok a používatelia povedia, že takto si to nepredstavovali.
Často nejde o zlý úmysel. Ľudia na začiatku projektu nevedia všetko. Niekedy si svoje potreby ujasnia až vtedy, keď vidia prvý návrh obrazovky. Inokedy pochopia dopad zmeny až pri testovaní. Niekedy sa zmení proces mimo projektu a pôvodná požiadavka prestane dávať zmysel.
Ak analytik berie discovery ako uzavretú fázu, tieto signály môže prehliadnuť. Ak ho berie ako priebežnú disciplínu, zachytí ich včas a pomôže tímu upraviť smer skôr, než sa minie veľa času.
Priebežné overovanie neznamená, že sa všetko donekonečna spochybňuje. Znamená to, že pri dôležitých rozhodnutiach sa tím vráti k otázkam: čo sa zmenilo, čo stále platí, čo sme sa naučili a ktorý predpoklad už nemôžeme brať ako istotu.
Čo z toho vyplýva pre IT biznis analytika
Začínajúci IT biznis analytik si často myslí, že jeho práca je hlavne pýtať sa na začiatku a potom písať požiadavky. V praxi je rovnako dôležité vracať sa k otvoreným bodom aj neskôr. Niekedy stačí krátka otázka na backlog refinement stretnutí. Niekedy treba overiť proces s používateľom. Niekedy treba porovnať, či metrika, ktorú tím sleduje, skutočne ukazuje zmenu správania, nie iba aktivitu v systéme.
Analytik by mal pri práci vedieť pomenovať, čo je fakt a čo je predpoklad.
Fakt môže byť napríklad existujúci legislatívny limit, schválený proces alebo dáta zo systému. Predpoklad môže byť tvrdenie, že používatelia budú nový formulár vypĺňať dobrovoľne, že manažéri budú report denne čítať alebo že kratší proces automaticky zníži počet chýb.
Takéto predpoklady treba overovať. Nie vždy veľkým výskumom. Niekedy pomôže rozhovor, prototyp, krátky test, kontrola dát alebo spätná väzba od človeka, ktorý bude riešenie používať. Podstatné je nezamieňať si ticho stakeholderov so súhlasom.
Praxou podložený pohľad bez prikrášľovania
V projektovej práci sa často ukáže, že najväčšie riziko nie je v technickom riešení, ale v neoverenej domnienke. Tím vie naprogramovať obrazovku, report aj automatické pravidlo. Otázka je, či tým rieši správny problém.
Ak stakeholder povie, že chce nový report, analytik sa môže pýtať, aké rozhodnutie má report pomôcť urobiť.
Ak používateľ chce ďalší schvaľovací krok, analytik môže overiť, či ide o kontrolu kvality alebo iba o strach prevziať zodpovednosť.
Ak tím pridáva akceptačné kritériá, mal by kontrolovať, či opisujú reálne prijatie riešenia, alebo iba technické správanie obrazovky.
Toto je práca, ktorá niekedy vyzerá nenápadne. No práve v nej sa oddeľuje zapisovateľ požiadaviek od analytika, ktorý chráni hodnotu zmeny.
Discovery pokračuje, kým sa učíme
Discovery sa nekončí tým, že vznikne prvý dokument. Pokračuje vždy, keď sa tím dozvie niečo nové o probléme, používateľovi, procese alebo dopade riešenia.
Pre človeka, ktorý uvažuje o kariére IT biznis analytika, je to dobrá správa. Nemusíte byť technický génius, aby ste mali v projekte hodnotu. Potrebujete sa naučiť klásť dobré otázky, rozlišovať fakty od predpokladov a pokojne overovať, či riešite správnu vec.
Ak sa chcete naučiť, ako IT biznis analytik premýšľa nad požiadavkami, stakeholdermi a hodnotou riešenia, pozrite si kurzy IT biznis analýzy v Springbut akadémii: academy.springbut.com.
Som Alena, IT biznis analýzu robím aj učím. Nezáväzne ma kontaktujte, nájdeme cestu pre vaše ambície v IT:
📩 info@springbut.com
📞 +421 905 255 360
🎓 academy.springbut.com
🌐 www.springbut.com
#ITBiznisAnalytik #ITKariéra #SpringbutAcademy
