Vždy mne potěší, když se nad články resp. příspěvky na tomto webu rozproudí diskuse a velice rád na ně také odpovídám. Proto mne potěšilo, když jsem po vydání předchozího článku s názvem O jedné časté a velmi nepříjemné chybě při zadávání prací analytikovi obdržel zajímavý mail s reakcí na tento článek. V tomto článku předkládám tento mail a následně mou odpověď i s příkladem.
Citace mailu
Dobrý den,
četl jsem Váš článek „O jedné časté a velmi nepříjemné chybě při zadávání prací analytikovi“ a dovolím si drobnou polemiku na téma sekundární a primární/prioritní zákazník. Spíše je to o mé interpretaci článku, nemyslím si, že jsme v jádru v rozporu.
Naprosto souhlasím s hlavní myšlenkou článku (tak jak jsem ji interpretoval já), tedy že analytik (ve smyslu jak roli analytika chápu já a jak ji chápeme u nás ve firmě, kdy u nás analytik plní současně roli „konzultanta“, tj. má blíže k businessu než implementaci/designu) má dva zákazníky – odběratele řešení a programátora.
Analytik je pro mě překladatelem z jazyka zákazníka=odběratele řešení do jazyka, kterým mluví zákazník=programátor a naopak. Odběratel nemluví řečí programátora (nerozumí ji), programátor nemluví řečí odběratele (nerozumí ji) (bavíme se principielně).
Analytik musí porozumět zadání odběratele, na základě tohoto zadání, svých zkušeností, znalostí systému a dané věcné problematiky s odběratelem diskutuje/domlouvá výsledné řešení. Výsledek této „diskuze“ je zdokumentován a tato dokumentace podléhá schvalování odběratelem – my ji nazýváme business principy řešení = je orientována businesově (tedy jazykem zákazníka=odběratele), aby tomu porozuměl. Současně toto zadání analytik „přepisuje“ do analytického zadání, kterému rozumí zákazník=programátor = u nás formou jazyka UML. U nás i toto analytické zadání podléhá schvalování odběratelem (i když je to občasným zdrojem „brblání“ odběratele, že tomu moc nerozumí a tedy nějakým zdrojem interních diskuzí o správnosti tohoto přístupu…). Odběratel zpravidla schvaluje business specifikaci současně s analytickou specifikací, při větších požadavcích se nejdříve „ladí“ business specifikace a až poté analytická specifikace.
Rozhodně platí, že obě „části“ návrhu řešení požadavku mají svoji váhu a dle mého názoru nelze říct, že je něco méně nebo více důležité. Pokud je nekvalitní business specifikace, odběratel nemusí business specifikaci analytika správně pochopit, může dojít při odsouhlasení k omylu a pak sebelepší analytická specifikace a tedy výsledná implementace může být „k ničemu“, protože zkrátka systém nedělá, to co odběratel chtěl a co si ve výsledku zaplatil.
Ale samozřejmě to platí i obráceně – sebelepší business specifikace je k „ničemu“ když je nekvalitní analytická specifikace. Prostě to musí být vyvážené a rozhodně obě strany – jak zákazník (odběratel) business specifikace, tak zákazník (programátor) analytické specifikace má právo (respektive správně „povinnost“) nekvalitní zadání odmítnout.
Pro každého tedy musí analytik vyhotovit kvalitní zadání, aby oba zákazníci pochopili, co se řeší. Co se týče toho, co je dřív, tak každopádně platí, že nejdřív musí analytik pochopit zadání – tj. vyjasnit si, co vlastně odběratel požaduje (a ideálně proč to požaduje). A dál to asi záleží na situaci (rozsahu požadavku, způsobu řízení projektu atp.).
No doufám, že jsem Vás svoji polemikou nenaštval a že jsem se vyjádřil srozumitelně – jen mě Váš článek přinutil k zamyšlení se.
Pěkný den!
D. H.
Takže nejprve k poslednímu odstavci, zda mne mail „nenaštval“. V žádném případě, naopak, jak jsem již uvedl v úvodu, vítám vždy diskusi s povděkem a rád reaguji na připomínky ze strany čtenářů mých stránek.
Poznámka: Pokud chcete, můžete také reagovat posláním svého názoru na mail objects@objects.cz.
Nyní k samotnému obsahu mailu.
Analytik by měl vstupovat do komunikace se zákazníkem (ještě lepší pojem než zákazník lze zvolit Product Owner – role ve SCRUMU) hned několikrát a vždy musí být přesný, korektní a vždy musí používat správné logické pojmy.
Vzhledem ke vzniku této diskuse upřesním přesněji a detailněji myšlenku, proč považuji za prioritní práci analytika jako zadání pro technology a programátory.
Analytik jako role v projektu je vývojář jako každý jiný. Z hlediska vývoje je jeho hlavním posláním odevzdat dokumenty na úrovni abstrakce IS, která se nazývá analytické modelování
Analytik by měl tvořit a odevzdávat na této úrovni abstrakce tyto dokumenty:
- Business Process Model
- Use Case Model
- Class Model
Navíc analytik pro komunikaci se zákazníkem používá také navíc i Instance Model. Důvodem je ta skutečnost, že pro laika je mnohem snazší pochopit pozici informace v IS na úrovni instancí (příklad evidence) než na úrovni tříd (meta-pravidlo pro tyto instance).
Poznámka: Je třeba ještě poznamenat, že součástí jeho prací je i tvorba a evidence funkčních požadavků (Requirement Model).
Podle procesní školy na počátku hovoří se zákazníkem ve smyslu „o co v podniku a v systému jde“: (Business Process Model), přitom současně eviduje funkční požadavky (Requirement Model), a tvoří model případů užití (Use Case Model). Při zpracování případů užití vzniká hned poté Class Model a při jeho znalosti vznikají další okruhy procesů a případů užití.
A nyní se dostáváme k meritu věci, v čem je jádro naší diskuse:
Pokud analytik tvoří tyto dokumenty tak říkajíc „správnými a přitom jednoduchými postupy“ a pokud přitom používá „metodicky správně CASE nástroj“, potom přímo z těchto dokumentů „vypadnou“ po velmi jednoduché úpravě dokumenty pro zákazníka. V tomto smyslu se analytické dokumenty pro vývoj jako zadání pro fázi technologie stávají velmi kvalitním zdrojem pro tvorbu tzv. business dokumentace pro zákazníka a v tom lze chápat prioritu vývojářské dokumentace.
V mnoha firmách tomu tak není: Dokumenty pro zákazníka se tvoří jakoby z „čisté vody“ a nikoliv jako dokumenty odvozené z tvorby analytické dokumentace. Pro objasnění této závislosti si uveďme příklad:
Nechť například analytik z rozhovorů a konzultací s Product Ownerem dospěl k následujícímu textovému popisu scénáře procesu Zpracování objednávky:
- Vystaví se objednávka.
- Následně se provede v účetním oddělení vystavení faktury a současně s tím proběhne ve skladu vyskladnění zboží.
- Následně se vyskladněné zboží a vystavená faktura sejdou při procesu kompletace zboží (balení). Pokud by jeden proces skončil dříve, musí počkat na druhý.
- Zboží se expeduje k zákazníkovi
Tomuto textu, který je součástí analytické dokumentace v počátečním stádiu projektu, určitě rozumí i zástupce zákazníka – tj. Product Owner. (Poznámka: Pokud by takovému textu nerozuměl, měl by být vyměněn 🙂 ).
Analytik tento text překlopí do roviny modelování pomocí UML (BPMN) a současně navrhne i případy užití (UCM). V tomto příkladu z předešlého textu by mohl model podle procesní školy vyhledávání případů užití vypadat například takto:
Obrázek 1 Ukázka BPM UCM modelu
Všimneme si, že tento obrázek přesně sedí s textovým popisem. Oproti předešlému textu je model doplněn o případy užití. Z pohledu laika se jedná o velmi srozumitelný zápis: „Když budete dělat to, co je vlevo, systém vám vypomůže funkcionalitou vpravo…“. Jinými slovy jedná se o chod činností podniku (chod procesů) s podporu informačním systémem (volání případů užití).
Poznámka: Tyto případy užití budou dále specifikovány „uvnitř“ podrobněji v další části dokumentace.
Abychom dovedli tento příklad až do úplné názornosti, pokračujeme v něm dále:
Diagram i texty vysvětlíme budoucímu uživateli a ten se například ozve s námitkou: „Objednávka by měla být nejprve odsouhlasena a pak teprve by se provedla fakturace a vyskladnění, to tam chybí!“ Vidíme, že nám tam schází jeden krok procesu (jeden tzv. Task) a jedna elipsa neboli Use Case s názvem „Odsouhlasení objednávky“ (poznámka: S dodatkem, že již v prvním kroku by mohla obsluha založit objednávku do stavu odsouhlasena, pokud je to třeba a má na to právo.).
Je třeba zdůraznit, že v procesní škole vyhledávání případů užití (uvedený příklad používá tuto procesní školu) vychází z této úvahy: Najděte činnosti okolo vašeho systému (tj. procesy podniku) takové, že je třeba použít systém (případy užití). Jinak řečeno analytik (ať chce nebo ne) musí najít správný kontext použití systému okolím, tedy musí navrhnout chod procesů, které tyto případy použití potřebují a právě tím vzniká základ neboli velmi kvalitní jádro budoucí dokumentace pro uživatele. Takže jak je vidět, z této ryze vývojářské dokumentace vzniká následně dokumentace pro uživatele ve smyslu: „toto budete dělat a takto vás přitom bude podporovat IS“.
To je opravdu nesporná obrovská výhoda procesní školy (BPM & UCM).
Samozřejmě nemůžeme dokumentaci pro zákazníka odevzdat pouze jako prosté diagramy bez textů a přitom předpokládat, že vše bude jasné (i když je třeba poznamenat, že předešlý diagram je velice názorný). Texty jsou velice důležité a diagramy víceméně ilustrují danou situaci.
V čem je problém mnohých firem, že to takto nefunguje? Analytik mnohdy netvoří dokumentaci tím „správným metodickým postupem“. Vznikají tak dokumenty „miš maš povahy“ bez fokusu na uvedené tři okruhy dokumentace (BPM, UCM a Class Model). Z toho důvodu dokumentace pro uživatele vzniká ad hoc jako další víceméně nezávislý okruh dokumentace, mnohdy s odlišnými skutečnostmi …
Na závěr je třeba v návaznosti na předešlou poznámku o nutné znalosti správných postupů vývoje IS zdůraznit ještě jednu důležitou okolnost: Nejenže každý vývojář by měl dobře znát metodické postupy, ale měl by také velmi dobře ovládat CASE nástroj přesně podle potřeb správných metodických postupů. Problém je v tom, že CASE nástroj umí opravdu spoustu věcí, které jsou určeny k mnoha různým účelům (což je výhodou), avšak vývojář by měl používat nástroj účelně ke svým potřebám a metodicky správně.
Konec článku