Pogłębiony poradnik
Symulator utraty tempa przez dług techniczny: ile przeróbki kosztuje Twój zespół inżynierów
Analiza branży dla zarządu
Dług techniczny to nagromadzony koszt skrótów: kod, który działa, ale trudno go zmieniać, brakujące testy, splątane zależności i stare systemy, których nikt nie rozumie. Rzadko pojawia się w budżecie. Zamiast tego objawia się poczuciem, że wszystko trwa dłużej niż kiedyś. Szacunki się wydłużają, drobne zmiany psują niezwiązane rzeczy, a zespół spędza sprinty na pracy, która nie tworzy niczego nowego. Rachunek za to nie przychodzi jako opłata, lecz jako mniejsza liczba funkcji dostarczanych co miesiąc przy tych samych płacach.
Istotą problemu jest podatek od zdolności produkcyjnej. Jeśli piąta część każdego sprintu idzie na obejścia i przeróbki, zespół zachowuje się tak, jakby był o piątą część mniejszy, podczas gdy pensje pozostają bez zmian. Dług się też kumuluje. Każda nowa funkcja zbudowana na chwiejnej podstawie dodaje złożoności, więc tracony udział rośnie, o ile część wysiłku nie zostanie przeznaczona na spłatę. Spłata długu kosztuje wynik teraz, dlatego zawsze kusi, by ją odłożyć, i dlatego decyzja zasługuje na liczby.
Model domina śledzi stratę. Udział sprintu tracony na dług zmniejsza zdolność do nowej pracy, co zmniejsza liczbę dostarczonych funkcji. Mniej funkcji zmniejsza wartość dostarczoną na dolara płac, a ciężar przeróbek, gaszenia pożarów i rotacji rośnie wraz z długiem. Ostatnie pole porównuje dostarczoną wartość z prawdziwym kosztem zespołu. Umiarkowany wzrost długu może zamienić zdrowy zwrot w stratę, ponieważ płace są stałe, a wartość nie.
Góra lodowa pokazuje, co ukrywa pozycja płac. Widoczne są same płace. Pod linią wody znajdują się część płac wydana na przeróbki, gaszenie pożarów, które dług powoduje na produkcji, rotacja inżynierów odchodzących ze zmęczonych baz kodu oraz wartość funkcji, które nigdy nie powstały. Ostatnia pozycja to koszt utraconych możliwości, który nigdy nie pojawia się w księgach, a zwykle jest największy. Użyj symulatora, aby znaleźć poziom długu, przy którym zespół przestaje się sam opłacać, i sprawdzić, czy plan spłaty ma sens.
Wzory i założenia metodyczne
Model to miesięczny widok zespołu produktowego. Płace to inżynierowie razy pełny koszt. Część sprintu idzie na dług, część na świadomą spłatę, a reszta buduje nowe funkcje. Dostarczone funkcje to inżynierowie razy funkcje na inżyniera razy ta pozostała część, wyceniane według wartości funkcji. Dług powoduje też incydenty, jako udział kosztu przeróbek, i podnosi rotację, wycenianą na cztery miesiące pełnego wynagrodzenia za jedno zastąpienie. W projekcji dług co miesiąc rośnie, chyba że spłata jest finansowana.
- Udział budowania
- b = 1 − dług − spłata
- Część sprintu, która idzie na nowe funkcje.
- Dostarczone funkcje
- F = inżynierowie × funkcje na inżyniera × b
- Nowe funkcje dostarczone w miesiącu.
- Koszt przeróbek
- W = płace × dług
- Płace, które nie kupiły żadnej nowej wartości.
- Koszt rotacji
- A = inżynierowie × (1% + 0,06% × punkty długu) × 4 miesiące × koszt
- Oczekiwany miesięczny koszt zastępowania inżynierów, rosnący wraz z długiem.
- Wynik netto
- Wynik = F × wartość − płace − 0,15 × W − A
- Dostarczona wartość minus prawdziwy koszt zespołu. Punkt krytyczny to miejsce, w którym spada do zera.
Kaskadowa elastyczność
Udział długu to najbardziej elastyczne dane wejściowe, ponieważ jednocześnie zmniejsza wynik i zwiększa koszty incydentów oraz rotacji. Wartość funkcji i funkcje na inżyniera skalują cały zwrot. Koszt płac ma znaczenie, bo to stała podstawa, którą wartość musi przewyższyć.
Trzy rzeczywiste studia przypadku
Start na własnych środkach
Mały zespół z czystą bazą kodu
Zespół trzech osób utrzymuje niski dług, dostarcza szybko i wysoko wycenia każdą funkcję względem płac. Przeróbki są niewielkie. Załaduj ten przykład, aby zobaczyć wczesną przewagę czystej bazy i jak niewiele długu wystarczy, by zacząć ją podkopywać.
Skalowanie w średniej firmie
Duży zespół, który inwestuje w spłatę
Czterdziestopięcioosobowy zespół ma umiarkowany dług, ale rezerwuje jedną dziesiątą każdego sprintu na porządki. Funkcje są dostarczane w dobrym tempie, a incydentów jest mało. Załaduj ten przykład, aby zobaczyć, dlaczego zdyscyplinowana spłata skaluje się.
Kryzys typu czarny łabędź
Szybko rosnąca baza kodu, której nikt nie potrafi zmienić
Dwudziestopięcioosobowy zespół odziedziczył lata skrótów. Ponad połowa każdego sprintu idzie na przeróbki i incydenty, rotacja jest wysoka, a czas na spłatę wynosi zero. Załaduj ten przykład, aby zobaczyć duże płace przynoszące niewiele i która dźwignia ratuje miesiąc.
Macierz wskaźników branżowych
| Wskaźnik | Strefa zagrożenia | Średnia branżowa | Czołowe 10% najlepszych |
|---|---|---|---|
| Udział sprintu tracony na przeróbki | Powyżej 40% | 15–25% | Poniżej 10% |
| Czas zarezerwowany na spłatę długu | Zero | 5–10% | 15–20% tam, gdzie trzeba |
| Dostarczona wartość na dolara płac | Poniżej 1,0 | 1,2–1,6 | Powyżej 2,0 |
| Miesięczna rotacja inżynierów | Powyżej 2,5% | 1–1,5% | Poniżej 1% |
| Praca przy incydentach jako udział kosztu przeróbek | Powyżej 25% | 10–15% | Poniżej 8% |
Zmienne i dźwignie
Inżynierowie w zespole
Programiści pracujący nad produktem, liczeni w ekwiwalentach pełnego etatu.
Dźwignia: Nie dodawaj najpierw inżynierów do zespołu z dużym długiem, ponieważ każda nowa osoba odziedziczy ten sam balast i spowolni wdrożenie.
Pełny koszt inżyniera miesięcznie
Wynagrodzenie plus podatki, świadczenia, sprzęt i koszty ogólne jednego inżyniera w miesiącu.
Dźwignia: Trzymaj wynagrodzenia na poziomie rynku, ale tnij ukryte koszty ogólne, bo każda godzina stracona na dług jest opłacana według pełnej stawki.
Sprint tracony na dług i przeróbki
Część czasu inżynierów poświęcona na obejścia, naprawianie błędów, wolne budowanie i walkę ze starym kodem zamiast na nowe funkcje.
Dźwignia: Uczyń dług widocznym: wypisz najgorsze moduły, oszacuj godziny przeróbek i napraw najpierw te, które dotykają największej liczby funkcji.
Funkcje na inżyniera miesięcznie (bez długu)
Ile znaczących funkcji jeden inżynier dostarczyłby w miesiącu, gdyby żaden czas nie był tracony na dług.
Dźwignia: Usuń tarcie w budowaniu, testach i przeglądach kodu, ponieważ doświadczenie programisty decyduje o tym, ile funkcji osoba może dostarczyć.
Miesięczna wartość dostarczonej funkcji
Przychód, oszczędności lub utrzymanie klientów, które typowa funkcja dodaje miesięcznie po wdrożeniu, według Twojego szacunku.
Dźwignia: Dostarczaj funkcje, które poruszają przychód lub utrzymanie klientów; jeśli dostarczona wartość jest niska, żadne tempo nie sprawi, że zespół będzie rentowny.
Sprint inwestowany w spłatę długu
Część sprintu świadomie poświęcona na zmniejszanie długu. Kosztuje wynik teraz, a zmniejsza dług później.
Dźwignia: Zarezerwuj stałą część każdego sprintu, często dziesięć do dwudziestu procent, na dług, który blokuje nadchodzącą pracę.
Jak korzystać z tego symulatora
- 1Zacznij od realistycznego ustawienia wstępnego lub wpisz wielkość zespołu, pełny koszt i szacowany udział przeróbek.
- 2Przeczytaj pięć pól efektu domina, aby zobaczyć, czy tempo czy ciężar długu zaczerwieni się pierwszy.
- 3Naciśnij „Znajdź mój punkt krytyczny”, aby zobaczyć udział długu, który czyni zespół nierentownym.
- 4Porównaj obecny plan z planem spłaty na wykresie 24-miesięcznym.
- 5Mierz przeróbki przez kilka sprintów i wracaj do modelu co kwartał.
Błędy, których należy unikać
- Traktowanie czasu traconego na dług jako darmowego, bo pensje są stałe, podczas gdy każda godzina niesie pełny koszt.
- Dodawanie inżynierów do wolnej bazy kodu i oczekiwanie, że tempo wzrośnie proporcjonalnie.
- Planowanie wielkiego przepisania zamiast stałej spłaty długu tam, gdzie blokuje nadchodzącą pracę.
- Ignorowanie rotacji, która jest realnym i powtarzającym się kosztem nieprzyjemnego kodu.
Najczęściej zadawane pytania
Jak oszacować udział sprintu traconego na dług?
Przez kilka sprintów oznaczaj zgłoszenia i pull requesty, które są przeróbkami, poprawkami błędów lub obejściami, a następnie podziel ten czas przez całkowity czas inżynierów. Poproś zespół o zgrubną liczbę jako kontrolę krzyżową.
Czy każdy dług techniczny jest zły?
Nie. Skrót podjęty, by szybciej się uczyć lub dotrzymać terminu, może być dobrą wymianą, jeśli go śledzisz i spłacasz. Dług staje się problemem, gdy jest niezarządzany i się kumuluje.
Ile czasu poświęcać na spłatę?
To zależy od poziomu długu i nadchodzącej pracy. Stałe dziesięć do dwudziestu procent jest częste, ale wydawaj je na dług, który blokuje planowane funkcje, a nie na porządki dla samych porządków.
Jak wycenić funkcję?
Oszacuj choćby zgrubnie miesięczny przychód, utrzymanie klientów lub oszczędności kosztów, które dodaje. Jeśli to niemożliwe, użyj jako punktu wyjścia średniego wzrostu przychodu podzielonego przez liczbę dostarczonych funkcji.
Jak znaleźć poziom długu, przy którym zespół traci pieniądze?
Naciśnij „Znajdź mój punkt krytyczny”. Narzędzie przesuwa każdą daną wejściową w stronę gorszego końca i podaje wartość, przy której miesięczny zysk spada do zera.
Jak dokładne jest to narzędzie?
To edukacyjny model z podanymi założeniami, a nie porada zarządcza. Rzeczywiste wyniki inżynierskie zależą od wielu czynników. Zastąp dane własnymi.
To edukacyjny model planistyczny oparty na jawnie podanych założeniach. Nie stanowi porady finansowej, podatkowej ani prawnej. Należy zastąpić dane wejściowe własnymi liczbami, a ważne decyzje skonsultować z wykwalifikowanym specjalistą.