Jak uciec od wiecznie rozwijającego się projektu? Strategie na zamknięcie długu programistycznego

Wersja 0.9. Prawie gotowe. Jeszcze ta jedna funkcja, jeszcze ta poprawka, jeszcze refaktoring, który „powinien był być zrobiony wcześniej". Potem okazuje się, że numer wersji ma już trzy człony, projekt trwa trzeci rok, a premiera jest ciągle za rogiem.

Znasz to uczucie? Zwróć uwagę na coś, co w tej historii nie wystąpiło ani razu. Przez trzy lata nikt nie usunął z zakresu ani jednej rzeczy.

I to jest właściwa diagnoza, bo problem nie polega na tym, że jest za dużo do zrobienia. Polega na tym, że w tym projekcie nikt nie ma prawa niczego wyciąć. W projekcie bez decyzji odejmujących wszystko, co raz dodasz, zostaje na zawsze — a lista rzeczy do zrobienia rośnie szybciej, niż zespół jest w stanie ją skracać.

Dodanie jest decyzją jednej osoby, usunięcie wymaga zgody wielu

Zacznij od zaobserwowania, jak faktycznie wchodzą zmiany do zakresu. Ktoś pisze na Slacku „dodajmy dark mode", ktoś inny odpowiada „dobry pomysł", i po dwóch wiadomościach rzecz jest w projekcie. Nikt nie robił spotkania ani oceny wpływu.

Teraz spróbuj tak samo coś usunąć, a zobaczysz zupełnie inny proces. Trzeba ustalić, kto o to prosił, wytłumaczyć mu, dlaczego jednak nie, sprawdzić, czy nikt tego nie obiecał klientowi, i uzasadnić decyzję przed osobą, która wpisała to do roadmapy. Dodanie kosztuje dwie wiadomości, a usunięcie cztery rozmowy i czyjś zawód.

Z tej różnicy kosztów wynika wszystko dalsze. Jeśli dokładanie jest dziesięć razy tańsze od odejmowania, to zakres rośnie nawet wtedy, gdy każda pojedyncza decyzja jest sensowna. Nikt nie musi być nierozsądny, żeby projekt puchł — wystarczy, że mechanizmy nie są symetryczne.

Współczesne narzędzia dokładają do tego przyspieszenia. Kiedy prototyp powstaje w godzinę, próg wejścia dla nowego pomysłu praktycznie znika. Shopify ujmuje to trafnie: „to, że możesz coś szybko zbudować, nie znaczy, że powinieneś". Łatwość implementacji zabija priorytetyzację, bo priorytetyzacja jest potrzebna tylko wtedy, gdy coś jest drogie.

Dlaczego „gotowe" jest słowem zakazanym

Spójrz teraz na to, co właściwie oznacza zamknięcie projektu. Nie oznacza, że skończyła się praca, bo praca się nigdy nie kończy. Oznacza, że ktoś przeciął listę i powiedział, co znalazło się po drugiej stronie.

To dlatego słowo „gotowe" jest w wielu zespołach nie do wypowiedzenia. Wypowiedzenie go wymaga wskazania rzeczy, które nie wejdą, czyli sprawienia komuś zawodu w sposób jawny i udokumentowany. Znacznie wygodniej jest powiedzieć „prawie", bo „prawie" nie odbiera nikomu niczego.

Stąd bierze się charakterystyczna asymetria terminów. Termin przesuwa się cicho i sam z siebie, bez żadnej decyzji, a wycięcie funkcji wymaga spotkania, na którym ktoś musi to powiedzieć na głos. Zespół zawsze wybierze to pierwsze, bo jest tańsze społecznie — i tak projekt sam się przedłuża, mimo że nikt tego nie postanowił.

Kod też się tylko dokłada

Dokładnie ten sam mechanizm działa piętro niżej, w kodzie, tylko nazywa się inaczej. Nowa funkcja to nowy kod, nowy kod to nowa powierzchnia do utrzymania, a usuwanie kodu jest tak samo społecznie drogie jak usuwanie funkcji.

Skala tego zjawiska jest policzona i podana w dolarach. CISQ w raporcie o koszcie słabej jakości oprogramowania w USA szacuje ten koszt na co najmniej 2,41 biliona dolarów rocznie. Sam skumulowany dług techniczny, czyli rzeczy zbudowane i nienaprawione, to według tego raportu około 1,52 biliona. To nie jest koszt naprawy, tylko wartość zaległości, która co roku pracuje na twoją niekorzyść.

W tym samym raporcie przywołane jest skandynawskie badanie z 2019 roku, według którego programiści tracą przez dług techniczny średnio 23% czasu pracy. Prawie jeden dzień w tygodniu nie idzie na to, po co ich zatrudniono.

📖 Ze słownika Noraline Dług techniczny (technical debt) — kompromisy w jakości kodu podjęte świadomie albo z pośpiechu, które generują „odsetki" w postaci wolniejszej pracy, trudniejszego utrzymania i wyższego ryzyka błędów. Jak dług finansowy: da się go zaciągać strategicznie, pod warunkiem że ktoś pilnuje harmonogramu spłat. Bez tego rośnie sam, bo odsetki płaci się przy każdej kolejnej zmianie.

Na poziomie pojedynczego projektu policzył to Sonar, analizując ponad dwieście rzeczywistych projektów przez dwanaście miesięcy. Na każdy milion linii kodu wychodzi mniej więcej 5 500 godzin pracy rocznie na usuwanie skutków długu, co Sonar wycenia na około 306 tysięcy dolarów. W pięcioletnim horyzoncie robi się z tego blisko półtora miliona.

Te cztery pomiary łatwo pomylić, bo wszystkie opisuje się jednym słowem „dług". Każdy mierzy jednak co innego i tylko ostatni da się przełożyć na własny projekt.

Warto powiedzieć, czego te liczby nie znaczą. To nie jest koszt awarii ani przestojów, tylko sam podatek od utrzymywania istniejącego kodu — płacony niezależnie od tego, czy cokolwiek się popsuło.

Kto płaci odsetki

Rachunek nie trafia do arkusza kosztów, tylko rozkłada się po ludziach i po kalendarzu, i dlatego długo go nie widać.

Płaci go najpierw tempo pracy. Każda zmiana wymaga obejścia trzech prowizorek z dawnych lat, sprawdzenia, czy nie zepsuje czegoś, co „działa jakoś", i przetestowania na infrastrukturze, której nikt nie rozumie w całości. To ta sama pułapka, którą opisywałem przy okazji tego, kiedy automatyzacja staje się pułapką. Budowanie szybciej na złym fundamencie nie skraca drogi, tylko powiększa to, co trzeba będzie utrzymać.

Płacą go potem ludzie, i to oni odchodzą pierwsi. Nikt nie chce spędzać kariery na łataniu cudzych skrótów ani pracować w kodzie, gdzie zmiana koloru przycisku wymaga ruszenia trzech plików i modlitwy do pipeline'u. Wychodzą ci, którzy mają dokąd, czyli zwykle najlepsi, a zostają ci, którzy się przyzwyczaili.

I tu pętla się domyka. Zespół pracuje wolniej nie dlatego, że mniej się stara, tylko dlatego, że część kompetencji już wyszła drzwiami. A nowe osoby wchodzą w bazę kodu, w której nikt nigdy niczego nie usuwał.

Pięć decyzji odejmujących

Wszystkie sposoby, które faktycznie zamykają projekty, mają jedną wspólną cechę. Nie zwiększają tempa dodawania, tylko wprowadzają mechanizm odejmowania.

Zamrożenie zakresu z listą „nie w tej wersji". Nie chodzi o samo zapisanie, co wchodzi — chodzi o drugą, jawną listę tego, co nie wejdzie. Atlassian zaleca, żeby każda zmiana zakresu przechodziła formalną ocenę wpływu przed zatwierdzeniem. Sens jest jeden: zrównać koszt dodania z kosztem usunięcia.

Termin traktowany jak odlot samolotu. Samolot startuje o czternastej niezależnie od tego, czy zdążyłeś się spakować, a to, co nie weszło do walizki, leci następnym. Termin bez tej właściwości nie jest terminem, tylko życzeniem. Tak działa zasada 70%: lepiej wypuścić siedemdziesiąt procent zakresu na czas niż całość nigdy.

Wypuszczenie minimum, żeby rynek wyciął resztę za ciebie. Nie wiesz, których funkcji użytkownicy naprawdę potrzebują, i oni też tego nie wiedzą, dopóki nie dostaną produktu do ręki. Wypuszczenie minimum zamienia twoją subiektywną decyzję o wycięciu w dane. I nie kończ funkcji tylko dlatego, że ją zacząłeś — to błąd utopionych kosztów w wersji na poziomie zadania.

Stały dzień na spłatę długu. „Kiedyś zrobimy refaktoring" znaczy „nigdy", bo dzień bez daty nie istnieje w kalendarzu. Piątek albo dowolny inny dzień, ale ten sam, co tydzień, i bez możliwości przesunięcia go „ten jeden raz". To jedyna forma odejmowania, którą da się zaplanować z góry.

Wyrzucanie funkcji jako czynność cykliczna. Raz na kwartał przejrzyj, co faktycznie jest używane, i usuń to, czego nie używa prawie nikt. Mniej kodu to mniej utrzymania, mniej długu i szybsze kolejne zmiany. To nie jest przyznanie się do porażki, tylko higiena — i jedyny moment, w którym baza kodu może się skurczyć.

„Jeszcze tylko ta jedna funkcja" nigdy nie jest jedna

Warto nazwać frazę, która uruchamia całą sekwencję. W biznesie opisywałem kiedyś najdroższe słowa; w projektach programistycznych odpowiednikiem jest „jeszcze tylko ta jedna funkcja".

Nie jest jedna, bo za nią idzie ta, która ją domyka, a potem ta, bez której poprzednia wygląda dziwnie. Każda z osobna kosztuje dzień. Dwadzieścia takich decyzji to kwartał, którego nikt nie zaplanował i nikt za niego nie odpowiada.

Blisko tego siedzi fałszywa produktywność, która w tej branży boli szczególnie. Commit wygląda jak postęp, a bywa tylko ruchem — można pisać kod dwanaście godzin dziennie i nie zbliżyć się o krok do wypuszczenia czegokolwiek. Projekt, który nigdy nie jest gotowy, nie generuje wartości — generuje wyłącznie koszty i rosnącą listę rzeczy do utrzymania.

Wskaż osobę, która ma prawo powiedzieć „nie w tej wersji"

Cała ta konstrukcja opiera się na jednej rzeczy, której zwykle brakuje, i nie jest nią proces. Jest nią konkretne nazwisko wpisane obok konkretnego uprawnienia.

Zamrożenie zakresu, twardy termin, wycinanie funkcji i dzień na dług — każdy z tych mechanizmów wymaga, żeby ktoś konkretny mógł powiedzieć „nie" bez proszenia o zgodę. Jeśli takiej osoby nie ma, mechanizm istnieje na papierze, a w praktyce każda propozycja i tak przechodzi, bo nikt nie ma mandatu, żeby ją zatrzymać.

Zrób więc rzecz, która zajmuje pięć minut i nic nie kosztuje. Napisz jedno imię i nazwisko obok zdania: ta osoba decyduje, co nie wchodzi do tej wersji. Powiedz to zespołowi i klientowi, żeby nikt nie próbował omijać tej decyzji na Slacku.

Przy wyborze nazwiska warto wiedzieć jedno o sobie, zanim wpiszesz własne. Mandat do mówienia „nie" jest bezużyteczny u kogoś, kto pod presją odruchowo ustępuje albo wychodzi z rozmowy — a to nie jest kwestia charakteru, tylko wyuczonego stylu reagowania na spór. Test stylu rozwiązywania konfliktów rozkłada to na pięć postaw, od rywalizacji po unikanie i dostosowanie. Jeśli twoje dwie najwyższe to unikanie i dostosowanie, lista „nie w tej wersji" przetrwa dokładnie do pierwszej niewygodnej rozmowy.

Reszta jest już tylko wykonaniem. Idealna wersja pierwsza nie istnieje — istnieje wystarczająco dobra, którą da się wypuścić, zmierzyć i poprawić. Ale żeby w ogóle powstała, ktoś musi mieć prawo przeciąć listę.