personal<IT>y: „Analýza není dokument, ale proces,“ říká analytička o hledání potřeb, use case-och a tom, jak z byznys požadavků vzniká funkční systém

Tři světy analýzy: byznysová, datová a softwarová

Jak vlastně vypadá tvoje práce analytičky?

No, když to mám zjednodušit, tak já dělám analýzu softwarových řešení, často se jedná o systémy na míru. Zákazník přijde s nějakou vizí, nebo alespoň s představou, co by chtěl. A my to potom přetavíme do funkčního systému. Je to hlavně o komunikaci. Hodně si povídáme se zákazníkem, snažíme se pochopit, co potřebuje, co mu pomůže.

A pak spolu s architektem a programátory dáváme dohromady návrh řešení. Během vývoje s klientem věci konzultujeme, aby výsledek, tedy finální produkt, nebyl jen něco, co musí používat, ale něco, co mu reálně pomáhá.

Myslíš si, že lidé vůbec vědí, co děláš?

Upřímně? Většina ne. Většina lidí si myslí, že jen sedím za počítačem a něco tam ťukám. I když někomu řeknu, že jsem analytik, tak první reakce je často: „A to je co?“ Většina lidí si to neumí představit.

Dají se analýzy nějak rozdělit? Jsou různé typy?

Určitě ano. Těch způsobů dělení je více, ale z mé praxe se nejčastěji setkávám se třemi typy: byznys analýza, datová analýza a softwarová analýza.

Byznys analýza je o tom, že jdeš za zákazníkem, podíváš se, jak fungují jeho procesy, jak vypadá jeho byznys. Většinou už existuje nějaký problém, něco nefunguje, něco je třeba zefektivnit. Snažíš se tedy pochopit, kde je zádrhel, a navrhnout řešení, ať už jde o úpravu procesů nebo návrh systému, který to celé podpoří.

Potom jsou datoví analytici, to je už jiná liga. Já jsem nikdy nedělala s daty takhle do hloubky. Datový analytik řeší například migraci dat, musí pochopit, jak byla data strukturována předtím, aby je uměl správně přenést do nového systému.

No a to, co dělám já, je softwarová analýza. Já už dostanu od zákazníka nějaké byznys požadavky, a ty pak přetavuji do funkčních a nefunkčních požadavků. Navrhuji funkcionality, rozkresluji obrazovky, specifikuji chování systému. Je to už techničtější, blíže k samotnému vývoji.

Takže když mluvíme o „byznysu“, máme na mysli jeho procesy, provoz a to, jak věci reálně fungují?

Přesně tak. V našem žargonu to nazýváme „byznys procesy“, tedy jak má firma nastaveno fungování. A když se objeví problém, řešíme ho. Buď se něco upraví, nebo navrhneme zcela nový systém.

Od testování k analýze

Jak ses vlastně dostala k práci IT analytičky?

Začínala jsem jako tester-konzultant. Studovala jsem na Žilinské univerzitě, obor řídící informační systémy. Dělali jsme tam nějaké návrhy, hlavně databázové, ale spíše jen okrajově. Celkově to bylo více zaměřeno na dopravu a logistiku, ne přímo na vývoj softwaru.

Moje první pracovní pozice byla právě tester-konzultant. Tam jsem se začala učit všechny ty základní věci, jak se testují aplikace, jak se píší uživatelské příručky a podobně. Byl to fajn na rozběh. A tam jsem měla kolegu, který mě postupně začal táhnout směrem k analýze. Nejprve jsem mu pomáhala při projektech jako junior analytik, později jsem už měla vlastní.

Takže tě to samo „vtáhlo“ do světa analýzy?

Přesně. Ani to nebylo tak, že bych si vysloveně řekla: „Chci být analytik.“ Ono to tak přirozeně vyplynulo. Ale nebránila jsem se tomu, vůbec ne. Spíš naopak, bavilo mě to. Mám ráda ten moment, kdy projekt začíná. Tím, že děláme systémy na míru, každá zakázka je úplně jiná, vždy je to nový svět, nové téma. Neustále se učíš něco nového. A ten pocit, když na konci vidíš výsledek, když to, co jsme vytvořili, reálně někomu pomůže, to mě na tom opravdu baví.

Jak probíhala ta transformace z testeru na analytičku?

Nejprve jsem pomáhala s různými výstupy, které hlavní analytik potřeboval, dokumentace, výstupy z workshopů, specifikace. Postupně mi začal dávat více prostoru. A když přišel první projekt, kde mi řekl: „Zkus si to vést sama,“ tak jsem do toho šla. Začala jsem sama připravovat zadání pro programátory, konzultovat se zákazníkem, probírat návrhy s vývojáři… a najednou jsem zjistila, že se v tom cítím přirozeně. Neměla jsem problém komunikovat, klást otázky, spojovat si souvislosti. A tak to postupně celé najelo.

Přenesli se ti nějaké dovednosti z testování do analytické práce?

Určitě ano. I když občas je to spíše naopak, že když jsem už jako analytik testovala některé části systému, ne vždy jsem se uměla úplně odosobnit. Už jsem věděla, jak to má fungovat, a tím pádem jsem to možná netestovala se zcela čerstvým pohledem. Ale z druhé strany, tester musí mít také jistý analytický přístup. Když se objeví nějaký problém, musí jej rozebrat, pochopit, kde vzniká, co se děje. Potřebuje se v tom systému vyznat, vědět, jak jednotlivé části fungují, a pak to také umět vysvětlit programátorovi, v ideálním případě tak, aby už měl představu, kde hledat chybu nebo co opravit.

Spolupracuješ tedy úzce s programátory?

Spolupracuji se všemi. V podstatě s celým týmem od projektového manažera, se kterým na začátku připravujeme nabídku, odhady náročnosti a pracnosti až po testery a konzultanty, kteří řeší výstupy na konci projektu. Důležitý je i softwarový architekt, tedy „návrhář“, jak jej voláme. Když mám nějaký návrh řešení, probírám ho s ním. On mi řekne, jestli je to technicky realizovatelné, zda tam nejsou nějaké limity, případně navrhne lepší cestu. To už probíhá během projektu, ale s týmem jsme v kontaktu neustále.

Potom samozřejmě komunikuji s testery a konzultanty. Když během testování najdou problém, řešíme, zda se jedná o chybu, nebo o nepochopení funkcionality, a zda je třeba něco upravit. A pokud je něco nejasné v podkladech, umíme si to hned vydiskutovat. No a v neposlední řadě, zákazník. Toho máme na paměti během celého projektu. A programátoři? Tam je to o jasných zadáních. Když je něco dobře připraveno, i vývoj jde hladší.

Co obsahuje analýza

Píšeš i ty „analytické bichle“ s několika stovkami stran?

Jasné.  To už je taková klasika.

A kolik takového textu jsi už vyprodukovala? To musí být tisíce stran.

Uf, od roku 2006 jsem dělala na fakt spoustu projektů. Ani neumím říct, kolik jich bylo, ale stovky určitě. Ty větší zakázky, tam to bývá opravdu kvantum dokumentace. 400 stran? Úplně běžné. Ale vše záleží na velikosti projektu. Když jde o malý projekt, tak samozřejmě neprodukuješ dvě stě stran dokumentace. Někdy jde jen o menší změnu v systému, něco drobného, ​​co se potřebuje dodělat. Ale když je to velké řešení nebo systém pro velkou firmu, tak ano, jde to i do stovek stran.

A co uživatelské příručky? Ty taky píšeš?

Ano, také příručky pro uživatele. A i ty mohou být dosti rozsáhlé, záleží, jak robustní je systém. Někdy se jedná jen o jednoduchý portál, kde se něco vyhledává, eviduje. Jindy máš rozsáhlý systém se spoustou funkcionalit, interní i veřejnou částí, a tam se už dokumentace opravdu nafoukne.

Jak bys rozdělila ty projekty podle náročnosti?

Jsou takové tři kategorie. První jsou ty úplně malé změny, systém už existuje a jen se něco drobného upravuje. Potom jsou menší projekty, jako jednoduché evidence nebo portály, které něco zobrazují, vyhledávají, případně se tam něco ukládá. A potom jsou ty velké, robustní systémy, často pro velké firmy.

Existuje vůbec něco jako typický pracovní den analytika?

Ne, asi ne. Opravdu to velmi závisí na tom, v jaké fázi projektu se právě nacházím.

Jak vzniká dobrá analýza

A jak vypadá takový začátek, první setkání se zákazníkem?

Buď už máme k dispozici nějaké vstupní podklady, tedy dokumentaci, objednávku, nebo alespoň popis toho, co zákazník potřebuje, nebo to teprve rozpracováváme. Většinou to začíná rozhovorem. Ptáme se, snažíme se věci pochopit, rozkouskovat projekt na menší části, podle toho, jak robustní systém bude. A zákazník nám říká, co potřebuje, jak to funguje u nich.

A kdo za zákazníka obvykle komunikuje?

Měl by to být někdo, kdo ten proces dobře zná, tedy „byznys owner“ nebo člověk z provozu. Někdy je to jeden člověk, někdy více, závisí na rozsahu. Například při jednom projektu to celé zastřešoval jeden člověk a ten to uměl i ostatním kolegům interně vysvětlit jejich „řečí“. Tehdy jde komunikace o dost snazší.

Nestává se, že během analýzy vyjdou najevo věci, které zákazník předtím sám netušil?

Určitě ano. Někdy během analýzy narazíme na „úzká hrdla“, která si ani sami neuvědomovali. Například při migraci měřičů jsme zjistili, že pokud se pošle velké množství požadavků najednou, jejich interní systém nestíhá. Tak jsme to přizpůsobili na naší straně, změnili jsme způsob odesílání požadavků, aby nedošlo k zahlcení. Nemuseli oni měnit celý svůj proces, stačilo, že jsme to uměli přizpůsobit u nás.

Které části analýzy jsou ty nejzásadnější?

Základem jsou byznys požadavky, to, co systém má vědět. Ty se rozdělí na funkční a nefunkční požadavky. Funkční znamenají konkrétní funkcionalitu, kterou má systém zajistit, například „uživatel si umí vytvořit žádost“. Nefunkční jsou technické nebo provozní, například, že systém má být responzivní, bezpečný, škálovatelný, nebo dostupný 24/7.

Jak se to dále rozpracovává?

Každý funkční požadavek by měl být pokryt nějakým „use case-em“. Ty popisují, co má systém dělat, kdo jej používá, jaký je průběh akce. Potom připravujeme prototypy obrazovek, jak bude vypadat uživatelské rozhraní. Jsou to spíše technické návrhy pro tým, kde budou jaké prvky, tlačítka, vstupy. Není to ještě finální design pro zákazníka, ale slouží to jako podklad pro další komunikaci s týmem i se zákazníkem.

A co všechno ještě popisuješ?

I to, jak systém zpracuje konkrétní proces, například jak se zpracuje objednávka nebo faktura, jaké stavy může mít, jak se mění. K tomu děláme také stavové diagramy, entity, doménové modely a následně již detailní zadání pro programátory.

Zadání pro programátory? Co si máme pod tím představit?

To jsou specifikace, co má konkrétní funkcionalita dělat, jak se má chovat. Aby vývojáři věděli, co a jak mají naprogramovat, jaké jsou limity, co je nutno dodržet. Bez dobře připraveného zadání by to nešlo, je to vlastně přemostění mezi tím, co chce byznys, a tím, co vytváří vývoj.

Která část tvé práce je podle tebe nejnáročnější?

Na začátku pochopit, co vlastně zákazník chce. Správně identifikovat požadavky. Čím méně si rozumíme, tím více problémů může vzniknout později. A zákazník často neumí přesně říct, co potřebuje, jen on ví, jaký chce výsledek. Mým úkolem je pochopit, co se musí v systému udát, aby se k tomu výsledku dostal.

Je i nějaká část práce, kterou bys označila za jednoduchou?

Těžko říct. Podle mě je to o tom, jak se k tomu postavíš. Pokud si už předem řekneš, že je to složité nebo že to nedáš, tak to bude působit náročně. Ale když si to rozdělíš, rozanalyzuješ a postupně se tím „kousneš“, tak se to dá zvládnout. Není to o tom, že něco je úplně jednoduché, spíše o tom, že něco tě baví víc.

Jsi součástí projektu i po implementaci?

Ano, na projektech, na kterých pracuji, jsem zapojena od začátku až po nasazení. Je možné, že na větších projektech má analytik jen jeden úkol, provede analýzu, předá ji, a pak se k tomu vrátí jen v případě, že je problém. Ale u nás je to tak, že jsme u toho celého až do konce.

Analýza jako živý proces

Takže analýza nežije „vlastním životem“, pořád si u ní?

Analýza není jen dokument, který se někam pošle a zapomene se na něj. Je to proces, který pokračuje, diskutuje se, upravuje, přizpůsobuje realitě. A analytik je toho součástí až do momentu, kdy systém reálně funguje. Takže nikdy úplně „nežije vlastním životem“. I když se projekt uzavře, stále se k ní dá vrátit, například když přijde požadavek na změnu, úpravu nebo opravu.

Změny se obvykle zapracovávají na základě původních podkladů. Nemusí to dělat tentýž analytik, co ji tvořil, ale je důležité, aby dokumentace byla kvalitní a srozumitelná i pro někoho jiného v případě, že analytik projekt opustí nebo odejde z firmy. Kontinuita je klíčová. Změny, které mají dopad na funkcionalitu, musí být zpětně zapracovány i do dokumentace. Analýza jako taková tedy zůstává součástí projektu během celého jeho životního cyklu.

Jaké jsou podle tebe ideální dovednosti pro dobrého analytika?

Komunikativnost je základ. Potom analytické myšlení, schopnost ptát se, proč věci fungují tak, jak fungují. A určitě i cit pro jazyk, umět věci srozumitelně vysvětlit a zapsat, aby měly výpovědní hodnotu a byly přehledné i pro jiné.

Stává se, že si někdo analýzu špatně představí?

Občas ano. Používáme různé standardy, jazyky a notace jako UML nebo BPMN. A někdy se stane, že když někdo použije složitější prvky, ten diagram může zákazníkovi připadat nesrozumitelný.

Proto vždy připojujeme také textový popis, vysvětlení, jak proces probíhá. Cíl je, aby si zákazník uměl spojit schéma s realitou. Pokud to zpracuje spolu, text i diagram, měl by pochopit, o co jde.

Takže BPMN je modelovací jazyk?

Ano. BPMN používají analytici i softwaroví architekti k popisu procesů. UML se zase využívá spíše k popisu funkcionality, například přes „use cases“. Tyto modely umožňují všem, analytikům, architektům, programátorům „mluvit stejným jazykem“. Na základě nich se pak systém dá naprogramovat.

Existují podle tebe nějaké mýty o práci analytika?

Myslím, že běžní lidé často vůbec netuší, co děláme. Někdy si nás zaměňují s datovými analytiky, představují si, že jen sedíme v tabulkách a počítáme. Nebo si myslí, že jsme jen konzultanti, co sedí na poradách a něco povídají. I mezi firmami jsou v názvosloví rozdíly, někde se stejná role jmenuje „byznys analytik“, nebo „konzultant“ popřípadě „procesní specialista“. Takže když si porovnáš popisy pozic v různých firmách, zjistíš, že neexistuje jeden univerzální standard.

Analytika i mimo práci

A probíráš si někdy věci i doma, v hlavě?

Ano, občas se mi to stává. Když mám něco rozdělaného, ​​přemýšlím nad tím i doma. Říkám si: „Zítra si to musím sepsat.“ Nebo se mi něco vyjasní, když dělám úplně jinou činnost. Není to ovšem tak, že bych nonstop řešila práci. Spíše v těch fázích, kdy se něco rozjíždí, když se potřebuji zorientovat, pochopit souvislosti, připravit se na setkání se zákazníkem. Tehdy mi to v hlavě víc „šrotuje“.

A jak relaxuješ?

Spánkem. Když můžu. Ale vedle dětech to není vždy jednoduché. Děti jsou priorita a když se věnuji jim, tak se snažím být s nimi naplno, nepřehánět to s prací, nemíchat to.

Zasahuje tvoje práce do rodičovství? Umíš úplně „vypnout“?

Asi ani ne úplně. Občas se mi stává, že při školních úkolech, hlavně při matematice, začnu věci příliš analyzovat. Dítě se na to podívá a jde to rovnou řešit. Já už přemýšlím, co tím autor role chtěl říct. A to není vždy výhoda. Možná je to dáno tím, jak uvažuji. Snažím se řešit věci, pochopit, proč nastal problém, co je za tím i doma, při běžných situacích. Ale tam je to spíš taková „emoční analýza“. Někdy je však lepší věci jen přerušit a neřešit je hned do hloubky.

A kde nacházíš největší spokojenost ve své práci?

Asi v tom, když to celé funguje. Když si tým rozumí, když komunikace probíhá přirozeně, není tam napětí. To je velké plus. Někdy jsou dokumenty dlouhé, 300stránkové výstupy, ale pokud v týmu funguje pohoda, jde to snazší. A pak samozřejmě je fajn i zpětná vazba od zákazníka, když řekne, že je spokojen, že to, co jsme připravili, mu dává smysl. To je tak malý „win“. I když dokument ještě není finálně schválen a čekají nás další úpravy, je to moment, kdy si řekneš, dobře, jsme na dobré cestě.

Takže spokojenost přichází i dříve než až po nasazení?

Určitě. Nemusím čekat na finální podpis, než si řeknu, že mám z toho dobrý pocit. Například když dám dohromady dokument, který je jasný, srozumitelný, má hlavu a patu, a už ho jen ladíme. Tehdy mám pocit, že mám hotovo. I když vím, že ještě přijdou připomínky, je to pro mě důležitý milník.

Co bys doporučila někomu, kdo se chce stát analytikem? Co by měl vědět?

Určitě je důležité mít odborné znalosti, znát modelovací jazyky jako UML, umět číst a vytvářet procesní diagramy. A pak, velmi důležité je ptát se. Proč to funguje takhle? Jak to funguje? A co tím vlastně zákazník myslí?

Co tě motivuje?

Tím, že dělám analýzy pro informační systémy na míru, dostanu se k různým oblastem, každý projekt je trochu jiný. Člověk pozná různé světy. Například jsem se dozvěděla, jak funguje systém objednávání časopisů na poště, nebo jak se distribuují ty vitríny, kde jsou knihy, hračky a podobně. Možná to v běžném životě nevyužiji, ale baví mě to, najednou vím něco, co jsem předtím netušila.

A využíváš analytické uvažování iv běžném životě?

Asi ano, ale ne cíleně. Když děláme doma rekonstrukci nebo něco plánujeme, tak si přirozeně porovnám ceny, udělám si seznamy, zvážím možnosti. Ale to dělá spoustu lidí, nejen analytici. Do databáze si to zatím nezapisuji (smích).

Jaké stereotypy panují o analyticích?

No, nejsou tak výrazné jako u programátorů s károvanými košilemi. Ale ano, někdy nás lidé vnímají jen jako ty, co dělají tabulky nebo kreslí diagramy. Ale to je jen část toho, co děláme. A hlavně, jsme také lidé.