Dług technologiczny: jak go rozpoznać i kiedy spłacać

Dług technologiczny to suma skrótów, odłożonych aktualizacji i przestarzałych decyzji w systemie, za które firma płaci odsetki: wolniejszym rozwojem, częstszymi awariami i rosnącym ryzykiem bezpieczeństwa. Rozpoznasz go bez czytania kodu, po objawach widocznych w biznesie, a spłacać go trzeba wtedy, gdy odsetki zaczynają blokować plany firmy. Poniżej opisuję objawy, przyczyny, kryteria decyzji i sposób, w jaki planuję spłatę w budżecie rozwoju.

Czym jest dług technologiczny w języku zarządu

Dług technologiczny działa jak kredyt: pozwala dostarczyć coś szybciej dziś w zamian za wyższy koszt jutro. Sam w sobie nie jest błędem, błędem jest brak wiedzy, ile go jest i ile kosztuje jego obsługa.

Część długu zaciąga się świadomie. Zespół wie, że rozwiązanie jest tymczasowe, bo trzeba zdążyć na start sezonu, i zapisuje, co trzeba będzie poprawić. Część powstaje mimochodem: z czasem zmieniają się wymagania, biblioteki się starzeją, a rozwiązanie dobre trzy lata temu przestaje pasować do skali firmy. Ten drugi rodzaj jest groźniejszy, bo nikt go nie zapisał i nikt go nie pilnuje.

W rozmowie z zarządem używam prostego porównania. Każda zmiana w systemie z dużym długiem kosztuje więcej niż ta sama zmiana w systemie zadbanym. Różnica to właśnie odsetki, które płacisz przy każdym zleceniu, nawet jeśli nie widać ich w żadnej fakturze jako osobnej pozycji.

Objawy długu technologicznego widoczne bez znajomości kodu

Nie musisz czytać kodu, żeby zauważyć problem. Dług technologiczny zostawia ślady w harmonogramach, wycenach i zgłoszeniach, które widzi każdy, kto zarządza systemem.

• Drobne zmiany są wyceniane coraz drożej. Nowe pole w formularzu, które kiedyś zajmowało godzinę, dziś wymaga dni, bo dotyka wielu miejsc naraz.
• Każde wdrożenie coś psuje. Poprawka w module zamówień wywołuje błąd w raportach, choć z pozoru nie mają ze sobą nic wspólnego.
• Tylko jedna osoba umie coś zmienić. Jeśli urlop konkretnego programisty wstrzymuje rozwój, wiedza nie jest zapisana ani w kodzie, ani w dokumentacji.
• Wdrożenia są rzadkie i stresujące. Zespół wdraża raz na kilka tygodni, wieczorem, ręcznie, z listą kroków w notatkach.
• Słychać „tego się nie da zrobić”. Zmiana, która w biznesie wydaje się prosta, jest odrzucana, bo architektura jej nie przewiduje.
• Komponenty bez wsparcia. System działa na wersjach języka, frameworka albo wtyczek, dla których producent nie wydaje już poprawek.
• Nowa osoba długo się wdraża. Programista dołączający do zespołu potrzebuje tygodni, zanim odważy się coś zmienić.

Jeden objaw nie przesądza sprawy. Kilka naraz, zwłaszcza rosnące wyceny i błędy po wdrożeniach, to sygnał, że odsetki zaczynają być wyższe niż rata.

Pytania, które warto zadać zespołowi lub dostawcy

Najprościej zapytać tych, którzy pracują z kodem, ale trzeba zadawać pytania konkretne, bo na ogólne „czy mamy dług?” odpowiedź zawsze brzmi „trochę”.

1. Na jakich wersjach języka, frameworka i bazy działa system i do kiedy mają wsparcie?
2. Jaka część kluczowych procesów jest objęta testami automatycznymi?
3. Ile trwa wdrożenie nowej wersji i czy da się je cofnąć jednym poleceniem?
4. Które części systemu boicie się zmieniać i dlaczego?
5. Gdybyście mieli tydzień na porządki, od czego byście zaczęli?

Ostatnie pytanie jest najcenniejsze. Zespół zwykle doskonale wie, gdzie leży problem, tylko nikt go o to nie pytał. Gdy odpowiedzi są niepewne albo dostawca unika rozmowy, dobrym krokiem jest niezależny przegląd, podobny do tego, który opisuję przy przejęciu projektu IT i audycie kodu.

Skąd bierze się dług technologiczny

Dług technologiczny rzadko wynika ze złej woli programistów. Najczęściej jest skutkiem decyzji biznesowych podejmowanych bez świadomości ich kosztu technicznego.

• Presja terminów. Funkcja musi być na wczoraj, więc testy i porządki odkłada się na później, które nie nadchodzi.
• Brak budżetu na utrzymanie. System po wdrożeniu dostaje pieniądze tylko na nowe funkcje, a aktualizacje czekają. Dlatego zakres aktualizacji powinien być zapisany już w umowie SLA na utrzymanie systemu.
• Zmiany kierunku. System zaprojektowany pod sprzedaż detaliczną zaczyna obsługiwać klientów hurtowych, a nikt nie przebudował fundamentów.
• Rotacja w zespole. Każdy kolejny wykonawca dokłada kod w swoim stylu, nie znając decyzji poprzedników.
• Starzenie się zależności. Biblioteki, z których korzysta system, starzeją się same, nawet gdy nikt nie dotyka kodu.

Nowym źródłem długu jest kod pisany szybciej, niż zespół go przegląda. Narzędzia AI przyspieszają programowanie, ale bez przeglądu i testów potrafią szybciej produkować także dług. Szerzej o tym, jak ustawić zasady pracy z takimi narzędziami, piszę w tekście o AI w zespole programistów.

Ryzyko bezpieczeństwa: przestarzałe komponenty

Najdroższą formą długu są komponenty bez wsparcia, bo nie płacisz za nie czasem programistów, tylko ryzykiem włamania. Luka w starej wersji biblioteki jest publicznie opisana, a poprawki nie będzie.

To nie jest problem teoretyczny. W zestawieniu zagrożeń OWASP Top 10 w wersji z 2025 roku błędy łańcucha dostaw oprogramowania, w tym używanie komponentów nieaktualnych i niewspieranych, zajmują trzecie miejsce wśród najważniejszych zagrożeń dla aplikacji webowych. OWASP wymienia tam wprost brak wiedzy o wersjach używanych komponentów i brak regularnych aktualizacji jako sytuacje, w których aplikacja jest podatna.

Dla decydenta wniosek jest prosty: lista komponentów i ich wsparcia powinna być częścią każdego przeglądu systemu, tak samo jak przegląd uprawnień czy kopii zapasowych.

Kiedy spłacać dług technologiczny, a kiedy z nim żyć

Spłacasz wtedy, gdy koszt odsetek przewyższa koszt spłaty albo gdy dług blokuje coś, co firma chce zrobić. Nie każdy dług trzeba spłacać, czasem rozsądniej jest z nim żyć albo wygasić moduł razem z długiem.

Sytuacja	Decyzja
komponent bez wsparcia z poprawkami bezpieczeństwa	spłacać od razu, to ryzyko, nie koszt
moduł często zmieniany i często psujący się	spłacać w pierwszej kolejności, odsetki rosną najszybciej
moduł stabilny, rzadko zmieniany	zostawić, monitorować
moduł do wygaszenia w ciągu roku	nie inwestować, zaplanować wygaszenie
dług blokuje nową funkcję biznesową	spłacić w ramach projektu tej funkcji

Kryterium jest więc częstotliwość zmian, a nie estetyka kodu. Brzydki moduł, którego nikt nie dotyka od lat, kosztuje mniej niż średnio napisany moduł zmieniany co tydzień.

Uważaj też na dwie skrajności. Pierwsza to wstrzymanie rozwoju na kilka miesięcy, żeby „posprzątać wszystko”: biznes traci cierpliwość, zanim zobaczy efekt, a porządki kończą się w połowie. Druga to odkładanie spłaty do czasu, aż zrobi się spokojniej, czyli w praktyce nigdy. Dług technologiczny najlepiej spłaca się małymi, regularnymi ratami, tak samo jak zwykły kredyt, a decyzję o każdej racie podejmuje się na podstawie ryzyka i częstotliwości zmian w danym module.

Jak zaplanować spłatę w budżecie rozwoju

Najlepiej działa stała, przewidywalna część budżetu rozwoju przeznaczona na spłatę, zamiast jednorazowych akcji ratunkowych. Ustalam ją z klientem jako część każdego okresu rozliczeniowego, na przykład jeden dzień w tygodniu albo jedno zadanie w każdym cyklu prac.

1. Spisz dług. Prowadź rejestr znanych problemów z krótkim opisem skutków biznesowych, nie tylko technicznych.
2. Nadaj priorytety. Na górę trafia bezpieczeństwo, potem moduły zmieniane najczęściej, potem reszta.
3. Łącz spłatę z funkcjami. Gdy zespół i tak pracuje w danym module, porządkuje go przy okazji. To najtańsza forma spłaty.
4. Mierz efekt. Czas wdrożenia, liczba błędów po wdrożeniach, czas realizacji typowej zmiany. Jeśli te wskaźniki się nie poprawiają, spłata idzie w złe miejsce.
5. Raportuj zarządowi. Krótko: co spłacono, co zostało, jakie ryzyko zniknęło.

Jeśli dług jest na tyle duży, że stała część budżetu nie wystarcza, potrzebny jest osobny projekt modernizacji. Wtedy zwykle wymieniam system kawałek po kawałku: nowy moduł przejmuje funkcję starego, a stary jest wyłączany, gdy przestaje być potrzebny. To wolniejsze niż przepisanie wszystkiego naraz, ale firma przez cały czas ma działający system. Takie decyzje zawsze sprawdzam z perspektywy całości, o czym pisałem w tekście o projektowaniu skalowalnej architektury systemów.

Jeśli widzisz w swojej firmie kilka objawów z tej listy, zacznij od rozmowy z zespołem i pięciu pytań powyżej, a potem ustal stałą część budżetu na porządki. Dług technologiczny, który jest zmierzony i spłacany w rytmie, przestaje być zagrożeniem i staje się zwykłą pozycją w planie rozwoju.