Jak naprawić zepsute MVP (bez pisania od nowa)

Niemal każdy założyciel z zepsutym MVP pyta, czy je przepisać. Niemal zawsze odpowiedź brzmi nie — a powodem jest arytmetyka, nie sentyment.

Zepsute MVP objawia się zwykle na jeden z trzech sposobów: przewraca się pod realnym ruchem, każda zmiana psuje coś innego albo pierwotni programiści odeszli i nikt tego nie rozumie. Instynkt każe zacząć od nowa. Ten instynkt jest kosztowny i zwykle błędny.

Dlaczego przepisanie to pułapka

Przepisanie kusi, bo nowy system jest wyobrażony, a wyobrażone systemy nie mają błędów. W rzeczywistości:

• Istniejący kod koduje lata przypadków brzegowych, których nikt nie udokumentował — zostaną odkryte na nowo jako incydenty produkcyjne
• Zamrażasz rozwój funkcji na miesiące, a konkurencja nie
• Przepisanie trafia na tę samą złożoność, bo złożoność jest w domenie, a nie w kodzie
• Szacunki przepisań są mocno błędne, konsekwentnie, w każdej organizacji

Krok 1: zatamuj krwawienie

Zanim cokolwiek poprawisz, uczyń system obserwowalnym i odwracalnym. Nie naprawisz tego, czego nie widzisz, i nie poeksperymentujesz bez drogi powrotnej.

1. Śledzenie błędów, żeby awarie były znane, a nie zgłaszane przez klientów
2. Monitoring dostępności i kluczowych transakcji — płatność, rejestracja, zakup
3. Rollback, który działa i został przetestowany
4. Kopie zapasowe i odtworzenie, które faktycznie raz przeprowadzono

Krok 2: triaż, a nie inwentaryzacja

Oprzyj się pokusie wypisania wszystkiego, co nie działa. Posortuj problemy według konsekwencji:

Większość projektów ratunkowych znajduje dwie albo trzy pozycje w pierwszym kubełku i garść w drugim. To wykonalny program pracy — zupełnie inny niż przytłaczające wrażenie, które zespół miał przed uporządkowaniem.

Krok 3: naprawiaj w kolejności, która się kumuluje

1. Najpierw integralność danych — uszkodzone albo utracone dane są nieodwracalne w sposób, w jaki przestój nie jest
2. Potem ścieżka wdrożeniowa — dopóki wydawanie nie jest bezpieczne i częste, każda inna poprawka jedzie wolno i ryzykownie
3. Potem główne źródło awarii — zwykle jeden albo dwa endpointy czy zapytania powodują większość incydentów
4. Potem blokada zmian — sprzężenie albo brak testów, przez które zespół boi się czegokolwiek dotknąć
5. Dopiero potem wydajność i szlif

Krok 4: zapobiegnij nawrotowi

• Testy na ścieżkach, które bolą — pieniądze, autoryzacja i dokładnie to, co się zepsuło
• Spisany dziennik decyzji, żeby kolejny inżynier dziedziczył rozumowanie, a nie sam kod
• Proces wdrożeniowy, który potrafi uruchomić każdy w zespole
• Wyraźna zasada, że roadmapa zawiera moc przerobową na utrzymanie — inaczej dług wraca

Ratowanie to nie sprzątanie. To niewielka liczba celowanych zmian, które przenoszą system z niebezpiecznego w nudny — a nudny to stan, w którym zespół znów dowozi.

Ustal granicę naprawy przed przepisaniem

Pokaż, że jedną wadliwą ścieżkę da się ustabilizować. Użyj wyniku do wyceny następnego etapu i porównania wymiany.

1. Napisz test regresji odtwarzający zaobserwowaną usterkę.
2. Napraw ograniczony obszar i sprawdź sąsiednie zachowania.
3. Porównaj naprawę i wymianę z migracją oraz pracą równoległą.

• ratowanie MVP →
• audyt techniczny MVP →