Dlaczego dobre decyzje techniczne przegrywają z biznesem

Przeglądasz pull request kolegi i widzisz, że komponent, nad którym pracujecie, zrobił się trudny do utrzymania, a wy właśnie dopisujecie do niego kolejny przypadek. W komentarzu proponujesz, żeby najpierw go uporządkować, zanim dołożycie następną rzecz. Na standupie product manager przytakuje, ale dodaje: „jasne, tylko najpierw feature X, klient oczekuje go na piątek”. Refactor trafia do backlogu i już z niego nie wraca.

Wychodzisz z tego spotkania z poczuciem, że biznes nie dba o jakość. To znajome wrażenie, ale w większości przypadków mylące. Problem rzadko polega na tym, że druga strona nie dba o kod. Chodzi o to, że ty i oni rozmawialiście w dwóch różnych językach, a w tej rozmowie liczy się tylko jeden z nich.

Ty argumentowałeś jakością kodu: czysty kontra zabałaganiony. Oni podejmowali decyzję na zupełnie innej podstawie. Dopóki tego nie zauważysz, najlepsza technicznie decyzja będzie przegrywać raz za razem, a tobie będzie się wydawać, że to wina drugiej strony.

#Czym naprawdę liczy biznes

Biznes nie myśli w kategoriach „dobry kod” kontra „zły kod”. Każdą swoją decyzję mierzy trzema rzeczami:

• Koszt - ile to pochłonie. Czas ludzi, pieniądze, uwagę zespołu, która mogłaby pójść gdzie indziej.
• Ryzyko - co się może zepsuć, jak bardzo i dla kogo. Czy stracimy klienta, dane, reputację, zgodność z prawem.
• Time-to-market - kiedy to realnie trafia do klienta. Nie kiedy „skończone”, tylko kiedy zaczyna przynosić wartość albo wyprzedzać konkurencję.

„Czysty kod” nie jest żadną z nich. To opis stanu technicznego, a nie kosztu, ryzyka ani czasu. Kiedy mówisz „to jest źle napisane”, podajesz informację, której druga strona nie umie przeliczyć na swoją decyzję. Mówisz w języku, którego nie rozumieją.

Cała sztuka polega na tym, żeby swój argument techniczny przełożyć na którąś z tych trzech. Nie dlatego, że twoja ocena techniczna jest nieważna - jest. Ale staje się decyzją dopiero wtedy, gdy ktoś usłyszy ją w języku, którym myśli.

#Tech debt to nie bałagan, to podatek

„Ten kod jest nieelegancki” opisuje estetykę. Nikt nie kupuje estetyki. To pierwszy powód, dla którego tech debt przegrywa: przedstawiasz go jako kwestię gustu.

Przełóż go na koszt i czas, a zmienia się wszystko: „każdy następny feature w tym komponencie zajmuje o jakąś jedną trzecią więcej czasu, bo zanim cokolwiek dodamy, musimy najpierw rozszyfrować, jak to działa - i zgadnąć, co przy okazji zepsujemy”. Teraz to nie gust, tylko koszt i czas - to, co biznes naprawdę liczy.

Słowo „debt” jest trafne nieprzypadkowo. Dług nalicza odsetki. Komponent, którego nie ruszasz, nie kosztuje cię nic dzisiaj - ale z każdym tygodniem podnosi cenę następnej zmiany w tym miejscu. Kiedy przedstawiasz tech debt jako narastające odsetki, a nie brzydotę, dajesz biznesowi to, czego naprawdę potrzebuje do decyzji: nie „jest źle”, tylko „im dłużej czekamy, tym drożej”.

#„Jakość kontra szybkość” to fałszywy wybór

Kiedy stawiasz sprawę jako „zróbmy to porządnie albo szybko”, przegrywasz, bo szybko prawie zawsze wygrywa - i słusznie, jeśli to jedyna oferta na stole.

Uczciwe postawienie sprawy wygląda inaczej. Nie „dobrze kontra szybko”, tylko trade-off w języku biznesu: „możemy dowieźć feature X na piątek na tym, co jest, i wtedy trzy kolejne rzeczy w tym obszarze będą kosztować jakąś jedną trzecią więcej. Albo poświęcamy dwa dni teraz i kolejne wchodzą normalnym tempem. Wasza decyzja”.

Warto zauważyć, co się tu zmieniło. Nie prosisz, żeby docenili elegancję. Dajesz im wybór kosztu i czasu, opisany tak, że da się go rozważyć, i zostawiasz decyzję tam, gdzie jej miejsce. Często i tak usłyszysz „dowozimy na piątek” - i to w pełni uprawniona decyzja biznesowa, podjęta ze świadomością ceny, a nie z niewiedzy. Różnica jest ogromna: w pierwszym scenariuszu zlekceważyli twoją uwagę, w drugim świadomie kupili dług, znając jego koszt.

Twoja robota nie polega na tym, żeby podjąć tę decyzję za nich. Polega na tym, żeby dać im pełny obraz - koszt, ryzyko i czas - i pozwolić im zdecydować z otwartymi oczami.

#„Good enough” to decyzja, nie porażka

Inżynierowie traktują „wystarczająco dobre” jak miejsce, w którym się poddali. Tak, jakby odpuścili sobie zrobienie tego porządnie.

Warto odwrócić to myślenie. „Good enough” to świadomie wybrany punkt, w którym przestajesz dopracowywać - wyznaczony przez koszt, ryzyko i czas. Test nie brzmi „czy to najlepsze, co potrafię zbudować”. Brzmi: „czy następna godzina dopieszczania zmniejsza jakiś realny koszt albo ryzyko - czy tylko mój dyskomfort?”.

Polerowanie ścieżki, na której nic poważnego nie może się zepsuć, to wydawanie budżetu tam, gdzie nie ma żadnego ryzyka do ograniczenia. Rozpoznanie, gdzie leży „wystarczająco dobre”, i powiedzenie tego na głos, to umiejętność seniora, nie kompromis. Junior pyta, czy może już skończyć. Senior mówi, że to jest dokładnie ten punkt, w którym kończymy - i dlaczego dalej byłoby marnotrawstwem.

#Kiedy „nie” jest właściwą odpowiedzią

Czasem najbardziej dojrzała decyzja to „nie”. Ale „nie” w języku biznesu, nie w twoim.

„Nie, to zła architektura” to twój język - i odbija się od ściany. „Możemy to zrobić, i oto co to kosztuje, czym ryzykujemy i co opóźnia - chcecie tej wymiany?” to to samo „nie”, przełożone na trade-off, który da się rozważyć. Czasem usłyszą cenę i się wycofają. Czasem powiedzą „płacimy” - i znów, mają do tego prawo.

A to działa w obie strony. Czasem właściwe „nie” dotyczy refactoru, który sam chcesz zrobić - bo ryzyko, które ogranicza, jest małe, a koszt realny. Senior umie jedno i drugie: obronić refactor, który się opłaca, i odpuścić ten, który się nie spina - oceniając oba tym samym rachunkiem kosztu, ryzyka i czasu. Ani „zawsze refaktoryzuj”, ani „nigdy nie ruszaj” nie jest dobrym podejściem. Warto mieć z tyłu głowy, że za każdym razem trzeba to przeanalizować od nowa, a nie zakładać odpowiedzi z góry.

#Sedno

Wróćmy do tego inżyniera z początku - tego, który zgłosił refactor i patrzył, jak umiera w backlogu. Co do kodu miał rację. Ale milczał w języku, który o tym kodzie zdecydował.

Przewaga seniora nie polega na głośniejszej opinii technicznej ani ładniejszym kodzie. Polega na nawyku przeliczania opinii na koszt, ryzyko i czas, zanim jeszcze zaczniesz rozmowę. Ten sam człowiek, ta sama ocena techniczna - cała różnica w tym, w którym języku argument ląduje.

Następnym razem, gdy otworzysz pull request i pomyślisz „trzeba by to uporządkować”, dokończ to zdanie w języku biznesu, zanim powiesz je na głos. Reszta spotkania potoczy się inaczej.