Ward Cunningham ukuł termin “dług techniczny” w 1992 roku, podczas prezentacji na konferencji OOPSLA. Miał na myśli coś precyzyjnego: świadomy kompromis między szybkością dostarczenia a jakością kodu, który kiedyś trzeba będzie spłacić. Trzydzieści lat później jego metafora żyje własnym życiem i oznacza niemal wszystko – od porzuconej dokumentacji po system ERP napisany przez kogoś, kto od ośmiu lat nie pracuje w tej firmie, a numeru telefonu nikt nie ma.
Dług technologiczny to sytuacja, w której wcześniejsze decyzje techniczne generują rosnące koszty utrzymania, zmiany lub rozbudowy systemu. Cunningham porównał to do finansowego kredytu: zaciągasz go, żeby działać szybciej, ale odsetki się nakapią. Problem polega na tym, że w IT odsetki bywają ukryte przez kwartały, a potem trafiają na jedną fakturę.
Skąd bierze się dług – i kto go zaciąga
Wyobraź sobie sytuację: masz sprint, deadline za dwa tygodnie, zarząd chce demo przed inwestorami. Ktoś w zespole proponuje obejście zamiast pełnej implementacji. Wszyscy widzą, że to obejście, ale wszyscy też wiedzą, że demo musi działać w piątek. Ticket trafia do backlogu z etykietą “refaktoryzacja – do ustalenia” i tam zostaje przez osiemnaście miesięcy. W tym czasie kod wyrasta wokół tego obejścia jak miasto wokół śmietnika. Nikt nie chce go ruszać, bo nikt nie wie, co się posypie.
To jeden scenariusz. Drugi wygląda inaczej: dług pojawia się nie ze złej woli, lecz z ignorancji. Zespół 5‑osobowy pisze kod, który działa świetnie przy 500 użytkownikach. Rok później masz 50 000 użytkowników i architektura, która nigdy nie była projektowana pod taką skalę, zaczyna się sypać przy każdym większym evencie. Nikt nie zaciągnął długu celowo. Zaciągnął go czas i sukces produktu.
Trzeci scenariusz, który widuję najczęściej u klientów: fuzja albo przejęcie. Dwie firmy łączą się, każda ma swój stos technologiczny, swoje narzędzia do monitoringu, swoje podejście do CI/CD. Po połączeniu nikt nie ma budżetu na konsolidację, więc przez trzy lata obie infrastruktury działają równolegle. Koszty utrzymania rosną, a każdy nowy projekt musi obsługiwać dwa ekosystemy jednocześnie.
Co mówią liczby – i dlaczego CIO często ich nie widzą
McKinsey w raporcie z 2020 roku zebrał dane od CIO i wyszło z tego coś niepokojącego: od 10 do 20 procent budżetu przeznaczonego na nowe produkty jest faktycznie pochłaniane przez obsługę długu technologicznego. Pieniądze, które miały finansować innowacje, idą na łatanie. Dwa lata później McKinsey przeanalizował konkretne systemy i stwierdził, że dług technologiczny może stanowić od 15 do 60 procent każdego dolara wydanego na IT – zakres absurdalnie szeroki, bo absurdalnie różne są poziomy dojrzałości organizacji.
Problem ze świadomością tego długu jest raczej strukturalny. Inżynierowie go widzą, ale mają trudność z przełożeniem na język, który trafi do zarządu. Zarząd widzi koszty utrzymania, ale nie rozumie, skąd się biorą. Gdzieś pomiędzy tymi dwoma światami siedzi dług i rośnie w najlepsze, bo nikt nie ma pełnego obrazu. Sprawdź, jak wygląda ta komunikacja u ciebie – jeśli twój CTO nie potrafi w 5 minut wyjaśnić CFO, ile kosztuje obecna architektura, to odpowiedź jest raczej oczywista.
Zarządzanie długiem – nie chodzi o zerowanie
Najczęstszy błąd, który obserwuję w organizacjach, to traktowanie długu technologicznego jak czegoś, co trzeba wyeliminować. Tymczasem Cunningham od początku mówił o świadomym zaciąganiu – czasem wziąć dług, żeby dowieźć produkt, a potem go spłacić. Pytanie nie brzmi “czy mamy dług”, tylko “czy rozumiemy, ile mamy i jakie są odsetki”.
Praktyczne podejście, które widać w dojrzałych zespołach, opiera się na trzech krokach. Najpierw inwentaryzacja: co masz, gdzie jest stare, gdzie brakuje testów, gdzie dokumentacja ma dwa lata i nijak nie odpowiada temu, co jest w kodzie. Potem priorytetyzacja – nie wszystko jest tak samo pilne. Komponent, który ruszasz raz na kwartał i który działa stabilnie, może poczekać. Komponent, przez który przechodzi 80% transakcji i który ma zerowe pokrycie testami, nie może. Wreszcie planowanie spłaty, najlepiej wbudowane w cykl sprintów albo przypisane do dedykowanego czasu – część zespołów rezerwuje jeden sprint na kwartał wyłącznie na refaktoryzację i spłatę długu.
Jeśli pracujesz w środowisku Scrumowym, masz do tego gotowe narzędzie: backlog. Problem polega na tym, że w wielu organizacjach dług technologiczny trafia do backlogu, a potem grzęźnie na dole pod nowymi funkcjonalnościami, bo Product Owner patrzy na wartość biznesową, a refaktoryzacja starego kodu rzadko wygrywa w tej konkurencji. Rozwiązaniem jest wyraźny kontrakt między biznesem a technologią: ile procent każdego sprintu idzie na spłatę długu. Dwadzieścia procent to liczba, którą słyszę najczęściej. Bywa respektowana, bywa nie.
Kiedy dług staje się kryzysem
Są sytuacje, w których dług przestaje być problemem technicznym i staje się ryzykiem biznesowym. Trzy sygnały, które powinny zapalić ci lampkę alarmową w głowie.
- Każda nowa funkcjonalność trwa dwa razy dłużej niż rok temu, mimo że zespół nie zmalał;
- twoi inżynierowie odchodzą i mówią wprost, że nie chcą pracować z tym kodem;
- incydenty produkcyjne zaczęły się zdarzać częściej i trwają dłużej, bo diagnoza wymaga przedzierania się przez warstwy niedokumentowanych zależności.
W takim momencie rozmowa przestaje być rozmową o technikaliach. To rozmowa o ryzyku operacyjnym, którą trzeba przeprowadzić z zarządem – w języku pieniędzy i czasu, nie refaktoryzacji i coverage’u. Jeśli chcesz zobaczyć, jak wygląda ta rozmowa w szerszym kontekście zarządzania usługami IT, ten artykuł może dać ci kilka użytecznych punktów wyjścia.
Pytanie, które rzadko zadaje się wprost: ile długu technologicznego twoja firma zaciągnęła w ciągu ostatnich 12 miesięcy i czy ktokolwiek w zarządzie ma świadomość tej liczby?
Źródła
- Cunningham W., “The WyCash Portfolio Management System” (experience report), OOPSLA, 1992.
- McKinsey & Company, “Tech debt: Reclaiming tech equity”, McKinsey Digital, 2020.
- McKinsey & Company, “Demystifying digital dark matter: A new standard to tame technical debt”, McKinsey Digital, 2022.
- Allman E., “Managing Technical Debt”, Communications of the ACM, 2012.
- Standish Group, CHAOS Report, wydania cykliczne od 1994.
Zdjęcie: Marek Piwnicki / Pexels
