Legislativní změny ve velké organizaci

Zákony se v čase vyvíjí, mění se, ruší se a vznikají nové. Tyto zákony mají dopady do činnosti organizace, které tato organizace musí respektovat, jakmile tento zákon nabyde účinnosti.

Vezměme si jako příklad takové organizace velkou banku. Velká banka zaměstnává tisíce lidí různých profesí, nabízí různé typy produktů a služeb a její činnost zahrnuje různé procesy podporované spoustou informačních systémů.

Parlament schválí nový zákon s účinností od určitého data. Právní oddělení banky by mělo monitorovat tyto legislativní změny. Důležitou otázkou je, zda má nebo nemá/může mít tato legislativní změna dopad do jakékoliv činnosti banky. Pokud ano, měla by následovat právní analýza dopadů, následovaná business analýzou na úrovni celé banky.

Co by taková business analýza měla zahrnout?

• Detailní business popis legislativní změny -  o co přesně jde, v jakých případech se legislativní změna projevuje.
• Business procesy - do jakých business procesů má tato legislativní změna dopad.
• Produkty - jakých produktů se tato změna týká.
• Informační systémy - v jakých informačních systémech bude potřeba provést změny a jaké změn to budou.

Co následuje? Příprava plánu.

• Je třeba naplánovat detailní analýzu a implementaci změn v dotčených informačních systémech a změny zkoordinovat.
• Naplánovat a připravit změnu business procesů, promítnout tyto změny do metodiky a další dokumentace. 
• Seznámit všechny dotčené pracovníky s provedenými změnami (změna v zákoně, změna v procesu, změna v informačním systému).

Pak už "stačí jen" plán spustit a sledovat, jak se jednotlivé změny realizují a samozřejmě řešit případné problémy, které ve velké organizaci a při dostatečně velkých změnách mohou nastat.

Analýza juniorního analytika

Dnes mám konkrétní příklad týkající se úpravy systému pro poskytování úvěrů. Na začátku procesu se zadávají údaje o osobách, přičemž některé informace se získávají z jiných systémů. Příkladem je údaj o případném insolvenčním řízení. Poté následuje další zpracování žádosti o úvěr, včetně zadávání dalších dat, předkládání dokumentů klientem, schvalování atd.

Tento příklad se týká úpravy obrazovky, která slouží k zadání údajů o osobách a načítání dalších informací z externích systémů. Na obrazovce se zobrazuje údaj, zda u dané osoby probíhá insolvenční řízení. Požadavek je tuto informaci odstranit, protože v dané fázi procesu není potřebná. Tato informace je však stále dostupná později, při schvalování úvěru.

Juniorní analytik tedy sepíše, co mu zadavatel zadal.

Změna: Informace o probíhajícím insolvenčním řízení bude odstraněna.

A je hotovo. Požadavek je specifikován a práce by měla být dokončena. Ale je to skutečně vše? Co přesně znamená, že informace bude "odstraněna"? Znamená to, že se už nebude dotahovat z externího systému? Nebo se stále bude načítat a zapisovat do databáze, ale nebude zobrazena na uživatelském rozhraní? A pokud se informace přestane dotahovat, jaký to bude mít dopad na další části systému?

Popis změny by měl vypadat takto:

Změna: Informace o probíhajícím insolvenčním řízení bude odstraněna z obrazovky Osoby. Nebude voláno API getInsolvencyFlag, které získává danou informaci ze systému XYZ a informace o insolvenčním řízení nebude zapisována databáze do sloupce INS_FLAG v tabulce CLIENT_DATA (tato hodnota se naplní až později v průběhu schvalování úvěru). Hodnota INS_FLAG z databáze se používá v šabloně dokumentu CaseOverview. Pokud bude dokument CaseOverview generován v době, kdy není naplněna hodnota  INS_FLAG , doplní se  k "Probíhající insolvenční řízení: " text "Není k dispozici".

MacBook jako pracovní nástroj analytika

Co takhle pořídit si jako pracovní počítač MacBook? Nebude to problém ve srovnání s počítačem s Windows? Jelikož o pořízení pracovního MacBooku sám uvažuji, rozhodl jsem se sepsat možné problémy při použití MacBooku jako počítače pro analytika.

Odlišné ovládání MacBooku

MacBook má mírně odlišnou klávesnici a jiné klávesové zkratky. Pro uživatele Windows to může být drobný problém (zvlášť pokud potřebujete využívat oba dva systémy a přecházet mezi nimi), ale dá se na to bez problémů zvyknout. Kdybych to měl k něčemu přirovnat, tak je to jako střídat dvě různá auta - jedno s manuální převodovkou a jedno s automatickou převodovkou.

Aplikace určené pouze pro Windows

Největší obavou je pro mě Sparx Enterprise Architect. Tento software bohužel nemá verzi pro MacOS. Ano, existují alternativy. Ale pokud pracujete v týmu, kde se používá  Sparx Enterprise Architect, těžko můžete používat něco jiného a nebo se použití tohoto software nějakým způsobem vyhnout. Nicméně provozování Enterprise Architectu by mělo být možné pomocí nástroje CrossOver viz https://sparxsystems.com/enterprise_architect_user_guide/16.1/getting_started/install_ea_crossover.html.

AI a analýza

 AI (umělá inteligence) nás všechny nahradí, zvládne naši práci lépe a rychleji, nebo je to jinak? Tyhle otázky se s nástupem LLM - large language models (rozsáhlé jazykové modely) objevují docela často. Je obdivuhodné, co dokáže třeba takový chatGPT. Osobně mě to, stejně jako celou řadu dalších lidí, z počátku ohromilo. Ale pokud znáte Gardnerovský Hype Cycle, tak jistě víte, že za vrcholem přehnaných očekávání nevyhnutelně následuje propast zklamání. Ano, je to dobré, ale... Občas si to vymýšlí, nepochopí zadání, vyžaduje kontrolu. 

Může to pomoci, pokud se to vhodně použije. Ale nenahradí to zkušeného analytika.

Proč je důležitý business slovník

Každý business používá specifické pojmy. Například označení produktů, právní termíny, oborové termíny atd. Business slovník slouží k vysvětlení, co který pojem znamená a ideálně i co znamená z pohledu našeho (analyzovaného) systému. Business slovník zaručuje, že všichni chápou daný pojem stejně. Pokud je někde v analýze použit neznámý termín, je vysvětlen v business slovníku.

Zrovna nedávno jsem se s potřebou takového business slovníku setkal. Kolega je na dovolené. Analyzoval požadavek, kdy se jistá hodnota má plnit na základě vlastností úvěru. Takže například:

• Plníme hodnotu A, pokud se jedná o úvěr s účelem výstavba.
• Plníme hodnotu B, pokud se jedná o úvěr s účelem koupě.
• Plníme hodnotu C, pokud se jedná o úvěr s účelem koupě a zároveň výstavba.
• Plníme hodnotu A2, pokud se jedná o úvěr s účelem výstavba +  extra.
• Plníme hodnotu B2, pokud se jedná o úvěr s účelem koupě + extra.
• Plníme hodnotu C2, pokud se jedná o úvěr s účelem koupě a zároveň výstavba + extra.

A nyní se zjistilo, že nikdo neví, co znamená to "+ extra". Žádný z účelů úvěru se nejmenuje "extra". Žádný produktový parametr se nejmenuje "extra". Žádný produkt, který by měl v názvu extra neexistuje.

Nakonec se to podařilo zjistit, ale bylo to zdlouhavé a náročné. Kdysi existoval produkt, který se jmenoval Extra hypotéka. Před 10 lety byl tento produkt zrušen. Tento úvěrový produkt umožňoval čerpat extra peníze na vybavení domácnosti. Po extra hypotéce zbyla v parametrech produktu dodatečná částka. Dodatečná částka se nabízí jako služba k hypotéce. "+ extra" znamená, že je vyplněna tato dodatečná částka. Kdyby existoval business slovník, nebo alespoň vysvětlení v analýze, dost by to usnadnilo život všem zúčastněným.

Analytik - samostatná pozice nebo jen role

Má smysl najímat lidi  (ať už jako zaměstnance nebo externí kontraktory) na samostatnou pozici business analytik? Nebo je analytik jen role, kterou zastane i člověk najatý jako vývojář? 

Pojďme si nejprve vyjasnit o jakých typech softwarových projektů se chci bavit. Mám na mysli velké bankovní projekty v rozsahu několika tisíc MD. Tj. projekty které jsou i z pohledu businessu poměrně komplikované. Věřím, že na projektu, který je malý a dostatečně jednoduchý může roli analytika zastat třeba vývojář. Ale na velkých bankovních projektech si to moc nedovedu představit. Tady jsou důvody proč si nemyslím, že by roli analytika mohl zastávat vývojář a proč je třeba na těchto projektech samostatná pozice analytika:

1. Odlišná sada dovedností: Vývojáři jsou zpravidla zaměřeni na technické řešení a implementaci, zatímco analytici se zaměřují na pochopení obchodních požadavků a jejich překlad do technických specifikací. Tyto role vyžadují odlišné přístupy a dovednosti.
2. Časová náročnost: Vývojáři jsou často přetíženi úkoly souvisejícími s kódováním a technickou implementací. Převzetí role analytika by mohlo vést k časové tísni a snížení kvality jak vývoje, tak analýzy.
3. Ztráta specializace: Každá z těchto rolí vyžaduje vysokou míru specializace. Pokud vývojář přebere roli analytika, může dojít ke ztrátě odbornosti v obou oblastech, což by mohlo negativně ovlivnit projekt.
4. Konflikt zájmů: Vývojář může být příliš technicky zaměřený a méně se soustředit na obchodní potřeby. To může vést k tomu, že se prioritizují technická řešení nad obchodními požadavky, což může být pro projekt škodlivé.
5. Riziko nedorozumění: Analytici jsou vyškoleni v komunikaci s různými zainteresovanými stranami, jako jsou zákazníci a manažeři. Vývojář bez těchto zkušeností může mít potíže s efektivním přenesením požadavků mezi technický a obchodní svět, což může vést k nedorozumění a chybám.
6. Omezená zkušenost s obchodním prostředím: Vývojáři mají často menší povědomí o širším obchodním kontextu, což může vést k nedostatečnému pochopení požadavků a cílů projektu.
7. Komplexita a rozsah projektů: Velké projekty často zahrnují složité obchodní procesy a různé zájmové skupiny. Analytik je schopen lépe zmapovat a pochopit tyto složitosti než vývojář, který by se měl soustředit na technické řešení.
8. Riziko zaměření na technické detaily: Vývojář může mít tendenci zaměřit se na technické detaily a přehlédnout širší obchodní cíle. Analytik by měl být zaměřen na to, aby technická řešení podporovala obchodní strategie, nikoli naopak.
9. Neefektivita: Kombinace rolí může vést k nižší efektivitě, protože vývojář nemusí být schopen efektivně rozdělit svůj čas mezi technické a analytické úkoly. To může vést k zpožděním a chybám.
10. Dlouhodobý dopad na kvalitu projektu: Bez specializovaného analytika může dojít k nedostatečnému pochopení obchodních potřeb a k vytvoření produktu, který neodpovídá očekáváním klienta nebo konečných uživatelů. To může mít dlouhodobé negativní dopady na kvalitu projektu a spokojenost zákazníků.

Kvalita zadání ovlivňuje kvalitu výstupu

Nedávno jsem dostal velmi přesné zadání s požadavkem na náhradu textace na uživatelském rozhraní:

Kvůli novému stavebnímu zákonu je třeba provést změnu textu. Pole "Je požadováno stavební povolení?" se změní na "Je vyžadováno povolení stavebního záměru dle stavebního zákona?"

Jak mělo vypadat správné zadání:

Nový stavební zákon namísto pojmu stavební povolení používá pojem povolení stavebního záměru. Proveďte nahrazení těchto pojmů na uživatelské rozhraní, všude, kde se pojem stavební povolení vyskytuje.

Ano, pojem se vyskytovat i u jiných polí. Přesné zadání vyvolalo dojem, že uživatel ví, co změnit.

Změna povolání

Asi změním povolání. V blízké nemocnici je teď volné místo kardiochirurga. Je to celkem dobře placené a mám to blízko a zřejmě by mě to i bavilo. Ne, nemám žádné lékařské vzdělání a ani žádnou praxi v oboru. Ale rychle se učím a určitě na to bude nějaký rekvalifikační kurz. Podívám se dnes do knihkupectví, možná tam bude kniha "Kardiochirurgem snadno a rychle" a uvidíme. 

Ne, opravdu jsem se nezbláznil a ve skutečnosti se nechci stát kardiochirurgem. Jen jsem si představil stejnou situaci, se kterou se setkáváme v oblasti IT, kde se lze snadno setkat s lidmi, kteří nemají žádné vzdělání v oblasti informačních technologií, žádnou praxi, jen přečetli nějakou knihu a v lepším případě absolvovali ještě krátký rekvalifikační kurz. A jak to dopadá? Jak si myslíte, že bych dopadl jako kardiochirurg amatér? 

Vývoj a podpora produkce

Je celkem obvyklé, že se vývoj neprovádí "velkým třeskem", kdy se najednou nasadí kompletně celý systém. Většinou to je postupné nasazování po jednotlivých ucelených modulech. Takže nastává situace, kdy něco už je nasazené na produkci a  už nějakou dobu funguje, něco dalšího se teprve vyvíjí a některé části jsou třeba zatím stále ve fázi analýzy.

Z části, která je na produkci přijde produkční incident - něco se pokazilo a nefunguje to. Co s tím? Kdo to má začít řešit?

Podle mě by to mělo fungovat následujícím způsobem:

• Vývojový tým vyvine například určitý modul. Tento modul je nasazen na testovací prostředí, kde jsou zahájeny testy. 
• V testech jsou identifikovány chyby u kterým je přiřazena závažnost dopadu. Tyto chyby jsou řešeny vývojovým týmem. 
• Po provedení testů je za stanovaných podmínek (např. 0 nevyřešených závažných chyb) je provedeno nasazení na produkci. Tým podpory produkce je seznámen s funkcionalitou daného modulu a přebírá dokumentaci. 
• Vývojový tým je po nasazení k dispozici pro případné řešení produkčních chyb. Tato podpora ze strany vývojového týmu je časově omezená, obvykle v řádu jednotek dní. 
• Poté už jsou chyby záležitostí podpory produkce, který by měl vyřešit většinu problémů a je zodpovědný za jejich řešení. Samozřejmě může konzultovat problémy s vývojovým týmem, ale neměl by na to spoléhat. Po dokončení posledního modulu a po jeho předání do produkce je vývojový tým rozpuštěn a nebo přechází na jiný projekt. 

Situace, kdy tým podpory netuší, jak řešit produkční chyby a úkoluje vývojový tým požadavky na urgentní vyřešení aktuálního problému je akceptovatelná pouze do několika málo dní po nasazení nové funkcionality za předpokladu, že se problém týká a nebo souvisí s nově nasazenou funkcionalitou. Rozhodně by to neměl být standardní způsob řešení problémů funkční podporou.

Technický design

Pojďme se na jednoduchém případě podívat, co to je technický design. Mějme jednoduchou aplikaci, která bude evidovat nějaké obchodní případy. K případům bude evidovat dokumenty. Uživatel si může zobrazit seznam dokumentů k danému případu, může přidat další dokument a může (pokud má příslušná práva) dokument smazat. Po smazání se už smazaný dokument na případu nezobrazuje (protože je smazaný).

Pojďme se zaměřit na tu poslední operaci, na smazání dokumentu. Analytik popíše use case, jakým způsobem uživatel dokument smaže,  v kterých případech dokument smazat lze a v kterých nelze. UX designer nakreslí tlačítko pro smazání. A co technický design?

Ten popíše, jakým způsobem bude dokument smazán. 

• Smažeme záznam o dokumentu v tabulce DOCUMENT.
• Odstraníme link (záznam z vazební tabulky) mezi tabulkou DOCUMENT a případem. 
• Zneplatníme link (záznam z vazební tabulky) mezi tabulkou DOCUMENT a případem. 
• Zneplatníme záznam v tabulce DOCUMENT, např. nastavíme status Deleted.

Každý z těchto způsobů má své výhody a naopak nevýhody.