Od MVP do produktu: Dlaczego MVP nie wystarcza i jak uniknąć długu technicznego na start

MVP działa. Pierwsze zapisy spływają, ktoś pyta o demo, zespół świętuje w czwartek po godzinach. Wszystko idzie zgodnie z planem, bo plan zakładał dokładnie to: sprawdzić, czy ktokolwiek tego chce.

Trzy miesiące później przychodzi pierwszy poważny klient. Chce integrację ze swoim systemem, logowanie firmowe i eksport danych. Siadasz do kodu i okazuje się, że skrót, który na starcie oszczędził wam dwa tygodnie, teraz kosztuje kwartał przebudowy.

Odruch podpowiada, że to był błąd. Nie był. Ten skrót był poprawną decyzją w momencie, w którym zapadł, i przestał być poprawny w konkretnym dniu — tylko nikt tego dnia nie zauważył. Dług z MVP nie jest wpadką inżynierską, tylko ceną prędkości, którą płacisz dopiero w chwili, gdy przestajesz sprawdzać hipotezę i zaczynasz obsługiwać klientów.

MVP to sonda, nie fundament

Największe nieporozumienie brzmi niewinnie: „zbudujemy MVP, a potem go rozbudujemy". Akcent w skrócie MVP pada na słowo viable, czyli zdolny do życia — a nie „gotowy do skalowania" czy „fundament produktu". Zdolny do życia dokładnie na tyle, żeby dostarczyć odpowiedź na jedno pytanie.

Dobrym obrazem jest tu sonda kosmiczna, a nie budynek. Ma przetrwać wystarczająco długo, żeby przesłać dane, i nikt nie planuje wozić nią ludzi. Konstrukcja, która jest optymalna dla sondy, jest fatalna dla statku pasażerskiego — i odwrotnie, gdybyś budował sondę jak statek, nigdy by nie wystartowała w terminie.

Dlatego skróty na tym etapie nie są długiem zaciągniętym przez nieuwagę. Twardo zakodowana konfiguracja, procesy obsługiwane ręcznie za kulisami, jedna baza dla wszystkiego — to wszystko jest poprawne, o ile pytanie brzmi „czy ktoś tego chce". Pisałem o tym przy okazji różnicy między budowaniem produktu a rozwiązywaniem problemów. MVP należy do drugiej kategorii, a jego jedynym zadaniem jest obalić albo potwierdzić hipotezę.

Że to ma znaczenie, widać w danych o przyczynach zamknięć. W analizie CB Insights obejmującej 431 spółek, które zamknęły się po 2023 roku, słaby product-market fit pojawia się w 43% przypadków. Nie zła architektura i nie zły kod — brak dopasowania do rynku.

Moment, w którym skrót przestaje być skrótem

Jest w życiu projektu dzień, w którym zmienia się pytanie. Przestajesz pytać „czy ktoś tego chce", a zaczynasz pytać „czy zdążę na termin, który obiecałem klientowi". Od tego dnia wszystkie skróty zmieniają status.

Przejście widać po jednej rzeczy: po tym, co steruje backlogiem. Dopóki wpisujesz do niego rzeczy, które mają czegoś dowieść, jesteś w fazie eksperymentu. Kiedy wpisujesz rzeczy, których ktoś od ciebie oczekuje, bo zapłacił, jesteś już gdzie indziej — nawet jeśli nikt tego nie ogłosił.

Praktyczna konsekwencja tej zmiany jest twarda i natychmiastowa. Sonda nie musi mieć testów, bo jeśli się rozbije, po prostu wyciągasz wnioski. Produkt, za który ktoś płaci, musi mieć testy, bo jeśli się rozbije, tracisz klienta i tłumaczysz się przez tydzień. Ten sam kod, dwa różne wymagania, jedna zmiana w otoczeniu.

Dlaczego nikt tego momentu nie zauważa

Przejście nie ma własnej daty i to jest cały problem. Nie przychodzi mail, nikt nie robi spotkania, a rano po tym dniu kod działa dokładnie tak samo jak dzień wcześniej.

Zespół też nie dostaje sygnału, bo dalej dowozi. Sprinty się zamykają, funkcje wychodzą, wykresy w narzędziu wyglądają zdrowo. Jedynym objawem jest to, że wszystko trwa dłużej, niż powinno. A to łatwo wytłumaczyć sobie zmęczeniem, urlopami albo tym, że akurat trafił się trudny kwartał.

Skalę tego podatku da się pokazać liczbami, tylko trzeba je czytać ostrożnie. Raport Stripe Developer Coefficient, przywoływany w opracowaniu TinyMCE, mówi o 42% tygodnia pracy programisty. Ta wartość składa się jednak z dwóch pozycji: 13,5 godziny na dług techniczny i 3,8 godziny na zły kod. Globalnie Stripe wycenia to na blisko 85 miliardów dolarów utraconej produktywności rocznie.

Warto od razu powiedzieć, że inne pomiary wychodzą niżej. Raport CISQ przywołuje skandynawskie badanie, w którym wychodzi 23% czasu. Różnica bierze się z definicji: jedni liczą sam dług, drudzy dokładają do niego walkę ze słabym kodem. Bezpiecznie jest przyjąć, że mówimy o przedziale od jednej piątej do jednej trzeciej tygodnia. Budżetu nie warto budować na wartości podanej co do procenta.

📖 Ze słownika Noraline Dług techniczny — termin ukuty przez Warda Cunninghama na określenie świadomego skrótu w kodzie, zaciąganego po to, żeby szybciej dowieźć. W jego pierwotnym rozumieniu dług jest narzędziem, a nie wpadką: bierzesz pożyczkę, bo prędkość jest teraz warta więcej niż czystość. Kluczowe jest drugie zdanie tej definicji, które w praktyce ginie — pożyczkę trzeba spłacić, a odsetki płacisz przy każdej kolejnej zmianie w tym miejscu.

Trzy typy długu, ale tylko jeden blokuje przejście

Dług nie jest jednorodny, a mieszanie jego rodzajów prowadzi do złych decyzji. Samo rozdzielenie zajmuje kwadrans i zwykle przestawia priorytety w backlogu.

Rozróżnienie ma prosty skutek praktyczny. Dług akumulacyjny obsługujesz stałą ratą, a dług architektoniczny wymaga decyzji i miejsca w harmonogramie, bo wstrzymuje konkretne rzeczy, które chcesz sprzedać.

Warto zaznaczyć jedno, żeby nie robić z tego fałszywej precyzji. Efekt kuli śnieżnej — skrót oszczędzający kilkadziesiąt godzin, który po kilku latach kosztuje ich kilkaset — to ilustracja mechanizmu, a nie pomiar. Kształt krzywej jest prawdziwy, konkretne wartości zależą od tego, jak często wracasz w to samo miejsce w kodzie.

Wielki refaktor nie jest odpowiedzią na spóźnione przejście

Scenariusz powtarza się co do przecinka w kolejnych firmach. Projekt ma dwa lata, klientów przybywa, każda nowa funkcja zajmuje trzy razy dłużej, niż powinna. Pierwsza reakcja brzmi zawsze tak samo: przepiszmy to od zera.

Problem z tą reakcją jest podwójny i oba powody są policzalne. Po pierwsze, przez pół roku nie powstaje nic, za co klient zapłaciłby więcej, a konkurencja w tym czasie wypuszcza swoje rzeczy. Po drugie, działa mechanizm, który Frederick Brooks nazwał efektem drugiego systemu. Przepisując, wkładasz do nowej wersji wszystko, czego brakowało w starej — i po roku masz konstrukcję bardziej zagmatwaną od wyjściowej.

Właściwe podejście jest węższe i znacznie mniej efektowne. Nie potrzebujesz przepisać wszystkiego — potrzebujesz znaleźć tę część kodu, która pochłania większość czasu utrzymania, i uderzyć tylko w nią. Zwykle jest to jeden, najwyżej dwa komponenty, a nie system.

Po drodze czyha jeszcze pułapka niezwiązana z techniką. „Zainwestowaliśmy w ten kod za dużo, żeby go wyrzucić" to błąd utopionych kosztów w czystej postaci. Wyrzucić czasem trzeba, ale decyzja ma wynikać z tego, co ten kod blokuje, a nie z tego, ile w niego włożyłeś.

Stała rata zamiast jednorazowej spłaty

Rozwiązanie, które działa u zespołów wychodzących z tej pułapki, jest nudne. Netguru opisuje praktykę przeznaczania kilkunastu do dwudziestu procent pojemności każdego sprintu na spłatę długu — nie w wielkich zrywach, tylko stałym strumieniem drobnych porządków.

Logika tej proporcji jest arytmetyczna, a nie magiczna. Przy zbyt małej racie dług narasta szybciej, niż go spłacasz, więc problem tylko się odsuwa. Przy zbyt dużej przestajesz rozwijać produkt i klient zaczyna szukać gdzie indziej. Szukasz punktu, w którym spłacasz nieco więcej, niż zaciągasz w tym samym czasie.

Wdrożenie sprowadza się do trzech rzeczy, z których żadna nie wymaga nowego narzędzia. Backlog dostaje osobny tor techniczny, żeby te zadania w ogóle miały gdzie istnieć. Priorytet w tym torze ustalasz według jednego kryterium: co blokuje najwięcej rzeczy, które chcesz zbudować w najbliższym kwartale. I ta rata jest nienegocjowalna, bo pierwszy raz, kiedy ją przesuniesz „tylko w tym sprincie", zamienia ją w postulat.

To ta sama logika, którą opisywałem przy okazji tego, jak uciec od wiecznie rozwijającego się projektu. Wielkie zrywy umierają, bo wymagają zgody w każdej iteracji, a rata wpisana w kalendarz nie wymaga jej ani razu.

Zapisz datę przejścia, zanim ona minie

Skoro cały koszt bierze się z przegapienia momentu, to najtańsza rzecz, jaką możesz zrobić, jest oczywista: ustalić ten moment z góry, kiedy jeszcze nie nadszedł.

Nie chodzi o datę w kalendarzu, tylko o zdarzenie, które da się zaobserwować. Pierwszy klient spoza kręgu znajomych, który zapłacił pełną stawkę. Pierwsze pytanie o integrację z cudzym systemem albo pierwsza umowa, w której pada słowo „dostępność". Wybierz jedno i zapisz je tam, gdzie zespół to zobaczy.

Zapisz też, co się wtedy zmienia, bo bez tego zdarzenie minie niezauważone. Że od tego dnia wchodzi do sprintu stała rata na dług. Że lista skrótów z fazy eksperymentu przestaje być notatką, a staje się pozycjami w backlogu z priorytetem. Że decyzje architektoniczne przestają być odwracalne za darmo.

To jest cała różnica między zespołem, który przechodzi z eksperymentu do produktu, a zespołem, który się o to przejście potyka. Pierwszy podjął decyzję świadomie i w terminie. Drugi odkrył ją pół roku później, licząc, dlaczego wszystko trwa trzy razy dłużej.

Datę tego przejścia wyznacza się raz i zapisuje w miejscu, do którego zespół zagląda — nie w głowie założyciela. Jeśli nie potrafisz jej dziś wskazać, to jest pierwsza rzecz do ustalenia, zanim dopiszesz kolejną funkcję.