Dług techniczny w startupie: ile to za dużo?

Każdy startup ma dług techniczny i przeważnie była to słuszna decyzja. Pytanie nie brzmi, jak go wyeliminować — tylko które części naliczają odsetki, na które już cię nie stać.

Dług techniczny ma złą sławę, na którą nie do końca zasługuje. Pójście na skróty, żeby szybciej zwalidować pomysł, zwykle jest słuszne — alternatywą jest staranne budowanie w stronę czegoś, czego nikt nie chciał. Porażką nie jest zaciągnięcie długu; porażką jest nigdy nie sprawdzić oprocentowania.

Cztery rodzaje, a liczą się tylko dwa

Jak poznać, że zrobiło się go za dużo

Nie ma progu absolutnego; dług ma sens tylko względem tego, co próbujesz zrobić. Ale te sygnały niezawodnie wskazują, że odsetki stały się nie do udźwignięcia:

• Szacunki dla podobnych rozmiarowo funkcji stale rosną — najczystszy sygnał ilościowy
• Zespół rutynowo mówi «tego nie da się przy obecnym układzie» o zwyczajnych prośbach
• Błędy raz po raz kumulują się w tych samych modułach
• Wdrożenie nowego inżyniera trwa miesiące zamiast tygodni
• Ludzie unikają dotykania pewnych plików i wszyscy wiedzą których
• Wdrożenia są łączone w paczki i planowane, bo są ryzykowne

Co spłacać i kiedy

Dług warto spłacać, gdy blokuje coś konkretnego, a nie z zasady. Trzy reguły, które działają:

1. Spłacaj dług leżący na drodze przed tobą. Jeśli najbliższe dwa kwartały prowadzą przez jakiś moduł, wysprzątaj go, zanim tam zbudujesz. Dług w kodzie, którego nie ruszysz, nic nie kosztuje.
2. Dług dotykający pieniędzy, danych albo autoryzacji spłacaj natychmiast, niezależnie od roadmapy — awarie tam są nieodwracalne, a nie tylko irytujące.
3. Refaktoryzuj oportunistycznie. Poprawiaj to, co i tak zmieniasz, zamiast planować osobne projekty porządkowe, które pod presją są ścinane jako pierwsze.

Budżet, który działa

Żaden uniwersalny procent utrzymania nie stabilizuje automatycznie długu. Planuj zasoby według ryzyk i roadmapy, następnie je weryfikuj. Przepisanie systemu jest opcją do oceny, nie obowiązkowym wynikiem audytu.

Celem nie jest zerowy dług techniczny. Celem jest dług, który wybrałeś, o którym wiesz i który mógłbyś spłacić, gdyby roadmapa tego wymagała.

Co mówić inwestorom

Założyciele często próbują ukryć dług podczas due diligence. To się mści: badanie i tak go znajduje, a odkrycie kosztuje w negocjacjach więcej, niż kosztowałoby ujawnienie. Silniejszą pozycją jest spisany rejestr — jaki dług istnieje, co blokuje, ile kosztuje naprawa. Zespół, który potrafi to wyartykułować, czyta się jako kompetentny; zespół twierdzący, że ma czysty kod, czyta się jako naiwny albo wymijający.

Priorytetyzuj dług techniczny na podstawie dowodów

Przegląd kodu bada implementację, architektury — granice i działanie. Zacznij od decyzji biznesowej: czy system obsłuży kolejny release lub nowych klientów? Oceń skutek, obserwowaną częstotliwość i wysiłek. Aktywne problemy bezpieczeństwa lub integralności danych traktuj oddzielnie jako pilne.

Żaden uniwersalny procent utrzymania nie stabilizuje automatycznie długu. Planuj zasoby według ryzyk i roadmapy, następnie je weryfikuj. Przepisanie systemu jest opcją do oceny, nie obowiązkowym wynikiem audytu.

• Zobacz zakres usługi →