Jak wyjaśniasz dług technologiczny odbiorcom nietechnicznym?

Question

Accepted Answer

**Przekładam tech debt na język, którym odbiorca już się posługuje: pieniądze, szybkość i ryzyko.** Nietechnicznego stakeholdera nie obchodzi coupling ani pokrycie testami; obchodzi go, że dostarczanie feature'ów staje się wolniejsze i droższe. Dlatego ujmuję dług jako problem finansowy i dostawczy, a nie problem kodu.

## Ujęcie, którego używam

- **Metafora finansowa, używana ostrożnie.** „Poszliśmy na skróty, żeby dowieźć szybko, jak zaciągnięcie pożyczki. Zadziałało, a teraz co sprint płacimy od tego odsetki. Każdy nowy feature w tym obszarze kosztuje więcej z powodu tych odsetek”. To trafia, bo każdy rozumie dług i odsetki.
- **Uczyń to konkretnym ich metrykami.** Nie „kod jest niechlujny”, lecz „ten feature zajął trzy tygodnie; dwa lata temu ten sam rozmiar zajmował jeden. Różnicą jest narzut utrzymania, który zakumulowaliśmy”.
- **Powiąż z rezultatami, na których im zależy.** Wolniejsze dostarczanie, więcej bugów docierających do klientów, trudniejszy onboarding nowych osób, rosnące ryzyko awarii. Połącz dług z przychodem, reputacją i szybkością roadmapu.

## Jak czynię z tego decyzję, a nie skargę

- Prezentuję to jako **trade-off z opcjami**, a nie żądanie: „Możemy dalej dostarczać feature'y w obecnym, zwalniającym tempie, albo zainwestować dwa sprinty teraz, by obniżyć przyszły koszt feature'ów o mniej więcej jedną trzecią”.
- Kwantyfikuję, gdzie mogę: czas tracony na sprint, częstotliwość incidentów, procent zdolności wydawany na gaszenie pożarów.
- Bądź szczery, że **część długu jest w porządku.** Nie cały dług trzeba spłacać; chodzi o spłacenie tego, który aktywnie obciąża dostarczanie.

## Pułapki

- **Używanie żargonu** („refaktor”, „coupling”, „architektura jest zła”). Brzmisz, jakbyś chciał wypolerować kod ponad miarę.
- Ujmowanie tego jako inżynierów chcących czystego kodu dla samej idei; to czyta się jako pobłażanie sobie.
- Wszczynanie fałszywego alarmu — nazywanie wszystkiego długiem podkopuje wiarygodność, gdy pojawi się coś naprawdę pilnego.

## Dlaczego to ważne

Jeśli nie potrafisz wyjaśnić tech debt w kategoriach biznesowych, nigdy nie zostanie sfinansowany, a zespół powoli staje, podczas gdy kierownictwo zastanawia się, dlaczego velocity spada. Ujęcie tego jako kosztu, szybkości i ryzyka jest tym, co daje Ci czas na naprawę, zanim stanie się to kryzysem.