Dług technologiczny – spojrzenie praktyczne

29 września, 2020

Dług technologiczny – spojrzenie praktyczne

Nie chcę odpowiadać na pytanie czym jest dług technologiczny, ani wdawać się w  teoretyczne rozważania na ten temat. Łatwo można je znaleźć na wikipedii i w wielu innych źródłach. Chciałbym odpowiedzieć na pytanie: czym jest dług technologiczny w praktyce?

Dług technologiczny pojawia się w dwóch momentach projektu. Na początku, przy wycenie i negocjacjach oraz po produkcyjnym uruchomieniu oprogramowania.

Negocjacje – konkurs taniości

W trakcie negocjacji klient, nawet jeśli nie szuka najtańszego wykonawcy (zakładam scenariusz optymistyczny), to zwyczajnie nie chce przepłacać ponad stawki rynkowe – więc nie wybiera ani najtańszej oferty, ani najdroższej. Wybiera coś pośrodku. Jest to moment w którym różni wykonawcy próbują przekonać klienta do swoich usług. Prezentując pełen wachlarz swoich możliwości, doświadczenia i tego jak przełożą jego budżet na korzyści projektowe.

W tym momencie – zakładam że bez złej woli – po prostu można nie wspomnieć o tym, że oferuje się wykonanie systemu w sposób, który dzisiaj jest łatwiejszy i tańszy, ale w przyszłości zablokuje niektóre możliwości rozwoju. Przygotowując plan na wdrożenie systemu jest mnóstwo elementów, z których można zrezygnować (a których klient nie wymaga). Można np. nie pisać dokumentacji, można nie pisać testów, można zatrudnić do pracy przy projekcie niedoświadczone osoby, które będą się uczyły w locie. 

To wszystko są kwestie, które w długim terminie muszą zostać uzupełnione. Co gorsza, szkody wyrządzone przez juniora mogą być nieodwracalne – system będzie działał, ale kod przygotowany niezgodnie ze standardami sprawi, że nikt nie będzie w stanie go naprawiać, nie mówiąc już o rozwijaniu. W niedługim terminie staniemy przed dylematem, czy stworzyć nowy system, czy nadal “pudrować trupa”.

W chwili negocjacji zazwyczaj mało który sprzedawca odważa się wspominać klientowi, że raz stworzone oprogramowanie wymaga inwestycji w utrzymanie systemu. Pracę efektów której nie widać bezpośrednio. Koszt, który wzięty pod uwagę drastycznie podnosi cenę i obniża konkurencyjność. W końcu oferty porównują zazwyczaj osoby bez wiedzy technologicznej (np. działy zakupów, marketingu, rozwoju, innowacji, itd). 

Spojrzenie w przyszłość

Stworzony system informatyczny – np. strona internetowa (np. WordPress), aplikacja webowa (np. React, Symfony), sklep (np. Magento) – wymaga do swojego ciągłego działania m.in. serwera, domeny, backupów. Koszt tych elementów jest zazwyczaj dobrze rozumiany i przyjmowany bez mrugnięcia okiem. To jednak nie jest cała historia – coś nam często umyka.

Na wstępnych etapach, przy planowaniu, tworzeniu produktu, łatwo zapominamy o tym, że po uruchomieniu serwisu niezbędna będzie ciągła praca związana z utrzymaniem kodu oraz środowiska. Jeżeli klient nie zostanie wcześniej o tym poinformowany, to w przyszłości może go zaskoczyć dodatkowy koszt. Nic dziwnego, że wtedy nie zdecyduje się go podjąć, przecież nie jest to zaplanowane w budżecie. 

Bardzo trudno jest wydać pieniądze na zmianę czegoś, co przecież i tak działa. Wszystko działa przecież całkiem dobrze, od lat spełnia swoją rolę – po co więc robić jakieś remonty, aktualizacje, refaktoringi?

To dotyczy w takim samym stopniu również małych stron. Przykładowo strony wykonane w oparciu o WordPress, do pewnego stopnia można skonfigurować tak, aby aktualizacje wykonywały się same. Nie zmienia to jednak faktu, że co jakiś czas trzeba sprawdzić, czy nadal wszystkie wtyczki działają, czy szablon się aktualizuje, przeprowadzić większe aktualizacje, sprawdzić działanie backupów. To są działania, które trzeba wykonywać cyklicznie niezależnie od poziomu skomplikowania systemu. Dla mniejszych stron jest to po prostu bardziej odczuwalne – kwota utrzymania stanowi procentowo większy udział w koszcie wykonania całej strony.

Jak można ten impas rozwiązać?

Podejdź do tworzenia oprogramowania tak, jak do budowania relacji. Dla twórców software oznacza to: nie zabijaj klienta wyceną stworzenia, nie buduj zapory budżetowej, zaproponuj podejście zwinne (agile), przyrostowe budowanie produktu. Na początku warto również wykonać etap analityczny, koniecznie we współpracy z klientem – partnersko. 

Dla klienta oznacza to włączenie w proces, większą kontrolę nad powstającym produktem, rozłożenie płatności w czasie oraz możliwość dokładniejszego planowania budżetu na kolejne lata. Z każdym kolejnym miesiącem współpracy lepiej poznajemy swoje potrzeby i możliwości – z tego wprost wynika ilość poświęcanego czasu oraz tempo rozwoju.

Podsumowując. 

Dług technologiczny jest, był i będzie – nie ma w tym niczego złego. To, czego brakuje, to otwarta komunikacja z klientem. Software house powinien występować w roli partnera technologicznego dla klienta i negocjując pierwszy kontrakt rozmawiać i planować współpracę na długi termin, na lata.

Dlaczego warto inwestować w relacje z software house?

Dlatego właśnie tak ważne jest wybranie do współpracy takiego wykonawcy, z którym będziemy w stanie złapać “chemię”. Musimy się dobrze rozumieć i umieć przekazać sobie również trudne informacje. 

Jak jednak wybrać takiego partnera? Łatwo można wystawić dobrego sprzedawcę, który świetnie się sprzeda, a później w praktyce realizować projekt będą osoby z którymi już nie będzie się tak łatwo dogadać. W odpowiedzi przychodzą ludzie oraz wartości organizacji. Może to zabrzmieć jak truizm, jeśli jednak organizacja nie ma określonych wartości, to nie ma też szans, że stosuje je w praktyce.

Najlepiej to sprawdzić w rozmowie. Na etapie wybierania oferty postaraj się porozmawiać z możliwie wieloma osobami z zespołu. To nie znaczy, że na tym etapie będziesz w stanie poznać dokładnie osoby, które będą pracowały przy Twoim projekcie – na dobrych specjalistów się czeka – ale pozwoli Ci to poznać nastrój w organizacji. Sprawdź, czy wszyscy mówią mniej więcej w podobnych nastrojach. Zapytaj o wartości.

To jest powód dla którego warto porównując oferty różnych wykonawców, poza ceną sprawdzić również jakie będą mieli podejście do współpracy. Pamiętaj – wybierasz partnera na lata współpracy. W tym czasie może się zmienić osoba prowadząca Twój projekt, czy programiści, ale jeśli w organizacji jest zdrowa kultura – każda następna osoba będzie przynajmniej tak samo dobra.

Kultura organizacji ma też jeszcze jeden bardzo pozytywny skutek. Programiści nie są tam traktowani jako operatorzy klawiatury, tylko raczej jako samodzielne, twórcze jednostki. Tylko takie spojrzenie pozwala kreatywnym osobom wprowadzać ciekawe nowości, wychodzić poza schemat. To sprawi, że Twój produkt będzie lepiej zadbany “pod maską” i nie zostaniesz z tyłu. Pomysły na zmiany które będziesz miał, nie będą problemem (bo “kod jest stary i nikt go nie chce dotykać”), tylko nowym ciekawym wyzwaniem. 

Zaangażowany zespół będzie pracował na 120% i z taką też siła będzie ciągnął Twój projekt do przodu.

Dług technologiczny jako lewar dla Twojego biznesu

Pisałem już wcześniej czym jest dług technologiczny [wstawić linka]. Zazwyczaj jest on poruszany w negatywnym kontekście – jako dodatkowe obciążenie budżetu lub jako tajemnica o której wykonawcy nie mówią, żeby nie zniechęcić klientów. Proponuję jednak zwrócić uwagę na jego pozytywną stronę.

Kiedy dług (kredyt) działa jako lewar?

Tak, możemy wykorzystać dług technologiczny na naszą korzyść. Sytuacja jest analogiczna jak z kredytem w banku. Jeśli bierzemy kredyt konsumpcyjny i bez świadomości zagrożeń. To będzie on tylko zwiększał nasze zadłużenie i zmniejszał siłę nabywczą w długim terminie. Jeśli jednak zaciągniemy, w pełni świadomie, kredyt na inwestycję z której zwrot będzie wyższy niż oprocentowanie. Wtedy zadziała efekt dźwigni i w długim terminie zyskamy.

Tak samo może to wyglądać w przypadku tworzenia oprogramowania. Jeżeli tworzymy np. nową usługę lub funkcję w systemie. To możliwe że dzisiaj nie jesteśmy pewni czy ona zrealizuje potrzeby użytkowników, trafi w niszę na rynku, itp. W takiej sytuacji możemy wykonać jakieś rozwiązania prościej, taniej i szybciej – żeby sprawdzić jak reagują na nie użytkownicy, jak sprawdzają się w praktyce – stworzyć MVP (minimum viable product) lub PoC (proof of concept). Trzeba jednak cały czas pamiętać, że taka droga oznacza spłacanie odsetek – czyli w długim terminie tak wykonane oprogramowanie pochłonie sumarycznie więcej czasu i pieniędzy – niż jakby została wykonana po prostu porządnie ostatnia wersja.

Problem jest też w tym, że w oprogramowaniu właściwie nigdy nie wiemy jak powinna wyglądać ostatnia wersja, dlatego takie podejście jest prawie zawsze jedynym (a mimo to się o tym nie mówi). Na plus w tej sytuacji jest to, że stworzone oprogramowanie zawsze możemy wyłączyć i zakopać pod ziemię – a kredytu umorzyć już nie zawsze.

Dla pełnej jasności, trzeba jeszcze powiedzieć że nie zawsze takie działanie jest możliwe. Nie zawsze zadowoli nas stworzenie proof of concept. Nie jest to możliwe jeśli np. mamy przygotować system do obsługi transakcji płatniczych. Wtedy nie ma innej drogi niż długoterminowa współpraca z wykonawcą i continuous delivery. 

Przewaga konkurencyjna

Tempo rozwoju technologii jest zawrotne. Nie ma w tym nic odkrywczego. Na rynku wygrywają te firmy, które potrafią skutecznie przez lata utrzymywać i wytwarzać przewagę konkurencyjną. To między innymi odbywa się poprzez wprowadzanie nowych technologii, nowego oprogramowania, reagowanie na zmiany szybciej niż konkurencja. 

Do tego właśnie czasem trzeba zwiększyć zadłużenie, żeby w pełni wykorzystać potencjalną okazję. Tym właśnie będzie np. szybkie stworzenie PoC nowej aplikacji, której konkurencja jeszcze nie ma. Tym będzie zastosowanie nowej funkcji, czy przerobienie interface’u aplikacji zgodnie z nowymi standardami szybciej niż cały rynek. 

To są właśnie idealne momenty, kiedy warto rozważyć skorzystanie z gorszego, szybszego rozwiązania, które pozwoli nam być pierwszymi, które pozwoli nam szybko sprawdzić nasze założenia i pomysły. W końcu nikt nie ma umiejętności przewidywania przyszłości i jedyne co możemy zrobić to szybko sprawdzić nasze przypuszczenia z rzeczywistości. 

Jeśli działa – super – warto inwestować w to dalej. Jeśli nie działa – nie straciliśmy na to dużo czasu – nadal mamy czas żeby coś poprawić i spróbować jeszcze raz. Jeśli nadal nie działa – mamy wnioski z kilku prób i dostaliśmy realną odpowiedź rynku. To bardzo cenne i zazwyczaj warte poświęconego czasu – ponieważ prowadzi do kolejnych projektów, pomysłów i wniosków

Sharing is caring!