Dług technologiczny a zarządzanie firmą

Poradniki | 15.02.2017 | Czas czytania: 6 minut

Czasami nastaje taki dzień, który w kalendarzu musi zostać zakreślony na czarno. Dla różnych osób przybiera on różną formę: dla programisty może to być „spaghetti kod”, w którym koniecznie trzeba dopisać nową funkcję, a dla Dyrektora IT będzie to konieczność wdrożenia nowego narzędzia i zintegrowania go ze skomplikowanym ekosystemem łatanej od lat infrastruktury IT w firmie. Coś co łączy te sytuacje, to specyficzne zjawisko, którego występowania często do ostatniej chwili nie jesteśmy świadomi - zjawisko długu technologicznego. Dług ten, nawet nieuświadomiony, daje nam poczucie komfortu, pozwala odwlekać w nieskończoność trudne decyzje, wysiłek czy nawet przyznanie się do błędu. A że jest to życie na kredyt, niech przestrogą będą słowa śpiewane przez Billy’ego Gibbonsa: „To zbyt proste, to zbyt proste, by dobrze się czuć”, które w tym wypadku układają się w gorzką pieśń o konsekwencjach odkładania rzeczy na później.

Poznaj wroga

Dług technologiczny oznacza dodatkową pracę, która musi zostać wykonana, w celu zrealizowania jakiegoś zadania ze względu na wcześniejsze zaniedbania w projekcie. Zjawisko to często pojawia się w projektach informatycznych, kiedy pewne zaniedbania względem prac powodują, że pojawia się dług w postaci czasu, który należy przeznaczyć na doprowadzenie projektu do oczekiwanego stanu. We wcześniejszym przykładzie Dyrektora IT, który staje przed wyzwaniem wdrożenia nowego narzędzia, spłata długu będzie polegała na tym, że integracja z przestarzałą, rozwijaną długie lata, często bez odpowiedniej dokumentacji infrastrukturą będzie najprawdopodobniej procesem długim i bolesnym. Poza samym wdrożeniem, konieczne będzie zainwestowanie sporo pracy w dostosowanie całego systemu i naprawę zbierających się przez lata nierozwiązanych problemów.

Długiem technologicznym określa się również problemy, które pojawiają się w niechlujnie napisanym kodzie. Osobiście jestem skłonny stwierdzić, że same problemy nie są długiem technologicznym, a bardziej odsetkami od zaciągniętego długu. Sam dług zaciągamy natomiast, wykonując dowolną czynność, która przyczynia się do dostarczenia kodu nie całkiem spełniającego oczekiwania, nie tylko pod względem zadań jakie ma wykonać, ale też wydajności, czytelności, utrzymywalności i tego, w jaki sposób można go w przyszłości rozwinąć. Powodów takiego stanu rzeczy może być wiele.

Źródła technologicznego długu

Chcąc sprostać wyzwaniu, które stawia nam dług technologiczny, należy przyjrzeć się jego przyczynom, wśród których najczęstsze są następujące zjawiska:

  • brak zaangażowania pracowników w wykonywane zadania;
  • niewystarczające pokrycie funkcjonalności testami;
  • brak testów automatycznych;
  • przestarzałe narzędzia lub technologie używane w projekcie;
  • brak doświadczenia zespołu;
  • presja czasu;
  • brak dokumentacji lub jej niska jakość.

Powyższa lista nie jest oczywiście kompletna, a niektóre aspekty mogą być ze sobą ściśle powiązane. Programiści mogą tworzyć kod niskiej jakości z bardzo wielu powodów: ze względu na brak motywacji, wiedzy lub doświadczenia albo z powodu presji czasu lub braku odpowiednich narzędzi. Programista jest często jedynie pośrednią przyczyną długu, gdyż zarządzanie należy do kierownika projektu, który podejmuje decyzje dotyczące czasu, narzędzi, technologii czy przydzielenia tego, a nie innego pracownika. Czasem trudno jednoznacznie wskazać przyczyny powstawania długu. Do jego powstania mogą prowadzić małe błędy w projekcie lub strategiczne decyzje – na przykład konieczność dostarczenia rozwiązania w bardzo krótkim czasie. Geneza zjawiska w każdym projekcie może być odmienna i bardzo skomplikowana, co jednak nie zmienia faktu, że bez względu na jego pochodzenie, długiem technologicznych należy skutecznie zarządzać.

Dług technologiczny nie zawsze taki zły

Błędem jest jednoznaczne traktowanie długu technologicznego jako czegoś, czego zawsze należy za wszelką cenę unikać. Podobnie jak zaciągnięty kredyt może pozwolić firmie rozwinąć skrzydła, dług technologiczny, zaciągany z głową, może być w wielu przypadkach pomocny.

Dług technologiczny można podzielić na trzy typy, które wyraźnie pokazują, że dług długowi nierówny:

  1. Bałagan – powstający w wyniku niedbałości, kiepskich praktyk, niedojrzałości biznesu.
  2. Nieunikniony dług – dług, którego wystąpienia nie jesteśmy wstanie przewidzieć. Dobra decyzja podjęta dzisiaj może w przyszłości być przyczyną powstania długu.
  3. Strategiczny dług – dług zaciągany świadomie, kiedy wynikające z niego korzyści są większe niż jego konsekwencje.

Może się zdarzyć, że zaciągnięcie długu przynosi bardzo wymierne korzyści. Szczególnie w sytuacji, kiedy projekt wisi na włosku, a dostarczenie odpowiedniej partii programu staje się „być albo nie być” dla projektu. Decyzja o zaciągnięciu takiego długu może nawet uratować cały projekt (a czasem całą firmę). Z tego typu decyzjami należy być jednak bardzo ostrożnym, gdyż nieodpowiednie zarządzanie powstałym w ten sposób długiem może prowadzić do katastrofy.

Czy jestem zadłużony?

Jeśli jesteśmy świadomi swoich długów, jesteśmy w stanie je regularnie spłacać – bez szkody dla bieżącego funkcjonowania, zadłużenie nie jest problemem. Najgorsza jest nieświadomość, ponieważ nie spodziewając się zagrożenia, nie będziemy mieli możliwości odpowiednio się przygotować. Na szczęście w projektach informatycznych symptomy świadczące o istnieniu długu technologicznego pojawiają się dosyć szybko i są widoczne gołym okiem.

Oto kilka pytań diagnostycznych, zaproponowanych przez redakcję portalu Webmastah:

  • Czy rozwijanie oprogramowania jest coraz wolniejsze?
  • Czy zdarzają się częściowe lub całościowe przestoje w działaniu systemu?
  • Czy powracają te same błędy?
  • Czy czas wdrażania nowych funkcjonalności stale wzrasta?
  • Czy twoja aplikacja działa wolno?
  • Czy twoi programiści niechętnie pracują nad projektem?
  • Czy popychałeś zespół do wdrażania nowych funkcjonalności szybciej, niż było to planowane?
  • Czy zdarzają się błędy trudne do odtworzenia lub rozwiązania?

Nawet jeśli na wszystkie pytania odpowiedź jest negatywna, nie należy czuć się przesadnie bezpiecznie. Niektórzy eksperci są zdania, że dług technologiczny jest stałym elementem posiadania lub rozwoju oprogramowania i infrastruktury informatycznej.  

Załóżmy więc, że w każdym projekcie informatycznym dług technologiczny w jakiejś postaci występuje. Oznacza to, że bardzo ważne jest skuteczne zarządzanie tym długiem. Czyli nie wystarczy kontrola i neutralizowanie skutków, dużo ważniejsze jest metodyczne podejście do jakości aplikacji i zapobieganie wystąpieniu długu tam, gdzie nie chcemy go zaciągać.

Jak zarządzać długiem technologicznym?

Długiem technologicznym należy zarządzać i przeciwdziałać mu tam, gdzie nie jest planowany. Ważne są:

  1. Budowa świadomości wagi jakości w firmie. Sama jakość musi być postrzegana jako wartość, o którą należy dbać. Bez tego trudno zarządzać długiem, gdyż niewiele jesteśmy w stanie zrobić bez odpowiedniego podejścia pracowników. Ich zaangażowanie jest kluczowe.
  2. Kontrola procesów. Stała informacja o tym, co dzieje się w projekcie, pozwoli szybko reagować na problemy.
  3. Quality assurance. Opieka nad jakością oprogramowania, sprawowana przez specjalistów, nie tyko w zakresie testów, ale też wszystkich aspektów jakości.
  4. Testy. Im szybciej rozpocznie się testy, tym wcześniej zlokalizowane zostaną problemy. Testy na poziomie dokumentacji i testów jednostkowych bardzo szybko eliminują dług.
  5. Stosowanie dobrych praktyk, np.:
    1. przestrzeganie reguł nazewnictwa dla funkcji, procedur itp.;
    2. stosowanie stylu kodowania (ang. coding style), polegającego na wprowadzaniu odpowiednich wcięć;
    3. tworzenie dokumentacji technicznej;
    4. zapobieganie podstawowym błędom, np. przekroczeniu rozmiaru tabel (ang. table overflow), problemom przy inicjalizowaniu zmiennych itp.;
    5. zarządzanie wydaniami/kopiami zapasowymi (ang. backup);
    6. poprawianie kodu w celu uzyskania lepszej czytelności i łatwiejszego utrzymania, rozwoju w przyszłości (ang. refactoring);
    7. algorytmika: upraszczanie funkcji;
    8. programowanie w parach, aby tworzyć kod lepszej jakości (ang. pair programming);
    9. przeglądy (code review): zastanawianie się nad użytymi rozwiązaniami, usuwanie widocznych błędów.
  6. Szkolenie pracowników.
  7. Promowanie testów jednostkowych jako podstawowego narzędzia, w tym TDD jako standardowego narzędzia wytwarzania oprogramowania przez programistę.

Tak jak poprzednio, także i ta lista jest niestety niekompletna. Dług może mieć bardzo różne źródła, często charakterystyczne dla konkretnej firmy czy nawet projektu. Należy więc wypracować własną technikę zarządzania długiem, najważniejsze natomiast, żeby nie ignorować go do momentu, kiedy jest już za późno i katastrofa, jak komornik, zapuka do naszych drzwi.

Autorem wpisu jest

Leszek Zieliński, JCommerce

Software Quality Assurance Engineer

Od 2011 roku realizuje i kieruje projektami QA. Ekspert w obszarze testów manualnych i automatycznych. Zafascynowany głównie rozwiązaniami BDD. Absolwent Politechniki Śląskiej w Gliwicach. Po godzinach działacz społeczny, muzyk, trójboista.

Komentarze

  • dzek dnia 2018-04-10 20:40:55
    Przyczepiłbym się tylko do jednego: > stosowanie stylu kodowania (ang. coding style), polegającego na wprowadzaniu odpowiednich wcięć; styl kodu to coś więcej niż wcięcia, to również spacje przed/po nawiasach, znaki tabulatora vs. X spacji do robienia wcięć, w php używanie `[]` zamiast `array()`, w javascript nazywanie funkcji anonimowych i cała masa innych rzeczy, zależnych lub nie od samego języka

Skontaktuj się z nami