Vybíráme business analytika

Vzpomínám si na jeden přijímací pohovor na pozici business analytik, který jsem absolvoval. Zeptal jsem se, jaké předpoklady by měl splňovat kandidát na pozici, kterou hledají.

"Hledáme Supermana. Někoho, komu stačí ukázat, jak to ve firmě funguje a on je to schopen za krátkou dobu pochopit a vylepšit. Zkrátka někoho, komu když jednou ukážeme, jak točit pivo, tak za krátkou dobu bude nejlepším hostinským široko daleko."

Business analýza je především o schopnostech pochopit složité věci, naučit se mluvit jazykem dané business oblasti, proniknout pod povrch. Pokud zvládne analytik tohle, pak to stačí. Je k tomu potřeba přirozená zvídavost, schopnost rychle chápat, přemýšlet o souvislostech a důvodech. proč věci fungují tak, jak fungují a o tom, jak je lze vylepšit.

Vše ostatní se už dá naučit poměrně jednoduše.

Z PLR do MLR jel jsem přes ČSSR, SNB mé DKW si stoplo na TK...

Známá písnička Ivana Mládka plná zkratek z dob socialismu mi vždy připomene, že v rámci IT se také poměrně často bavíme ve zkratkách. Zrovna dnes, po jednom jednání, prohlásila kolegyně, že nerozuměla téměř ničemu.

A přitom jsme se bavili jen o zahájení jednoho projektu. PM vytvořil WBS a vypadá to na 800 MD. Takže business case vyjde, protože ve finále ušetříme 2 FTE. Analýza začně co nejdřív, pro UML diagramy použijeme EA. Testovací scénáře pro FAT a UAT budou dostupné v HPQC.  Projekt má dopady do DWH a CRM, což by mohl být problém. Na druhou stranu projekt je priorita pro jednoho manažera  B-1 a podporuje ho  i CEO, takže by vše mělo být hotovo v následujícím release...

Rozsah projektu

V tomto příspěvku bych se chtěl zmínit o jedné věci, která mi je důležitá nejen v rámci projektu, ale v zásadě při jakékoliv práci. Je to rozsah projektu (anglicky se označuje jako scope). Jde o určení hranic, co projekt řeší a co už neřeší.

Pro ilustraci jeden příběh ze začátku mé kariéry. Dostal jsem za úkol vytvořit analýzu systému, kam se budou zadávat požadavky na úpravu různých softwarových produktů. Původní myšlenka zněla tak, že zákazník telefonicky kontaktuje pracovníky podpory, sdělí jim svůj požadavek a ti ho zaevidují do zmíněného systému. Časem přibyl nápad, že by systém přímo přiděloval požadavky jednotlivým vývojářům. To by vyžadovalo evidenci dostupnosti jednotlivých vývojářů (dovolená, nemoc), jejich vytíženosti a náročnosti jednotlivých požadavků. Za nedlouho pak bylo jasné, že systém musí podporovat i vyhodnocování práce jednotlivých vývojářů. Také je třeba ošetřit předávání práce mezi jednotlivými vývojáři. A co když přijdou složitější požadavky, které budou vyžadovat zahájit samostatný projekt? Systém by s tím měl počítat a umožnit komplexní podporu řízení projektu ve všech jeho fázích... Zkrátka rozsah narůstal tak, že se úkol ukázal jako nesplnitelný, pokud by nedošlo k jasnému definování rozsahu projektu.

Definování rozsahu projektu není nijak složité. Je třeba vyjít z toho, co je cílem projektu, jaký problém projekt řeší. Pak je třeba vymezit, jaké oblasti projekt řeší. Stejně tak je třeba vymezit, co projekt neřeší. Definice rozsahu by měla být tak podrobná, aby byl analytik schopen určit, zda je nový požadavek v rozsahu projektu nebo je mimo rozsah projektu (out of scope).

Příklad: Vraťme se zpět k mému příběhu a ukažme si, co bylo třeba udělat. Nejdříve bylo třeba vyjasnit si cíl projektu. Základní problém, který projekt řešil, byla evidence drobných změn, které zákazníci navrhovali ale nikdo je nezaznamenal. Takový požadavek pak většinou zapadl a nebyl řešen. Oblastí, kterou by měl projekt řešit byla tedy pouze samotná evidence požadavků. Jejich přidělování vývojářům bylo, alespoň pro první fázi mimo rozsah projektu. Tím pádem je mimo rozsah projektu i evidence pracovní doby, předávání práce a její vyhodnocování.