Kiedy warto zaciągnąć dług technologiczny?

Dług technologiczny jest zaciągany wtedy, gdy mając na szali krótszy czas developmentu i jakość kodu – świadomie wybieramy szybsze/tańsze ukończenie projektu kosztem jakości. Warto powiedzieć, że jeśli ta droga nie jest świadoma to nie mamy do czynienia z długiem technologicznym tylko niekompetencją 🙂

Dług technologiczny nie musi być zaciągany tylko w kodzie, można go również zaciągnąć w zarządzaniu projektem i w każdej innej płaszczyźnie mniej lub bardziej związanej z projektem, który tworzymy. Jeśli chodzi o kod, długiem technologicznym może być brak napisanych testów jednostkowych, brzydkie metody (długie, nie rozbite, z mylącą nazwą – ale o jakości kodu kiedy indziej) czy użycie wzorca projektowego, który jest nam znany, zamiast tego, który jest odpowiedni 🙂 Jeśli chcemy zaciągnąć dług technologiczny w płaszczyźnie zarządzania projektem, to wbrew pozorom też mamy duże pole do popisu. Można napisać okrojoną  dokumentacje (lub w ogóle nie pisać); nie stworzyć odpowiedniej higieny pracy dla developerów (trzymać pliki projektowe w nieodpowiedniej strukturze, nie zapewnić komunikacji między zespołem, nieprzygotowanie struktury repozytorium itp). Odpowiednia higiena pracy dla developera jest gdy nie musi o nic pytać (gdzie/co/jak) ponieważ potrafi sam znaleźć odpowiedź np. w przygotowanym dokumencie. Dług technologiczny zaciągnięty w płaszczyźnie zarządzania projektem, może być groźniejszy ponieważ rzutuje na ogół projektu. Bez jasno wytyczonych zasad, kod może być niespójny, niesprawdzony – a co najgorsze nie będziemy wiedzieć, w którym miejscu występuje “defekt”.
Nie spłacając długu technologicznego, tylko łatając łatki łatek i modląc się, żeby nic innego się nie “wysypało” jesteśmy w “kole śmierci” 😉 Doskonale obrazuje to tweet, na który dziś się natknąłem:

 

 

Każdy dług trzeba spłacić – technologiczny również. Zaciągając go, powinniśmy mieć plan, kiedy go spłacimy. Musimy też odpowiedzieć sobie na pytanie, ile wtedy będą wynosiły odsetki 🙂 W niektórych przypadkach nie da się przewidzieć kiedy będzie potrzeba spłaty długu, lub jaka będzie jego cena. Ważne by mieć odpowiedni “timing” i poprawić jakość projektu zanim wystąpi problem (bo powinniśmy się skupić na zapobieganiu problemów zamiast ich rozwiązywaniu 😉 ).

Dług technologiczny często jest zaciągany w startupach, ze względu na to, że są to najczęściej projekty niskobudżetowe. Czasami trzeba coś zrobić “na kolanie” żeby zdążyć pokazać wersję inwestorowi lub na konferencji. Czy to coś złego? Wręcz przeciwnie, uważam, że są to bardzo dobre decyzje. W startupach głównie chodzi o to, żeby zarobić na produkcie w pewnej perspektywie czasu. Po co nam produkt, który będzie napisany idealnie pod względem technologicznym, jeśli nie wiemy czy będzie rentowny, spodoba się użytkownikom, a czas produkcji MVP (minimum viable product) wydłuży się o kilka tygodni. Pomijamy fakt, że konkurencja nie śpi, więc każdy dzień może być kluczowy. We wszystkim trzeba zachować umiar, produkt nie może mieć tyle bug’ów ile funkcjonalności, ale można zastosować prostsze algorytmy, wolniejsze rozwiązania (czas wykonania kodu) itp. Kolejnym aspektem jest to, że wbrew pozorom (w niektórych przypadkach) dług technologiczny staje się tańszy w perspektywie czasu.

Przykład: do zrealizowania projektu, najlepszym wyborem będzie framework X. Natomiast jesteśmy biegli we framework Y, który jest wolniejszy, starszy. Zrealizowanie produktu na framework X będzie trwało dłużej o 2 tygodnie (bo musimy się go nauczyć). Jeśli jesteśmy startupem to 2 tygodnie kosztuje nas 15% naszego budżetu. Zaciągamy dług technologiczny, wybierając framework Y, który jest nam znany. Jeśli produkt okazał się nietrafiony i nie jest rentowny – zamykamy go, nie spłacając długu. Natomiast jeśli produkt się zwraca, wraz z tym rośnie nasz budżet. Nawet jeśli odsetki wynoszą kolejne 2 tygodnie (bo musimy przenieść więcej rzeczy), cały dług wynosi 4 tygodnie, jest to mniejsza część naszego budżetu, np. 2-5%. Cena, którą musimy zapłacić jest relatywnie niższa, dlatego “boli” nas mniej, mimo, że płacimy więcej. Liczby są fikcyjne, chodzi mi o przekazanie sposobu podchodzenia do zaciągania długu.  Istnieją oczywiście sytuacje, które działają odwrotnie – nie opłaca się zaciągać długu technologicznego ponieważ jego cena będzie niewymiernie duża.

Dobrze jeśli decyzja o zaciągnięciu długu technologicznego wychodzi “od góry” – czyli jest decyzją biznesową. Rodzi się problem, gdy developerzy postanowili zaciągnąć dług nie konsultując tego z nikim i nagle dowiadujemy się o “kwocie” i odsetkach 😉
Tym wpisem, nie chcę nakłaniać nikogo do zaciągania długu, chcę pokazać, że nie trzeba się bać tego typu pożyczek. Najważniejsze jest by robić to świadomie i mieć plan i termin jego spłaty 🙂


Stworzyłem ebook o zarządzaniu projektami, analizie IT i startupach, który możesz bezpłatnie pobrać zapisując się na poniższą listę mailingową.


Na co dzień prowadzę fresh-apps.com.

Jeśli wpis ci się spodobał, udostępnij go lub śledź mnie na facebooku, twitterze, LinkedIn lub subskrybuj mój kanał na YouTube – twoja interakcja motywuje do dalszego pisania! Jeśli interesują cię podobne treści, dopisz się do newslettera (na górze strony) :).


Udostępnij

3 thoughts on “Kiedy warto zaciągnąć dług technologiczny?

  • 20 października 2015 at 11:50
    Permalink

    Deweloperski dług technologiczny uważam, że nie trzeba jakoś szczególnie konsultować – jeśli w zespole jest zgodna na użycie gorszego framework-a to spoko. Biznes chce by po prostu działało. Niektórzy jednak zamiast wziąć dług technologiczny to biorą technologiczny kredyt hipoteczny a potem zwalniają się z pracy. Oni uważają, że kody, które piszą są super – na rozmowach się chwalą jakie to wielkie systemy napisali a później robią to samo – kredyt hipoteczny i ucieczka ; )

    Reply
    • 20 października 2015 at 18:28
      Permalink

      technologiczny kredyt hipoteczny – ciekawe określenie 🙂
      masz na myśli, że Ci programiści piszą taki zły kod, czy robią przerost formy nad treścią? Dlaczego “uciekają”? 🙂

      Reply
      • 5 sierpnia 2016 at 14:03
        Permalink

        ci co ja ich znam nie piszą kodu, robia kod kreatorem i podają za swoj, iinkasuja kase i uciekaja

        Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.