Dług technologiczny – jak nim zarządzać?

Dług technologiczny nie jest nowym zjawiskiem. Przedstawiciele branży IT znają to sformułowanie aż za dobrze, gdyż nader często zmuszeni są stawiać czoła jego konsekwencjom. Rzecz w tym, by nie tylko wiedzieć, że ma się dług, ale przede wszystkim umieć sobie z nim radzić. Problemy techniczne spowodowane powyższym utrudniają, a czasem nawet uniemożliwiają dostarczanie wartości przez firmę – w ten sposób jej rozwój wyhamowuje, a koszty pracy rosną. Kluczem do sukcesu w zarządzaniu długiem technologicznym jest regularne rozwiązywanie problemów w ramach codziennego rytmu pracy programistów. Zaległość musi zostać uregulowana – w przeciwnym razie firma może zaczynać pracę od zera. Mówiąc wprost: dług techniczny to wszystko, co spowalnia lub utrudnia proces rozwoju przedsięwzięcia uniemożliwiając programistom osiągnięcie pełnej produktywności.

Skąd się bierze dług technologiczny?

Specjaliści są zgodni w kwestii źródeł długu technologicznego. Twierdzą oni, że wynika on przede wszystkim z niedbalstwa i działania w pośpiechu w celu szybszego osiągnięcia wyników. Czasami powstaje on wyniku źle lub pospiesznie napisanego kodu. Zdarza się również, że ów kod w dniu swoich narodzin jest ósmym cudem świata, jednak po jakimś czasie nie spełnia już tak dobrze swojej funkcji. Innym razem zaciągamy dług zupełnie świadomie, dla dobra projektu, spodziewając się pewnych konsekwencji.

W drodze do perfekcji

Optymiści uważają, że dług technologiczny, choć z reguły kłopotliwy, doprowadza w końcu firmę do miejsca, w którym powinna się znaleźć. Chodzi o bezustanne ulepszanie kodu w niekończącej się drodze do perfekcji.

Spłacanie zadłużenia technologicznego możemy porównać do przebudowy kodu źródłowego. Wyobraźmy sobie, że postawiliśmy właśnie idealny dom – wszystko jest w nim na swoim miejscu, a każdy element zgodny jest z najnowszymi trendami. Czy oznacza to, że do końca życia mamy już z głowy i nie czekają nas żadne dalsze prace? Nic podobnego! W końcu i tak będziemy musieli wymienić kilka elementów, takich jak np. okna lub dach. Niektóre zmiany nie będą spowodowane upływem czasu lub nadmierną eksploatacją, lecz po prostu naszą decyzją – chcemy przecież, żeby nasze otoczenie nie odbiegało od obowiązujących standardów. W ten sposób nasz dom zawsze będzie wyglądał świeżo i służył nam tak samo dobrze, jak w momencie oddania do użytku. To samo dotyczy kodu źródłowego.

Ulepszanie to niekończąca się podróż. Doskonałość to stan, którego nie da się osiągnąć — zawsze będziemy do niej dążyć. Ważne, by nie zostać w tyle.

Niestety, dług technologiczny ma tę nieprzyjemna właściwość, że często go nie zauważamy, aż do momentu krytycznego. Wróćmy na moment do naszego idealnego domu. Wyobraźmy sobie, że ma on już swoje lata, ale nadal wygląda i sprawuje się doskonale. Nic nie wskazuje na to, że dach się zestarzał i wymaga remontu. Przekonujemy się o tym dopiero w momencie, kiedy zaczyna nam kapać na głowę. Wtedy przychodzi czas na radykalne działania. Jeżeli będziemy trzymać rękę na pulsie, unikniemy zapóźnień, które mogą słono kosztować naszą firmę (niezależnie od tego, czy będziemy mierzyć te straty w przychodach, czasie czy zaangażowaniu pracowników). Klucz do sukcesu tkwi w utrzymywaniu bezustannie aktualizowanego kodu, żeby… dach nie zawalił nam się na głowę.

Jak spłacić dług techniczny?

Warunkiem spłaty długu technologicznego jest posiadanie odpowiedniej ilości czasu, a tego – jak dobrze wiemy – zwykle nam brak. Przekonanie zarządu, by ten udzielił nam zezwolenia na pracę nad poprawkami i nowymi funkcjami, które pozwolą nam spłacić zadłużenie, graniczy z cudem. Poświęcenie całego tygodnia na refaktoryzację projektu? To się raczej nie uda.

Cóż zatem począć? To proste – trzymać rękę na pulsie! Za każdym razem, kiedy trafi nam się zły kod, którego usunięcie nie pożre wiele naszego czasu, powinniśmy zająć się nim natychmiast. Nie trzeba naprawiać wszystkiego naraz – wystarczy mieć pewność, że przy każdym zatwierdzeniu kod jest lepszy niż przed naszą ingerencją. Trzymając się tej zasady z czasem poprawimy jakość całego kodu, nie przestając dostarczać klientowi produktu najwyższej jakości. Solidnie przetestowany kod bazujący na niezależnych od siebie modułach to oszczędność czasu. Dlaczego? To proste! Jeżeli nasz kod pisany jest modułowo, łatwiej będzie go naprawić, działając na jego niezależnych elementach. Zmiany dokonywane podczas takiej operacji nie wpłyną na resztę projektu, a więc będziemy zabezpieczeni na wypadek prawdziwej katastrofy.

Dobrym nawykiem jest spłacanie niewielkich kwot długu technologicznego za każdym razem, kiedy uda nam się zakończyć nasze zadania przed czasem. Takie wyciskanie do cna czasu pracy to nie nadgorliwość, a raczej prosta droga ku ograniczaniu prawdopodobieństwa pojawienia się przykrej niespodzianki.

Inną kwestią jest komunikacja wewnątrz zespołu. Grupa programistów działających w ramach jednej firmy powinna odbywać regularne rozmowy na temat spłaty zadłużenia technologicznego. W ten sposób, dzięki wspólnemu poczuciu odpowiedzialności za projekt, ich praca będzie jeszcze bardziej wydajna. Wykrywanie i natychmiastowe naprawianie błędu, zanim zostanie on faktycznie zintegrowany z systemem, jest niezwykle cenne, ponieważ nie generuje nowego długu technicznego.

Specjaliści zwracają uwagę na konieczność przygotowywania planów spłaty ewentualnych długów. Bo, jak wiemy, przezorny jest zawsze zabezpieczony.

Warto utrzymywać dobry kontakt z kierownictwem wysyłając regularne raporty o naszych postępach. Nawet jeśli interesariuszom średnio zależy na wiedzy, w jaki sposób udało nam się usunąć dziesiątki wierszy zduplikowanego kodu, z przyjemnością usłyszą, że nasza refaktoryzacja pomogła naprawić błąd, którym nikt wcześniej nie chciał się zająć.

Co z tym długiem? Wniosek

Choć sformułowanie „dług technologiczny” brzmi groźnie, czasem spokojnie możemy z nim żyć. Najważniejsza jest świadomość jego istnienia i wiedza, z jakimi wiąże się on konsekwencjami. W przypadku niektórych firm naprawa błędu może oznaczać 100 godzin pracy programisty, natomiast pozostawienie go w stanie „nienaprawionym” to kwestia ingerencji kogoś z obsługi raz na 12 miesięcy. Przy takim założeniu naprawa błędu zwróciłaby się pewnie dopiero po kilkunastu latach. Owszem, jest to dość ekstremalny przypadek, jednak pokazuje nam, że długiem technologicznym trzeba po prostu umiejętnie zarządzać — nie zawsze trzeba się go pozbywać tak szybko, jak to jest tylko możliwe, a czasem nawet nie opłaca się go „spłacać”.