Czym jest dług techniczny? Krótki przewodnik

W samych Stanach Zjednoczonych dług techniczny po cichu zjada z gospodarki około 2,41 biliona dolarów rocznie. To ogromna kwota – jak na problem, którego wiele firm nawet nie próbuje mierzyć.

Ten przewodnik kierujemy do liderów, którzy potrzebują przełożyć ten techniczny, abstrakcyjny temat na język liczb i biznesu. Przedstawimy ogólny zarys problemu: wyjaśnimy, czym jest dług techniczny, dlaczego może doprowadzić do katastrofy, ile kosztuje i – co najważniejsze – jak zbudować pragmatyczną strategię zarządzania nim.

1. Czym jest dług techniczny?

U podstaw długu technicznego leży… kompromis. Termin ten został po raz pierwszy użyty w 1992 roku przez Warda Cunninghama, pioniera metodyk zwinnych (Agile). Według niego dług techniczny to konsekwencja wdrożenia szybkiego, lecz nieoptymalnego rozwiązania, które będzie później wymagało dodatkowej pracy przy naprawie lub wymianie.

Wdrażanie nowego kodu jest jak zaciąganie pożyczki. Niewielki dług przyspiesza prace, o ile zostanie szybko spłacony poprzez refaktoryzację. Niebezpieczeństwo pojawia się, gdy dług nie jest spłacany. Każda minuta spędzona na niedopracowanym kodzie […] jest niczym odsetki od tego długu. Jeśli refaktoryzacja jest latami spychana na koniec listy priorytetów, dług techniczny w pewnym momencie dociąża organizację do tego stopnia, że działy inżynieryjne praktycznie stają w miejscu. – Ward Cunningham (źródło)

Gdy dług techniczny zaczyna spowalniać każdy sprint i wymuszać gaszenie pożarów, projekt wchodzi w fazę wysokiego ryzyka. Jeśli chcesz łatwo ocenić, czy Twój projekt już zbacza z kursu, sprawdź najczęstsze symptomy upadających projektów IT – pomogą Ci szybko wychwycić pierwsze sygnały ostrzegawcze i ustalić priorytety działań.

Jakie są przyczyny długu technicznego?

Główne przyczyny to presja, którą zna każdy lider: wyścig o zdobycie udziału w rynku, potrzeba szybkiej weryfikacji pomysłów biznesowych za pomocą MVP (Minimum Viable Product) oraz oczekiwania inwestorów domagających się szybkiego wzrostu.

• Presja czasu (Speed-to-Market): Startupy często idą na skróty, aby jak najszybciej wypuścić swoje MVP.
• Oczekiwania inwestorów, którzy chcą widzieć szybkie postępy.
• Systemy zastane (Legacy Systems): Starsze banki lub przejęte platformy często opierają się na starych, przestarzałych rozwiązaniach.
• Ograniczone zasoby: Jeśli zespół inżynierski jest zbyt mały, prawdopodobnie refaktoryzacja lub testowanie zejdą na dalszy plan.

Jakie są rodzaje długu technicznego?

Jednak dług długowi nierówny. Możemy wyróżnić na przykład dwa typy: Dług Celowy (Rozważny) i Dług Przypadkowy (Lekkomyślny):

• Dług Celowy (“Rozważny”): To świadoma, strategiczna decyzja. Wiesz, że idziesz na skróty, aby wyrobić się przed deadline’m lub przetestować hipotezę rynkową za pomocą MVP, i masz plan, aby zająć się tym później. To skalkulowane ryzyko.
• Dług Przypadkowy (“Lekkomyślny”): To dług, który narasta przez zaniedbania, złe praktyki inżynierskie lub brak świadomości. Jest wynikiem bałaganu w kodzie, przestarzałej architektury i postawy „naprawimy to później”, która zawsze schodzi na dalszy plan. To ten rodzaj długu prowadzi do niekontrolowanej spirali ryzyka i spowolnień.

To oczywiście tylko jeden z przykładów. Dług techniczny można kategoryzować według jego “formy” (dług w kodzie, dług w testach, dług architektury itp.) lub pochodzenia (odziedziczony vs. spowodowany szybkim rozwojem).

2. Studium przypadku TSB Bank: Jak dług techniczny może doprowadzić do upadku firmy?

Katastrofalna migracja IT banku TSB z 2018 roku to podręcznikowy przykład tego, co się dzieje, gdy przez lata zamiata się ryzyko technologiczne pod dywan, a potem ono wybucha prosto w twarz zarządowi.

Po przejęciu przez hiszpańską grupę Sabadell, TSB zdecydował się przenieść 5,2 mln klientów ze starej platformy IT na nowy, szyty na miarę system Sabadell – „Proteo4UK”. Zamiast robić to etapami, kierownictwo wybrało podejście „big bang”: wszystko, dla wszystkich, w jeden weekend.

Ryzykowna strategia, napięty harmonogram i zbyt mało testów szybko się odegrały. System praktycznie od razu się posypał – i to na pełnej skali.

Co to oznaczało w praktyce?

• Paraliż operacyjny – nawet 1,9 mln klientów straciło dostęp do kont, część na całe tygodnie. Spłynęło ponad 225 tys. skarg: brakujące środki, nieudane płatności, chaos.

• Cios finansowy – sam bezpośredni koszt akcji przekroczył 330 mln funtów (odszkodowania dla klientów, straty na oszustwach, gaszenie pożaru operacyjnego). Do tego kary regulacyjne w wysokości 48,65 mln funtów. W sumie prawie 400 mln funtów.

• Utrata zaufania – w 2018 roku z banku odeszło 80 tys. klientów, a reputacja TSB została mocno nadszarpnięta.

Wniosek?
Kiedy dług techniczny i ryzyko IT są zarządzane „na czuja”, a nie strategicznie, stawką przestaje być pojedynczy projekt. Stawką staje się przyszłość całej firmy.

Więcej o przypadku TSB:

1. Final Notice 2022: TSB Bank
2. FCA, TSB fined £48.65m for operational resilience failings
3. Independent, TSB IT meltdown cost bank £330m and 80,000 customers

3. Jaki jest prawdziwy koszt długu technicznego?

Jeśli jesteś CTO, i chcesz zdobyć poparcie dla zmierzenia się z długiem technicznym, musisz mówić językiem biznesu: liczbami, kosztami i ryzykiem. Mierzenie długu przekształca narzekanie deweloperów w konkretną pozycję w rachunku zysków i strat. Koszty dzielą się na dwie główne kategorie.

Jakie są bezpośrednie koszty długu technicznego?

Koszty bezpośrednie to mierzalne wydatki ponoszone każdego dnia za pójście na skróty w przeszłości: utracona produktywność deweloperów, zwiększona liczba testów QA i awaryjne poprawki.

• Koszt utraconej produktywności: Ta metryka pokazuje, ile pieniędzy “przecieka” przez zespół deweloperski. W zespole 10 deweloperów, zarabiających, po mocnym uproszczeniu, średnio 160 000 PLN rocznie, którzy spędzają 30% czasu na obchodzeniu problemów wynikających z długu technicznego, roczny koszt utraconej produktywności wynosi …480 000 PLN rocznie. Z miesięcznej pensji dewelopera wynoszącej około 13 300 PLN brutto miesięcznie, 4 tysiące idą wyłącznie na naprawianie istniejących problemów.
• Zwiększone koszty QA: Niestabilne systemy wymagają znacznie intensywniejszego testowania. Inżynierowie spędzają 33% swojego czasu tylko na walce z długiem technicznym.

Rozważmy te scenariusze:

• Pospieszne wdrożenie produktu: Startup FinTech wypuszcza w pośpiechu aplikację do płatności P2P, pomijając kluczowe testy bezpieczeństwa. Całkowity koszt tego długu wynosi 250 000 USD. W jego skład wchodzą koszty poprawek błędów, zwiększonego wsparcia klienta, utracone przychody przez złe recenzje oraz wdrożenie awaryjnej łatki bezpieczeństwa.
• Opóźnione aktualizacje bezpieczeństwa: Większa firma opóźnia kluczowe aktualizacje zabezpieczeń, aby uniknąć przestojów. Prowadzi to, powiedzmy, do wycieku danych o wartości 2,25 miliona USD (według IBM, średni globalny koszt wycieku danych to obecnie 4,4 miliona USD). Firma musi pokryć koszty reakcji na incydent, grzywny, opłaty prawne i straty wynikające z utraty zaufania klientów.

Jakie są ukryte koszty długu technicznego?

Jeszcze bardziej szkodliwe mogą być utracone szanse: stracone okazje rynkowe i opóźnienia w innowacjach. Im bardziej konkurencyjna branża, tym boleśniejsze są te straty. Każda złotówka i każda godzina, którą zespół spędza na zmaganiu się ze starym kodem, to złotówka i godzina, których nie poświęcono na innowacje.

Wyobraź sobie, że Twoja firma nie była w stanie uruchomić konkurencyjnej funkcji płatności P2P (np. przelewów na telefon lub płatności zbliżonych do BLIK P2P), ponieważ stara architektura była zbyt sztywna. Prosta analiza finansowa mogłaby pokazać, że:

• przy potencjalnym rynku 10 milionów użytkowników w Polsce, wykonujących średnio 20 transakcji rocznie, i skromnej marży 0,20 PLN na transakcji, roczny utracony przychód z tej jednej straconej okazji mógłby wynieść nawet:
  • 10 000 000 × 20 × 0,20 PLN = 40 000 000 PLN rocznie.

W takim scenariuszu dług techniczny nie jest już drobną niedogodnością. To kula u nogi, która spowalnia adaptację, blokuje nowe funkcje i sprawia, że coraz trudniej nadążyć za oczekiwaniami klientów.

4. Jak w takim razie zarządzać długiem technicznym?

Celem nie jest całkowite wyzerowanie długu technicznego. Tak naprawdę gonienie za „zerem” mogłoby nawet oznaczać, że firma boi się ryzyka tak bardzo, że przy okazji dławi innowacje. Chodzi o coś innego: znalezienie rozsądnego, optymalnego poziomu długu i konsekwentne trzymanie go pod kontrolą.

1. Audyt i identyfikacja długu: Nie można zarządzać czymś, czego się nie mierzy. Pierwszym krokiem jest dokładne zidentyfikowanie problemu. Stwórz “rejestr długu technicznego” (Technical Debt Backlog), traktując każdy problem jak zadanie lub historyjkę użytkownika. Rejestr powinien opisywać problem, jego wpływ na biznes i szacowany koszt naprawy. Istnieją również metryki, których można użyć do pomiaru kosztów długu technicznego.
2. Priorytetyzacja spłaty: Nie każdy dług jest równie pilny. Niektóre można bezpiecznie zignorować – inne paraliżują firmę. Wybierz odpowiednie działanie:
   1. Refaktoryzacja (Refactor): Przebudowa istniejącego kodu bez zmiany jego zewnętrznego działania. Idealna, gdy główna logika jest poprawna, ale kod stał się zbyt skomplikowany.
   2. Przebudowa (Rebuild): Całkowita wymiana komponentu lub systemu. To rozwiązanie stosuje się, gdy architektura jest wadliwa, technologia przestarzała lub system blokuje kluczowe cele biznesowe.
   3. Akceptacja (Accept): Czasami najbardziej pragmatycznym wyborem jest… nie robienie niczego. W przypadku stabilnych, starych modułów, które są rzadko zmieniane i nie są kluczowe dla strategii, koszt naprawy może przewyższać korzyści.
3. Przygotuj uzasadnienie biznesowe dla inwestycji: Użyj wskaźników z poprzedniej sekcji, aby uzasadnić potrzebę działania. Nie proś o budżet na “refaktoryzację modułu płatności”. Zamiast tego przedstaw klarowną analizę inwestycji: “Inwestując X USD w modernizację tego modułu, możemy odzyskać 360 000 USD rocznie z produktywności deweloperów i odblokować wejście na rynek płatności P2P o wartości XYZ”. To stawia rozmowę w zupełnie innym świetle.

5. Podsumowanie i kolejne kroki

Dobre zarządzanie długiem technicznym pozwala rozwijać produkt szybko, ale bez rozwalania stabilności systemu. Najtrudniejszy etap? W ogóle zrozumieć, z jak dużym problemem masz do czynienia. Porządny audyt zamienia „wydaje nam się, że…” w konkretny plan działania.

Jeśli chcesz przestać płacić odsetki od dawnych decyzji i zacząć naprawdę inwestować w przyszłość swojego systemu, porozmawiajmy. Pomożemy Ci ustalić, od czego najlepiej zacząć i co realnie da największy efekt.

Dług techniczny – najczęściej zadawane pytania (FAQ)

Summarize this article with AI

ChatGPT

Claude

Perplexity