Dług techniczny: analiza kosztów i korzyści, której nie da się policzyć

Potrzebujesz zespołu, który wykona przebudowę bez zatrzymywania rozwoju produktu? Poznaj nasze usługi Staff Augmentation.

Zobacz też: Prawdziwy koszt długu technologicznego i jak zacząć go spłacać oraz Technical debt 2026: jak mierzyć i spłacać dług techniczny

Prezentacja jest zawsze taka sama. Zespół pokazuje wykres: dług techniczny kosztuje nas dwadzieścia procent zdolności w każdym sprincie, sprint kosztuje osiemdziesiąt tysięcy złotych, więc tracimy szesnaście tysięcy na sprint i czterysta tysięcy rocznie. Naprawa kosztuje sześćset tysięcy, zwróci się w osiemnaście miesięcy. Zarząd kiwa głową, zadaje jedno pytanie o to, skąd wzięło się dwadzieścia procent, dostaje odpowiedź „z szacunku zespołu”, i decyzja zostaje odłożona do przyszłego kwartału. W przyszłym kwartale wraca ta sama prezentacja z innymi liczbami.

Ten rytuał powtarza się w polskich organizacjach od lat i warto zadać niewygodne pytanie: skoro rachunek jest tak korzystny, dlaczego nikt go nie przyjmuje?

Teza tego przewodnika brzmi i można się z nią spierać: zwrotu z inwestycji w spłatę długu technicznego nie da się policzyć w sposób, który wytrzyma krytykę, a uporczywe próby jego liczenia są głównym powodem, dla którego dług nie zostaje spłacony. Licznik tego ułamka wymaga kontrfaktu — trzeba wiedzieć, ile kosztowałoby nas niepodjęcie działania — a kontrfakt jest z definicji niemierzalny. Mianownik jest systematycznie zaniżony, ponieważ szacują go ludzie, którzy nie znają pełnego zasięgu problemu; nieznajomość zasięgu to jest właśnie definicja długu technicznego, a nie okoliczność towarzysząca. Rachunek złożony z niemierzalnego licznika i zaniżonego mianownika nie jest analizą, tylko retoryką — i zarząd, który go odrzuca, zachowuje się racjonalnie.

Kontrargument jest mocny i trzeba go postawić uczciwie: zarząd nie przyzna budżetu bez uzasadnienia biznesowego, więc odbieranie zespołowi jedynego narzędzia perswazji zostawia go bez niczego. Odpowiedź: organizacje finansują dziś wiele rzeczy o niepoliczalnym zwrocie — kopie zapasowe, monitoring, testy odtworzeniowe, ubezpieczenia, zgodność z przepisami. Żadna z nich nie ma wyliczonego ROI i żadna nie jest z tego powodu kwestionowana, ponieważ pytanie postawiono inaczej: jaki poziom ryzyka akceptujemy i ile kosztuje jego utrzymanie. Dług techniczny należy do tej samej kategorii i przenosi się do niej bez straty argumentacyjnej. Zyskuje się przy tym coś istotnego: przestaje się obiecywać oszczędności, których nikt później nie potwierdzi.

Dlaczego rachunek ROI dla długu technicznego nie daje się policzyć?

Trzy przyczyny, każda wystarczająca samodzielnie.

Licznik wymaga kontrfaktu. Zdanie „dług kosztuje nas dwadzieścia procent zdolności” znaczy: gdyby długu nie było, ta sama praca zajęłaby o dwadzieścia procent mniej. Nikt nie obserwuje świata bez długu, więc ta liczba jest szacunkiem zespołu na temat hipotetycznej wersji własnej pracy. Szacunki tego typu są obciążone w przewidywalnym kierunku — ludzie, którzy chcą refaktoryzacji, oceniają koszt jej braku wyżej. Nie jest to nieuczciwość, tylko normalne działanie ludzkiej oceny.

Koszt długu jest nieciągły, a nie liniowy. To jest przyczyna najważniejsza i wracam do niej w następnej sekcji. Dług przez długi czas nie kosztuje prawie nic, a potem kosztuje bardzo dużo naraz, przy jednej konkretnej zmianie, której nie da się przewidzieć z wyprzedzeniem. Uśrednianie tego do „dwudziestu procent na sprint” opisuje przeszłość i nie prognozuje przyszłości.

Mianownik jest zaniżony z definicji. Wycena naprawy powstaje na podstawie tego, co zespół wie o systemie. Dług techniczny to w znacznej części właśnie to, czego zespół o systemie nie wie: zależności, o których nikt nie pamięta, zachowania, na których ktoś polega, dane, które przechodzą przez kod nieoczywistą drogą. Wycena naprawy jest więc wyceną znanej części problemu i nie może być niczym innym.

Ten sam dług, dwa przeciwne rachunki

Warto zobaczyć, jak łatwo ten sam stan faktyczny daje dwa uzasadnione i przeciwne wyniki.

Moduł rozliczeń, wiek siedem lat, kod powszechnie uznawany w zespole za najgorszy w systemie. Wycena uporządkowania: dwanaście tygodni zespołu, co przy realnych kosztach polskiego zespołu deweloperskiego daje rząd wielkości kilkuset tysięcy złotych.

Rachunek pierwszy, sporządzony przez zespół: w minionym roku dziewięć zadań dotykało tego modułu, każde z nich zajęło średnio o cztery tygodnie więcej, niż zajęłoby w uporządkowanej strukturze. To trzydzieści sześć tygodni straty rocznie wobec dwunastu tygodni naprawy. Zwrot w cztery miesiące, wniosek oczywisty.

Rachunek drugi, sporządzony przez dyrektora finansowego z tych samych danych: skąd wiadomo, że zajęłyby o cztery tygodnie mniej? Z szacunku zespołu, który chce tej pracy. Ile z tych dziewięciu zadań w ogóle by powstało, gdyby moduł był łatwy w zmianie — czy nie jest tak, że część z nich to obejścia poprzednich obejść, które w uporządkowanej wersji nie byłyby potrzebne, a inna część powstałaby i tak? I skąd wiadomo, że naprawa zajmie dwanaście tygodni, skoro poprzednia przebudowa w tym systemie, wyceniona na osiem, zajęła dwadzieścia jeden?

Oba rachunki są uczciwe i oba są nieweryfikowalne. Dyskusja między nimi nie ma rozstrzygnięcia empirycznego, więc kończy się rozstrzygnięciem przez pozycję w hierarchii — czyli odłożeniem. Rok później wraca ta sama prezentacja.

Zwróćmy przy tym uwagę na jedną liczbę, która w tym sporze przeszła bez dyskusji, choć jest jedyną twardą daną w całym materiale: dziewięć zadań dotykało tego modułu w ciągu roku. To jest fakt z historii repozytorium, nikt go nie szacował i nikt go nie kwestionuje. Cała metoda proponowana dalej w tym tekście opiera się właśnie na takich liczbach i na niczym innym.

Suma trzech obciążeń działa w tę samą stronę: rachunek zawsze wychodzi korzystnie. Wskaźnik, który zawsze wychodzi korzystnie, przestaje nieść informację, a osoby po drugiej stronie stołu wyczuwają to bez znajomości metodyki. Odrzucenie takiego wniosku jest reakcją na jego strukturę, nie na jego treść.

Co jest nie tak z metaforą odsetek?

Metafora długu z odsetkami jest najlepiej rozpoznawalną figurą w tej dziedzinie i jednocześnie źródłem najpoważniejszego błędu w rozumowaniu.

Odsetki od zobowiązania finansowego mają dwie własności: są ciągłe i są przewidywalne. Naliczają się codziennie, w znanej wysokości, i można je zaplanować w budżecie na trzy lata do przodu. Właśnie dlatego rachunek „spłać wcześniej, oszczędzisz odsetki” ma sens.

Koszt długu technicznego nie ma żadnej z tych własności. Jest nieciągły: przez rok nikt nie dotyka fragmentu systemu i koszt wynosi zero. Potem pojawia się jedna zmiana, która akurat wchodzi w ten fragment, i koszt wynosi osiem tygodni. Jest też nieprzewidywalny co do miejsca — nie wiadomo z góry, która z planowanych zmian trafi w splątaną część, bo splątanie nie jest widoczne z poziomu planu.

Konsekwencja jest poważniejsza, niż wygląda. Skoro koszt materializuje się w zmianach, a nie w upływie czasu, to spłacanie długu w modułach, których nikt nie będzie zmieniał, ma zwrot dokładnie zerowy — niezależnie od tego, jak zła jest tam jakość kodu. I odwrotnie: dług w module dotykanym co tydzień kosztuje realnie i naprawia się z korzyścią, nawet jeśli kod wygląda tam znacznie lepiej.

Wniosek praktyczny, który przeżyje resztę tego tekstu: o wartości naprawy decyduje częstotliwość zmian w danym miejscu, a nie jakość kodu w tym miejscu. Historia repozytorium jest więc lepszym źródłem priorytetów niż jakiekolwiek narzędzie do statycznej analizy jakości — i jest przy tym danymi, a nie szacunkiem.

Dlaczego wycena naprawy jest zawsze zaniżona?

Warto rozłożyć ten mechanizm, bo to on odpowiada za większość przekroczeń budżetu w projektach porządkowych.

Zespół wycenia przebudowę modułu na sześć tygodni. Wycena obejmuje to, co widać: strukturę kodu, znane zależności, testy, które istnieją. Nie obejmuje trzech rzeczy, których zobaczyć nie można przed rozpoczęciem pracy.

Pierwsza to zależności ukryte. Raport, który ktoś zbudował trzy lata temu na tej tabeli. Integracja, o której wiedziała osoba, która już nie pracuje. Zadanie wsadowe uruchamiane raz na kwartał, więc niewidoczne w bieżącym monitoringu. Każde takie odkrycie dodaje dni.

Druga to zachowania, na których ktoś polega. Klasyczny przypadek: system ma błąd, użytkownicy nauczyli się go obchodzić, a obejście stało się częścią procesu. Naprawa błędu psuje proces i wymaga uzgodnień, których nikt nie wyceniał.

Trzecia to testy, których nie ma. Przebudowa bez możliwości weryfikacji równoważności wymaga najpierw zbudowania tej możliwości, a to bywa większą pracą niż sama przebudowa.

Rozsądny mnożnik, obserwowany w naszych projektach dla przebudów w systemach starszych niż pięć lat, mieści się w przedziale od półtora do trzech razy wobec pierwotnej wyceny. Nie jest to argument przeciwko przebudowom — jest to argument za tym, żeby nie budować uzasadnienia na wycenie, o której z góry wiadomo, że jest zaniżona. Uczciwe postawienie sprawy brzmi: „wyceniamy na sześć tygodni, przy przedziale od dziewięciu do osiemnastu w realnych warunkach”. Ten sposób mówienia buduje wiarygodność, którą optymistyczny szacunek niszczy przy pierwszym przekroczeniu.

Co mierzyć zamiast ROI?

Rezygnacja z liczenia zwrotu nie oznacza rezygnacji z pomiaru. Trzy wielkości są mierzalne bez kontrfaktu i wszystkie trzy da się pokazać zarządowi.

Rozrzut wycen, nie ich średnia. Zespół dojrzały poznaje się nie po tym, że wycenia nisko, tylko po tym, że wycenia trafnie. Śledźcie stosunek czasu rzeczywistego do wyceny dla zakończonych zadań i patrzcie na rozrzut. Rosnący rozrzut oznacza, że system staje się coraz mniej przewidywalny, a to jest najbardziej bezpośredni obserwowalny skutek długu. Ta liczba jest odporna na manipulację i nie wymaga hipotez.

Odsetek zmian dotykających więcej niż jednego modułu. Rośnie wraz z rozmywaniem się granic w systemie. Liczy się bezpośrednio z historii repozytorium, bez niczyjej oceny.

Czas od zgłoszenia gotowości do wdrożenia na produkcję. Obejmuje testy, regresję i uzgodnienia. Wydłuża się wtedy, gdy system staje się trudniejszy do bezpiecznej zmiany, i jest wielkością, którą biznes rozumie bez tłumaczenia.

Jak policzyć te trzy wielkości w jeden dzień

Wszystkie trzy pochodzą z systemów, które już macie, i żadna nie wymaga nowego narzędzia.

Rozrzut wycen. Z systemu śledzenia zadań wyciągnijcie zamknięte pozycje z ostatnich sześciu miesięcy z wyceną początkową i czasem rzeczywistym. Policzcie iloraz obu wartości dla każdej pozycji, a potem medianę i dziewięćdziesiąty percentyl tego ilorazu. Mediana mówi o systematycznym niedoszacowaniu, percentyl o nieprzewidywalności — i to ten drugi jest wielkością, o którą chodzi. Rozbijcie wynik na moduły; zwykle okazuje się, że dwa albo trzy odpowiadają za cały ogon rozkładu.

Odsetek zmian wielomodułowych. Z historii repozytorium policzcie, ile zatwierdzeń dotyka plików z więcej niż jednego katalogu najwyższego poziomu. Trend w czasie jest ważniejszy niż wartość bezwzględna, bo wartość zależy od struktury katalogów, a trend nie.

Czas od gotowości do produkcji. Z systemu zadań albo z historii wydań: różnica między znacznikiem gotowości a wdrożeniem, mediana miesiąc po miesiącu.

Cały pomiar to kilka zapytań i pół dnia pracy analityka. Warto wykonać go raz porządnie, zapisać sposób liczenia i powtarzać kwartalnie tą samą metodą — w tym pomiarze wartość ma porównywalność w czasie, a nie precyzja pojedynczego odczytu.

Jedna uwaga o interpretacji: wszystkie trzy wielkości mogą się chwilowo pogorszyć zaraz po rozpoczęciu porządkowania, bo przebudowa sama w sobie generuje zmiany wielomodułowe i wydłuża ścieżkę do produkcji. Uprzedźcie o tym przy pierwszym raporcie. Zaskoczenie tym efektem w trzecim miesiącu jest jednym z częstszych powodów, dla których stały budżet zostaje wycofany dokładnie wtedy, gdy zaczyna działać.

Czego nie warto mierzyć: syntetycznego wskaźnika jakości kodu jako liczby śledzonej w czasie. Po pierwsze, natychmiast staje się celem i przestaje mierzyć. Po drugie, mierzy jakość tam, gdzie jej wartość jest zerowa — w kodzie, którego nikt nie zmienia. Po trzecie, daje złudzenie obiektywności, które w rozmowie z zarządem obraca się przeciwko wam, gdy ktoś zapyta, co ta liczba znaczy w złotówkach.

Dlaczego księgowość gra przeciwko spłacie długu?

To jest mechanizm rzadko nazywany na głos, a wyjaśniający więcej niż wszystkie argumenty o kulturze inżynierskiej razem wzięte.

Nakłady na wytworzenie nowej funkcjonalności mogą — przy spełnieniu określonych warunków dotyczących prac rozwojowych — być ujmowane jako składnik aktywów i rozliczane w czasie. Nakłady na refaktoryzację, która z definicji nie zmienia zachowania systemu i nie tworzy nowego składnika majątku, trafiają do kosztów bieżącego okresu. Kwalifikacja zawsze zależy od konkretnego stanu faktycznego i polityki rachunkowości jednostki, więc rozstrzyga ją dział finansowy, a nie dział techniczny.

Skutek dla dyrektora, który patrzy na wynik kwartału, jest jednak systematyczny: złotówka wydana na nową funkcjonalność obciąża bieżący wynik w mniejszym stopniu niż złotówka wydana na uporządkowanie istniejącego rozwiązania. To nie jest niczyja zła wola ani krótkowzroczność. To jest bodziec wbudowany w sposób, w jaki mierzy się wynik.

Drugi element tej układanki dotyczy ulg podatkowych. Ulga badawczo-rozwojowa premiuje działalność twórczą prowadzoną systematycznie w celu zwiększenia zasobów wiedzy i tworzenia nowych zastosowań. Refaktoryzacja rzadko się w tym mieści, bo jej istotą jest zachowanie dotychczasowego zachowania systemu. Nowa funkcjonalność mieści się częściej. Kierunek bodźca jest ten sam.

Ten sam bodziec działa zresztą jeszcze jednym kanałem, mniej oczywistym. Nowa funkcjonalność ma w organizacji rzecznika — dyrektora sprzedaży, właściciela produktu, klienta — czyli kogoś, kto o nią zabiega i ponosi konsekwencje jej braku. Uporządkowanie istniejącego rozwiązania nie ma takiego rzecznika poza zespołem technicznym, a zespół techniczny jest w tej rozmowie stroną, więc jego głos jest z góry dyskontowany. Struktura interesów działa więc w tę samą stronę, co struktura księgowa, i obie razem tłumaczą wynik lepiej niż jakiekolwiek wyjaśnienie odwołujące się do braku świadomości.

Praktyczny wniosek nie brzmi „walczcie z księgowością”. Brzmi: przestańcie konkurować z nową funkcjonalnością o ten sam budżet, bo w tej konkurencji przegrywacie z powodów, na które nie macie wpływu. Zamiast tego przenieście spłatę długu do innej kategorii — kosztu stałego utrzymania zdolności, obok monitoringu i kopii zapasowych. To jest właśnie ta zmiana ramy, o której mówi teza tego przewodnika, i ma ona twarde uzasadnienie finansowe, a nie tylko retoryczne.

Ile powinien wynosić stały budżet i jak go obronić?

Przedział piętnastu do dwudziestu procent zdolności zespołu jest rozsądnym punktem wyjścia i ma tę zaletę, że jest w branży rozpoznawalny. Ważniejsze od jego wysokości są jednak trzy właściwości.

Stałość. Piętnaście procent w każdym sprincie działa nieporównanie lepiej niż zero przez pół roku i osobny projekt porządkowy na kwartał. Projekt porządkowy ma sponsora, który znika w połowie, i termin, który przegrywa z pierwszą pilną potrzebą biznesową. Stały udział nie ma tych wad, bo nie jest projektem.

Brak konieczności uzasadniania za każdym razem. Budżet, o który trzeba prosić co sprint, jest budżetem, który zniknie w pierwszym trudnym kwartale. Uzgodnienie ma zapaść raz, na poziomie zasady, i być odnawiane rocznie, a nie negocjowane w każdym planowaniu.

Widoczność wyniku bez obietnicy oszczędności. Raportujcie, co zostało zrobione i jak zmieniły się trzy wielkości z poprzedniej sekcji. Nie obiecujcie, że wyceny spadną o trzydzieści procent — jeśli nie spadną, tracicie budżet na dwa lata.

Sposób prowadzenia rozmowy, który sprawdza się najlepiej: postawcie pytanie o akceptowalny poziom nieprzewidywalności. „Dziś nasze wyceny mylą się średnio o osiemdziesiąt procent w górę na zadaniach dotykających modułu rozliczeń. Możemy z tym żyć albo możemy przeznaczyć piętnaście procent zdolności na zmniejszenie tego rozrzutu. Nie obiecuję konkretnej liczby po roku; obiecuję pomiar i raport.” To jest rozmowa, którą zarząd zna z innych obszarów ryzyka i w której czuje się kompetentny.

Jaka jest jedyna decyzja, którą naprawdę trzeba podjąć?

Cała reszta tego przewodnika sprowadza się do jednej macierzy, którą wypełnia się raz na moduł i aktualizuje raz na rok. Nie ma w niej wskaźników ani wag — są trzy możliwe decyzje i dwa wejścia, oba pochodzące z danych, a nie z ocen.

Wejście pierwsze: częstotliwość zmian w module przez ostatnie dwanaście miesięcy, liczona z historii repozytorium. Wejście drugie: czy moduł ma w planie na najbliższe osiemnaście miesięcy jakąkolwiek zmianę wymuszoną — regulacyjną, kontraktową albo wynikającą z końca wsparcia.

Częstotliwość zmian	Zmiana wymuszona w planie	Decyzja	Co to znaczy w praktyce	Czego nie robić
Wysoka	Tak	Przepisz	Zaplanuj przebudowę przed zmianą wymuszoną, z wyceną w przedziale, nie punktową	Nie wykonuj zmiany wymuszonej na obecnej strukturze „tymczasowo”
Wysoka	Nie	Utrzymuj	Stały udział zdolności na bieżące porządkowanie przy okazji zmian	Nie planuj osobnego projektu przebudowy
Niska	Tak	Napraw punktowo	Tylko to, co niezbędne do wykonania zmiany wymuszonej	Nie porządkuj całego modułu przy okazji
Niska	Nie	Zamroź	Zero inwestycji, opis interfejsu, zakaz zmian bez decyzji	Nie refaktoryzuj, choćby kod był najgorszy w systemie
Wysoka, ale wyłącznie przez jeden zespół	Dowolna	Utrzymuj i wydziel granicę	Ustal właściciela i kontrakt interfejsu, dopiero potem porządkuj wnętrze	Nie zaczynaj od wnętrza
Zerowa od 24 miesięcy	Nie	Zamroź i rozważ wygaszenie	Sprawdź, czy moduł jest jeszcze używany; bywa, że nie	Nie utrzymuj z przyzwyczajenia

Wiersz czwarty jest tym, który wywołuje najwięcej sprzeciwu i jest najważniejszy. Zamrożenie modułu o złej jakości kodu, którego nikt nie zmienia, jest decyzją poprawną, a poczucie dyskomfortu, które wywołuje, jest kosztem estetycznym, nie finansowym. Wiersz ostatni bywa źródłem największych oszczędności w całym ćwiczeniu — w każdym większym systemie znajduje się zwykle coś, co jest utrzymywane, choć nie jest już używane.

Kto wypełnia macierz i jak często

Macierz ma jedną właściwość, która decyduje o tym, czy zostanie użyta: jest na tyle mała, że mieści się na jednym slajdzie, i na tyle mechaniczna, że nie wymaga eksperta do wypełnienia. Warto tego nie zepsuć rozbudową.

Wypełnia ją architekt albo lider techniczny wspólnie z osobą odpowiadającą za plan produktowy — pierwsza wnosi historię repozytorium, druga listę zmian wymuszonych i planowanych. Godzina pracy na moduł to górna granica; przy dwudziestu modułach cała macierz powstaje w dwa dni.

Aktualizacja raz w roku wystarcza, z jednym wyjątkiem: każda nowa zmiana wymuszona wchodząca do planu przesuwa moduł, którego dotyczy, i ta aktualizacja jest natychmiastowa. To jest cały mechanizm zarządzania i jego prostota jest zamierzona. Proces wymagający kwartalnego przeglądu stu pozycji zamiera po drugim kwartale.

Warto też ustalić, kto podejmuje decyzje z ostatniej kolumny. Rekomendacja z macierzy jest mechaniczna, ale decyzja „przepisz” oznacza kilkaset tysięcy złotych i musi mieć właściciela na poziomie, który tym budżetem dysponuje. Praktyczny układ: macierz przygotowuje zespół techniczny, decyzje w wierszach „przepisz” zapadają na poziomie zarządu, wszystkie pozostałe — w zespole, bez eskalacji. Ten podział ma znaczenie, bo eskalowanie decyzji o zamrożeniu jednego modułu na poziom zarządu jest najprostszym sposobem, żeby macierz przestała być używana.

Jak wybrać moduły do zamrożenia i co to znaczy w praktyce?

Zamrożenie nie jest zaniedbaniem i musi mieć operacyjną treść, inaczej zamienia się w powolne psucie.

Opisz interfejs. Co moduł przyjmuje, co zwraca, od czego zależy. Jedna strona. To jest cała dokumentacja, jakiej zamrożony moduł potrzebuje, i jest niezbędna, bo bez niej zamrożenie oznacza utratę wiedzy.

Zamknij drogę zmian. Zmiana w zamrożonym module wymaga decyzji nazwanej osoby. Nie zakazu — decyzji. Chodzi o to, żeby zmiana była zdarzeniem, a nie rutyną.

Zostaw bezpieczeństwo i zgodność poza zamrożeniem. Aktualizacje bezpieczeństwa i zmiany wymuszone przepisami wykonuje się zawsze, także w modułach zamrożonych. Zamrożenie dotyczy inwestycji w jakość, nie utrzymania podstawowego.

Ustal przegląd roczny. Raz w roku sprawdźcie, czy założenie o braku zmian jest nadal prawdziwe. Moduł, który trafił do planu, wychodzi z zamrożenia i wraca do macierzy.

Praktyczna korzyść z zamrożenia bywa niedoceniana: uwalnia zdolność zespołu i, co ważniejsze, uwalnia uwagę. Lista długu obejmująca cały system jest paraliżująca. Lista obejmująca cztery moduły, które faktycznie się zmieniają, jest wykonalna.

Warto się też przygotować na opór, bo pojawia się zawsze i ma dwa źródła. Pierwsze jest zawodowe: inżynierowi trudno zaakceptować, że zły kod ma zostać zły. Odpowiedź na ten sprzeciw jest prosta i uczciwa — nie oceniamy kodu, tylko decydujemy o alokacji ograniczonej zdolności zespołu, a zdolność wydana na moduł, którego nikt nie tknie, jest zdolnością odebraną modułowi, który blokuje dostarczanie co tydzień. Drugie źródło jest praktyczne i poważniejsze: zamrożony moduł z czasem przestaje mieć kogokolwiek, kto go rozumie. Dlatego opis interfejsu i przegląd roczny nie są formalnością — są jedynym zabezpieczeniem przed sytuacją, w której zamrożenie zamienia się w utratę kontroli.

Praktyczna miara skuteczności całego ćwiczenia: po pierwszym przejściu przez macierz zwykle od połowy do dwóch trzecich modułów trafia do zamrożenia. Jeżeli u was ten odsetek wychodzi znacznie niższy, prawdopodobnie mylicie „moduł, który może się zmienić” z „modułem, który zmieni się w planie” — a to pierwsze obejmuje cały system i nie jest kryterium.

Kiedy przepisanie jest naprawdę tańsze niż naprawa?

Przepisanie od zera jest decyzją, którą zespoły proponują częściej, niż jest uzasadniona, i którą zarządy odrzucają częściej, niż powinny. Rozstrzygnięcie sprowadza się do jednego pytania: czy koszt zrozumienia istniejącego rozwiązania przewyższa koszt zbudowania go od nowa.

Trzy warunki muszą wystąpić łącznie. Zakres daje się opisać wejściem i wyjściem — bez tego nie ma kryterium ukończenia, a przepisywanie bez kryterium ukończenia nie kończy się nigdy. Istnieje sposób weryfikacji równoważności: komplet testów, możliwość równoległego uruchomienia obu wersji na produkcji z porównaniem wyników albo zbiór danych historycznych, na którym da się sprawdzić zgodność. Moduł jest aktywnie rozwijany — przepisywanie kodu, którego nikt nie dotyka, ma zwrot zerowy, co wynika wprost z argumentu o nieciągłości kosztu.

Brak któregokolwiek warunku przesuwa właściwą decyzję na inną. Brak opisu zakresu oznacza, że najpierw trzeba go odtworzyć, a to jest osobna praca, którą warto wycenić osobno. Brak sposobu weryfikacji oznacza, że przepisanie zamienia dług techniczny na ryzyko produkcyjne — czyli wymienia problem na gorszy. Brak aktywnego rozwoju oznacza zamrożenie.

Dwie zasady wykonawcze, jeśli decyzja zapadła. Po pierwsze, przepisujcie fragmentami z możliwością przełączania ruchu, nie w całości z jednym momentem zamiany — przełączenie całości jest zdarzeniem, którego nie da się cofnąć w rozsądnym czasie. Po drugie, zamrażajcie funkcjonalność starej wersji na czas przepisywania. Równoległy rozwój obu wersji jest najpewniejszym znanym sposobem, żeby przepisanie nie skończyło się nigdy, a przy okazji podwaja koszt każdej zmiany w tym okresie.

Co zrobić, gdy termin regulacyjny zamienia dług w blokadę?

To jest sytuacja, w której cała powyższa spokojna arytmetyka przestaje obowiązywać, i warto ją rozpoznać wcześnie, bo materializuje się w polskich organizacjach regularnie.

Terminy wynikające z przepisów mają dwie własności, których nie mają terminy biznesowe: są nienegocjowalne i są znane z wyprzedzeniem. Wdrożenie obowiązku wystawiania faktur ustrukturyzowanych, wymogi operacyjnej odporności cyfrowej dla sektora finansowego, obowiązki wynikające z transpozycji przepisów o cyberbezpieczeństwie — każdy z nich zamienia dług w konkretnym module z problemu odkładanego w blokadę z datą.

Postępowanie w takiej sytuacji ma trzy kroki. Po pierwsze, wyceńcie zmianę wymuszoną w dwóch wariantach: na obecnej strukturze i po przebudowie. Po drugie, sprawdźcie, ile innych pozycji z planu na osiemnaście miesięcy dotyka tego samego miejsca — jeśli jest ich więcej niż dwie, przebudowa przed zmianą wymuszoną prawie zawsze wygrywa. Po trzecie, i to jest punkt najczęściej pomijany, policzcie ryzyko harmonogramu: przebudowa przed terminem regulacyjnym oznacza dwie niepewności zamiast jednej. Jeżeli margines czasu jest mniejszy niż górna granica przedziału wyceny przebudowy, właściwą decyzją jest wykonanie zmiany wymuszonej na obecnej strukturze i przebudowa po terminie.

Ostatnie zdanie jest niepopularne wśród inżynierów i jest poprawne. Przekroczenie terminu ustawowego kosztuje więcej niż utrzymanie długu przez kolejny kwartał.

Jest przy tym jedna rzecz, którą w takiej sytuacji trzeba zrobić bezwarunkowo, niezależnie od wybranego wariantu: zapisać decyzję razem z uzasadnieniem i datą. Zmiana wymuszona wykonana „tymczasowo” na starej strukturze bez takiego zapisu staje się po roku po prostu kolejną warstwą, o której nikt nie pamięta, że miała być tymczasowa. Notatka na pół strony — co zrobiliśmy, dlaczego, co zostało odłożone i do kiedy — jest tanim zabezpieczeniem przed najczęstszym mechanizmem narastania długu w organizacjach, które skądinąd zarządzają nim świadomie.

Warto też odnotować, że terminy regulacyjne mają jedną nieoczywistą zaletę: są jedynym momentem, w którym uzyskanie budżetu na przebudowę nie wymaga żadnego rachunku ROI. Nikt nie pyta o stopę zwrotu z obowiązku ustawowego. Organizacje, które umieją to wykorzystać, przeprowadzają przy okazji zmian wymuszonych porządkowanie, które w normalnym trybie czekałoby latami — pod warunkiem że margines czasu na to pozwala. To nie jest obejście reguły z tego przewodnika, tylko jej najczystsze zastosowanie: budżet powstaje z ryzyka i z terminu, a nie z obliczonego zwrotu.

Jakich błędów unikać?

Obiecywanie oszczędności, których nie da się potwierdzić. Największy pojedynczy niszczyciel wiarygodności. Po jednym niedowiezieniu następne wnioski przepadają na dwa lata.

Priorytetyzowanie według jakości kodu zamiast według częstotliwości zmian. Prowadzi wprost do porządkowania modułów, których nikt nie dotyka.

Projekt porządkowy zamiast stałego udziału. Traci sponsora w połowie i zostawia system w stanie pośrednim, gorszym niż wyjściowy.

Refaktoryzacja bez możliwości weryfikacji równoważności. Zamienia dług techniczny na ryzyko produkcyjne, czyli wymienia problem na gorszy.

Traktowanie zamrożenia jako porażki. To jest decyzja, i to zwykle najbardziej opłacalna z trzech dostępnych.

Liczenie długu w liniach kodu albo w liczbie ostrzeżeń narzędzia. Obie miary rosną najszybciej wtedy, gdy zespół pisze więcej kodu, niezależnie od jego jakości. Ten sam mechanizm opisaliśmy szerzej przy okazji metryk QA i benchmarków — mianownik oderwany od funkcjonalności psuje każdą metrykę gęstości.

Jak ARDURA Consulting podchodzi do długu technicznego?

Nie zaczynamy od audytu jakości kodu, bo jego wynik jest zwykle znany zespołowi i nie zmienia niczyjej decyzji. Zaczynamy od dwóch danych, które da się wyciągnąć w jeden dzień: historii zmian w repozytorium za ostatni rok i listy zmian wymuszonych z datami na najbliższe osiemnaście miesięcy. Na tej podstawie wypełniamy macierz z tego tekstu i przedstawiamy cztery, pięć decyzji do podjęcia, a nie listę stu rekomendacji.

Kiedy decyzja brzmi „przepisz”, udostępniamy zespół w modelu Staff Augmentation lub Time & Materials, zwykle w składzie pozwalającym prowadzić przebudowę równolegle do bieżącego rozwoju — to jest zresztą główny powód, dla którego organizacje sięgają po zewnętrzne kompetencje w tym obszarze: przebudowa wykonywana przez ten sam zespół, który dowozi funkcjonalność, przegrywa z funkcjonalnością w każdym trudnym tygodniu.

Najtańszy krok, który możecie wykonać w tym tygodniu samodzielnie: wyciągnijcie z repozytorium liczbę zmian na moduł za ostatnie dwanaście miesięcy i zestawcie ją z listą modułów, o których zespół mówi, że są najgorsze. Rozbieżność między tymi dwiema listami jest zwykle uderzająca i jest najkrótszą drogą do zrozumienia, dlaczego dotychczasowe plany spłaty długu nie przynosiły efektu.

Skontaktuj się z nami, jeśli chcecie przejść przez tę macierz na własnym systemie.