5 dokumentů, které IT analytik reálně píše (a jak vypadají)

Zeptejte se lidí, kteří uvažují o kariéře IT analytika, co ta práce vlastně obnáší, a dostanete odpověď ve slovesech: „komunikuje“, „sbírá požadavky“, „je mostem mezi byznysem a vývojáři“. Všechno to sedí — a přesto si podle toho nikdo nedokáže představit jediný pracovní den. Chybí tam totiž ta hmatatelná část: analytik na konci dne něco odevzdá. Konkrétní dokument, který si přečte vývojář, tester i člověk z byznysu, a podle kterého se pak něco postaví.

Právě tyhle výstupy jsou to, za co vás firma platí, a taky to, na čem se u pohovoru pozná, jestli tomu řemeslu rozumíte. Pojďme si projít pětici dokumentů, která pokryje drtivou většinu toho, co budete jako analytik psát — u každého si řekneme, co v něm je, k čemu slouží a podle čeho se pozná, že je dobrý.

1. Funkční specifikace

Vlajkový dokument analytika. Popisuje, co má systém dělat — ne jak to má být naprogramováno. Je to překlad z jazyka byznysu („potřebujeme, aby zákazníci mohli platit kartou“) do podoby, ze které dokáže vývojář postavit řešení a tester ověřit, že funguje.

Struktura se firmu od firmy liší, ale kostra bývá skoro vždycky stejná:

• Kontext a cíl — proč to vůbec děláme, jaký problém to řeší a co se stane, když to neuděláme. Tahle část se nejčastěji vynechává a nejvíc chybí.
• Rozsah — co je součástí zadání a hlavně co součástí není. Explicitně vypsané „mimo rozsah“ vám ušetří polovinu budoucích sporů.
• Funkční požadavky — co systém umí. Přihlášení, výpočet ceny, odeslání notifikace.
• Nefunkční požadavky — jak dobře to musí umět. Rychlost odezvy, dostupnost, bezpečnost, počet souběžných uživatelů. Junioři je zapomínají skoro vždy, přitom právě ony často rozhodují o architektuře.
• Okrajové a chybové scénáře — co se stane, když platba selže, když uživatel zavře prohlížeč uprostřed procesu, když přijde prázdný soubor.
• Otevřené otázky — co ještě není rozhodnuto a kdo to má rozhodnout. Poctivě vedený seznam otevřených otázek je známka dobrého analytika, ne jeho slabosti.

Poznávací znamení dobré specifikace je jednoduché: každou větu jde otestovat. Když z požadavku nedokážete odvodit test, který ho buď potvrdí, nebo vyvrátí, je ten požadavek zatím jen přání.

Špatně: „Systém bude uživatelsky přívětivý a rychlý.“ · Dobře: „Uživatel dokončí objednávku nejvýše ve třech krocích. Stránka se načte do 2 sekund při 500 souběžných uživatelích.“

2. User story a akceptační kritéria

V agilních týmech se velká specifikace často rozpadá na drobné kousky — user stories. Každá popisuje jednu potřebu jednoho typu uživatele, v ustáleném formátu: jako {role} chci {co}, abych {jaký přínos}. Ta poslední část je nejdůležitější a nejčastěji odbytá — bez ní totiž nikdo neví, co se má stát, když se ukáže, že původně navržené řešení nefunguje.

Story sama o sobě ale nestačí. Musí k ní patřit akceptační kritéria — seznam podmínek, které musí být splněné, aby šla práce prohlásit za hotovou. Často se píšou ve formátu když {výchozí situace}, a {událost}, pak {očekávaný výsledek}:

• Story: Jako zákazník e-shopu chci vidět stav své objednávky, abych nemusel volat na zákaznickou linku.
• Kritérium: Když je zákazník přihlášený a má aspoň jednu objednávku, pak v sekci Moje objednávky vidí u každé objednávky její aktuální stav a datum poslední změny.
• Kritérium: Když objednávka změní stav, pak zákazník do 5 minut obdrží e-mailovou notifikaci.
• Kritérium: Když zákazník nemá žádnou objednávku, pak se zobrazí prázdný stav s odkazem do katalogu — ne prázdná stránka ani chyba.

Nejčastější chyba začínajícího analytika je, že do story napíše řešení místo potřeby: „Jako zákazník chci tlačítko v pravém horním rohu.“ Zákazník nechce tlačítko. Chce vědět, kde má balík. Jakmile popíšete potřebu, otevřete vývojářům prostor přijít s lepším řešením, než jaké by vás napadlo — a to je přesně to, co od dobré story chcete.

3. Procesní diagram

Některé věci se textem popisují mizerně. Když má proces pět rozhodovacích bodů, tři zúčastněné role a dvě výjimky, je obrázek nesrovnatelně srozumitelnější než tři stránky souvětí. Pro tenhle účel se používá procesní notace — nejčastěji BPMN — kde má každý tvar pevně daný význam: obdélník je činnost, kosočtverec rozhodnutí, kolečko začátek nebo konec, plavecké dráhy ukazují, kdo co dělá.

V praxi kreslíte obvykle dva diagramy k jednomu zadání. První je as-is: jak proces funguje dnes, včetně všech obezliček a excelů, které si lidi vymysleli, protože jim systém nevyhovuje. Druhý je to-be: jak má vypadat po změně. Rozdíl mezi nimi je vlastně zadání projektu, a bývá to nejpřesvědčivější slide, jaký můžete managementu ukázat.

Diagram má ale ještě jednu funkci, na kterou se často zapomíná: je to nástroj na kladení otázek. Když ho kreslíte na workshopu před zákazníkem, spolehlivě narazíte na místo, kde dva lidé ze stejného oddělení popíšou stejný krok jinak. To je ten okamžik, kvůli kterému tam analytik je. Právě proto je chybou zavřít se do kanceláře a vytvořit dokonalý diagram o samotě — hodnota vzniká při jeho kreslení, ne po něm.

4. Datový model

Datový model — v nejběžnější podobě ERD, tedy diagram entit a vztahů — popisuje, jaké informace systém uchovává a jak spolu souvisejí. Entita je věc, o které si vedete záznamy (zákazník, objednávka, produkt), atributy jsou její vlastnosti a vztahy říkají, jak jsou entity pospojované a v jakém počtu.

Tady bývá největší překvapení pro lidi, kteří do IT teprve vstupují: modelování dat není technická činnost pro vývojáře. Je to nejostřejší nástroj na odhalování nedorozumění, jaký analytik má. Otázky, které z něj přirozeně vypadnou, totiž nikdo jiný nepoloží:

• Může mít zákazník víc doručovacích adres? A může jednu adresu sdílet víc zákazníků?
• Co se stane s objednávkami, když zákazník zruší účet — smažou se, nebo se jen anonymizují kvůli účetnictví?
• Je „zákazník“ a „uživatel účtu“ totéž? Ve chvíli, kdy objednává firma a účet má její zaměstnanec, najednou není.
• Potřebujeme znát historii změn ceny produktu, nebo stačí aktuální hodnota? Na tuhle otázku se přijde obvykle až měsíc po nasazení, když někdo chce reportovat vývoj marže.

Každá z těch otázek vypadá jako detail a každá dokáže po půl roce vývoje způsobit přepis půlky aplikace. Analytik, který se je naučí ptát včas, ušetří firmě víc peněz než celý jeho roční plat.

5. Zadání pro rozhraní mezi systémy

Málokterý systém dnes stojí sám. E-shop mluví s platební bránou, skladem, účetnictvím a dopravcem — a všechny tyhle výměny dat je potřeba popsat. Pátý typický výstup analytika je tedy popis rozhraní, obvykle API: co si dva systémy posílají, kdy, v jakém formátu a co se stane, když to selže. Formalizovaná podoba se jmenuje OpenAPI specifikace.

Nebojte se, tenhle dokument obvykle nepíšete sami a rozhodně u toho nemusíte programovat. Píšete ho s vývojářem nebo architektem — vaše část je věcná, ne technická:

• Jaká data druhá strana potřebuje a která z nich jsou povinná. Překvapivě často se zjistí, že požadujeme údaj, který nikdo nemá odkud vzít.
• Co je zdrojem pravdy. Když má e-shop i sklad vlastní počet kusů, který z nich platí?
• Jak často a čím se výměna spouští — okamžitě při události, nebo dávkově každou noc?
• Co se stane při chybě. Zopakuje se pokus, a kolikrát? Kdo se to dozví? Smí zákazník mezitím dokončit objednávku?
• Jak se řeší duplicity, když se stejná zpráva pošle dvakrát. V integracích je to spíš pravidlo než výjimka.

Nefunkční integrace patří k nejdražším poruchám v IT vůbec, protože se projeví až v provozu a obvykle na penězích. Analytik, který si u zadání rozhraní dá práci s chybovými scénáři, má u vývojářů vyhráno.

Co mají všechny tyhle dokumenty společné

Na první pohled to vypadá jako pět různých formátů, ale spojuje je jedna věc: žádný z nich není administrativa. Jsou to nástroje na myšlení. Jejich hlavní hodnota nevzniká ve chvíli, kdy je někdo čte, ale ve chvíli, kdy je píšete — protože vás donutí položit otázky, které by jinak zůstaly nevyslovené až do okamžiku, kdy je jejich zodpovězení drahé.

Z toho plyne i praktický důsledek: nástroj je vedlejší. Někde se specifikace píšou v Confluence, jinde ve Wordu na sdíleném disku, user stories žijí v Jiře a diagramy vznikají v Miru nebo Draw.io. Tohle se naučíte za odpoledne v každé nové firmě. Co se za odpoledne nenaučíte, je poznat, že požadavek „musí to být intuitivní“ zatím nic neznamená, a umět z něj rozhovorem vytáhnout něco, co jde postavit a otestovat.

Jak si to zkusit, než vás někdo zaměstná

Nejrychlejší způsob, jak zjistit, jestli vás tahle práce baví, je udělat si ji nanečisto. Nepotřebujete k tomu klienta ani přístup do firemního systému — stačí aplikace, kterou používáte:

1. Vyberte si funkci z aplikace, kterou znáte — třeba rezervaci jízdenky nebo vrácení zboží v e-shopu.
2. Nakreslete procesní diagram toho, jak to dnes funguje, včetně toho, co se stane při chybě platby.
3. Napište tři user stories s akceptačními kritérii pro vylepšení, které vás napadne.
4. Načrtněte datový model — jaké entity za tím musí být a jaké mezi nimi platí vztahy.
5. Dejte to přečíst někomu, kdo tu aplikaci nezná, a nechte si ukázat každé místo, kde si musel domýšlet. Tam je vaše slabina.

Tohle cvičení má ještě jeden vedlejší přínos: výsledek je použitelné portfolio. Na pohovoru na juniorní pozici je ukázka vlastní specifikace mnohem silnější argument než věta „hodně jsem o tom četl“ — a bývá to jediná věc, kterou většina uchazečů bez praxe nemá.

Závěr

Práce IT analytika není mlhavé prostředkování mezi dvěma tábory. Je to řemeslo s konkrétními výstupy: funkční specifikace, user stories s akceptačními kritérii, procesní diagram, datový model a popis rozhraní mezi systémy. Kdo tuhle pětici umí napsat tak, aby se podle ní dalo stavět a testovat, má obor v ruce — a je celkem jedno, jestli k tomu došel přes vysokou školu, rekvalifikaci, nebo tím, že si to poctivě zkusil na aplikaci, kterou používá každý den.