Dług w produkcie — jak uzasadnić jego spłatę?
W życiu każdego inżyniera, zwykle w okolicach Nowego Roku przychodzi czas, gdy zaczynamy patrzeć wstecz i widzieć cały dług, który, celowo bądź nie, zaciągnęliśmy w naszym produkcie. I kiedyś trzeba zacząć go spłacać. Dziś porozmawiamy o tym, jak uzasadnić spłatę takiego długu.
Jak uzasadnić spłatę długu w produkcie
Powiedzmy to sobie szczerze. Jeśli nasz produkt jest na produkcji, to najprawdopodobniej mamy w nim pewien dług. Tworzyć produktu, który długu nie ma, niestety po prostu się nie da. Naturalnie, pewne aspekty rozwijamy lepiej, a na innych skupiamy się mniej.
A więc skończyliśmy mając dług, większy lub mniejszy. I co z tym zrobić?
Ale nie tak szybko, na początku zastanówmy się, czy coś w ogóle. I czy w ogóle warto się przejmować
Jaki dług warto spłacić?
Bo nie każdy warto.
Wyobraź sobie (albo zauważ ), że jesteś właścicielem mieszkania. Niezależnie, czy mówimy o penthouse czy kawalerce – zawsze znajdzie się takie pomieszczenie, czy obszar, nad którym nie skupiamy się tak bardzo. Jakaś spiżarnia, schowek, graciarnia. Brzmi znajomo? Rzeczy tam leżą i się kurzą, półki trochę skrzypią, światło lekko smuży. Ale działa. I jakoś nie czujesz potrzeby, by tę kanciapę modernizować.
Dokładnie tak samo sprawy się mają z długiem w produkcie. Nie każdy jest na tyle wartościowy, by go spłacać. Czasem można z nim żyć, oswoić się albo nawet zaprzyjaźnić.
Do oceny, czy nasz dług się do takich zalicza, może posłużyć kategoryzacja z artykułu Tech Debt Walls Pete’a Hodgsona:
Kategoryzujemy dług ze względu na:
Zysk z jego spłacenia.
Koszt z jego spłacenia.
W rezultacie, z analizy może nam wyjść, że części długu nie warto spłacić, bo:
Zbyt rzadko coś zmieniamy w danym obszarze, aby to poprawić.
Możemy żyć z manualną akcją raz na miesiąc.
Koszt poprawy tej funkcjonalności jest zbyt wysoki w stosunku do jej naprawy.
Jaki dług nie musimy uzasadniać by spłacić
Warto zauważyć, że z powyższej kategoryzacji wychodzi nam jeszcze dodatkowa kategoria: Dług, który możemy spłacać od razu.
Ten typ charakteryzuje się relatywnie niskim kosztem naprawy. Na tyle, że w zasadzie szkoda marnować czas na szczegółowe uzasadnianie jego spłaty, a właściwie to więcej czasu poświęcimy na argumentację, niż faktyczną akcję.
Aby wdrożyć takie naprawy w praktyce, polecam wykorzystać regułę Boy Scout Rule:
Leave your product better than you found it.
Poświęcamy więc regularnie jakiś niewielki procent czasu pracy nad daną funkcją, aby nieco poprawić stan naszego produktu. Może to być na przykład:
Poprawa nazewnictwa klas i zmiennych.
Podział dużej funkcji na kilka mniejszych.
Aktualizacja instrukcji uruchamiania aplikacji.
Usunięcie niepotrzebnych kroków z CI/CD.
Ale ostrzegam, nie próbujcie przy tym zbawiać całego świata Nie będzie (najprawodpodobniej) problemem jeśli, w ramach 10 dniowej pracy, poświęcicie pół dnia na sprzątanie. Kłopot zacznie się jednak, jeśli proporcje zaczną wyglądać odwrotnie.
Business case dla spłaty długu
Najmniejsze długi (i najszybsze rozwiązania) mamy już z głowy, więc pora przejść do bardziej skomplikowanych zagadnień. Dla problemów z prawego górnego rogu (wysoki i zysk, i koszt), potrzeba innego podejścia — z jednej strony mamy dużą potencjalną wartość, ale z drugiej — wiąże się ze sporą inwestycją. Aby łatwo i skutecznie przekonać interesariuszy, że warto w to zainwestować, można wykorzystać wykorzystać podejście Business Case
A business case provides justification for undertaking a project, programme or portfolio. It evaluates the benefit, cost and risk of alternative options and provides a rationale for the preferred solution.
Czyli odpowiednio przedstawić argumenty za tym, by zainwestować w spłatę długu. O czym więc powinniśmy pamiętać?
Zmiana kierunku myślenia
Nikomu nie będzie w smak „spłata długu” jako etykietka projektu. Taka nazwa, zamiast obietnicy korzyści, przywodzi na myśl same negatywne skojarzenia. W głowie pojawiają się obrazy błędów przeszłości i ich smutnych konsekwencji.
Aby tego uniknąć, Alberto Brandolinii promuje inną nazwę — Design Integrity.
Design Integrity describes how much the current codebase fits its purpose. No past, no guilt. Just, “How close are we to where we should be?” Or, “If we were redesigning this from scratch, how different would it be?”
Musimy patrzeć w przyszłość i na długofalowych celach opierać argumenty za tym, do jak solidnego systemu doprowadzi zajęcie się kwestią.
Zrozumieć interesariuszy
Aby dostać zielone światło dla usprawnień systemu, musimy rozumieć, na czym zależy naszym interesariuszom. Tylko dzięki temu przekujemy techniczne zyski (czas developerów, mniej błędów, usprawnione procesy) w biznesowe cele.
Powiedzmy sobie szczerze:
Nikogo nie obchodzi, że Ty będziesz mieć lepszą pracę. Aby sprzedać swoją ideę, musisz odnieść się do potrzeb i celów drugiej strony.
Pomocne w przygotowaniu do rozmowy będzie zadanie sobie kilku pytań:
W jaki sposób interesariusz korzysta z systemu?
Jak osiąga pośrednie zyski z mojej produktywności?
Na co narzeka teraz najczęściej?
Jak awarie wpływają na pracę tej osoby lub działu?
Zebrane refleksje ułatwią Ci pracę w kolejnym etapie.
Przełożenie prac technicznych na zyski biznesowe
Biorąc pod uwagę Drivery Architektoniczne, możesz zastanowić się, jak twoje usprawnienia wpłyną na pracę interesariuszy. Weź pod uwagę na przykład poniższe zagadnienia:
Refaktoring starego kodu
Drivery: produktywność, utrzymywalność, odporność na błędy.
Zysk: Po napisaniu kodu łatwiej będzie dodawać kolejne przypadki użycia. Szybciej będziemy poprawiać istniejące scenariusze. Przez łatwiejszy do zrozumienia kod będziemy popełniali mniej błędów.
Poprawa CI/CD
Drivery: produktywność, time-to-market, czas naprawy.
Zysk: Mniej czasu przepalamy na czekanie. Szybciej jesteśmy w stanie wdrożyć zmianę, zarówno funkcyjną, jak i poprawkę do błędu.
Zwiększenie jakości testów automatycznych
Drivery: produktywność, odporność na błędy, stabilność.
Zysk: Szybciej zauważamy, że nasze zmiany wprowadziły błąd – poświęcamy na to mniej czasu, i mniej błędów przechodzi na produkcję. Nasze zmiany nie powodują niestabilnej pracy produktu, a co za tym idzie unikamy problemów pracowników.
Optymalizacja efektywności działania aplikacji
Drivery: wydajność, skalowalność, dostępność.
Zysk: Nasi pracownicy szybciej pracują w aplikacji. Możemy obsłużyć więcej klientów. Aplikacja nie składa się, gdy ruch rośnie.
Usprawnienie praktyk obserwowalności
Drivery: czas naprawy, satysfakcja klienta, utrzymywalność.
Zysk: Reagujemy bardzo szybko na problemy. Często klienci nawet nie zauważają problemów. Widzimy, które ścieżki nie działają wydajnie i jesteśmy w stanie zaplanować dla nich poprawę.
Dzięki stworzeniu takiej korelacji, ubierzesz w biznesowe argumenty twoje techniczne usprawnienia.
Dodatkowo możesz jeszcze się zastanowić nad określeniem dokładniejszych liczb. Nie zawsze jest to konieczne, ale nierzadko pomaga.
Kwantyfikacja zysków
Naszym celem jest pokazanie zysków na konkretnych liczbach. Chcemy obliczyć potencjalny zysk tak, by zobaczyć, czy poniesiony koszt będzie faktycznie warty spłaty.
Aby zobaczyć, jak to działa w praktyce, weźmy na tapet takie usprawnienie:
Optymalizacja efektywności działania aplikacji.
Nasi pracownicy szybciej pracują w aplikacji. Możemy obsłużyć więcej klientów. Aplikacja nie składa się gdy ruch rośnie.
Celem jest wykazanie, przykładowo, o ile szybciej zwiększy się tempo pracy w aplikacji. Znając zakres obowiązków wykonywanych przez pracowników oraz czas poświęcany na dane zadanie, możemy to zrobić następująco:
Pracuje tutaj X pracowników.
Dziennie poświęcają na zadanie Y minut czasu.
Po zmianach będą poświęcali Z minut czasu.
Miesięcznie oszczędzi to ( Y – Z ) * X minut czasu.
Jak ubrać w liczby ten i bardziej skomplikowane przypadki? Jak zmierzyć, o ile jesteśmy w stanie przyśpieszyć pracę?
W tym aspekcie polecam świetną książkę How to Measure Anything i zaczerpnięte z niej podejście:
Define a decision problem and the relevant uncertainties.
Determine what you know now.
Compute the value of additional information.
Apply the relevant measurement instrument(s) to high-value measurements.
Make a decision and act on it.
Przekładając to na nasz przykład:
Naszą niewiadomą jest to, ile dokładnie zyskamy na poprawie.
Określamy
a. Ile czasu pracownicy na to poświęcają na ten scenariusz, wykonując kilka rozmów.
b. Które scenariusze wymagane są do poprawy.Oceniamy, które informacje są dla nas kluczowe, a jeszcze ich nie mamy:
a. Miejsca, w których następuje wąskie gardło – proces utyka.
b. Czas, na jaki potencjalnie moglibyśmy wstrzymać wykonywanie scenariusza.Dla tych miejsc przeprowadzamy szybkie działania terenowe:
a. Inwestygacja miejsc w kodzie.
b. Dyskusja o usprawnieniach, PoC dla rozwiązania.Po zebraniu informacji określamy, czy faktycznie uzyskaliśmy dane, które potwierdzają nasze założenia.
Pozwolę sobie przytoczyć świetny cytat z powyższej książki:
When you have a lot of uncertainty, a few samples greatly reduce it, especially with relatively homogeneous populations.
Podążając za tą wskazówką, możemy, poświęcając stosunkowo niewiele czasu, uzyskać najważniejsze informacje. Nie potrzebujesz ogromnej ilości danych. Już niewielkie eksperymenty i inwestygacje pozwalają zgromadzić przekonywujące dowody.
Podsumowanie
Praca nad spłatą długu w produkcie zawsze będzie trudniejsza do uargumentowania niż „new shiny thing". Ale nie zapominajmy, to jakość produktu ostatecznie sprawia, że ludzie korzystają z produktu. I tylko poprzez spłatę długu jesteśmy w stanie tę jakość zapewnić.
A ty, w jaki sposób argumentujesz spłatę długu w swoim produkcie?