Technický dlh vo firemnom softvéri: ako ho rozpoznať a splácať

Firma si objedná úpravu, ktorá pred dvoma rokmi trvala tri dni. Dnes na ňu dodávateľ dáva dva týždne a v ponuke pribudla veta o „nutnom zásahu do jadra systému". Navonok sa pritom nezmenilo nič — ten istý systém, ten istý typ úpravy, často aj ten istý tím. Zmenilo sa len to, koľko starých rozhodnutí musí niekto obísť, kým sa dostane na miesto, kam má pridať jedno tlačidlo.

Presne to je technický dlh. Nie je to nadávka na programátorov ani dôkaz, že niekto pracoval zle. Je to rozdiel medzi tým, ako je softvér postavený dnes, a tým, ako by musel byť postavený, aby sa v ňom dalo pohodlne pracovať zajtra. Tento rozdiel vzniká úplne prirodzene — mení sa biznis, menia sa požiadavky, menia sa knižnice a platformy pod vami. Problém nastáva až vtedy, keď o ňom nikto nevedie záznam a keď sa jeho úroky platia potichu, v podobe stále dlhších odhadov a stále opatrnejších vývojárov.

Najužitočnejšie rozlíšenie, aké si viete ako netechnický majiteľ osvojiť, je rozdiel medzi dlhom, ktorý niekto vedome vzal, a dlhom, ktorý sa nikdy nerozhodol vzniknúť.

Vedomý dlh je legitímne biznisové rozhodnutie. Potrebujete stihnúť sezónu, tak sa cenník na tri mesiace zadrôtuje priamo do kódu namiesto konfigurovateľného modulu. Pilot pre jedného zákazníka beží s ručným exportom namiesto integrácie, lebo netušíte, či pilot vôbec prežije. Toto sú správne rozhodnutia — za predpokladu, že spĺňajú tri podmienky: je to zapísané, má to majiteľa a má to dátum splatnosti. Bez týchto troch vecí to nie je pôžička, to je len odklad, na ktorý sa zabudne.

Náhodné hnitie nikto nerozhodol. Vzniká z odchodov ľudí, z pretrvávajúceho copy-paste, z knižníc, ktoré tri roky nikto neaktualizoval, z testov, ktoré sa prestali písať, keď bol tlak, a už sa nezačali. Tento typ dlhu je nebezpečnejší, lebo nemá stopu — nikde nie je zápisnica, v ktorej by stálo „vedome to robíme takto".

Nemusíte rozumieť architektúre, aby ste vedeli, že máte problém. Technický dlh sa prejavuje v číslach a správaní ľudí, ktoré máte pred očami.

Odhady rastú pri porovnateľných úlohách. Nie pri nových a zložitejších veciach — to je normálne. Ale ak „pridať pole do formulára" stálo vlani dva dni a dnes stojí týždeň, platíte úroky.

Existuje modul, ktorého sa všetci boja. Spoznáte ho podľa toho, ako o ňom tím hovorí: „do fakturácie by som radšej nešiel", „to sa musí robiť cez víkend". Strach z dotyku je najspoľahlivejší indikátor, aký máte k dispozícii.

Po každom vydaní sa pokazí niečo iné. Ak oprava v objednávkach rozbije reporty, systém nemá hranice medzi časťami a nemá záchrannú sieť. Tá záchranná sieť sa volá automatizované testy a je to téma, ktorú oplatí riešiť skôr, než začnete rátať škody — viac k tomu v texte o automatizácii testovania softvéru.

Onboarding nového vývojára trvá neprimerane dlho. Ak sa nový človek dostane k prvej samostatnej úlohe až po mesiacoch, systém je buď nezdokumentovaný, alebo nekonzistentný — najčastejšie oboje.

Všetko dôležité vie jeden človek. Keď je odpoveď na otázku „kto tomu rozumie?" vždy to isté meno, nemáte dodávateľa, máte jedného človeka s rizikom.

Technický dlh, ktorý nie je nikde zapísaný, neexistuje pre nikoho okrem vývojárov — a tí ho v ponuke schovajú do odhadu. Prvý krok je preto register dlhu: obyčajná tabuľka, kde má každá položka štyri stĺpce — čoho sa týka, čo v biznise blokuje alebo ohrozuje, čo sa stane, ak nespravíme nič, a odhad nákladu na odstránenie.

Druhý krok je prioritizácia. A tu robí väčšina firiem tú istú chybu: nechá poradie na vývojárov. Vývojár prirodzene chce najprv opraviť to, čo ho najviac irituje. To nemusí byť to, čo najviac stojí firmu.

Praktické kritérium má tri osi:

• Frekvencia zmien. Dlh v module, ktorý sa mení každý mesiac, generuje úroky. Dlh v module, ktorý nikto tri roky neotvoril, ich negeneruje takmer žiadne.
• Expozícia. Čo je za tým modulom — tržby, osobné údaje, zákonná povinnosť? Dlh v autentifikácii alebo v spracovaní platieb má inú váhu než dlh v internom exporte pre marketing.
• Cena odkladu. Niektorý dlh je stabilný a čaká. Iný rastie — napríklad neaktualizované závislosti, ktorým skončí podpora, alebo platforma, z ktorej sa neskôr migruje výrazne drahšie.

Technický dlh sa nikdy nespláca sám. Buď ho splácate vy vedome a v rozpočte, alebo ho spláca každý ďalší odhad — len sa to volá inak.

V praxi existujú štyri realistické spôsoby, ako dlh znižovať. Prvé dva sa dajú kombinovať, posledné dva sú rozhodnutia, ktoré sa robia raz a ťažko sa vracajú.

Prečo je prepis zvyčajne najhoršia možnosť

Prepis vyzerá lákavo, lebo sľubuje čistý štart. V skutočnosti má tri systematické problémy.

Prvý: starý systém obsahuje roky nezapísaných rozhodnutí. Tie zvláštne výnimky vo výpočte zľavy, ktoré nikto nevie vysvetliť, sú spravidla reakcie na reálne situácie. Prepis ich mlčky zahodí a vy ich objavíte v produkcii.

Druhý: počas prepisu firma platí dva tímy — jeden udržiava starý systém, druhý stavia nový — a dlhé mesiace nedostáva žiadnu novú funkcionalitu. To je presne obdobie, keď konkurencia niečo dodá.

Tretí: nový systém začne generovať vlastný dlh od prvého mesiaca. Ak sa nezmenil spôsob práce, ktorý dlh vytvoril, o tri roky ste na tom rovnako. Preto má často väčšiu hodnotu upraviť proces dodávky a údržby softvéru po spustení než technológiu samotnú.

Prepis obhájite vtedy, keď platforma stratila podporu, keď na ňu neviete nájsť ľudí, alebo keď sa biznisový model zmenil natoľko, že pôvodný dátový model už nedáva zmysel. Aj vtedy je zvyčajne bezpečnejšia postupná náhrada po moduloch než výmena naraz.

Technický dlh je téma, na ktorej sa dá dobre otestovať kvalita dodávateľa. Dobrý dodávateľ ho pomenuje sám a v biznisových dôsledkoch. Slabý ho buď zamlčí, alebo ním vysvetlí každý predražený odhad. Ak práve vyberáte partnera, oplatí sa prejsť si checklist na výber softvérového dodávateľa a doplniť si doň body nižšie.

Do zmluvy alebo do rámca spolupráce patrí niekoľko konkrétnych vecí:

• Definícia hotového. Úloha je hotová vtedy, keď má testy a dokumentáciu, nie keď „to funguje na demo".
• Vyhradená kapacita na dlh. Explicitne dohodnuté percento kapacity mesačne, s reportom, čo sa za ne spravilo.
• Aktualizácie závislostí ako súčasť údržby. Nie ako samostatne fakturovaný projekt raz za tri roky.
• Pravidelný report stavu. Kvartálne, v jazyku rizika: čo sa zhoršilo, čo sa splatilo, čo hrozí.
• Vlastníctvo kódu a prístupov. Vrátane repozitára, dokumentácie a infraštruktúrnych prístupov na vašej strane.
• Odovzdávacia doložka. Popis toho, čo dostanete, ak spoluprácu ukončíte — je to najlacnejšia poistka proti závislosti.

V INTERFASE riešime tieto body radšej na začiatku spolupráce než pri prvom konflikte; podrobnosti k nášmu prístupu k vývoju softvéru na mieru sú v samostatnej sekcii.

Nie každý dlh sa oplatí splácať. Ak sa systém do roka vypína, ak modul podporuje produkt, ktorý ešte nemá overený odbyt, alebo ak ide o časť kódu, ktorá sa mení raz za dva roky — nechajte ho tak. Splácanie dlhu má význam len tam, kde platíte úroky. Peniaze vložené do vyčistenia mŕtvej časti systému sú stratené rovnako spoľahlivo ako peniaze vložené do jeho ďalšieho zanedbávania.

Technický dlh je ekonomická veličina, nie technická sťažnosť. Vedomý a časovo ohraničený dlh je normálny nástroj riadenia; nebezpečný je ten, o ktorom nikto nevedie záznam. Ako majiteľ ho spoznáte podľa rastúcich odhadov, regresií po vydaniach, dĺžky onboardingu a strachu z konkrétnych modulov — všetko sú to veci, ktoré viete odmerať bez čítania kódu.

Prioritizujte podľa frekvencie zmien, expozície a ceny odkladu, nie podľa toho, čo tím najviac irituje. Splácajte priebežne alebo cez vyhradené percento kapacity, prepis nechajte ako poslednú možnosť a aj vtedy uprednostnite postupnú náhradu po moduloch. A hlavne: dohodnite si spôsob, akým sa o dlhu bude reportovať, ešte predtým, než začne bolieť.

Ak potrebujete nezávislý pohľad na stav vášho systému a odhad, čo z dlhu reálne stojí za splatenie, ozvite sa nám a prejdeme si to spolu.