Przeczytaj wersję webową.

Kto zarabia na tworzeniu długu technicznego

2023-03-20

Cześć!

To pierwszy newsletter, który wychodzi zarówno w formie emaila, jak i na stronie. Daj znać jak się czyta i czy nie powstały jakieś błędy.

A więc w dzisiaj mam dla Ciebie:

Miłego czytania 😀

💸 Kto zarabia na tworzeniu długu technicznego

… i go nie spłaca?

To pytanie jest tricky. Z dwóch powodów.

  1. Na długu technicznym (raczej) nikt świadomie nie zarabia.
  2. Nie chodzi tutaj o celowe zaciąganie długu np. na potrzeby MVP. Wtedy zaciąga się dług, aby go spłacić.

Jednak w organizacjach, często możecie spotkać grupy, które na długu technicznym zarabiają nieświadomie, a go nie spłacają:

  • Managerowie lub interesariusze, którzy przedkładają krótkoterminowe zyski nad długoterminową stabilność. Zyskują bonusy za dowiezienie projektu na czas. Następnie nie partycypują w spłacaniu długu przez np. zmianę projektu, czy firmy.
  • Zespół produktowy który jest premiowany pod kątem liczby wprowadzanych funkcji. Nie biorą pod uwagę techniczne ograniczenia lub skutki ich decyzji dla jakości produktu.
  • Sprzedawcy, którzy są rozliczani za liczbę klientów którzy wykorzystują system. A że Ci klienci wymagają funkcjonalności, które się szyje na kolanie, to już jest problem IT.
  • Mogą być to również developerzy/liderzy, którzy dowożą projekt w słabszej jakości, ale szybciej. Dzięki temu są promowani na wyższe stanowisko, gdzie nie muszą już utrzymywać danego systemu.
  • Developerzy mogą również zarabiać na długu technicznym będąc jedyną osobą, która może ten dług spłacać. Wtedy staje się herosem, który jest w stanie naprawić obecny stan systemu.

Każda z tych ról odnosi konkretne zyski z zwiększania się poziomu długu technicznego.

Ale jak to, przecież organizacji jest gorzej

Jedna osoba skomentowała draft:

Nie prawda - Project Managerowie zarabialiby na projektach dających wartość dla organizacji.

To jest interesujący komentarz, ponieważ uświadomił mi pewien błąd kognitywny.

Problemem jaki tutaj wpadamy jest patrzenie na firmę jako na całość, a nie jako na zbiór jednostek. Owszem, obiektywnie firmie przez to dzieje się gorzej. Ale subiektywnie jednostkom może być nawet coraz lepiej. Poszczególne osoby będą osiągać zyski tak długo jak organizacja żyje. A później się zwolnią i pójdą pracować gdzieś indziej.

Niestety, ludzie naturalnie są nakierowani na osiąganie krótkoterminowych zysków. Może nas wcale nie interesować, że w firmie będzie długofalowo źle, kiedy teraz pieniądz wpada.

Jak to mówił John Maynard Keynes:

In the long term we are all dead.

Jak organizacja sama wspiera tworzenie długu technicznego?

Nie chcę tutaj wzbudzać atmosfery przerzucania odpowiedzialności. W 99% nie jest tak, że jednostki celowo pracują przeciwko organizacji. Raczej organizacja jest tak zbudowana, że sama wspiera negatywne zachowania. A one ostatecznie tworzą dług techniczny.

Zwykle jest to spowodowane przez przez błędny system premii, promocji i inne zachęty:

  • Skupianie się na Output zamiast na Outcome, co sprawia, że optymalizujemy się pod wykonywanie pracy, a nie rzeczywiste wyniki. Oferowanie premii lub promocji na podstawie wskaźników krótkoterminowych, takich jak liczba wdrożeń nowych funkcji.
  • Brak informacji zwrotnej po całym procesie np. jaki nowo sprzedane funkcje dają zwrot dla całego produktu. Nie branie pod uwagę tych informacji przy naliczaniu bonusów i premii.
  • Koncentrowanie się na nagrodach dla jednostek, a nie dla zespołów. Tworzy to konkurencję pomiędzy członkami zespołu, prowadząc do braku współpracy i mniejszej uwagi do jakości produktu.
  • Promowanie “herosów”, którzy ratują pożary, zamiast osób, które sprawiają, że one w ogóle nie występują.

Można też spojrzeć na samą strukturę organizacji:

  • Budowanie struktur, które nie są nastawione na cały strumień wartości. To powoduje lokalną optymalizację i premiowanie pracy działu, zamiast efektywności całej organizacji.
  • Wyznaczanie nierealistycznych terminów bez dyskusji z działami, które faktycznie tworzą dane rozwiązanie. Będąc postawieni pod ścianą musimy zaciągać dług techniczny.
  • Brak ekspozycji informacji o stanie produktu do struktur osiągających zyski. Ułożenie struktury, gdzie informacja dociera zbyt późno, by mieć wpływ na decydentów.

Bardzo ciekawy jest artykuł z HBR, który opisuje jak plany bonusowe (incentive plans) powodują zwiększanie się problemów w organizacjach.

Nie ma Cię w newsletterze?
Zapisz się na radekmaziarka.pl

Jak zmienić organizację, aby wspierała radzenie sobie z długiem

Na pewno nie pomoże tutaj nawoływanie do walki z długiem. Nie zmienisz zachowań ludzkich. Jeśli osiągasz zyski z tego, że wypuszczasz słabe produkty i ich nie naprawiasz to nie będziesz zainteresowany ich poprawą.

To co organizacja może zrobić to zmienić system działania, aby brał pod uwagę zarówno wartości krótkoterminowe, jak i długoterminowe.

  • Definiuj cele, które biorą pod uwagę długofalowe wskaźniki. Osoby na każdym szczeblu powinny rozumieć konsekwencje długu technicznego i przedkładać zrównoważone praktyki nad krótkoterminowe zyski.
  • Unikaj bonusów i premii na podstawie wskaźników, które nie są związane z całym strumieniem wartości.
  • Buduj cross-funkcjonalne struktury, które naturalnie będą musiały kooperować ze sobą. Dzięki temu łatwiej jest unikać optymalizacji pod proste wskaźniki.
  • Tłumacz techniczne zawiłości na miary, które są zrozumiałe przez biznes. Określaj ile tracimy, przez to, że np. infrastruktura jest utrzymywana w skandalicznych warunkach.
  • Zapewnij edukację i szkolenia osobom nietechnicznym. Pokaż w jaki sposób organizacja cierpi przez wzrost długu technicznego.
  • Zachęcaj do zarządzania długiem technicznym i nagradzaj taką poprawę. Organizacja powinna mieć proces i plan regularnej oceny długu technicznego i zarządzania nim.

Na pewno nie jest to proces łatwy, ani przyjemny. Nikt nie lubi tracić bonusów gdy zarabia na przerzucaniu problemów na innych 😅

Część z powyższych porad jest zbliżona do tych, które opisywałem w artykule o prawie Conway’a, bądź prezentacji w tym samym temacie.

A jak to wygląda u Ciebie?

Spotkałeś(aś) się kiedyś z taką sytuacją?

Daj znać w odpowiedzi na tego e-maila z jakimi przykładami masz styczność. Bardzo mnie interesują te tematy i chętnie pogłębię swoją wiedzę na ich temat. 😊

🤝 Gdzie mnie złapać?

W najbliższym czasie będę występować na kilku spotkaniach i konferencjach:

📌 KGD.NET - Kraków - 22 marca

📌 rg-dev - Rzeszów - 23 marca

📌 4Developers - Warszawa - 18 kwietnia

Jeśli chcesz posłuchać prelekcji i pogadać ze mną to serdecznie zapraszam 😊

📧 Prześlij dalej

Dzięki, że doczytałeś(aś) do końca. 😊

Wszystkie poprzednie wydania newslettera są dostępne tutaj.

Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję.

A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się.

Polecam się na przyszłość!
Radek Maziarka

Radek Maziarka
"Inżynierskie podejście do produktów cyfrowych."

P.S. Co myślisz o tym newsletterze? Odpisz :)