Dług techniczny – czy Twoja firma go spłaca, czy tylko dokładasz odsetki?
Gdy słyszysz „dług techniczny”, pewnie myślisz o syfie w kodzie, który kiedyś trzeba będzie posprzątać. I to prawda – ale tylko połowiczna. Bo dług techniczny to nie tylko bałagan, to realny koszt biznesowy. Widzę to regularnie u klientów: zespół spędza 40% czasu na łataniu starego kodu zamiast na nowych funkcjach. Albo wdrożenie nowego API trwa dwa tygodnie, bo „trzeba najpierw przepisać legacy”.
Problem w tym, że większość małych firm nie ma pojęcia, jak zmierzyć ten dług. Po prostu czują, że „coś jest nie tak”. A bez pomiaru nie ma zarządzania. W tym artykule pokażę Ci trzy konkretne wskaźniki, które sam stosuję w audytach u klientów. Nie potrzebujesz do nich skomplikowanych narzędzi, tylko odrobiny analitycznego myślenia.
Dlaczego większość firm nie mierzy długu technicznego (i dlaczego to błąd)?
Zacznijmy od sedna: dług techniczny to pojęcie zapożyczone z finansów. W coding world oznacza decyzje projektowe, które są szybsze w krótkim terminie, ale kosztują w przyszłości. Jak kredyt – bierzesz dziś, oddajesz jutro z odsetkami. Problem pojawia się, gdy odsetki zaczynają zżerać Twój zysk.
Wiele małych firm działa w trybie „najpierw produkt, potem refaktor”. Rozumiem to – sam tak robiłem. Ale po latach widzę, że to podejście ma swoją cenę. Klient, który przyszedł do nas z aplikacją SaaS, notował coraz wolniejszy rozwój. Każda nowa funkcja wymagała modyfikacji w 5 miejscach, a testy regresyjne trwały tydzień. Gdy zmierzyliśmy jego dług techniczny, okazało się, że aż 60% czasu zespołu idzie na utrzymanie i poprawki. Zamiast rozwijać produkt, gasili pożary.
Większość firm nie mierzy tego, bo nie wie jak. Albo boi się wyniku. Albo myśli, że dług techniczny to tylko metafora. A prawda jest taka, że da się go zmierzyć i – co ważniejsze – zarządzać nim. Oto trzy wskaźniki, które pokazują realny obraz.
Wskaźnik 1: Współczynnik kosztów utrzymania (Maintenance Cost Ratio – MCR)
To najprostszy i najbardziej wymowny wskaźnik. MCR mówi, jaki procent czasu zespołu idzie na utrzymanie istniejącego kodu (bugi, refaktoring, optymalizacje) w porównaniu z nowymi funkcjami.
Jak to zmierzyć?
- Zbierz dane z ostatnich 3–6 miesięcy (np. z Jiry, Asany, wykresów commitów).
- Oznacz zadania jako „utrzymanie” i „nowa funkcjonalność”.
- Podziel czas poświęcony na utrzymanie przez całkowity czas rozwoju i pomnóż przez 100%.
Przykład:
Zespół 4 osób pracuje 160 godzin miesięcznie. Jeśli 80 godzin idzie na łatki, refaktoring i obsługę bugów, MCR wynosi 50%.
Co to oznacza?
- MCR < 20% – jest dobrze, dług nie zżera budżetu.
- MCR 20–40% – ostrzeżenie, warto przyjrzeć się procesom.
- MCR > 40% – alarm! Więcej czasu tracisz na naprawianie niż na rozwój.
U jednego z klientów (mały e-commerce oparty na WooCommerce z customowym motywem) MCR wynosił 70%. Każda aktualizacja wtyczki psuła integrację, a nowe funkcje były odkładane w nieskończoność. Po audycie wyodrębniliśmy warstwę API i zrefaktorowaliśmy najgorsze fragmenty. Po 3 miesiącach MCR spadł do 30%. Oszczędność czasu: 40% tygodniowo.
Wskaźnik 2: Czas wprowadzenia zmiany (Time to Implement – TTI)
TTI mierzy, ile czasu zajmuje wprowadzenie nowej, prostej funkcji – np. dodanie pola w formularzu czy zmiana koloru przycisku. Wybierz małą, powtarzalną zmianę (np. dodanie kolumny w tabeli) i mierz czas od zgłoszenia do wdrożenia na produkcję.
Dlaczego to działa?
W zdrowym kodzie taka zmiana zajmuje kilka godzin. W zadłużonym może trwać dni, bo trzeba przejrzeć 20 plików, znaleźć właściwe miejsce, a potem bać się, że coś zepsujesz.
Przykład:
U klienta (platforma SaaS dla małych firm) dodanie prostego przycisku eksportu danych zajmowało średnio 3 dni. Po refaktoringu warstwy widoków i API – 3 godziny. Ponieważ robili średnio 4 takie zmiany miesięcznie, oszczędzili 12 dni deweloperskich na miesiąc.
Jak zinterpretować?
- TTI < 1 dzień – kod jest elastyczny.
- TTI 1–3 dni – umiarkowany dług, warto poprawić architekturę.
- TTI > 3 dni – poważny dług, który hamuje rozwój.
Wskaźnik 3: Gęstość defektów (Defect Density – DD)
DD to liczba błędów produkcyjnych na 1000 linii kodu (lub na funkcję). Im wyższa, tym więcej „dziur” w kodzie, które wymagają łatania.
Jak mierzyć?
- Zlicz błędy zgłoszone przez użytkowników w ostatnim kwartale.
- Podziel przez szacowaną liczbę linii kodu (lub liczbę funkcji).
- Wynik to DD.
Przykład:
Aplikacja ma 100 000 linii kodu i w kwartale zgłoszono 50 błędów. DD = 0,5 błędu na 1000 linii. Jeśli po refaktoringu DD spadnie do 0,2, oznacza to poprawę jakości.
Dlaczego to ważne?
Wysoki DD nie tylko irytuje użytkowników, ale też generuje koszty wsparcia i łatania. Klient z sektora fintech miał DD na poziomie 1,2 – oznaczało to, że co miesiąc tracili 20 godzin na poprawki krytycznych błędów. Po wdrożeniu testów automatycznych i refaktoringu najgorszych modułów DD spadł do 0,4.
Jak te wskaźniki łączą się w obraz długu technicznego?
Każdy z nich patrzy z innej strony:
- MCR mówi o kosztach utrzymania – ile czasu zjada stary kod.
- TTI mówi o elastyczności – jak szybko możesz reagować na rynek.
- DD mówi o jakości – jak bardzo kod jest podatny na błędy.
Razem tworzą trójkąt diagnostyczny. Jeśli MCR > 40%, TTI > 3 dni i DD > 0,5 – masz poważny problem. Jeśli tylko jeden wskaźnik jest podwyższony, może to wynikać z bieżącego projektu.
Praktyczne kroki do obniżenia długu technicznego w małej firmie
Jeśli zmierzyłeś wskaźniki i wynik nie jest optymistyczny, nie panikuj. Oto co możesz zrobić bez zatrzymywania rozwoju:
1. Zrefaktoruj najczęściej modyfikowany kod
Nie próbuj poprawić wszystkiego naraz. Zidentyfikuj moduły, które zmieniasz najczęściej (np. koszyk, panel logowania) i popraw ich architekturę. To da największy zwrot z inwestycji.
2. Wprowadź testy automatyczne dla krytycznych ścieżek
Brak testów to jedna z głównych przyczyn długu technicznego. Zacznij od testów integracyjnych dla najważniejszych procesów (np. zakup w e-commerce, rejestracja użytkownika). Zobaczysz spadek DD w ciągu kilku miesięcy.
3. Ustal limit MCR
Umów się z zespołem (lub z samym sobą), że maksymalnie 30% czasu może iść na utrzymanie. Reszta – na nowe funkcje. Jeśli MCR przekracza limit, przeznacz sprint na refaktoring.
4. Mierz regularnie
Postaw sobie przypomnienie co kwartał – zmierz trzy wskaźniki i zanotuj. Po roku zobaczysz trend.
Podsumowanie
Dług techniczny to nie fatum, które wisi nad każdym projektem – to zjawisko, którym można zarządzać. Klucz to przestać go ignorować i zacząć mierzyć. Wskaźniki MCR, TTI i DD to praktyczne narzędzia, które możesz wdrożyć od ręki. Nie wymagają fancy narzędzi, tylko analizy Twojego procesu.
Jako praktyk widzę, że małe firmy, które regularnie mierzą dług techniczny, szybciej rozwijają produkt, rzadziej popełniają błędy i lepiej reagują na zmiany rynku. A to przekłada się na realne pieniądze.
Jeśli potrzebujesz wsparcia w audycie technicznym swojego kodu – w JurskiTech.pl pomagamy firmom mierzyć i redukować dług techniczny, żeby mogły skupić się na rozwoju. Ale nawet jeśli zdecydujesz się działać samodzielnie, te trzy wskaźniki dadzą Ci solidny punkt wyjścia.
