Nedávno jsem se v jedné SW firmě v Čechách při školení zaměřené na analytické modelování v UML setkal s chybným postupem při zadávání prací analytikovi. Na tento problém jsem narazil již ve vícero firmách a protože jej považuji za dost závažný, pojednávám o něm zde ve formě článku.
Kdo je prvním zákazníkem analytika?
V rámci výkladu jsme ve zmíněné firmě dospěli do bodu pojednávajícím o správném rozdělení rolí na analytika, technologa a programátora. Toto nutné rozdělení rolí vyplývá přímo z povahy návrhu softwaru a z nutnosti dodržovat při dokumentaci tzv. úrovně abstrakce.
Tato problematika se jeví vcelku jasnou v teorii, ale problém nastává v praktickém nasazení tohoto doporučení. Jaké dokumenty má vlastně analytik odevzdávat?
Ve zmíněné firmě měli naštěstí funkci analytika již zavedenu (což je první nutný, nikoliv však dostačující krok k nasazení správných postupů modelování pomocí UML), takže jsem mohl navrhnout, abychom si přímo na místě prohlédli současný stav analytické dokumentace a posoudili jej z hlediska správných postupů návrhu IS. Nutno poznamenat, že dost velkou výhodou školení in-house ve firmě je právě možnost okamžité konzultace přímo nad dokumenty vývoje.
Jakmile jsem na promítacím plátně spatřil části analytické dokumentace, tak jsem věděl, že jako školitel konzultant mám problém „jak to říci“. Obrázky na plátně byly totiž graficky velice pěkné, určitě pracně vytvořené a vyžadovaly zajisté spoustu úsilí, ale byly tak říkajíc „mimo“…
Zeptal jsem proto programátorů, kteří byli také účastni školení: „Prosím vás, a jak se vám podle tohoto programuje?“ Odpověď zněla dost rozpačitě: „Dost blbě…“ (Přeloženo do normální řeči: „My podle tohoto neprogramujeme.“)
A v tom je jádro pudla. Podle principu dodržení úrovní abstrakce je základním posláním analytické dokumentace zadání do technologie a programování, čemuž se říká mapování analytických modelů do technologie. Tuto věc je třeba mít neustále při řízení prací v projektu na paměti… a bohužel toto se často opomíjí.
Zajímalo mne samozřejmě, jak tato sice hezká, ale pro programátory nepoužitelná dokumentace vlastně vznikla. Na přímou otázku jsem obdržel tuto přímou odpověď: „Takto to chce zákazník – odběratel systému.“
Dokumenty pro zákazníka – odběratele a zadání do technologie
Ano, jistě, odběratel je samozřejmě zákazníkem, který si mnohdy diktuje pravidla. Při tvorbě analytických modelů je však pro analytika sám odběratel systému paradoxně až „sekundárním zákazníkem“ a jeho „prioritními zákazníky“ jsou kolegové z technologie, kteří čekají na jeho zadání. Vždy je totiž třeba vytvořit kvalitní zadání do technologie a programování a teprve se zaměřit na tvorbu dokumentace, kterou chce vidět zákazník. Samozřejmě budoucí odběratel se podílí zásadním způsobem na obsahu tohoto zadání do technologie svými požadavky, konzultacemi a připomínkami.
Závěr
Fokus analytických prací musí být od základu zaměřen na vytvoření kvalitního zadání do technologie a realizace a teprve následně je třeba dodat dokumentaci podle požadavků zákazníka. Znamená to, že až teprve z analytické dokumentace, která má povahu zadání do technologie, se vytvoří „sekundární“ a „omašličkovaná“ dokumentace pro zákazníka a nikdy naopak.
Navíc platí, že do jaké míry je analytická dokumentace kvalitním zadáním do technologie a realizace, posuzují sami zástupci technologie a programování, dokonce mají v určitých případech právo nekvalitní analytické zadání odmítnout jako nevyhovující.