Pro mnoho lidí a týmů je náročné změnit svůj přístup a zažité postupy ze dne na den. Člověk se rád drží svých zvyků, zůstává v zajetých kolejích a nechce je měnit. Jak se dočtete, nebyli jsme v jednoduché situaci a popravdě řečeno, najít společnou řeč nám chvíli trvalo. Ale teď jsme na dobré cestě. Jaké hlavní principy a postupy chceme uplatňovat při vývoji produktů, správě a provozu aplikací a mít je v našem DNA? Čtěte dál a dozvíte se víc.

 

 

Úvodem trocha historie

Risk Services tribe zahájil svou činnost v roce 2018 jako součást probíhající agilní transformace Komerční banky. Vznikl spojením tří týmů. První tým vyvíjel velké IT aplikace za pomoci tradičních způsobů a následně je předával do oddělení provozu, které se staralo o jejich běžný chod. Druhý tým vytvářel malá taktická řešení pro risk management a všechny aplikace si provozoval sám. A třetí tým stavěl analytická a reportingová řešení v datovém skladu. Uvedené týmy doplňovalo ještě několik chytrých lidí z provozní části risk managementu, architektury a security.

Doslova během pár dní jsme tak vytvořili tribe složený z devadesáti lidí a ti dostali na starost téměř sto různě velkých aplikací, které vznikly v bance za posledních 15 let a slouží pro správu produktů v oblasti řízení kreditního rizika, zajištění, poskytování, správy a vymáhání úvěrových produktů. Nejen že byly tyto aplikace technologicky a procesně velmi rozdílné, ale každý tým si s sebou přinesl i vlastní pohled na jejich rozvoj a provoz. A před námi byl (a stále je) cíl transformačního programu KB 2025 – tvorba Nové digitální banky.

 

Zákazník a vlastník produktu

Zákazník je pro nás na prvním místě a cílíme na to, aby byl ve středu naší pozornosti. Netýká se to jen zákazníků společnosti, tedy klientů naší banky, ale i týmů uvnitř organizace, které využívají naše produkty.

To, aby tento přístup nebyl jen klišé, je výzvou především pro naše produktové vlastníky. Podle průzkumů je 30 % funkcionalit každého produktu používáno zákazníky jen zřídka a 50 % funkcionalit téměř vůbec. Velkým úkolem produktového vlastníka je blíže poznat zákazníka, odhalit a dodat 20 % nejčastěji používaných funkcionalit produktu. Bez produktového vlastníka sice tým dělá krásnou architekturu, udržuje a rozvíjí aplikace v moderních nástrojích, ale nikdy neví, jestli zákazník skutečně ocení jeho produkt.

Produktový vlastník u nás v Risku začíná budovat nový produkt postupně, a to pomocí tzv. MVP přístupu. A často musí říkat NE. Každý den musí rozhodnout, na čem bude vývojový tým pracovat, čemu má věnovat svoji kapacitu a kam zaměřit svoji pozornost.

 

Kultura DevOps

DevOps je u nás jen jiný název pro kulturu spolupráce a společných cílů. DevOps je hlavně o lidech a až na druhém místě jsou procesy a technologie. Při vývoji aplikací prosazujeme kulturu, která zdůrazňuje komunikaci, spolupráci a integraci mezi byznysem, vývojem, QA, provozem a bezpečností. Týmy sestavujeme tak, aby měly všechny potřebné kompetence pro provoz a rozvoj produktu – někdy je samozřejmě nemají a v takovém případě jim pomůže vedlejší tým, který danou kompetenci má. Víme, jak je skvělé, když máme rozvoj i provoz našich riskových produktů a aplikací pod kontrolou bez zbytečných závislostí na okolí.

 

Mikroservisní architektura

Mnoho našich systémů jsou monolitické aplikace, které často obsahují produkty a procesy i jiných týmů. Dlouho nám trvá, než integrační změnu nasadíme do produkce. Zkrátka si s sebou neseme dědictví – Legacy. Někdo by v tom viděl problém, my příležitost. Řada systémů musí projít velkou obměnou, aby podporovaly nové digitální procesy. Při obměně systémů vycházíme z principů servisně orientované architektury a využíváme koncept microservices.

Také se nám hodí, že máme mnoho šikovných lidí, kteří vytvářeli původní systémy a mají silnou obchodní znalost. Náš mikroservisní přístup nám umožňuje na těchto základech stavět. Týmy vytváří služby, které jsou ohraničeny svým kontextem, autonomně vyvíjené, nezávisle nasaditelné, decentralizované a obvykle sestavené a nasazené do produkce pomocí automatizovaných procesů. Dáváme si dobrý pozor, abychom služby navrhovali podle business domén a dobře se starali o tu riskovou.

 

Automatizace a standardizace

Nejlepší vlastností produktivního vývojáře je lenost. Správný tým si snaží maximálně ulehčit život automatizací. Automatizujeme nasazování, monitoring aplikací a služeb, testování, infrastrukturu… prostě všechno. Chceme a musíme dodávat změny velmi často, a proto je automatizace a využívání standardních nástrojů, které připraví platformní týmy, alfou a omegou vývoje našich nových aplikací. Kapacity a čas našich vývojářů je cenný a nechceme ho plýtvat na rutinní úlohy.

U Legacy aplikací naopak pečlivě zvažujeme, zda se nám investice do automatizace vyplatí a zda má pro nás aplikace ještě přínos, anebo ji zrušíme.

 

Měříme cíle

Jak poznáme, že musíme investovat do obchodních funkcionalit v aplikaci? A kdy naopak potřebujeme investovat do technologických vylepšení, odstranění technického dluhu, nebo do vzdělání týmu? Obchodní cíle stanovujeme a měříme metodou OKR. V oblasti efektivity vývoje a provozu aplikací používáme něco podobného.

Společnost Google vydává už řadu let report s názvem „State of DevOps“, kde pravidelně zveřejňuje čtyři metriky, které firmy pro měření této oblasti používají. Rozhodli jsme se, že je budeme používat i my. Mean Time to Restore, Change Failure Rate měří kvalitu a chybovost softwaru. Lead time for Changes a Deployment frequency měří rychlost průchodu změny celým procesem.

U Legacy aplikací se nám ne vždy daří tyto metriky sbírat a vyhodnocovat, ale s tím umíme žít.

 

Závěrem

Je rok 2021 a mezi jednotlivými týmy si rozumíme o něco více než na začátku. Pomáhá nám v tom sdílení společných principů a společné vize. Líbí se vám náš přístup k budování produktů, vývoji a provozu aplikací? Prima, připojte se k nám a budujte riskovou doménu v KB spolu s námi.