Dług techniczny językiem zarządu: jak go policzyć i kiedy spłacać

Dług techniczny to nie problem estetyczny w kodzie, tylko odsetki płacone w velocity: każda funkcja kosztuje więcej godzin, niż powinna, bo zespół pracuje na skrótach z przeszłości. Policzyć go można prosto: lista top pozycji długu, przy każdej koszt utrzymania status quo (godziny tracone miesięcznie) i koszt spłaty (tygodnie pracy). Spłacać warto wtedy, gdy odsetki przekraczają ratę, a nie wtedy, gdy inżynierowie mówią, że kod jest brzydki. Ten tekst daje founderom i zarządom model do tej decyzji, bo rozmowa "biznes vs inżynieria" o długu jest zwykle jałowa tylko dlatego, że obie strony mówią innymi jednostkami.

Dług techniczny to świadome lub nieświadome skróty w technologii, które przyspieszyły dostarczenie kiedyś, a spowalniają je teraz: architektura z czasów MVP dźwigająca 50x większy ruch, brak testów w krytycznych ścieżkach, biblioteki bez wsparcia, wiedza wyłącznie w głowach dwóch osób.

Długiem nie jest: kod, który komuś się nie podoba, technologia starsza niż modna, ani wszystko, czego nowy inżynier nie napisałby tak samo. Rozróżnienie jest proste: dług generuje mierzalny koszt (godziny, awarie, ryzyko), reszta to preferencje. Zarząd finansuje spłatę kosztów, nie preferencji.

Krok 1: inwentaryzacja top 5-10. Nie katalogujcie wszystkiego, bo pełna lista długu w dojrzałym systemie ma setki pozycji i zero wartości decyzyjnej. Inżynierowie w godzinę wskażą 5-10 pozycji, które bolą najbardziej.

Krok 2: wycena odsetek. Przy każdej pozycji: ile godzin miesięcznie kosztuje jej istnienie? Składniki: dłuższy czas developmentu funkcji w tym obszarze, godziny na powtarzalne awarie i hotfixy, czas onboardingu nowych osób. To będzie estymacja i tak ma być, dokładność ±30% wystarcza do decyzji.

Krok 3: wycena spłaty. Ile tygodni pracy kosztuje usunięcie pozycji i co odblokowuje (szybszy development, mniej awarii, możliwość zbudowania funkcji X, która dziś jest zablokowana).

Przykład: brak testów w checkout kosztuje 40-60 godzin miesięcznie w regresjach i ręcznych testach, a spłata to 3-4 tygodnie pracy, co odblokowuje bezpieczne iteracje na konwersji. Kolejny przykład: monolit w module raportów kosztuje 30 godzin miesięcznie, bo każda zmiana dotyka całości, a spłata to 6-8 tygodni pracy, co odblokowuje równoległą pracę dwóch zespołów.

Taka tabela zamienia jałowy spór o "czas na refactoring" w decyzję portfelową, którą zarząd umie podjąć: pozycje o wysokich odsetkach i taniej spłacie idą do roadmapy, pozycje o niskich odsetkach czekają, niezależnie od tego, jak bardzo drażnią estetycznie.

Spłacaj, gdy: odsetki pozycji przekraczają miesięczny koszt raty spłaty (matematyka domyka się w kwartały), dług blokuje konkretną pozycję roadmapy albo skalowanie przed spodziewanym wzrostem, albo pozycja generuje ryzyko binarne (bezpieczeństwo, zgodność, biblioteka tracąca wsparcie).

Nie spłacaj, gdy: moduł jest stabilny i rzadko dotykany (brzydki kod, którego nikt nie zmienia, ma odsetki bliskie zeru), produkt szuka PMF i za kwartał może wyglądać zupełnie inaczej (spłacanie długu w kodzie, który zostanie wyrzucony, to czysta strata), albo "spłata" jest w istocie przepisaniem systemu od zera, bo wielkie przepisania mają fatalną statystykę dowożenia.

W praktyce dobrze działa stały budżet: rezerwowanie rzędu 15-20% mocy zespołu na spłatę długu i utrzymanie, cykl w cykl, zamiast heroicznych "kwartałów refactoringu". Stały strumień jest łatwiejszy do obrony w planowaniu i nie zatrzymuje roadmapy. Te 15-20% to praktyka rynkowa, nie prawo fizyki: po dużym wzroście albo przed skalowaniem bywa, że przejściowo trzeba więcej.

W due diligence dług techniczny nie jest flagą. Flagą jest founder, który o swoim długu nie wie albo twierdzi, że go nie ma. Tabela jak wyżej, pokazana w data roomie z planem spłaty, działa na korzyść wyceny, bo dowodzi kontroli. Pisałem o tym w przygotowaniu startupu do tech DD; z 30+ procesów DD, które prowadziłem, spółki z udokumentowanym długiem wychodziły z lepszą narracją niż te "bez długu".

Ile długu technicznego jest normalne? Każdy system, który rósł szybko, ma dług i to jest zdrowe: brak długu oznacza zwykle, że zespół optymalizował kod zamiast szukać rynku. Miarą nie jest ilość długu, tylko trend odsetek: jeśli czas dostarczania podobnych funkcji rośnie kwartał do kwartału, odsetki wymknęły się spod kontroli.

Jak przekonać zarząd do budżetu na spłatę? Nie słowem "refactoring", tylko tabelą odsetek: pokaż, ile godzin miesięcznie kosztuje status quo i co konkretnie odblokowuje spłata. Prośba "potrzebujemy czasu na jakość kodu" przegrywa z roadmapą zawsze. Rachunek "3 tygodnie pracy zwraca się w 2 miesiące i odblokowuje iteracje na checkoutcie" wygrywa często.

Czy nowy CTO powinien zacząć od spłaty długu? Od inwentaryzacji tak, od spłaty nie. Wielki refactoring w pierwszym kwartale, przed zrozumieniem produktu i priorytetów biznesowych, to klasyczny błąd nowego lidera technologii. Najpierw tabela odsetek i szybkie, tanie wygrane, duże spłaty dopiero pod konkretne cele roadmapy.

Co z długiem po software house? Oceniaj tak samo: odsetki i koszt spłaty per moduł, decyzje per moduł. Odruch "przepiszemy wszystko po dostawcy" bywa uzasadniony rzadko i zwykle zatrzymuje produkt na kwartały. Praktyczny plan przejęcia takiego kodu opisałem w tekście o przejściu z software house na własny zespół.

Jedna godzina z inżynierami na listę top 5, dwie godziny na wycenę odsetek i rat. Jeśli chcesz zrobić to z kimś, kto wycenia dług w procesach DD zawodowo, umów bezpłatny audyt: w 30 minut przejdziemy przez twój system i powiem, które pozycje policzyć najpierw. Więcej o zakresie na stronie usług.