Poruszone tematy:
Kiedy warto rozpocząć wychodzenie z długu technologicznego w projekcie, jakie są jego konsekwencje i jak właściwie nim zarządzać? O tym, w drugiej części naszego podcastu o długu technologicznym, rozmawiali: Paweł Kaźmierczak - Project Manager, Damian Maślanka - CTO oraz Szymon Kania - CEO.
Paweł: Witam Was bardzo serdecznie w naszej drugiej części podcastu na temat długu technologicznego. Ja jestem Paweł Kaźmierczak, ze mną są Szymon Kania i Damian Maślanka. W pierwszej części naszego podcastu dywagowaliśmy nad tym, czym w ogóle jest ten dług technologiczny, jakie są przyczyny powstawania tego długu technologicznego. Jak sobie z nim radzić, jak on też wpływa na projekty długofalowe, jak wpływa na rozwój produktu. Oczywiście zachęcam do zapoznania się z pierwszą częścią naszego podcastu.
Przejdźmy sobie panowie do tych kwestii takich bardziej może biznesowych o długu, bo ostatnio skończyliśmy właśnie dywagować na takich technicznych tematach, bardziej jak zarządzać projektem, jak technicznie się do tego przygotować, ale jak uważacie, jakie mogą być biznesowe konsekwencje takiego długu technologicznego dla danej firmy, dla potencjalnego klienta w branży IT? Jak to wpływa przede wszystkim na koszty operacyjne firmy?
Szymon: Dwa takie aspekty, które na pewno bym wymienił, to są przede wszystkim wyższe koszty danej firmy, a także uderzenie często w jakiś wizerunek i zaufanie. Jeśli chodzi właśnie o te koszty, to utrzymanie długu technologicznego powoduje szereg różnych koniecznych dodatkowych działań. Często w związku z długiem technologicznym pojawiają się różne problemy, które musi obsługa klienta obsłużyć, podejmować zgłoszenia od klientów, szukać jakichś rozwiązań, czasami szukać jakichś rozwiązań naokoło, jak pomóc tym klientom? No bo system kuleje w jakimś zakresie z uwagi narośnięty dług technologiczny, na przestarzałe rozwiązania. To oczywiście generuje koszty, bo zespół zamiast skupić się na rozwoju firmy, na rozwoju produktu, walczy z narastającymi problemami. To jeden oczywiście z przykładów. Też można rozpatrywać to w kontekście kosztów, nawet utraconych korzyści.
Jeżeli rozwiązanie będzie tracić swoją renomę, ludzie stracą zaufanie do danego rozwiązania, bo będzie bardzo dużo problemów związanych z długiem technologicznym, no to możemy mieć mniej klientów, klienci mogą odchodzić od nas, przestać korzystać z naszego produktu. Właśnie z uwagi na zaniedbany dług technologiczny, który został zaciągnięty, nie został spłacony i wpadliśmy w spirale długów.
Damian: Tak, ja bym tutaj jeszcze dodał, że tak naprawdę to, co Szymon powiedział, można podsumować jako poniekąd taka hybryda bezpieczeństwa, wydajności i dalszego dewelopmentu. Bezpieczeństwo, no bo bez wątpienia dług technologiczny wpływa na to, że są luki w systemie, które mogą zostać wykorzystywane przez hakerów, czy po prostu jakieś boty, cokolwiek, jakieś znalezienie podatności. Wydajność, no bo dług technologiczny ma to do siebie, że ciężko tam zaimplementować jakieś nowsze technologie, które są bardziej wydajniejsze, szybsze. A co za tym idzie, wrażenia użytkownika końcowego, który korzysta z danego systemu, nie są takie, jak być powinny w aktualnych czasach. Nie wiem, strony się mogą dłużej ładować, brakuje jakichś takich dynamicznych elementów przykładowo. Więc to też ma bezpośredni taki, można powiedzieć, wydźwięk. No i trzeci aspekt to jest dalszy development.
O tym rozmawialiśmy już w pierwszej części, że tak naprawdę zlecanie kolejnych modułów, czy cokolwiek, dopracowywanie, to są po prostu większe koszty, aniżeli mielibyśmy ten base code na takim wyższym poziomie zrefaktoryzowany i bez tego długu technologicznego.
Paweł: Ok, czyli reasumując mamy tu kilka ważnych aspektów w takim biznesie, na które warto tutaj spojrzeć, czyli rosnące koszty, bo nieustanny development, wtedy jak kręcimy się w kółko i fiksujemy nieustające problemy i tak naprawdę brak nam czasu i zasobów do tego, żeby rozwinąć funkcjonalnie nasz produkt. Druga rzecz to to, co powiedziałeś, bezpieczeństwo i wydajność. Przez to możemy być narażeni, czy nasz projekt na jakieś ataki z zewnątrz i też utrata zaufania dotychczasowych klientów, bo mogą odchodzić i to też może odbić się w ostateczności na finansach firmy, ale też to, co Szymon wspomniał, myślę, że warto to też zaliczyć do tej naszej listy. Ta utrata potencjalnych korzyści, czyli potencjalnych może nowych klientów, których moglibyśmy mieć, jeśli nasz produkt dalej by się rozwijał w takim samym tempie, zanim doszło do długu.
Jeszcze tak z perspektywy właśnie takiego biznesu i kosztów chciałem, żebyśmy się zastanowili, jakie ryzyko niesie taki niekontrolowany dług technologiczny w biznesie.
Szymon: Raz, że te koszty mogą też w sposób coraz bardziej niekontrolowany rosnąć, bo nawet właśnie ta operacyjna obsługa problemów związanych z długiem technologicznym, kiedy tych zgłoszeń się będzie pojawiało coraz więcej. Jeżeli załóżmy, że skalujemy biznes, że mimo wszystko rośnie nam ilość klientów, użytkowników, to musimy cały czas dokładać osoby, które będą tak naprawdę skupione na obsługiwaniu istniejących problemów.
Damian: Ja bym tutaj jeszcze dodał, że może przyjść dzień, w którym tak naprawdę napotkamy ścianę, że chcemy zrobić aktualizację naszego systemu. W ramach tam oczywiście tych wszystkich przestarzałych paczek. A okazuje się, że któraś paczka właśnie zniknęła z internetu i zaczynają się pierwsze schody, które trzeba jakoś obejść i nigdy nie jesteśmy pewni, czy taki dzień po prostu nie nastąpi. Druga kwestia, też nigdy nie jesteśmy pewni czy nie nastąpi taki dzień, że nagle serwery powiedzą dość, bo aplikacje się na tyle poodkładały, jakieś takie niewłaściwe dane, niekompatybilna baza danych, coś tego typu. I nagle jest taki moment, że chcemy skorzystać z aplikacji, a tutaj się okazuje, że po prostu wszystko się bardzo długo ładuje. Po prostu przekroczyliśmy pewną barierę, a że był ten dług, nikt o to nie dbał, to po prostu nie mogliśmy przewidzieć, że takie coś może wystąpić.
Paweł: Ja też ze swojej strony dodam, bo to różnie bywa. Jak się zapędzimy z takim niekontrolowanym długiem i powiedzmy obudzimy się za późno po czasie, to miałem takie sytuacje, że dany biznes nawet się zamknął po prostu. Jakby szacując jakieś takie potencjalne koszty wyprowadzenia tego długu technologicznego, no i już to jakby nie spinało się z korzyściami, jakie dany biznes mógłby uzyskać, sprzedając kolejne po prostu abonamenty. Więc myślę, że też tu taki czarny scenariusz należy brać pod uwagę i ja te ryzyko bym też zgodnie tutaj ocenił jako bardzo wysokie dla takiego biznesu. Ok, ale pójdźmy dalej. Tak bardziej pozytywnie, może tak proaktywnie zastanówmy się, kiedy i jak najlepiej podjąć decyzję, jeśli chodzi o spłatę takiego długu technologicznego. Czyli już musimy mieć gdzieś z tyłu głowy, że chcemy przepisać cały projekt na nowe technologie na przykład.
Szymon: Najlepiej jest ograniczyć to zaciąganie długu technologicznego, robić to w kontrolowany sposób, tak jak rozmawialiśmy podczas ostatniego podcastu. Mieć nad tym kontrolę i zrobić to w świadomy sposób. Ale kiedy jest najlepszy moment na spłatę długu technologicznego? Na pewno nie w momencie takiego gwałtownego wzrostu, gwałtownego rozwoju projektu. Lepiej jest poczekać na taki moment, gdzie mamy etap, na którym możemy sobie pozwolić na trochę spokojniejszy development, kiedy dowieźliśmy najbardziej istotne funkcjonalności i teraz na przykład chcemy dopiero zaczynać kolejny etap projektu, możemy sobie pozwolić, że ten etap projektu chwilę poczeka, spłacimy dług technologiczny zaciągnięty w pierwszym etapie realizacji.
Paweł: Ok, czyli masz na myśli, że projekt już działa stabilnie, nie ma jakichś tam dużych powiedzmy bug fixów, ale jest moment na robienie jakichś takich usprawnień deweloperskich, jakaś refaktoryzacja.
Szymon: Dokładnie, też nie moment, kiedy wdrażamy duże funkcjonalności, kiedy jest całkowity focus na ich realizację, spięcie z systemem, bo to też jest zazwyczaj gorący okres w trakcie realizacji projektu.
Damian: Ja bym to też uzależnił od tego, że tak naprawdę jeżeli mamy wizję, że nasza firma, nasz produkt będzie się teraz dynamicznie rozwijała przez najbliższe lata, to tym bardziej właśnie powinniśmy wtedy podjąć ten krok o wyeliminowaniu tego długu, aniżeli go dalej zaciągać, bo to jest taki najbardziej komfortowy moment. Po prostu wiemy, że mamy to wszystko pod kontrolą, będzie się to stabilnie rozwiało, więc zainwestujmy część środków, żeby właśnie było to na wysokim poziomie.
Szymon: Im szybciej zaczniemy spłacać dług, tym lepiej. Trochę jak znowu, trzeba to porównać do tego długu finansowego. Kiedy zbyt długo go będziemy zaciągać i wpadniemy w spirale odsetek, to dużo ciężej jest spłacić ten dług niż spłacając bardziej na bieżąco, regularnie, w jakiś zaplanowany, kontrolowany sposób.
Paweł: Ok, a jeszcze pod takim kątem może bardziej technicznym, jakbyśmy się zastanowili, w jakim momencie takiego cyklu życia produktu jest najlepszy czas na jakieś optymalizacje, refaktoryzacje kodu, tego typu rzeczy, takie usprawnienia, które spowodują, że nie zaciągniemy tego długu na przyszłość.
Damian: Przede wszystkim jak pracujemy nad jakimiś nowymi modułami, bo to jest taki dobry moment, żeby zastanowić się jak podejść do architektury tego nowego modułu i jednocześnie jaki wpływ będzie to miało na całość aplikacji. Wtedy dobrze tak naprawdę prześledzić, czy to co aktualnie mamy sprosta wymaganiem tego nowego modułu, bo to zawsze się wiąże z jakimś tam dodatkowym wykorzystywaniem zasobów i tak dalej, więc ja bym to zazwyczaj zostawiał właśnie na takich można powiedzieć tworzenie kolejnych modułów komplementarnych do całego systemu lub gdy tak naprawdę mało się też dzieje w tym projekcie, a widzimy, że on mimo wszystko stabilnie się rozwija, bo nie wymaga jakiegoś takiego szybkiego developmentu, to po prostu robić sobie takie testy wydajnościowe, sprawdzać, czy za miesiąc, pół roku, czy rok czasu, jeżeli utrzymamy te tempo, ten projekt będzie dalej dobrze funkcjonował i tutaj rozplanować sobie całą ścieżkę, jak można to usprawnić, co można zrefaktoryzować, żeby po prostu lepiej działało. Przewidywać po prostu przed, a nie po fakcie, gdy okazuje się, tak jak wspominałem wcześniej, nadchodzi ten dzień, gdzie dostałem mnóstwo maili, telefonu, że po prostu aplikacja zaczęła bardzo słabo działać.
Paweł: Okej, czyli z tego co powiedziałeś to tutaj ponownie tak jak w pierwszej części to wybrzmiało bardzo ważne jest planowanie i całości projektu i poszczególnych funkcjonalności czy modułów danego projektu. Okej, to teraz chciałbym was zapytać jakie moglibyśmy określić najlepsze praktyki zarządzania takim długiem technologicznym? Czy znacie może jakieś narzędzia i procesy, które można by wdrożyć, żeby właśnie skutecznie monitorować w ogóle dług i nim zarządzać w takim projekcie?
Damian: Od strony technicznej to dobrze sobie zaimplementować wszelakie narzędzia, które sprawdzają składnie kodu, mniej więcej konwencje, czy ogólnie takie zmatchowanie z base codem. Jest szereg tego typu narzędzi, można to sobie zintegrować bezpośrednio np. z GitLabem i każdy programista, który puszcza tego commita, to już tutaj na tym etapie ma od razu zwrotkę, czy jakość tego kodu została zachowana, czy nie, a w dalszej takiej części, to tutaj zawsze te wzajemne sobie sprawdzanie tych wszystkich komitów, czy nawet wydzielenie odpowiedniej osoby technicznej, tak zwanego lead developera, który czuwa nad tym i dba o to, żeby wszystkie te MR-ki, te wszystkie commity, jakiekolwiek zmiany w kodzie, były raz, że spójne z całym projektem, a dwa, no też trzymały tutaj wysoki standard jakościowy.
Paweł: Czyli mamy narzędzie typu GitLab, jakieś robienie code review, czasem na krzyż, czasem tak powiem oddelegowanie tego tech leadowi albo lead developerowi w projekcie.
Damian: Z takich jeszcze miękkich umiejętności to warto też ogólnie dbać o sam zespół, dać im też przestrzeń, żeby na przykład mogli się raz w tygodniu spotkać o takim weekly, gdzie mogą porozmawiać o jakichś wytycznych nowych technologiach, zainspirować się nawzajem, zarzucić jakimiś tematami. To jest taka, można powiedzieć, zbiorowa wtedy nauka, takie zdobywanie doświadczenia, no i też utrzymywanie takiego odpowiedniego mindsetu, że dbamy o tą jakość, że nie odpoczywamy, nie idziemy na łatwiznę, tylko po prostu chcemy, żeby tutaj zawsze ten projekt jakościowo był wysoko.
Paweł: Czyli korzystanie z tych takich metodologii zwinnych, czyli taki właśnie to, co powiedziałeś, stały focus na projekcie, taka konsekwencja. Tutaj bym miał analogię do sportu, że najlepsze drużyny, które zwyciężają, muszą być konsekwentne. Ja bym jeszcze dodał, że można by się posłużyć właśnie narzędziami do prowadzenia backlogu, zadań developerskich i w ogóle takie, powiedzmy, procesy wytwarzania oprogramowania są ważne pod takim kątem. Trzymanie się jakości, potem jakieś testy, mogą być testy automatyczne, manualne.
Przeprowadź z nami testy swojego rozwiązania.
Damian: Tutaj też warto, tak naprawdę o tym się często nie mówi, nie myśli, ale nawet takie odkładanie się jakichś warningów z projektu. Nie mówię tutaj o jakichś exceptionach, jakichś criticalach, takich poważnych błędach, bo to oczywiste, że to się zawsze jak najszybciej poprawia, ale takie warningi, takie jakieś mało znaczące informacje, gdzieś tam odkładające się na serwerze w logach, to też jest taka bogata kopalnia wiedzy o naszym projekcie, bo to są takie rzeczy, na które na co dzień nie zwracamy uwagi, to się gdzieś tam odkłada, ale to już jest jakiś sygnał, że np. ta linia kodu jest trochę przestarzała i np. w kolejnej wersji PHPa przykładowo już będzie nie wspierana, a po prostu się to pomija.
Paweł: O, to też bardzo ważna rzecz, dbanie o aktualizację frameworków w projekcie, bo to często są wypuszczane jakieś nowe wersje i często jak zaniedbamy to, to później podniesienie np. o powiedzmy 4 pełne wersje, to już jest sporo roboty dev.
Damian: No to tutaj też jest istotne, żeby w miarę na bieżąco to aktualizować, a nie czekać aż skończy się wsparcie do tej danego framework'a, bo to też wiadomo z doświadczenia, że czasem takie rzeczy się odkłada, no bo jeszcze mamy czas, bo jeszcze ta wersja jest tam wspierana przez najbliższy rok czasu, no a czas ma to do siebie, że szybko przemija i nagle się budzimy i trzeba po prostu już robić to gwałtownie.
Paweł:Okej, a jak zespoły deweloperskie i nie tylko mogą planować taką spłatę długu technologicznego, taki plan jakbyśmy sobie mieli zrobić na przyszłość, aby właśnie zminimalizować ten jego i negatywny wpływ, jeśli obecnie występuje, ale w ogóle występowanie takiego długu?
Damian: Generalnie dobrą taktyką jest odrzucenie takiego mindsetu do zespołu, że na zasadzie robisz jakąś funkcjonalność i widzisz, że gdzieś tam jest jakaś linia kodu, która mogłaby zostać zrefaktoryzowana, to po prostu zrób to. Nie na zasadzie, a bo ktoś ją tam źle kiedyś napisał, przeszło to jakoś code review, zostało pominięte. Po prostu dbaj o ten porządek. To tak może trochę analogię do ulicy: że idziemy po parku, widzimy, że gdzieś tam leży jakiś śmieć, to po prostu można go podnieść i wrzucić do kosza, a można też pominąć i tak naprawdę się zasypać tymi śmieciami po jakimś czasie, więc podobnie podchodzimy do kodu, że jeżeli widzimy, że ktoś tam zostawił coś, to czasem warto to po prostu poprawić i dbać nawzajem o ten kod, traktować to jako taka jedna wspólna rzecz.
Paweł: Ok, to jest dobry pomysł, czyli tak jak harcerze, że jak coś napotkamy i można to zrobić np. lepiej, coś poprawić, to zróbmy od razu, czyli pozostawić to miejsce jeszcze lepszym niż zastaliśmy.
Damian: Dokładnie, po prostu patrzeć bardziej szeroko, a nie tylko wąsko na to, co wykonujemy. Projekt powinniśmy traktować po prostu jako taką wspólną część, którą wszyscy realizujemy, a nie tylko gdzieś tam w wyznaczonych swoich, można powiedzieć, obszarach.
Paweł: Ok, a znacie jeszcze jakieś praktyki, które mogłyby pomóc w uniknięciu takiego przyszłego długu technologicznego? Nie wiem, to może być powiedzmy coś, co weszło nam już w nawyk i nawet nie wiemy co to jest. Nie badamy tego na przykład w procesie, bo już to robimy na przykład.
Damian: Dług czasem też powstaje z tego, że ktoś nie rozumie kodu. Coś musi zrealizować, widzi tam jakiś taki fragment kodu, który wydaje się mu skomplikowany i zamiast tak naprawdę zastanowić się na tym, no to stara się to jakoś tam obejść, dopasować do tego. No i tutaj dobrą praktyką jest tak naprawdę komentowanie też tego kodu, bo to pozwoli szybciej wejść w logikę rozumowania. Też nawet dla osoby, która realizowała dany fragment systemu, po jakimś czasie też dla niej to się już wydaje dużo trudniejsze, nie takie zrozumiałe jak wtedy, gdy to pisała. Więc takie komentarze czy dokumentacje to mocno usprawnia takie zarządzanie tym kodem i sprawia, że dużo łatwiej nam podejść do tak jakby obudowania go w optymalny sposób, aniżeli gdzieś tam próbować obejść to, bo próg wejścia zrozumienia tego jest wysoki.
Paweł Czyli generalnie warto spisywać sobie wiedzę i informacje o danym projekcie, żeby ta wiedza nam w przyszłości gdzieś tam powiedzmy nie zwiała?
Damian Tak, to jest podstawa. Tak naprawdę, gdy projekt nie jest dobrze opisany, to dochodzimy do takiego momentu, że każdy zaczyna to robić po swojemu, zamiast dopasować się robi tak jakby równoległe rozwiązanie i w tym momencie już jest bardzo cienka linia do tego, żeby przekroczyć ten próg tworzenia długu technicznego.
Paweł To jeszcze tak na koniec, jakbyśmy mieli sytuację, że powiedzmy mamy projekt działający produkcyjnie, bardzo szybko się rozwija, powiedzmy, że co tydzień jest coś robione i powiedzmy co tydzień jakieś deploye są robione w tym projekcie. Jak przy takim projekcie możemy zarządzać takim długiem technologicznym?
Damian Przede wszystkim automatyzację, jeżeli mamy dużo testów w projekcie, mamy też automatyczny deploy, jeżeli to wszystko sobie zepniemy, żeby się automatycznie wykonywało i od razu sprawdzało, czy gdzieś nie popełniliśmy błędu, to jest jedno. Tak jak wcześniej mówiłem, że wszelkie takie fixery, które sprawdzają, czy składnia kodu, czy jakość, czy to wszystko jest na takim poziomie jak powinno być w projekcie. Im więcej takich automatyzacji mamy, to od razu dostajemy też taki feedback, czy to co napisaliśmy jest właściwe, prawidłowe. W momencie gdy tego nie ma, to może dojść do takiej patologii, że robimy szybko, gdzieś tam komuś coś się przeoczy, bo wiadomo jak jest szybko to czasem się może zdarzyć, że ktoś nie zauważy, że gdzieś tam jedna linia kodu jest napisana w niewłaściwy sposób, czy źle podeszliśmy do jakiegoś tematu.
No i tutaj brak takiej automatyzacji może spowodować, że po prostu wejdzie do tego codebase'a i będzie po prostu produkcyjnie gdzieś tam działało, a jednocześnie będzie już tworzyło ten dług technologiczny.
Szymon No i sam mindset zespołu, tak jak Demian powiedział. Jeżeli jest mindset, żeby nie zaciągać nadmiernie tego długu technologicznego, to też będzie się inaczej pracowało. I tak samo kwestia zaplanowania tego developmentu, bo nawet jeżeli robimy projekt, który intensywnie jest rozwijany, jest uruchomiony produkcyjnie, to też można to robić tak, że będzie za mało czasu nawet na ten bazowy development, co sprzyja zaciąganiu długu technologicznego lub cały projekt jest tak zaplanowany, że jest miejsce na powiedzmy umiarkowany development, który będzie bardziej ograniczał to powstawanie długu technologicznego, czy dawał nawet niewielką przestrzeń na takie działania, zwłaszcza z wykorzystaniem różnych automatyzacji, tak jak Damian powiedział, które ograniczą powstawanie długu technologicznego.
Damian Ja bym tutaj jeszcze dodał, że te wszystkie automatyzacje sprawiają, że jesteśmy w stanie szybciej to robić. A co za tym idzie, robiąc to szybko mamy więcej zasobów na to, żeby też zadbać o to, żeby trzymać tutaj mocną jakość, aniżeli próbować coś zrobić gorzej kosztem tego, żeby np. dotrzymać deadline, czy utrzymać tempo tworzenia oprogramowania.
Paweł Ok, to naprawdę dużo, dużo wskazówek tutaj wymieniliśmy, jak można zapobiegać, a wiadomo, że zapobieganie jest lepsze niż potem po fakcie reagowanie, bo też właśnie wychodzenie już z takiego zaciągniętego długu technologicznego to jest taka też ciężka i żmudna praca. Myślę, że tutaj bardzo dużo informacji sobie omówiliśmy w tym podcaście. Ja ze swojej strony mam tyle, także dziękuję wam za wzięcie udziału panowie. Myślę, że sporo ważnej i pożytecznej wiedzy dla wszystkich, którzy chcieliby robić jakieś projekty w IT. Ta kwestia długu, żeby wiedzieć co to w ogóle jest i jak sobie zaplanować. Jakieś takie wyjście ze swoim produktem, żeby tego uniknąć w przyszłości. Także myślę, że nasi słuchacze mogą wyciągnąć cenne lekcje. Także ja wam oczywiście serdecznie dziękuję za uwagę. Z nami był Szymon Kania i Damian Maślanka i Paweł Kaźmierczak.
Damian Ja tutaj jeszcze na sam koniec mogę dodać, że dług technologiczny można podsumować, że lepiej bawić się w profilaktykę niż leczyć.
Więc tym akcentem możemy zakończyć. Dzięki wszystkim.
Szymon Dzięki.
Paweł Dzięki.
