Sytuacja kobiet w IT w 2024 roku
12.04.20226 min
Ronen Yacobi

Ronen YacobiR&D Director Natural Intelligence

Koszty długu technicznego, o których możesz nie wiedzieć

Dowiedz się o więcej o długu technicznym i zwróć uwagę na kilka jego nie do końca wyraźnych aspektów.

Koszty długu technicznego, o których możesz nie wiedzieć

Wiele artykułów skupia się na tym, jak radzić sobie z długiem technicznym. Ja chciałbym się jednak skupić na mniej popularnym aspekcie tego zjawiska. Mam nadzieję, że to, co napiszę, pomoże Ci w lepszym podjęciu decyzji, jeśli będziesz chciał kiedyś pójść na skróty.

Czym jest dług techniczny?

Krótko mówiąc, dług techniczny tworzy się podczas chodzenia na skróty, aby przyśpieszyć sobie development. Komplikujemy i opóźniamy przez to przyszłe zmiany, sprawiając, że łączny ich koszt będzie większy, niż gdybyśmy w ogóle nie podjęli takiej decyzji. Badanie od CISQ wykazało, że łączny koszt oprogramowania o niskiej jakości w USA wyniósł w 2018 $2.84 biliardy, które w 18.2% były spowodowane przez dług techniczny.  

“Moje zmiany mają wpływ na to, co się dzieje w przyszłości. Mogę widzieć jakiś szybszy sposób na dodanie funkcji, ale może on być niezgodny z modularną strukturą programu, zaśmiecając system. Jeśli podążę więc tą ścieżką, to ułatwię sprawę samemu sobie, ale nie innym - reszta będzie siedzieć na tym kodem tygodnie, a nawet miesiące. Kiedy inni członkowie teamu podejmą taką samą decyzję, to prosta do modyfikowania aplikacja może szybko zgromadzić tyle śmieci, że każda, najmniejsza nawet zmiana, zajmie wiele tygodni i będzie wymagać mnóstwo wysiłku - Martin Fowler. “


Jest to bezpośredni koszt długu technicznego - zwiększony czas developmentu przyszłych funkcji. Ale nie jest to jedyna rzecz. Poniżej przedstawiam koszty długu technicznego, które nie są aż tak oczywiste.  

Ukryte koszty długu technicznego


Zwiększona złożoność

Śmieci w oprogramowaniu zwiększą złożoność systemu jako całości. Takie coś zwiększa koszty przez większą ilość ludzi, którzy wejdą w jakąkolwiek interakcję z danym obszarem (projektowanie nowych funkcji, analizowanie danych, krzywa uczenia się dla nowych członków zespołu itd). Zwiększone koszty zamanifestują się na kilka sposobów - dłuższe spotkania, silosy wiedzy i potrzeba skonsultowania się z większą ilością ludzi przed zmianą lub rozwojem naszego obszaru.


Większa liczba błędów i defektów

Źle zaprojektowane systemy, brak pokrycia testów, zachowania niezgodne z intuicją i inne rodzaje długu technicznego zwiększają szansę na pojawienie się w błędów w systemie, gdy będziemy modyfikować kod. Koszty błędów i defektów mogą być naprawdę duże - chodzi tutaj o czas developerów, utraconych klientów, słaby UX, niska reputacja itd. 


Stracone okazje

Podczas gdy łatwo jest dostrzec skutki długu technicznego, jeśli chodzi o czas developmentu, to zdecydowanie ciężej jest zobaczyć konsekwencje tego, że jakichś funkcji, czy produktów w ogóle nie udało się rozwinąć. Części systemu, które wiemy, że mają duży dług techniczny, mogą zniechęcić zespoły do rozwoju nowych funkcji, ponieważ potrzeba będzie większego wysiłku, a i ryzyko będzie wyższe. 

Sprawia to nie tylko, że dana organizacja nie szuka nowych wyzwań i wolno iteruje, ale też często pojawiają się decyzje, aby czegoś nie rozwijać, i to dopiero po zrozumieniu problemów i złożoności danego obszaru w systemie, szacując wcześniej możliwy nakład pracy i rozmawiając o alternatywach (np. o rozwiązaniach “quick and dirty”, które zwiększą dług techniczny). 


Trudniej jest coś przewidzieć

Ogólnie ciężko jest przewidzieć, która funkcja ucierpi na długu technicznym. Często dzieje się tak, że dowiadujemy się tego dopiero przy implementacji, bo to wtedy pojawiają się znaczne opóźnienia. Niezamierzony wysiłek, który wkładamy w development może być tak duży, że zmieniłby priorytet danej funkcji, gdybyśmy wzięli go pod uwagę przy początkowych planach. Wtedy pracowalibyśmy pewnie nad czymś, co przyniosłoby większą wartość.


Wysiłek wkładany w zarządzanie długiem technicznym

Utrzymanie długu technicznego wymaga wysiłku. A to dlatego, że trzeba m.in. zarządzać zadaniami z nim związanymi, priorytetyzowanie ich (a często też przesunięcie priorytetów), rozmawianie o ich pilności podczas planowania sprintów oraz rozmawianie o planowanych funkcjach. 

Co więcej, kiedy natrafimy na dług techniczny w trakcie developmentu, to team się zatrzymuje i dyskutuje o alternatywach. Co więcej, pod uwagę brany jest również wpływ na interesariuszy, takich jak product manager, feature owner, czy management itd. 


Kultura R&D

I na koniec, wprowadzanie długu technicznego do systemu, bez uporania się z nim, będzie z czasem miało też wpływ na kulturę rozwojowo-badawczą. Może to również zachęcić innych do wprowadzania długu technicznego. 

“Psychosocjologowie i policjanci zgadzają się co do tego, że jeśli w budynku jest jedno rozbite okno, to reszta również będzie niedługo rozbita - Teoria rozbitych okien


Dodawanie śmieci do systemu jest kuszące, a zwłaszcza tam, gdzie jakość jest już i tak niska. Co więcej, to również negatywnie wpływa na developerów i ich rozwój zawodowy - czytają oni niepoprawny kod, zamiast uczyć się czegoś dobrego. 

Przykład

Powiedzmy, że mamy stronę do rejestracji, a kiedy użytkownik klika przycisk, to wysyłane zostanie zdarzenie do potoku eventów - narazie jest on jednak używany w celach analitycznych. Dostajemy teraz nowe wymaganie, polegające na wysłaniu emaila po tym, jak użytkownik się już zarejestruje - wiadomość ma zaprosić ich do wyznaczenia terminu sesji treningowej dla produktu. Tworzymy serwis, który konsumuje te wszystkie zdarzenia i wywołuje wysłanie emaila zaraz po rejestracji. Wszyscy zadowoleni. 

Po chwili nowy serwis zostaje dodany do strony, dostarczając nowy przepływ rejestracji - nie będziemy w nim wysyłać emaila po zarejestrowaniu się. Developer, który to dodał, sugeruje szybkie rozwiązanie, w którym zdarzenie zarejestrowania się nie zostanie wysłane do strony, po weryfikacji z product managerem i analitykiem faktu, że event nie zostanie użyty w nowym serwisie. Nowa strona już działa i wszyscy są znowu zadowoleni. 

Przyjrzymy się konsekwencjom i kosztom takiej decyzji:

Złożoność systemu została zwiększona - powinniśmy mieć proste zdarzenie do zarejestrowania się, a mamy zdarzenie z ukrytą logiką, które nie zawsze jest wysyłane, a system wywołujący wysłanie emaila jest teraz połączony z tą logiką. Będzie to miało wpływ na przyszłe zmiany w tych komponentach, co może wymagać, aby wielu ludzi było zaznajomionych z powyższą logiką. Np. analitycy powinni wiedzieć, kiedy mogą, a kiedy nie powinni używać danych eventów do analizy - albo dowiedzieć się o tym w nieprzyjemny sposób. 

Bardziej prawdopodobne jest to, że wystąpią jakieś błędy. Na przykład, jeśli dodamy nowy przepływ, który nieprawidłowo uruchamia zdarzenie rejestracji, nie chcąc wywoływać wysyłania emaila do użytkownika. Jeśli developer zorientuje się odpowiednio szybko, to bug się jednak nie pojawi. Niemniej jednak pojawią się opóźnienia w projekcie, ponieważ team musi zdecydować, czy ominąć jakoś dług techniczny, czy refaktoryzować i usunąć go. Obie opcje wprowadzą do projektu nieplanowane opóźnienia, negatywnie wpływając na przewidywalność pewnych rzeczy. 

Jeśli team zdecyduje się na obejście tego problemu, to dodane zostaną pewnie do backlogu jakieś zadania dotyczące refactoringu, którym trzeba nadać priorytet, omówić je i ponownie o nich porozmawiać po pozbyciu się długu. Zarządzanie długiem technicznym jest wtedy o wiele bardziej kosztowne.  

Podsumowanie

Następnym razem, jak przyjdzie Ci do głowy wprowadzić dług techniczny, zadaj sobie, albo interesariuszom, następujące pytanie - czy wartość wydania nowej funkcji, produktu wcześniej tak bardzo przeważa wartość tych funkcji, które zostaną przez to opóźnione?

W większości przypadków odpowiedź będzie brzmiała “nie” - przyszłe rzeczy będą prawdopodobnie tak samo ważne, jak te, z którym paramy się teraz. Kiedy podejmujesz decyzję, żeby zrobić coś szybciej, to miej dobry plan i upewnij się, że dobrze go zakomunikujesz. Wtedy wszyscy będą już wiedzieć, czego trzeba, aby rozwinąć dany system, czy dany produkt.

Dajcie znać, co sądzicie w komentarzach.


Oryginał tekstu w języku angielskim możesz przeczytać tutaj.

<p>Loading...</p>