Realizace analytické schůzky

Realizace analytické schůzky je poměrně složitá věc, ačkoliv se to nemusí na první pohled zdát. Na úvod několik rad:

1. Je třeba mít předem jasně vymezeno, co je předmětem řešení a co už není předmětem řešení není. 

Na jednom ze svých prvních projektů jsem dostal za úkol provést sběr požadavků pro relativně jednoduchý informační systém evidující požadavky na servisní podporu. Jeden z manažerů mi pak nastínil rozsah řešení, jak ho chápe on: požadavky na servisní podporu v důsledku vytěžují programátory, analytiky a testery. Je třeba, aby systém umožňoval automatické přidělování úkolů těmto pracovníkům, evidoval disponibilní čas pracovníků (včetně plánovaných dovolených ), podporoval schvalovací proces (akceptování přidělení úkolu nadřízeným pracovníka, akceptování vytvořeného řešení), sledoval odpracovaný čas a výkonnost jednotlivých zaměstnanců, sledoval náklady na zpracování jednotlivých požadavků, uměl poskytovat reporty. Z malého systému se tak stal komplexní informační systém pro řízení celé firmy.  Přitom jsem měl na analýzu pouhých 20 MD (mandays - člověkodny). 

Zásadní problém byl, že jsem si nejprve jednoznačně se zadavatelem nevymezil rozsah řešení. Všechno sice souvisí se vším, nicméně není třeba vyřešit všechno v rámci daného projektu.

2. Je třeba se zaměřit na to co je požadováno a ne na konkrétní implementační detaily.

Budoucí uživatel systému má konkrétní představu o řešení. Snaží se analytikovi pomoct a přijít hned s řešením, které ale nemusí být vždy správné. Většinou se jedná o poměrně detailní  řešení typu "na obrazovku 547 Detail účtu je potřeba dolů přidat pole Typ smlouvy". Dobrý analytik by nejprve měl zjistit, co uživatel opravdu potřebuje a proč to potřebuje. Nakonec se může ukázat, že uživatel vlastně potřebuje něco úplně jiného...

3. Netrvejte za každou cenu na svém. 

Po několika prvních schůzkách má business analytik obvykle již jistou představu, co zákazník požaduje. Někdy ovšem  může být tato představa mylná a zákazník požaduje něco trochu jiného.  Buďte flexibilní a netrvejte za každou cenu na svém, naslouchejte zákazníkovi. Mohlo by se zdát, že rada 3 je v přímém rozporu s radou 2, ale není tomu tak.

4. Rozlišujte požadavky, které informační systém musí nezbytně splnit (must have) a které jsou navíc (nice to have).

Některé požadavky jsou nezbytně nutné - anglicky "must have" (například systém bude generovat fakturu), některé nezbytně nutné nejsou (systém bude zasílat zákazníkovi email o dostupnosti zboží), ty lze označit jako "nice to have". Rozlišujte tyto dva typy požadavků. Až zákazník zjistí, kolik bude výsledný systém stát a jak dlouho bude trvat vývoj, možná se vzdá realizace části požadavků "nice to have", případně budou tyto požadavky přesunuty do další verze.

5. Nerozšiřujte zbytečně rozsah požadavků.

Analytika občas napadne, že by bylo dobré, kdyby systém kromě toho, co zadavatel požadoval, uměl ještě něco navíc. A dá se to v podstatě zahrnout pod některý z požadavků zadavatele, tak proč to nezahrnout... Tímto způsobem dojde k narůstání požadavků a zvyšování pracnosti a tedy i doby realizace a ve výsledku ceny systému. Důležité je samozřejmě to slovo "zbytečně". Pokud analytika napadne něco, co zákazník nechtěl, ale zákazník je z nápadu nadšený a požadavek si vezme za vlastní, tak proč ne. Slovem "zbytečně" jsem měl na mysli požadavky u kterých se po nasazení systému zjistí, že je zákazník vlastně ani nepotřebuje.

6. Dávejte pozor na to, co prezentujete a komu. 

Jedna velká finanční instituce najala na analýzu proveditelnosti konzultační firmu. Jednalo se o náhradu zastaralého informačního systému. Tento systém se v dané firmě používal přes 20 let. Systém byl udržovaný a rozšiřovaný týmem postarších vývojářů z nichž někteří se systému věnovali od samého začátku. Na první schůzku si konzultanti připravili prezentaci v PowerPointu a hned první snímek obsahoval obrázek rakve a text "Systém XYZ končí!". Důsledkem bylo, že na základě této prezentace ukončilo několik vývojářů z daného týmu okamžitě pracovní poměr, protože se jich prezentace osobně dotkla. Úsměvná historka. Nicméně daný systém byl nahrazen až za několik let a po tu dobu by se těch několik vývojářů dané firmě hodilo.