Prokop Simek (DX Heroes): Technologický dluh je strašák všech vývojářských týmů. Jak s ním naložit?
Nespokojenost programátorů, pozdní dodávky práce, chyby v aplikaci nebo pomalý vývoj byznysu. To všechno může mít na svědomí technologický dluh. Tento nepříliš známý pojem značí laicky řečeno nepořádek ve vývojářských datech a týká se více či méně každé firmy, která využívá digitální technologie. Jak mu předejít a jak s ním naložit, když už se ve firmě objeví? O tom se ve svém autorském komentáři pro Digibiz rozepsal CEO DX Heroes Prokop Simek.
Na první pohled ho jen tak nepoznáte. A právě v tom je největší zrádnost technologického dluhu: většina firem ho totiž nedokáže včas odhalit, podceňuje jej nebo dokonce ingoruje. A pak už jen hasí jeho následky.
Když chybí prostor pro kvalitu
Technologický dluh vzniká již v okamžiku, kdy začnete vyvíjet software. Objevuje se například u firem, které nemají času nazbyt a místo kvality psaného kódu dávají přednost rychlosti. Což zpravidla poskytne zárodek pro dluh, který se časem nabalí jako obrovská sněhová koule – a mnohdy už není cesty zpět. Často se s ním lze setkat také v korporacích, zejména v některých konzervativních odvětvích, jako je třeba bankovní sektor, kde je dokonce technologický dluh vynucený regulacemi a legislativou. Banky totiž musí používat verze softwaru, jež jsou pečlivě ověřené, ale bohužel také mnohdy neaktuální. Hrozí pak, že si systém nebude rozumět s moderními technologiemi, které je třeba časem implementovat.
Určitá míra technologického dluhu je každopádně normální u každé firmy, protože škála digitálních nástrojů a modulů, se kterými musí vývojáři pracovat, je ohromná a často není možné mít o všech přehled. Platí, že dokud situace neomezuje jednotlivce nebo tým, nejde o zásadní problém. Ten nastává až ve chvíli, kdy začnete silně pociťovat jeho následky.
Zamračený vývojář značí špatný kód
Technologický dluh se dá snadno vysledovat na dvou důsledcích, které po sobě zanechává: problém se projevuje buď v samotném produktu, nebo nespokojeností v týmu. V prvním případě mohu zmínit banku, která využívá zastaralý způsob přihlašování a kvůli tomu špatně zavádí nové prvky požadované v bankovním světě. Jako konkrétní příklad mohu uvést open banking nebo podporu třetích stran (fintechů), které chtějí na bankovních službách stavět svůj byznys. Když se nové funkcionality vyvíjí byť jen o 25 % pomaleji, jsou pak také o 25 % dražší.
Druhým častým následkem technologického dluhu je nespokojenost vývojářů a špatná atmosféra v týmu. Je však třeba podotknout, že technologická příčina mizerné firemní nálady se vystopuje jen nesnadno. Daleko jistějším způsobem je proto zaměření se na produkt. Pokud jej lze například jen těžko rozšiřovat nebo se vyznačuje velkou chybovostí a do toho máte zamračené kolegy, pak je právě technologický dluh tou nejpravděpodobnější příčinou všeobecných chmur.
Jak z toho ven
Technologický dluh by měl zaměstnávat celý tým, samozřejmě pod patřičným vedením. Ve větších korporátech bývá určení odpovědnosti za dluh poněkud složitější, ale i tam existuje cesta – jako příklad lze uvést banku Erste, která dala vzniknout tzv. tribům neboli interním vývojářským spolkům složeným z programátorů napříč firmou. Při nich se pak zrodily role softwarových architektů, kteří dávají do vývoje stabilizační prvky a starají se právě také o technologický dluh. Další kompetentní člověk, jenž si může vzít dluh na starost, je produktový manažer, případně product owner.
Jestliže firmě přeroste technologický dluh přes hlavu, měla by se obrátit na externí partnery, kteří mají s problémem zkušenost – tedy zkušenost s konkrétní technologií nebo s produktem. Tito experti by měli znát doménu, ve které firma působí, tedy danou technologii, nebo produkt. Například pro finanční aplikaci by měli znát oblast bankovnictví a financí, pro bezpečnostní aplikaci sektor bezpečnosti, pro automotive by měli zase mít znalosti z automobilového průmyslu, a tak dále.
Pokud si pro řešení problému vyberete partnera, měl by jej dokázat nejen najít, ale rovnou i vyřešit. Obvyklá praxe ve světě konzultačních firem je totiž taková, že přijde konzultant, najde chyby, sepíše zprávu a odejde. Taková „pomoc“ většinou přináší jen malý posun k lepšímu, dost často rovnou skončí v koši. Správný partner by měl dohlédnout na napravení chyb i nastavení správných procesů, které pomáhají preventivně problémům předejít. A právě o to se snažíme i s DX Heroes – pěstujeme dlouhodobá partnerství, přičemž klademe důraz na jasně vydefinovanou práci s jasným koncem, díky kterému se klient necítí vázaný na naše know-how a nemá pocit vendor-locku. Výhodou tohoto přístupu je rovněž znalost klienta, na předchozí spolupráci se zkrátka lépe navazuje.
Dluh není ostuda
Je třeba mít na paměti, že technologický dluh není nic neobvyklého. Vývoj technologií je nesmírně dynamický, jen těžko se s ním drží krok. Vývojář bude jen těžko znát hned všechny nejžhavější trendy v technologiích, které bude chtít v kódu uplatnit. Úplná uzavřenost vůči novotám je ovšem také na škodu – někdy mohou být příčinou technologického dluhu právě sami programátoři, kteří udržují svůj 25 let starý systém, protože oceňují jeho neměnnost. Případně jej rovnou adorují a tuto výjimečnost dokládají tím, že přece přežil dekády.
Proto je v prevenci tolik důležitý horizontální růst lidí v rámci týmu. Každý by se měl vzdělávat v technologii, kterou přispívá celku. Kde se nemyslí na vzdělávání, tam technologický dluh vzniká nejrychleji. Předejít mu pomáhá mentoring a další vzdělávací aktivity.
I proto je důležité s technologickým dluhem počítat už od samého začátku a jeho průběžné řešení musí být zaběhnutý proces v rámci celého týmu. Včetně pravidelného vyčlenění části zdrojů na jeho zvládání. Jakákoliv investice – ať už časová, energická či finanční – se totiž firmě v tomto směru mnohonásobně vyplatí.