Dług techniczny w startupie — jak go mierzyć, priorytetyzować i spłacać bez zatrzymywania delivery

Każdy startup ma dług techniczny. Problem nie jest w jego istnieniu — problem jest w braku systemu zarządzania nim. Gdy dług jest niekontrolowany, spowalnia każdą kolejną zmianę, zwiększa koszty i staje się głównym powodem opóźnień w delivery.

Ale jest też drugi błąd: traktowanie długu technicznego jako czegoś z czym trzeba walczyć za wszelką cenę. Celowy, zarządzany dług techniczny to narzędzie — pozwala szybciej trafiać na rynek i weryfikować założenia. Błąd to nie zaciąganie długu, tylko zaciąganie go bez planu spłaty.

Dług techniczny to każda decyzja techniczna, która przyspiesza krótkoterminowe delivery kosztem długoterminowego kosztu utrzymania i rozszerzania systemu.

To nie jest kod "brzydki" albo "nieelegancki". To konkretne decyzje z konkretnym kosztem: hardcodowane konfiguracje zamiast systemu zarządzania środowiskami; brak testów dla krytycznej logiki biznesowej; monolityczna architektura która nie da się skalować horyzontalnie; copy-paste logiki zamiast wspólnego modułu. Każdy z tych przykładów ma konkretny koszt: czas potrzebny na każdą kolejną zmianę rośnie, a ryzyko błędu rośnie proporcjonalnie.

Cztery praktyczne metryki które możesz śledzić od zaraz: (1) Cycle time — jak długo trwa od "commit" do "production"? Rośnie? Dług rośnie razem z nim. (2) Unplanned work ratio — jaki procent sprintu to nieplanowane prace (bugi, hotfixy, "szybkie poprawki")? Powyżej 20% to sygnał że dług przejmuje kontrolę.

(3) Time-to-change — ile czasu zajmuje zmiana jednej konkretnej funkcji? Jeśli rośnie mimo stałego rozmiaru teamu — dług rośnie. (4) Test coverage w krytycznych modułach — nie ogólny coverage, tylko w modułach przez które przechodzą pieniądze lub dane użytkowników. Poniżej 60% to ryzyko którego nie kontrolujesz.

Dług celowy to decyzja podjęta świadomie: "robimy to szybko teraz, wrócimy za 6 tygodni". Ma datę i właściciela. Jest wpisany do backlogu jako task.

Dług przypadkowy to decyzja podjęta bez świadomości: "zrobimy to najprościej jak się da" bez planu co potem. Kumuluje się niewidocznie i wychodzi przy każdym nowym feature. Większość startupów ma przewagę długu przypadkowego nad celowym. Pierwszym krokiem do kontroli jest audyt: lista decyzji które wiesz że wrócimy zapłacić, z szacunkowym kosztem spłaty.

Nie każdy dług trzeba spłacać. Trzy pytania pomagają decydować: (1) Czy ten dług spowalnia kolejne delivery? Jeśli tak — spłacaj teraz. Jeśli to izolowany fragment który rzadko się zmienia — możesz poczekać.

(2) Czy jesteśmy blisko rundy? Przed due diligence VC/PE — spłać dług w obszarach które inwestor sprawdzi: architektura, bezpieczeństwo, metryki, obserwowalność. To nie jest tylko kwestia wrażeń, to kwestia wyceny.

(3) Czy ten dług jest w krytycznej ścieżce użytkownika? Cokolwiek przez co przechodzi płatność, onboarding lub dane — spłacaj priorytetowo.

Prosty i sprawdzony: zarezerwuj 20% capacity sprintu na debt reduction. Nie jako "jeśli zostanie czas", ale jako sprint commitment widoczny w backlogu.

Dlaczego 20%? To wystarczy żeby stopniowo zmniejszać dług bez zatrzymywania nowych feature'ów. Mniej — dług rośnie szybciej niż go spłacasz. Więcej — delivery nowych funkcji spada i business zaczyna naciskać.

Wyjątek: "debt sprint" co kwartał. Jeden sprint w całości poświęcony spłacie największych długów. Wymaga akceptacji biznesu, ale daje nielinearny skok w quality.

Tech due diligence po długu technicznym to jeden z częstszych powodów niższych wycen lub dodatkowych covenantów w term sheecie.

Inwestor nie szuka perfekcji. Szuka dwóch rzeczy: czy team jest świadomy długu (lista, priorytetyzacja, plan) i czy dług blokuje skalowanie (architektura, bezpieczeństwo, obserwowalność). Startup który mówi "mamy dług, oto lista, oto plan spłaty" wypada lepiej niż startup który mówi "nie mamy długu" lub "pracujemy nad tym" bez konkretów.

Ile długu technicznego to za dużo? Nie ma jednej liczby. Sygnał alarmowy: unplanned work ratio powyżej 30% przez dwa kolejne sprinty. Drugi sygnał: cycle time rośnie o ponad 50% w ciągu 6 miesięcy mimo stałego teamu.

Jak przekonać inwestora że dług nie jest problemem? Pokaż świadomość (lista znanych długów), priorytetyzację (które blokują skalowanie, które nie), plan spłaty (20% sprintu lub debt sprint co kwartał) i metryki pokazujące trend.

Czy narzędzia jak SonarQube wystarczą do mierzenia długu? Narzędzia statycznej analizy kodu mierzą jakość kodu, nie biznesowy koszt długu. Uzupełnij je metrykami delivery — to daje pełny obraz.

Kiedy warto przepisać system od nowa vs refaktoryzować? Przepisanie od nowa jest prawie zawsze droższe i ryzykowniejsze niż przewidujesz. Refaktoryzacja inkrementalna z jasnym targetem architektonicznym jest zwykle lepszym wyborem.