Technical debt mérlegszemléletben: hogyan magyarázzuk el a CFO-nak
A technikai adósság nem műszaki, hanem pénzügyi fogalom. Megmutatjuk, hogyan vezessük kamatfizetésként, amortizációként és mérlegben is látható tételként.
A technikai adósságnak kamata van. Ha nem fizetjük, a kamat kamatos kamattá válik.
A fejlesztők érzik a technikai adósságot. A CFO nem érti, miért kell "refactor-ra" költeni, amikor "működik a rendszer". Ezért kamat-nyelven magyarázzuk el. Ha a rendszer 100 egység munkaórát igényel hónapban egy új feature-höz, és a debt miatt ez 140 — akkor minden hónapban 40 óra "kamatot" fizetsz. Éves szinten 480 óra. Ha az órabér 15 000 HUF, az 7,2 M HUF kamatkiadás egy év alatt.
A debt 4 típusa — különböző kamatlábbal
- Szándékos, rövid távú: "csúszik a deadline, most gyorsan megoldjuk, holnap visszajavítjuk" — kamatláb alacsony, ha tényleg visszajavítjuk
- Szándékos, hosszú távú: "tudjuk, hogy nem ideális, de egyelőre elég" — közepes kamat, követni kell
- Véletlen: nem tudtuk, hogy jobb megoldás van — nincs szégyen, de dokumentálni kell
- Elhanyagolási: senki nem gondoskodik róla — ez a legdrágább, mert kamatos kamattá válik
A debt ledger
Nálunk minden projektben van egy tech-debt-ledger.md, amiben minden debt tétel rögzítve van: mikor keletkezett, miért, becsült "kamatláb" (órákban), javasolt visszafizetési határidő. A sprint tervezésnél mindig a ledger alapján döntünk, mennyi kapacitást allokálunk törlesztésre. Ez az ügyfél számára is láthatóvá teszi, hogy nem önkényes "refactor igény", hanem számolt pénzügyi döntés.
Egy példa ügyfélnél 6 hónapja vezetjük a ledger-t. 14 tétel. Havi 20–25% kapacitás megy törlesztésre. Az elmúlt fél évben a havi átlag új feature time csökkent 34%-kal — miközben a kapacitás nem nőtt. Ez a legszebb bizonyítéka annak, hogy a törlesztés megéri. És ezt meg tudjuk mutatni Excel-ben.