Každý, kdo uvažuje o práci business analytika, se při zvažování nové práce sám sebe zeptá, co že to vlastně dělá ten business analytik. Letmým pohledem do inzerátů na Internetu je možné celkem jasně zjistit, že je potřeba být komunikativní, ovládat UML, nějaké ty CASE nástroje, že se to asi bude týkat psaní dokumentace, a …. a dál je to pokaždé jiné, tak nějak v mlze – a je těžké přesně odhadnout, co po vás tedy vlastně budou chtít. Jako by vlastně nešlo přesně napsat, co onou náplní ve finále bude.
Z vlastní zkušenosti mohu potvrdit, že je to opravdu tak :-)
Rozsah práce business analytika je velmi široký, práce je poměrně náročná na mozkovou kapacitu a nároky na znalosti nejsou nejmenší, je ale velmi zajímavá – a dává možnost být u vzniku software prakticky od píky.
Ideální je, pokud je ve firmě pozice business analytika pevně zakotvená ve vývojovém teamu – pak se podílí prakticky na všech fázích vývoje:
Ve počáteční – iniciační – fázi analytik pomáhá identifikovat, v čem je problém. Zjišťuje, co organizaci, pro kterou pracuje, pálí. Z toho vychází návrhy na možná řešení. V této fázi je byznys analytik při ruce konzultantovi či projektovému manažerovi (případně oběma) a aktivně pomáhá s tvorbou nabídky. PM zpravidla požaduje odhady na analýzu (buď v hodinách, častěji ale v MD – Man-days, česky člověkodnech).
Klient vybere jednu z nabízených variant, nebo nevybere žádnou (buď více řešení problému není, nebo jsme zbabrali nabídku), případně jím preferovanou variantu třeba ještě upraví. Projektoví manažeři si s úsměvem vymění informace o zcela jistě zvládnutelných termínech na analýzu a vývoj, a pro analytika začíná boj. Boj s časem, vlastníky různých systémů, s často ne zcela srozumitelnou nebo nekompletní stávající dokumentací, a někdy i se sebou samotným.
Fáze analýzy je zcela klíčovou fází, ve které analytik sbírá detailní informace jednak o požadavcích klienta na nový systém, resp. na požadované úpravy toho stávajícího, a zároveň se snaží získat maximum informací o systémech, se kterými bude třeba komunikovat, získávat z nich data, nebo do nich data dodávat.
Výstupy analytika obsahují prakticky vždy tzv Requirement Specification Document – specifikaci požadavků na systém. K čemu slouží? Předně, obsahuje všechny požadavky klienta na systém – definuje rozsah projektu (často se používá anglický výraz „scope“). To, co je zde popsáno, musí být uděláno, aby byl projekt z pohledu klienta hotov. V praxi se toho ale musí udělat daleko více – design obrazovek, jejich posloupnost jsou zpravidla popsány v dalším dokumentu, často se také vytváří tzv. případy užití (USE CASES), analytik se také málokdy vyhne popisu komunikace s jinými systémy – Interface specification je tak dalším z dokumentů, do nichž analytik vloží v průběhu prací svou duši.
Když je hotovo, je třeba specifikaci schválit. Procesy se různí, někteří klienti mají kvalitní lidské zdroje, a specifikaci velmi podrobně pročtou a připomínkují. Tyto postupy a procesy si zpravidla nastavují projektoví manažeři a měly by být upraveny také ve smlouvě. Po schválení dokumentace j čas na vývoj…
… a ve vývojové fázi si analytik také moc neodpočine. Ve chvíli, kdy se specifikace zmocní vývojáři, je analytikova dokumentace podrobena další zatěžkávací zkoušce. Vývojáři se na „jejich“ BA obracejí buď sami, nebo jsou nastaveny pravidelné (ideálně s velmi malou periodou) konzultační schůzky. Pro každý projekt se hodí jiná intenzita komunikace, každopádně jí ale prakticky vždy je dostatek. Analytik rozhodně jen nedoplňuje dokumentaci o to, co mu „vypadlo“ při její tvorbě – někdy je třeba svolávat další analytické schůzky, analytik je de facto koordinuje ve snaze získat informace od všech zúčastněných stran, a upravuje svou dokumentaci. Pokud jsou na schůzkách sjednány změny zadání, analytik je zpracovává do dokumentace.
Vývojáři po čase s hrdostí v hlase oznámí, že je aplikace připravená k testu. Testování je momentem, kdy si konečně analytik může trochu oddechnout. Na základě jeho dokumentací a specifikací jsou buď testerem, nebo test analytikem vytvářeny testovací scénáře, a podle nich se poté aplikace testuje. Podle počtu členů vývojového teamu může testovací scénáře také někdy zpracovávat analytik. Také někdy může testovat – a to se také poměrně často děje.
Následné testování u klienta je následně opět momentem, kdy čeká na analytika výrazně více komunikace – klient přebral software k testu a jeho testeři (ať to jsou testeři najatí jen za účelem nalezení chyb v novém software, nebo jiní zástupci klienta) nacházejí chyby. A také „chyby“ – velmi často se totiž stává, že i když byly sepsány stovky stran dokumentace, až po naprogramování se zjistí, že některé funkcionality byly myšleny, ehm… trochu jinak. Na analytika se valí dotazy, proč která či oná část aplikace má takovou a takovou funkci, a také se na něj s žádostí o rozhřešení obrací projektoví manažeři. Jejich cílem je za každou změnu, která nebyla požadována a schválena ve specifikaci, dostat zaplaceno. Bezbožným přáním řady klientů je naopak neplatit za další úpravy nic. Analytik tak musí bránit sebe, své specifikace, potažmo svého zaměstnavatele. V tomto minovém poli pak musí s bezchybným poker-face argumentovat, vyjednávat, analyzovat, a nacházet řešení…
Jednoho dne je pak aplikace hotová, u zákazníka se vymění management, nebo ten stávající prudce trhne kormidlem, a je třeba provést řadu změn v informačních systémech a aplikacích. A kolotoč se roztáčí znovu… :)
—
A ještě malé doplnění – pro lepší představu, jak vše v IT projektech probíhá :-)
