Dług technologiczny – najczęstszy powód wykolejania się projektów
|
Jakiś czas temu współtworzyłem produkt, który cieszył się dość dużym powodzeniem — był to panel do zarządzania hostingiem. Przez kilka lat nasza baza klientów rosła, a my rozszerzyliśmy panel o wsparcie nowych platform i dodawaliśmy nowe funkcjonalności. To był mój pierwszy “własny” produkt i stał się on dość popularny. W pewnym momencie był on używany przez większość dostawców hostingu gier w Polsce.
Wraz z tym, jak baza klientów rosła i poszerzyliśmy funkcjonalność aplikacji, zaczęliśmy obierać drogę na skróty. Czasami wynikało to z ograniczeń czasowych, innym razem myśleliśmy, że tak będzie po prostu dobrze.
Czas uciekał, a naprawianie błędów i dodawanie kolejnych funkcji stawało się coraz trudniejsze. Okazało się, że przez cały ten czas nieświadomie dolewaliśmy oliwy do ognia. Pewnego dnia okazało się, że nasz produkt przestał być opłacalny przez dług technologiczny, który sami podczas rozwoju produktu powiększaliśmy. Wydatki na utrzymanie produktu przerosły przychody, które był on w stanie generować.
Musieliśmy podjąć trudną decyzję i porzucić projekt. Teraz wyobraź sobie, że jesteś w tej samej sytuacji: posiadasz większość udziałów w rynku i nie zarabiasz pieniędzy. To naprawdę niemiłe doświadczenie.
Ta sytuacja nauczyła mnie czegoś ważnego — oszczędzanie na jakości na dłuższą metę niesie za sobą większe straty i wydatki niż zarobki. Teraz jestem zażartym wrogiem długu technologicznego. W projektach, które prowadzę, zawsze staram się odpowiednio zadbać o jakość tworzonego kodu. Na samą myśl o długu technologicznym mam ciarki. Brr ;-/
Chwila. O jakim długu właściwie mówimy?
Dług technologiczny nie jest rzeczą fizyczną, namacalną. To metafora stworzona przez Warda Cunninghama, która pozwala na zrozumienie problemu, który się za nią kryje.
Dług technologiczny oznacza, że część systemu została stworzona w “prosty” sposób bez dbania o jakość kodu. Gdy oszczędzasz czas i pieniądze na rozwoju oprogramowania, Twój dług rośnie.
Tak samo jak dług finansowy, dług technologiczny niesie on za sobą odsetki, które musisz zapłacić. Im więcej długu zaciągasz, tym więcej odsetek. Jedyna różnica w tym przypadku jest taka, że nikt na Twoim długu nie zarabia — może jedynie prócz konkurencji, która zostawia Cię daleko w tyle.
Skąd bierze się dług technologiczny?
Dlaczego programiści wprowadzają dług technologiczny do projektu? Jest kilka powodów. Będę szczery — pierwszy powód nie jest zbyt przyjemny. Znaczna część deweloperów “zaciąga” dług, bo jest po prostu leniwa i wybiera łatwiejszą drogę wprowadzenia nowej funkcjonalności — bez myślenia o konsekwencjach.
Innym razem to młodzi i niedoświadczeni programiści zadłużają się technologicznie, bo nie do końca są świadomi tego, co robią, lub po prostu brakuje im pewnych umiejętności. Brak nadzoru nad takimi programistami może również doprowadzić do totalnego bałaganu w kodzie — który jest nawet gorszy niż dług technologiczny, ale to już inna historia…
Sytuacja, w której funkcjonalności muszą być stale implementowane w szybki i tani sposób jest dość powszechna w branży, szczególnie kiedy firma ściga się z konkurencją pod względem funkcjonalności. Mimo że, bycie pierwszym na rynku odpowiada potrzebom biznesowym, powinieneś pamiętać, że im szybciej wprowadzony dług zostanie spłacony, tym mniej będzie kosztował. Wiele firm mówi sobie, że zrealizuje teraz coś “na szybko”, a potem poprawi ten kod — niestety smutną prawdą jest, że wciąż za mało firm spłaca go szybko i odwleka spłatę do momentu, w którym jest już za późno, by miała ona sens. W takich przypadkach trzeba po prostu zacząć od nowa lub… porzucić projekt.
Czy w moim produkcie jest dług technologiczny?
Odpowiedz sobie na te pytania:
- Czy rozwijanie oprogramowania jest spowolnione?
- 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 planowane?
- Czy zdarzają się błędy trudne do odtworzenia lub rozwiązania?
Te pytania to tylko przykłady i oczywiście nie można ich na sztywno wiązać z długiem technologicznym, ale jeśli odpowiedziałeś TAK to warto się zastanowić czy przypadkiem nie masz już problemu.
Niezależnie od tego, czy jesteś świadomy długu, czy nie, możesz być pewny, że jeśli posiadasz jakiekolwiek oprogramowanie, posiadasz również jego dług i powinieneś go spłacić.
Jak duży jest mój dług?
Mam złe wieści — długu technologicznego nie da się zmierzyć. Są różne sposoby, które pomagają estymować wielkość długu, ale są tylko kiepskimi przybliżeniami, które mają niewiele wspólnego z rzeczywistością. Takie przybliżenia mogą jedynie pomóc w porównaniu różnych wersji Twojego systemu. Istnieją narzędzia, które pomagają zmierzyć przybliżoną wielkość długu, ale to temat na kolejny artykuł.
Czy dług technologiczny wpływa na mój biznes?
Tak, jak każdy dług, który zaciągasz. Nie dość, że posiadasz kod, który musi być refaktoryzowany (i musisz zapłacić za to programistom), to, co ważniejsze, im więcej długu posiadasz, tym dłużej zajmie Ci wprowadzanie nowych funkcjonalności. Innymi słowami, dług technologiczny zmniejsza Twoje możliwości szybkiego implementowania nowych funkcji. W niektórych przypadkach, gdy dług jest naprawdę duży, dodanie nowych funkcji w rozsądnym czasie i rozsądnym budżecie jest niewykonalne. To może doprowadzić do zatrzymania rozwoju oprogramowania i … dużych kłopotów.
Wyobraź sobie, utkwić w takim bałaganie i obserwować jak konkurencja z każdym dniem zwiększa swoją przewagę. Przerażające, prawda? Na szczęście, nie cały dług technologiczny jest groźny dla Twojego biznesu i dlatego nie cały musi być spłacony. Musisz tylko pamiętać, żeby trzymać go na niskim poziomie.
Dwa przypadki katastrofalnego wpływu długu technologicznego to Friendster i Knight Capitall. Friendster mógł być pierwszym portalem społecznościowym, ale stracił swoją szansę na zdobycie rynku ze względu na problemy związane z… zgadnij! Ich dług był tak duży, że strony ładowały się bardzo wolno, a platforma nie była w stanie szybko się skalować.
W Knight Capital stracili 440 milionów dolarów (!) w 45 sekund tylko dlatego, że mieli stary, nieprzetestowany kod wciąż zainstalowany na swoich serwerach. Możesz znaleźć dużo informacji na ten temat, bo to przypadek spowodował zamęt wokół notowań 148 firm, które znajdowały się na NYSE.
Co powinienem zrobić?
Jak wspomniałem wcześniej, trudno jest oszacować, jak duży dług posiadasz, więc najlepiej porozmawiaj o tym z Twoim zespołem. Mam nadzieję, że będzie z Tobą szczerzy i nikt nie będzie chciał ukrywać obecnego stanu oprogramowania. Może programiści już zaczęli Ci się skarżyć i sugerować, że jest coś, nad czym musicie popracować?
Najlepszym sposobem na zwalczenie długu technologicznego jest zbudowanie wspólnego zrozumienia wokół tego, czym ten dług jest i zmiana myślenia zespołu. Bardzo często najważniejszym krokiem jest ten, który zrobiłeś właśnie teraz. Masz już świadomość długu technologicznego i jeśli w tym momencie podejmiesz decyzję, żeby się z nim zmierzyć — jesteś na właściwej drodze.
- Spróbuj dowiedzieć się jak najwięcej, czym jest dług technologiczny. Wiem, że już zacząłeś swoją edukację na ten temat, skoro czytasz ten artykuł - świetnie. Również product owner i cały zespół powinni mieć możliwość nauczyć się, czym jest dług technologiczny i jak on wpływa na Wasz biznes. Postaraj się, żeby każdy był świadomy istnienia długu i zastanów się ze swoim zespołem nad wspólnym opracowaniem rozwiązania tego problemu. Bardzo ważne, żeby zespół wiedział, co tworzy dług, jak go zidentyfikować i jak go unikać.
- Razem stwórzcie proces zwalczania długu.
- Podziel swoją aplikację na mniejsze, logiczne części, które mogą być refaktoryzowane osobno.
- Zwracaj uwagę na jakość kodu, pisz automatyczne testy i zaplanuj odpowiednią ilość czasu na refaktoryzację.
- Możesz również zaplanować specjalny dzień każdego tygodnia lub miesiąca na refaktoryzację/zmniejszanie długu technologicznego. Nadaj mu zabawną nazwę i ustal ciekawe zasady. Zamów pizzę i pozwól zespołowi porozmawiać na temat najważniejszych funkcjonalności. Później wspólnie nad tym pracuj.
- Jeszcze raz: pozwól swoim deweloperom pisać automatyczne testy za każdym razem, gdy ktoś znajdzie błąd (test, który to będzie dokumentował). Staraj się dodawać test, zanim wdrożysz nowe funkcjonalności (Test Driven Development approach).
- Nie zmuszaj zespołu do zbyt szybkiego dostarczania nowych funkcjonalności, jeśli nie ma ku temu dobrych powodów.
Keep calm and…
Doświadczyłem w swojej karierze niszczącego wpływ długu i pomagałem firmom, które męczyły się z nim i szukały rozwiązania. Niestety jest to tak powszechny problem, że jeśli chciałbym spisać wszystkie historie, które znam z własnych doświadczeń związanych z tym tematem, powstałaby raczej książka niż artykuł na bloga.
Najważniejsze to nie tracić nadziei — w większości przypadków nie jest za późno i można naprawić/spłacić zaciągnięty dług. Musisz tylko zrobić pierwszy krok i pokazać swojemu zespołowi właściwy kierunek w stronę światełka w tunelu. Sugeruję zrobić ten pierwszy krok już dziś, nawet jeśli miałby być on mały.