Jak se stát analytikem

 Cesta, jak se stát analytikem je dlouhá a náročná. Analytik musí mít kombinaci tzv. hard skills a soft skills. Hard skills jsou znalosti mezi které patří:

• Přehled v oblasti software engineeringu. Tj. analytik musí vědět, jakým způsobem se vyvíjí software.
• Přehled v doménové oblasti. Pokud se projekt týká systému pro likvidaci pojistných událostí, měl by mít znalost pojišťovnictví.
• Specifické znalosti v oblasti analýzy. Jde o schopnost používat vybraný case nástroj pro modelování (například Sparx Enterprise Architect), měl by rozumět k čemu se jednotlivé modely používají (znalost UML). 

Hard skills ale nestačí. Pro analytika je velmi důležité mít sadu tzv. soft skills. Jde o vlastnosti, které mu umožní efektivně komunikovat se stakeholdery a dostat se rychle k informacím, které analytik potřebuje ke svojí práci. 

Příkladem je například situace, kdy stakeholder popisuje svůj požadavek například následujícími slovy: "Některé přijaté dokumenty potřebujeme mít možnost v určitém stavu vymazat."

Analytika by měla hned napadnout sada otázek:

• Proč je daná funkcionalita potřeba? Co přesně tato funkcionalita řeší?
• Kdy konkrétně lze dokument vymazat? V jakých stavech lze dokument vymazat a v jakých stavech to už není možné?
• Jaké dokumenty lze vymazat a jaké vymazat nelze?
• Co přesně znamená "vymazat"? Zrušit přiřazení dokumentu k danému případu? Nastavit na dokumentu příznak smazaný? Změnit stav dokumentu? Odstranit obsah dokumentu z databáze?
• Potřebuje někdo informaci, které dokumenty byly vymazány kým a kdy?
• Kdo může danou operaci provést? Za jakých podmínek (např. lze smazat dokumenty jen v určitém stavu apod.).
• Jaké má smazání dokumentu další dopady do systému? Nemění se například vlivem vymazání přijatého dokumentu stav případu?

Hard skills lze získat relativně snadno. Soft skills lze trénovat, ale jejich osvojení je otázkou delšího času a praxe.

Analýza v mezinárodní firmě

Nedávno jsem změnil projekt a přešel z velké nadnárodní společnosti do "české" banky. Tedy ona ta banka je spíš rakouská, i když v názvu má , že je "česká". Pokud se ale týká prostředí, tak komunikačním jazykem je čeština, schůzky jsou v češtině, analýza se píše v češtině a kolegové jsou Češi a Slováci.

Na předchozím projektu bylo prostředí skutečně mezinárodní. To znamená projekty pro celou Evropu, kolegové z různých zemí a komunikace téměr výhradně v angličtině (schůzky, analýza, prezentace, veškerá dokumentace). Dokonce i emaily mezi kolegy, kteří jsou Češi jsme psali v angličtině. Důvod je ten, že pokud je potřeba email přeposlat, pak se není třeba zdržovat překladem.

Mezinárodní prostředí má samozřejmě dopad i do analýzy. U českého kolegy vývojáře se dá předpokládat, že pokud dostane zadání, že se číslo českého účtu má validovat (modulo 11), tak si s tím zřejmě poradí. Pokud potřebujete validovat maďarský účet a vývojář je třeba z Kazachstánu, tak je to třeba specifikovat mnohem podrobněji a popsat jaké části má maďarský národní formát účtu a jak přesně toto číslo účtu validovat.

Výhodou mezinárodního prostředí je, že se naučíte skutečně používat angličtinu. Tím myslím pohotově reagovat a být schopni bez přípravy úplně automaticky prezentovat své nápady. Z hlediska použití cizího jazyka je mezinárodní prostředí super. Jazykové vzdělávání, kde se konverzaci v cizím jazyce věnujete 1 hodinu týdně je super, ale mezinárodní prostředí znamená, že v angličtině fungujete 40 hodin týdně a to od nástupu na projekt až po finální rozloučení.  A to je hodně intezivní jazykové vzdělávání... Za mě jedna z největších výhod mezinárodní firmy. 

Bohužel takových projektů je poměrně málo. České softwarové firmy chtějí pracovat pro zahraniční zákazníky zejména v západní Evropě. Platit svým lidem českou sazbu a fakturovat za jejich práci německé firmě německou sazbu by bylo super. Ale pokud vím, tak se to moc nedaří. Takže příležitostí účastnit se mezinárodního projektu je málo. 

Přepisujeme starou aplikaci - jak na to?

Máme existující aplikaci, který z technologických důvodů již nevyhovuje. Důvodem může být například nepodporovaná technologie na front endu, nebo nevyhovující uživatelské rozhraní. Cílem je tedy víceméně přepsat aplikaci 1:1. Zdrojové kódy původní aplikace jsou k dispozici, aplikace je plně funkční. Co chybí je analýza této aplikace, nebo jakákoliv jiná dokumentace. 

Co s tím? Jaký je správný postup analýzy? Začít popisovat uživatelské rozhraní jednotlivých obrazovek? Provést kompletní analýzu uživatelských požadavků a začít navrhovat jednotlivé obrazovky znovu od začátku? Nebo to vůbec není práce pro analytika a za předpokladu, že nejsou žádné změnové požadavky, není analytik vůbec potřeba?

Přepisu stávající aplikace jsem se zúčastnil už 2x. Pokaždé s kompletní analýzou uživatelských požadavků. Existující obrazovky byly použity víceméně jen pro inspiraci a kontrolu, zda se na nic nezapomnělo. Je jasné, že to není nejlevnější postup. Fakt, že aplikace již existuje, nehraje příliš podstatnou roli, zákazník platí kompletní analýzu. Výhodou je, že se nová aplikace může být podstatně lepší než původní aplikace. 

Nyní se účastním projektu, kde byl zvolen postup reverzní analýzy 1:1. To znamená, že analytici popisují existující obrazovky, u kterých se mění design (obsah zůstává) a snaží se popsat funkcionalitu na základě zkoušení, jak funguje stará aplikace a na základě toho, co najdou v kódu. Cílem je ve výsledku dostat stejnou aplikaci, ale realizovanou prostřednictvím novější technologie. Nevýhody tohoto postupu jsou následující:

• Minimální kontakt s uživateli a jejich požadavky. Požadavky se v daném případě nezjišťují a pracuje se víceméně s předpokladem, že uživatelé chtějí to samé, co mají k dispozici nyní, jen je to třeba dodat pomocí novější technologie a s hezčím designem. 
• Pokud původní obrazovka nevyhovovala, nic se nezmění, protože nová obrazovka bude hezčí, možná o něco přehlednější, ale z hlediska obsahu a funkcionality stejná, jako ta v původní aplikaci. 
• Pro většinu analytiků je to nezajímavá a nepříliš kreativní práce.

Jednoznačná specifikace požadavku

Dnes jsem dostal k revizi analýzu, která se týkala zavedení kontrol importovaných dat do informačního systému. Data se do systému importují pomocí csv souborů. Tato data mohou být z různých důvodů chybná a je třeba je zkontrolovat.

Jedna z kontrol byla v analýze popsána následovně: 

Nejmladší hodnotu datumu platnosti v databázi  porovnej s importovanou hodnotou datumu platnosti.

Otázka je, co je to nejmladší hodnota:

• Poslední vložená hodnota.
• Poslední aktualizovaná hodnota.
• Nejmenší hodnota datumu platnosti.

Specifikace požadavku by měla být jednoznačná. 

Cenové modely při vývoji software

Dva základní cenové modely při vývoji software jsou Fix Time Fix Price a Time and Material.

Fix Time Fix Price

Fix Time Fix Price představuje nacenění projektu jako celku na základě definovaného rozsahu a data dodávky. Riziko překročení rozpočtu je na straně dodavatele. Ve stavebnictví se tomuto modelu říká dodávka "na klíč". 

Předpokladem je, že zadavatel má jasno, co chce dodat. S dodavatelem se dohodne na fixním termínu dodání a fixní ceně.  Dodavatel přebírá veškerá rizika - pokud je projekt náročnější než předpokládal a nacenil, je to problém dodavatele, protože termín dodání i cena jsou zafixovány. 

Pro zadavatele je výhodou, že ví co, kdy a za jakou cenu dostane. Nevýhodou je zafixovaný rozsah projektu. Pokud zadavatel zjistí, že část zadání už nepotřebuje a nebo naopak potřebuje něco jiného, je to jeho problém. 

Time and Material

Time and Material (bodyshop) je fakturace na základě skutečně odvedené práce na projektových úkolech. Zafixovaná je cena práce za jednotku času (obvykle MD  -  man day).  Jak budou odpracované hodiny využity je záležitostí zadavatele. Z organizačního pohledu může jít o dodávku celého vývojového týmu, nebo o dodávku jednotlivých pracovníků. Tyto pracovníci mohou být fyzicky přítomni na pracovišti zadavatele.

V nejjednodušší podobě to tedy může vypadat následovně: Banka XY potřebuje analytika na projekt ABC. Firma Bodyshop s.r.o. ho na trhu najde, uzavře s ním smlouvu a prodá ho do banky. Analytik dochází do banky XY, kde pracuje na základě pokynů pracovníků banky XY a odpracované hodiny vykazuje firmě Bodyshop s.r.o., která je následně fakturuje bance XY. Analytik je placen firmou XY, se kterou ale nemá mnoho společného.

Jak vidíte, tato činnost je pro firmu Bodyshop s.r.o. prakticky bez jakýchkoliv rizik. Banka díky tomu získá pracovní sílu po dobu projektu. 

Migrace

Migrace je častým úkolem, který je třeba v IT řešit a to v případech, kdy nahrazujeme starý systém novým systémem. Může jít o to, že starý systém z nějakého důvodu zastaral a nevyplatí se ho nadále rozvíjet. Případně může jít o sloučení firem, kdy nemá smysl udržovat více obdobných systémů. Samozřejmě nemusí se jednat jen o 1:1 (starý systém nahrazujeme novým systémem), ale klidně o N:1 (několik starých systémů nahrazujeme jedním novým systémem) nebo N:M (několik starých systémů nahrazujeme několika novými systémy).

Co je potřeba v rámci migrace vyjasnit? Předpokládejme, že se jedná o informační systém nějaké finanční instituce, který obsahuje data o produktech, zákaznících a smlouvách. 

• Rozsah migrace - jakých dat se migrace týká. Všech dat, nebo jen omezené množiny dat? Jaké entity (zákazník, smlouva, …) budeme migrovat? Potřebujeme například migrovat i staré ukončené smlouvy? Potřebujeme data týkající se všech produktů, nebo můžeme některé produkty (a k nim navázané smlouvy) vynechat?
• Jaké jsou rozdíly mezi starým a novým systémem. Existuje ve starém systému nějaká funkcionalita, která v novém systému neexistuje? Potřebujeme jí? Pokud ano, měla by se vyvinout i  v novém systému. Existuje v novém systému nějaká nová funkcionalita, která ve starém systému neexistuje? Chceme jí využít? Možná jí budeme muset nakonfigurovat.
• Migraci můžeme rozdělit na migraci produktů (struktura produktů, parametry produktů) a migraci samotných dat (tj. migraci dat o zákaznících, smlouvách, …). Dat o samotných produktech je většinou poměrně málo, takže je potřeba se zamyslet, zda trávit čas migrací produktů, nebo tyto produkty ručně nastavit v novém systému.
• Dále je potřeba zjistit, jaké jsou požadavky na migraci, zejména na její provedení. Velmi důležitým požadavkem může být třeba požadavek na dobu přechodu ze starého systému na nový systém. Nelze zanedbat ani požadavky na bezpečnost dat při jejich migraci.
• V závislosti na požadavcích může být migrace provedena jako jednorázová (přesuneme najednou všechna data ze zdrojového systému do cílového systému) nebo postupná (přesouváme data postupně, například po jednotlivých produktech).

Předpokládejme nyní, že je spolehlivě vyjasněn rozsah migrace a máme jasno ve funkcionalitě obou systémů. Pojďme se nyní podívat, jak se samotná migrace dat provádí v praxi. Jde nám tedy o přesun dat z databáze starého systému do databáze nového systému. 

Pro přesun dat můžeme vyvinout vlastní nástroj, nebo použít existující ETL (Export-Transform-Load) nástroj. Data je třeba exportovat ze starého systému, transformovat a zkontrolovat a následně nahrát do nového systému. Je potřeba počítat s tím, že ve všech těchto fázích mohou nastat chyby. Na závěr je pak třeba vše otestovat i když samotných proces proběhne bez chyb. Výsledkem totiž mohou být data, kde migrace proběhla bez chyb, ale samotný výsledek je chybný (například kvůli chybně definovanému mapování dat).

Ideální je tedy mít k dispozici odborníky na starý i nový systém a to jak z hlediska dat, tak z hlediska jejich použití v tomto systému. Při definování transformací se navíc může zjistit, že existují rozdíly mezi oběma systémy, které se nepodařilo podchytit dříve. To může vyžadovat dodatečný vývoj na straně nového systému a vést k prodloužení doby dodání.

Další komplikací může být kvalita dat, která nemusí být dostatečná. Napravit datovou kvalitu zpětně bývá značně obtížné. Příklad může být adresa zákazníka, pokud není úplná a obsahuje chyby. Nebo chybějící údaje, které jsou ale potřeba pro plnou funkcionalitu nového systému.

Migrace může být obtížná a časově náročná, ale s dobrou přípravou je zvládnutelná.

Náborový inzerát

Nabíráme nové lidi. Kdo jsme? Jsme takový startup uprostřed korporátu. Oproti korporátu můžeš čekat punkovější kulturu a spoustu zábavy při vytváření apek na míru. Na mezinárodních projektech u nás potkáš spoustu domorodců i cizinců, ale všichni jsou fajn. Přidej se k nám.

Překlad:

Zoufale hledáme nové lidi. Máme tu chaos jako ve startupu a spoustu nesmyslných korporátních pravidel. Pokoušíme se vyvíjet software, ale moc nám to nejde, což je známka punku. Vyvíjíme aplikace pro slovenskou pobočku, takže máme mezinárodní projekty. Jelikož nabízíme interním zaměstnancům (domorodci) malé platy, potřebujeme využívat bodyshop (cizinci). Přidej se k nám, protože nutně potřebujeme nahradit kolegu, který to tu zabalil už před měsícem.

Seznam přání

Analytik se při sběru požadavků občas může setkat s tím, že dostane namísto seznamu požadavků pouze seznam přání. Seznam přání je seznam toho, co by uživatel chtěl bez ohledu na možnosti realizace (časové, finanční, …). Rizikem je, že analytik pak tráví spoustu času analýzou něčeho, co pak nebude nikdy realizováno , protože na to nejsou zdroje.

Jak se proti tomu bránit? 

• Jasně vymezit rozsah projektu (scope) s nezabývat se požadavky mimo rozsah projektu.
• Včas identifikovat co jsou "nice to have" požadavky.  Tyto požadavky na odložit později.
• Komunikovat o omezeních týkající se daného projektu.

Odhady

 Máte za úkol udělat odhad jak dlouho bude trvat dodání analýzy konkrétního požadavku. Jak na to? 

Předně si je třeba vyjasnit, co odhadujete. Co je obsahem daného požadavku a co obsahem daného požadavku naopak není? Jaká je představa zadavatele o výstupu? Tyto otázky jsou zcela zásadní. Pokud po provedení a odevzdání odhadu zjistíte, že se odhad týkal jen části řešení, nebo výstup má být detailnější než se zdálo, pak je to problém. Je dobré počítat s drobnou rezervou. Ale rozhodně se nevyplatí odhad několikanásobně "přestřelit" - zadavatel se pak většinou rozhodne daný požadavek nerealizovat, nebo si najme někoho jiného. 

Dále je třeba si ujasnit, že odhadujeme pracnost (effort) a nikoliv dobu trvání (duration). Mezi těmito dvěma hodnotami je zásadní rozdíl v tom, že pracnost je doba, kterou budete pracovat na analýze (například 2 MD), doba trvání je celkové kalendářní doba od zahájení práce do jejího dokončení. Takže pokud máte alokaci na projektu 50%, znamená to, že práce bude trvat 4 dny.

Pokud je jasné co odhadujete, můžete přistoupit k samotnému odhadu. Předpokladem je, že máte požadavky na správné úrovni. Rozlišme si 3 úrovně požadavků:

• Business requirement - požadavek definující, co musí být splněno z hlediska organizace.
• Stakeholder requirement - požadavek definující, co musí být splněno z hlediska "stakeholdera".
• Solution requirement - požadavek na řešení. 

Logicky potřebujete požadavky z nejnižší úrovně. Příkladem takového požadavku je "Uživatel bude schopen vyhledat všechny smlouvy daného klienta po zadání jeho rodného čísla." Požadavek z nejvyšší "business" úrovně by se odhadoval těžko, protože může znít "Zrychlení celkové doby zpracování škodních událostí o 20%."

A jak tedy odhadovat? Ideálně na základě historických dat. Odhadujeme již zmiňovaný požadavek "Uživatel bude schopen vyhledat všechny smlouvy daného klienta po zadání rodného čísla klienta.".  V minulosti byl zpracován požadavek "Uživatel bude schopen vyhledat všechny smlouvu na základě čísla smlouvy", jehož analýza zabrala 2 MD. Jedná se o tedy podobný požadavek. Náš požadavek je o něco náročnější  a to zejména z důvodu, že obsahuje 2 entity (na rozdíl od  požadavku, který se týkal pouze smlouvy, se náš požadavek týká ještě klienta). 

Pokud vytváříte odhad, připravte se na to, že tento odhad bude třeba obhájit. I když je požadováno jen jedno číslo, je vhodné připravit si rozpad na jednotlivé činnosti. Je to dobré i z psychologického hlediska. Jedno číslo vypadá většinou velké, pokud uvedete dílčí činnosti, najednou se jedná o spoustu práce a je proto logické, že takové množství úkolů nějaký čas zabere:

Pojďme na to:

Příprava na schůzku se zadavatelem: 2 hodiny

Schůzka se zadavatelem: 1 hodina

Vytváření analytického dokumentu: 5 hodin

Verifikace dokumentu se zadavatelem: 0,5 hodiny

Úpravy dokumentu: 0,5 hodiny

Schůzka s vývojovým týmem - verifikace řešení a nacenění vývoje: 1 hodina

Schůzka s testovacím týmem - nacenění testování: 1 hodina

Úprava dokumentace: 2 hodiny

Revize testovacích scénářů: 1 hodina

Spolupráce při testování: 2 hodiny

Řešení chyb a dodatečné konzultace: 4 hodiny

Celkem: 2,5 MD

Požadavky

Analytik zpracovává požadavky zadavatele. Pojďme se podívat na některé přístupy, které se mohou v praxi vyskytnout. A asi není třeba dodávat, že se jedná o negativní příklady:   

Každá informace se hodí. Čím více textu, tím lépe.

V průběhu schůzek se zadavatelem zjistí analytik spoustu informací. Některé informace jsou podstatné, některé mohou být důležité, ale jiné se požadavku týkají jen velmi vzdáleně. Analytik by měl být schopen rozlišit podstatné a nepodstatné informace. 

Sepíšu to přesně tak, jak mi to zadavatel řekl.

Analytik by neměl být pouhým zapisovatelem požadavků. Sepsat všechno slovo od slova tak, jak to bylo řečeno zadavatelem obvykle není správný postup. Informace je třeba roztřídit a strukturovat.

Zadavatel tomu nerozumí. Vím přesně co potřebuje.

V některých případech se analytik považuje za doménového experta. Obsah požadavku je mu jasný ještě než zadavatel dořekne první větu. A je mu jasné, že zadavatel ve skutečnosti potřebuje řešení, které analytik vymyslel. V některých případech tomu tak může být, ale ne ve všech. 

Vývojář potřebuje přesné zadání jak danou věc naprogramovat.

Analytik přeskočí rovnou na návrh a už popisuje, které třídy a metody bude třeba upravit a do které databázové tabulky přidat sloupec. 

Není čas něco analyzovat, rozkaz zněl jasně - začněte s vývojem.

Není čas se bavit o požadavcích a vytvářet zbytečné dokumenty. Analýza se dodá agilně v průběhu vývoje. Zadání je jasné - systém pro poskytování úvěrů. 

Požadavek byl verifikován zadavatelem, takže je naprosto v pořádku.

Není jasné je přesně obsahem požadavku, ale protože byl verifikován zadavatelem, tak je v pořádku. 

Sepsané požadavky nejsou v zásadě potřeba. Pokud vývojáři není něco jasné, tak se může zeptat. 

Analýza vůbec není potřeba. Vývojář začne vyvíjet a něco dodá. Ale možná to bude něco trochu jiného než mělo vzniknout.