Technický dluh ve firemním softwaru: jak ho poznat a splácet

Firma si objedná úpravu, která před dvěma lety trvala tři dny. Dnes na ni dodavatel dává dva týdny a v nabídce přibyla věta o „nutném zásahu do jádra systému". Navenek se přitom nezměnilo nic — tentýž systém, tentýž typ úpravy, často i tentýž tým. Změnilo se jen to, kolik starých rozhodnutí musí někdo obejít, než se dostane na místo, kam má přidat jedno tlačítko.

Přesně to je technický dluh. Není to nadávka na programátory ani důkaz, že někdo pracoval špatně. Je to rozdíl mezi tím, jak je software postavený dnes, a tím, jak by musel být postavený, aby se v něm dalo pohodlně pracovat zítra. Tento rozdíl vzniká zcela přirozeně — mění se byznys, mění se požadavky, mění se knihovny a platformy pod vámi. Problém nastává až tehdy, když o něm nikdo nevede záznam a jeho úroky se platí potichu, v podobě stále delších odhadů a stále opatrnějších vývojářů.

Nejužitečnější rozlišení, které si jako netechnický majitel můžete osvojit, je rozdíl mezi dluhem, který někdo vědomě vzal, a dluhem, který se nikdy nerozhodl vzniknout.

Vědomý dluh je legitimní byznysové rozhodnutí. Potřebujete stihnout sezónu, tak se ceník na tři měsíce zadrátuje přímo do kódu místo konfigurovatelného modulu. Pilot pro jednoho zákazníka běží s ručním exportem místo integrace, protože netušíte, jestli pilot vůbec přežije. To jsou správná rozhodnutí — za předpokladu, že splňují tři podmínky: je to zapsané, má to vlastníka a má to datum splatnosti. Bez těchto tří věcí to není půjčka, ale jen odklad, na který se zapomene.

Náhodné hnití nikdo nerozhodl. Vzniká z odchodů lidí, z přetrvávajícího copy-paste, z knihoven, které tři roky nikdo neaktualizoval, z testů, které se přestaly psát, když byl tlak, a už se nezačaly. Tento typ dluhu je nebezpečnější, protože nemá stopu — nikde není zápis, ve kterém by stálo „vědomě to děláme takhle".

Nemusíte rozumět architektuře, abyste věděli, že máte problém. Technický dluh se projevuje v číslech a v chování lidí, které máte před očima.

Odhady rostou u srovnatelných úkolů. Ne u nových a složitějších věcí — to je normální. Ale pokud „přidat pole do formuláře" stálo loni dva dny a dnes stojí týden, platíte úroky.

Existuje modul, kterého se všichni bojí. Poznáte ho podle toho, jak o něm tým mluví: „do fakturace bych radši nešel", „to se musí dělat přes víkend". Strach z dotyku je nejspolehlivější indikátor, jaký máte k dispozici.

Po každém vydání se pokazí něco jiného. Pokud oprava v objednávkách rozbije reporty, systém nemá hranice mezi částmi a nemá záchrannou síť. Ta záchranná síť se jmenuje automatizované testy a je to téma, které se vyplatí řešit dřív, než začnete počítat škody — víc k tomu v textu o automatizaci testování softwaru.

Onboarding nového vývojáře trvá nepřiměřeně dlouho. Pokud se nový člověk dostane k prvnímu samostatnému úkolu až po měsících, systém je buď nezdokumentovaný, nebo nekonzistentní — nejčastěji obojí.

Všechno důležité ví jeden člověk. Když je odpověď na otázku „kdo tomu rozumí?" vždycky totéž jméno, nemáte dodavatele, máte jednoho člověka s rizikem.

Technický dluh, který není nikde zapsaný, neexistuje pro nikoho kromě vývojářů — a ti ho v nabídce schovají do odhadu. Prvním krokem je proto registr dluhu: obyčejná tabulka, kde má každá položka čtyři sloupce — čeho se týká, co v byznysu blokuje nebo ohrožuje, co se stane, když neuděláme nic, a odhad nákladu na odstranění.

Druhým krokem je prioritizace. A tady dělá většina firem tutéž chybu: nechá pořadí na vývojářích. Vývojář přirozeně chce nejdřív opravit to, co ho nejvíc dráždí. To nemusí být to, co firmu nejvíc stojí.

Praktické kritérium má tři osy:

• Frekvence změn. Dluh v modulu, který se mění každý měsíc, generuje úroky. Dluh v modulu, který nikdo tři roky neotevřel, jich negeneruje téměř žádné.
• Expozice. Co je za tím modulem — tržby, osobní údaje, zákonná povinnost? Dluh v autentizaci nebo ve zpracování plateb má jinou váhu než dluh v interním exportu pro marketing.
• Cena odkladu. Některý dluh je stabilní a počká. Jiný roste — například neaktualizované závislosti, kterým skončí podpora, nebo platforma, ze které se později migruje výrazně dráž.

Technický dluh se nikdy nesplácí sám. Buď ho splácíte vy vědomě a v rozpočtu, nebo ho splácí každý další odhad — jen se to jmenuje jinak.

V praxi existují čtyři realistické způsoby, jak dluh snižovat. První dva se dají kombinovat, poslední dva jsou rozhodnutí, která se dělají jednou a těžko se vracejí.

Proč je přepis obvykle nejhorší možnost

Přepis vypadá lákavě, protože slibuje čistý start. Ve skutečnosti má tři systematické problémy.

První: starý systém obsahuje roky nezapsaných rozhodnutí. Ty zvláštní výjimky ve výpočtu slevy, které nikdo neumí vysvětlit, jsou zpravidla reakce na reálné situace. Přepis je mlčky zahodí a vy je objevíte v produkci.

Druhý: během přepisu firma platí dva týmy — jeden udržuje starý systém, druhý staví nový — a dlouhé měsíce nedostává žádnou novou funkcionalitu. To je přesně období, kdy konkurence něco dodá.

Třetí: nový systém začne generovat vlastní dluh od prvního měsíce. Pokud se nezměnil způsob práce, který dluh vytvořil, jste za tři roky na tom stejně. Proto má často větší hodnotu upravit proces dodávky a údržby softwaru po spuštění než technologii samotnou.

Přepis obhájíte tehdy, když platforma ztratila podporu, když na ni neumíte najít lidi, nebo když se byznysový model změnil natolik, že původní datový model už nedává smysl. I tehdy je obvykle bezpečnější postupná náhrada po modulech než výměna naráz.

Technický dluh je téma, na kterém se dá dobře otestovat kvalita dodavatele. Dobrý dodavatel ho pojmenuje sám a v byznysových důsledcích. Slabý ho buď zamlčí, nebo jím vysvětlí každý předražený odhad. Pokud právě vybíráte partnera, vyplatí se projít si checklist pro výběr softwarového dodavatele a doplnit si do něj body níže.

Do smlouvy nebo do rámce spolupráce patří několik konkrétních věcí:

• Definice hotového. Úkol je hotový tehdy, když má testy a dokumentaci, ne když „to funguje na demo".
• Vyhrazená kapacita na dluh. Explicitně dohodnuté procento kapacity měsíčně, s reportem, co se za ně udělalo.
• Aktualizace závislostí jako součást údržby. Ne jako samostatně fakturovaný projekt jednou za tři roky.
• Pravidelný report stavu. Kvartálně, v jazyce rizika: co se zhoršilo, co se splatilo, co hrozí.
• Vlastnictví kódu a přístupů. Včetně repozitáře, dokumentace a infrastrukturních přístupů na vaší straně.
• Předávací doložka. Popis toho, co dostanete, pokud spolupráci ukončíte — je to nejlevnější pojistka proti závislosti.

V INTERFASE řešíme tyto body raději na začátku spolupráce než při prvním konfliktu; podrobnosti k našemu přístupu k vývoji softwaru na míru jsou v samostatné sekci.

Ne každý dluh se vyplatí splácet. Pokud se systém do roka vypíná, pokud modul podporuje produkt, který ještě nemá ověřený odbyt, nebo pokud jde o část kódu, která se mění jednou za dva roky — nechte ji být. Splácení dluhu má význam jen tam, kde platíte úroky. Peníze vložené do vyčištění mrtvé části systému jsou ztracené stejně spolehlivě jako peníze vložené do jejího dalšího zanedbávání.

Technický dluh je ekonomická veličina, ne technická stížnost. Vědomý a časově ohraničený dluh je normální nástroj řízení; nebezpečný je ten, o kterém nikdo nevede záznam. Jako majitel ho poznáte podle rostoucích odhadů, regresí po vydáních, délky onboardingu a strachu z konkrétních modulů — všechno jsou to věci, které umíte změřit bez čtení kódu.

Prioritizujte podle frekvence změn, expozice a ceny odkladu, ne podle toho, co tým nejvíc dráždí. Splácejte průběžně nebo přes vyhrazené procento kapacity, přepis nechte jako poslední možnost a i tehdy upřednostněte postupnou náhradu po modulech. A hlavně: domluvte si způsob, jakým se o dluhu bude reportovat, ještě předtím, než začne bolet.

Pokud potřebujete nezávislý pohled na stav vašeho systému a odhad, co z dluhu reálně stojí za splacení, ozvěte se nám a projdeme si to spolu.