Na konkretnym przykładzie, pokażę Ci jak w perspektywie kilku lat prezentuje się dług technologiczny. Ten post kieruję przede wszystkim do strony osób reprezentujących stronę biznesową.
Czym jest dług technologiczny?
Konflikt między działem IT a działem biznesu
Problem ze zrozumieniem długu technologicznego
Wdrożenie ecommerce a dług technologiczny
Co wynika z przykładu obrazującego dług technologiczny?
Podsumowanie
Czym jest dług technologiczny?
Jak zawsze na początek konkretna i prosta odpowiedź. Dług technologiczny to naturalne zjawisko, polegające na tym, że koszt dodania identycznej funkcjonalności do danego projektu IT wzrasta wraz z rozwojem projektu IT.
Jeśli jesteś zainteresowany tym, jakie są skutki długu technologicznego, gdzie leży największy konflikt pomiędzy działem IT a działem biznesowym w kontekście tego zjawiska, zapraszam do dalszej części artykułu.
Konflikt między działem IT a działem biznesu
Są dwie przyczyny, poprzez które dług technologiczny stanowi obszar nieporozumień między działem IT a działem biznesu.
Przede wszystkim, dział IT często nie potrafi prosto wyjaśnić, czym jest dług technologiczny. Mówi się, że trzeba zainwestować więcej w kodowanie, aby uniknąć generowania długu technologicznego. Albo mówi się, że projekt ma duży dług technologiczny i powinno się przeprowadzić coś, co nazywamy „refinement”. Dział biznesowy zastanawia się, co to właściwie oznacza i nie dostaje klarownej odpowiedzi od IT.
Często zdarza się również, że biznes zadaje pytanie pomocnicze (skoro nie wie, co to jest, to przynajmniej chce wiedzieć czy ten dług technologiczny jest ważny, bo kosztuje dużo, czy można go po prostu pominąć) o koszt długu technologicznego. Problemem jest to, że dział IT nie jest w stanie często określić tego kosztu. I to jest duży problem.
Połączenie tych dwóch aspektów – nieznajomość kosztu oraz niezrozumienie samego pojęcia – sprawia, że biznes po prostu pomija zjawisko długu technologicznego. Każdy projekt IT, w tym także projekt wdrożenia ecommerce, jest związany z zjawiskiem długu technologicznego.
Problem ze zrozumieniem długu technologicznego
Problem polega na tym, że dług technologiczny jest bardzo nieuchwytny. Nikt nie raportuje jego wartości. Aby to zilustrować, wyobraź sobie, że mamy sklep na Magento w wersji podstawowej, bez żadnych modyfikacji czy dodatkowych modułów. Czysty kod “wyjęty z pudełka”.
Następnie decydujemy, że chcemy dodać moduł pomagający w zarządzaniu rabatami. Przy założeniu, że mamy Magento w wersji podstawowej, dodanie tego modułu zajmuje 16 godzin (tak szacuje agencja, z którą współpracujemy).
Jednak, gdybyśmy chcieli dodać identyczny moduł do projektu Magento, który ma już wdrożonych 20 modułów i niestandardowo zmodyfikowany kod, dodanie identycznego modułu z rabatami mogłoby zająć już 64 godziny zamiast 16 godzin. To, że rozwijanie projektu o kolejne funkcjonalności staje się coraz droższe, jest właśnie tym, co nazywamy długiem technologicznym.
Dług technologiczny nie jest często zauważalny w budżecie. Wynika to z tego, że gdy rozliczasz się z agencją ecommerce, najczęściej ustalasz konkretną liczbę godzin miesięcznie, którą agencja będzie przeznaczała na pracę nad Twoim projektem IT. Nikt z biznesu za bardzo nie wnika w to, ile z tych godzin poświęcanych jest na naprawianie błędów, ile na faktyczny rozwój, ile na podnoszenie wersji oprogramowania itd. Najczęściej jest tak, że po prostu biznes wie, że na współpracę z agencją poświęcanych jest 80h miesięcznie x 250 PLN = 20.000 PLN i tyle.
💡 Jeśli chcesz lepiej zrozumieć tą sytuację przeczytaj nasz wpis o tym ile kosztuje utrzymanie i rozwój Magento!
Załóżmy, że płacisz za 80 godzin, jak na prezentowanym przykładzie. Przez 5 lat miesięcznie płacisz za te same 80 godzin. Problemem jest jednak zmieniająca się proporcja godzin pomiędzy utrzymaniem i naprawianiem błędów a rozwojem.
W pierwszym roku to 20 godzin na utrzymanie i naprawianie błędów oraz 60 godzin na rozwój. Natomiast w piątym roku proporcja ta wynosi już 40 do 40.
Biznes nie zawsze dostrzega, że liczba godzin na utrzymanie i naprawianie błędów rośnie, co oznacza, że utrzymanie Magento kosztuje go coraz więcej. Widzi jedynie stałą liczbę godzin, które wydaje.
Po pewnym czasie biznes zaczyna zauważać, że za te same 80 godzin wykonuje się coraz mniej pracy, pojawia się więcej błędów, a serwis rozwija się wolniej. Coraz więcej środków idzie na rozwiązywanie konfliktów i inne utrzymaniowe zadania, które IT raportuje jako utrzymanie.
To obserwowane zjawisko to właśnie spłacanie zaciągniętego długu technologicznego. W rzeczywistości, płacisz software house’owi te same 80 godzin miesięcznie, ale coraz większa część tych godzin jest przeznaczona na utrzymanie i naprawianie błędów. Od razu wyjaśnijmy, że nie koniecznie oznacza to, że agencja ecommerce pogorszyła jakość swojej pracy i zaczęła zatrudniać tylko mało doświadczone osoby. Duży wpływ na wysokość długu technologicznego ma to jakie decyzje programistyczne zostały podjęte na etapie projektowania systemu.
Wdrożenie ecommerce a dług technologiczny
Pojawia się pytanie, czy sposób zakodowania pierwotnego sklepu internetowego lub platformy B2B oraz wybór agencji ecommerce wpływają na podział godzin pomiędzy utrzymaniem, usuwaniem błędów i rozwojem. Przeanalizujmy 2 sytuacje.
W pierwszej mamy sklep internetowy, za którego wdrożenie zapłacono 416.000 PLN. Utrzymanie i naprawianie błędów przez ten czas to liczba godzin przemnożona przez liczbę miesięcy w każdym roku i przemnożona przez stawkę godzinową 250 PLN, z uwzględnieniem rocznej inflacji 6%.
Po przeliczeniu wszystkiego, utrzymanie i naprawianie błędów wynosi 517.000 PLN przez 5 lat. Łącznie za wdrożenie, utrzymanie i naprawianie błędów zapłacimy 933.200 PLN. W tym przykładzie nie uwzględniono budżetu rozwojowego, celowo, aby pokazać pewne zjawisko
Załóżmy, że podejmujemy decyzję o obniżeniu kosztów wdrożenia. Zwracamy się do agencji ecommerce z prośbą o zmniejszenie ceny, ale przy zachowaniu tego samego zakresu funkcjonalności.
W takim wypadku agencja zazwyczaj zaczyna korzystać z większej liczby gotowych modułów, które są już napisane i gotowe do wdrożenia. Teoretycznie powinny one działać bezbłędnie, ale niestety nie zawsze tak jest.
Korzystając z większej liczby zewnętrznych modułów, możemy zmniejszyć koszt wdrożenia. Wyobraź sobie, że udało nam się zaoszczędzić na wdrożeniu 67.000 PLN. To znaczna suma. Dzięki temu koszt wdrożenia wynosi już nie 416.000 PLN, ale 349.000 PLN. Oszczędności te uzyskaliśmy dzięki zastosowaniu większej liczby gotowych rozwiązań, które spełniły zakres funkcjonalny i sprawiły, że serwis działa.
Niestety, z powodu dużej liczby zewnętrznych modułów, przy każdym podniesieniu Magento, próbie modyfikacji któregoś modułu, lub dodaniu nowej funkcjonalności do Magento, pojawiają się konflikty w tych modułach. To zmusza nas do ciągłego eliminowania błędów.
W pierwszym roku nie wydajemy już 20 godzin na utrzymanie i 60 na rozwój, ale 40 godzin na utrzymanie i 40 na rozwój. Wraz z rozwojem projektu, z uwagi na dług technologiczny, wydajemy coraz więcej na utrzymanie i naprawianie błędów.
W piątym roku poświęcamy już 70 godzin na utrzymanie i rozwiązywanie błędów, a jedynie 10 godzin miesięcznie na rozwijanie serwisu. Pozostałe zmienne, takie jak stawka godzinowa wynosząca 250 PLN i średnioroczna inflacja na poziomie 6%, pozostają niezmienione.
Gdy podsumujemy koszty utrzymania i rozwiązania problemów, okaże się, że przez 5 lat wyniosą one 911.100 PLN. To o 394.100 PLN więcej niż w poprzednim przypadku.
Co zatem zrobiliśmy? W skrócie, zaoszczędziliśmy 67.000 PLN na wdrożeniu. Ale rzeczywistość jest taka, że nie zaoszczędziliśmy tych pieniędzy per se. Zaciągnęliśmy raczej dług technologiczny, czyli zobowiązanie, które będziemy musieli spłacić i płacąc odsetki od tego zobowiązania. Wzięliśmy więc „kredyt” na 67.000 PLN i będziemy spłacać kapitał z odsetkami w wysokości 394.100 PLN przez kolejne 5 lat.
W rezultacie, przez ten okres wydamy 327.100 PLN więcej, mimo że etap wdrożenia kosztował nas mniej o 67.000 PLN.
To jest bardzo realistyczny przykład sytuacji, gdy za dużo oszczędzamy na kosztach wdrożeniowych. Oczywiście pod warunkiem, że te koszty nie wynikają z niższej stawki godzinowej.
Oszczędzamy, stosując więcej gotowych modułów Magento i próbując je połączyć, tak aby nasz serwis działał. Przygotowałem oddzielny wpis na temat gotowych modułów Magento, który możesz przeczytać, aby dowiedzieć się, dlaczego zazwyczaj odradzamy korzystanie z dużej liczby modułów firm trzecich.
Jeśli zarządzasz firmą, która posiada sklep na Magento, może to być pierwszy raz, kiedy widzisz te koszty. Być może wcześniej nikt z IT nie dostarczył Ci tych danych. Jeśli decydujemy się na takie oszczędności, jesteśmy świadomi ryzyka i jest to decyzja przemyślana – nie mamy teraz funduszy, ale w przyszłości je zdobędziemy i spłacimy dług – to jest to akceptowalne.
Jednak jeśli decydujesz się na obniżanie kosztów wdrożenia, nie wiedząc, jakie będą finansowe konsekwencje w przyszłości, to jest to niekorzystne. Dzięki temu przykładowi wiesz już, jak to wpłynie na Twój biznes.
Co wynika z przykładu obrazującego dług technologiczny?
Przejdźmy teraz do wniosków z tego prostego przykładu.
Dług technologiczny pojawi się zawsze
Pierwszy wniosek jest taki, że dług technologiczny zawsze wystąpi. Wynika to z faktu, że projekt zawsze będzie się rozwijał, zawsze będziemy dodawali dodatkowe funkcjonalności, dodatkowe integracje. Sposób ich dodawania i sposób kodowania wpływa na poziom tego długu technologicznego. Może on być znośny i ważyć względnie niedużo, lub może być bardzo wysoki.
Dług technologiczny jest kosztowny
Drugi wniosek dotyczy kosztów długu technologicznego, które są niesamowicie wysokie. Wydaje mi się, że to jest jedna z najczęściej pomijanych informacji finansowych, kiedy biznes decyduje się na wdrożenie określonego rozwiązania IT.
Istnieją serwisy, które miesięcznie wykorzystują od 480 do nawet 1000 godzin. Jeśli na początku projektu generowany jest znaczny dług technologiczny, duża część z tych 1000 godzin przeznaczana jest na utrzymanie i naprawę błędów. To stanowi problem.
Źródła długu technologicznego
Trzecia konkluzja dotyczy rodzajów źródeł długu technologicznego.
Pierwsze to te naturalne, które wynikają z rozwoju projektu. W miarę dodawania kolejnych funkcji, które są niezbędne dla konkurencyjności w ecommerce, dług technologiczny rośnie.
Jednakże istnieje również nienaturalne źródło długu technologicznego. Wynika ono z nadmiernego stosowania dużej liczby słabych, gotowych modułów firm trzecich, które są niesprawdzone, niekompatybilne między sobą i zbyt skomplikowane.
Nienaturalny dług technologiczny generowany jest również wtedy, gdy w projekcie Magento nie mamy architekta, który odpowiednio zaprojektowałby całą architekturę systemu oraz kontrolował proces ingerowania w niego.
Architektura systemu jest jak projekt podczas budowy domu. Jeśli na samym początku, podobnie jak w projekcie budowlanym, coś zostało źle zaprojektowane, później trudno jest zbudować dobry budynek. Będziemy ciągle łatać i naprawiać błędy, co stanowi duży i kosztowny problem.
Jeżeli decydujesz się na Magento i wybierasz software house, upewnij się, że w zespole jest certyfikowany architekt (w przypadku Magento jest to Adobe Commerce Architect Master).
Kolejnym aspektem, który generuje nienaturalny dług technologiczny, jest kodowanie niezgodne ze standardami lub stosowanie nietypowych metod przez programistów. Najczęściej wynika to z braku kontroli w zespole projektowym lub zbyt małego doświadczenia osób pracujących przy projekcie.
Software house, który bierze pod uwagę dług technologiczny
Czwarty wniosek dotyczy pytania, jak porównać oferty różnych agencji ecommerce i software house’ów, aby wybrać taką, która koduje w sposób niegenerujący dużego długu technologicznego.
To nie jest łatwe zadanie i nie jest możliwe, aby omówić to w tym artykule. Jednak obiecuję, że w jednym z kolejnych wpisów przedstawię ten temat i opiszę dokładnie, jak wybrać agencję ecommerce, która nie będzie generowała zbędnego i dużego długu technologicznego.
Natomiast dobrym wnioskiem jest na pewno to, że jednym z kryteriów wyboru agencji ecommerce powinno być to czy ma ona wypracowane procesy zapewniające utrzymanie długu technologicznego na niskim poziomie.
Podsumowanie
W tym artykule opisałem, czym jest dług technologiczny. W dużym uproszczeniu, jest to zjawisko, które polega na tym, że wraz z rozwojem danego projektu IT, koszty dodania identycznej funkcjonalności są wyższe.
Jednym z kluczowych wniosków dotyczących długu technologicznego jest to, że może on osiągnąć wysokie wartości. Oszczędności na wczesnych etapach projektu ostatecznie prowadzą do konieczności spłaty długu technologicznego w przyszłości. Dług technologiczny ma dwa rodzaje źródeł: naturalne i te nienaturalne, które powinny być eliminowane.
W mojej ocenie jednym z najbardziej niezrozumiałych przez biznes konceptów jest właśnie dług technologiczny. Mam nadzieję, że chociaż odrobinę pomogłem w porozumieniu pomiędzy biznesem a IT.
A jeśli chcesz chcesz dowiedzieć się więcej na tematy, które w naszej ocenie są źródłem wielu nieporozumień między działami IT i biznesem, koniecznie przeczytaj co to jest Total Cost of Ownership (TCO)?
