Audyt techniczny MVP: co sprawdzamy w pierwszych 48 godzinach

Większość audytów MVP kończy się dokumentem. Użyteczny kończy się decyzjami: co się pali, co może poczekać i ile kosztuje naprawa.

Audyt techniczny MVP odpowiada na jedno pytanie: czy ta baza kodu udźwignie kolejne dwanaście miesięcy biznesu, a jeśli nie — co dokładnie musi się zmienić? Cała reszta — preferencje narzędziowe, spory o styl, wybór frameworka — to szum.

Oto checklista, którą przechodzimy w pierwszych 48 godzinach. Jest celowo uporządkowana według kosztu błędu: to na górze potrafi zabić firmę, to na dole kosztuje tempo.

1. Integralność pieniędzy i danych (najwyższy koszt awarii)

Jeśli produkt przesuwa pieniądze albo przechowuje dane regulowane, to idzie pierwsze. Błędy tutaj to nie incydenty — to zobowiązania. Szukamy:

• Czy salda są wyprowadzane z księgi tylko-do-dopisywania, czy trzymane jako zmienialna liczba, którą kod może nadpisać
• Idempotencji na każdej ścieżce płatności i webhooka — czy ponowiony request może obciążyć lub uznać dwa razy?
• Używaj dokładnych liczb dziesiętnych lub całkowitych jednostek z regułami walut.
• Granic transakcyjnych: czy częściowa awaria może zostawić pieniądze zdublowane albo nigdzie
• Rekoncyliacji: czy istnieje proces, który wykryje rozbieżność, czy dowiecie się od klienta?

2. Bezpieczeństwo i kontrola dostępu

• Autoryzacja sprawdzana po stronie serwera przy każdym żądaniu, czy zakładana, bo interfejs ukrywa przycisk
• Sekrety w zmiennych środowiskowych i menedżerze sekretów, nie w historii repozytorium
• PII i dane kart: co jest przechowywane, gdzie i czy w ogóle powinno być
• Realnie osiągalne podatności zależności, nie tylko czerwona liczba w raporcie
• Izolacja multi-tenant: czy spreparowane żądanie odczyta dane innego klienta?

3. Architektura i limity skalowania

Nie szukamy elegancji. Szukamy konkretnej ściany, w którą uderzy system, i jak daleko ona jest.

• Pojedyncze punkty awarii — baza, kolejka, serwis, do którego dzwonią wszyscy
• Wzorce zapytań poprawne przy 1 000 wierszy i zabójcze przy 1 000 000 (N+1, brakujące indeksy, nieograniczone skany)
• Czy da się wdrożyć bez przestoju i czy ktokolwiek kiedykolwiek próbował
• Sprzężenie, które uniemożliwia dowiezienie funkcji bez ruszania pięciu modułów
• Czy architektura pasuje do wielkości zespołu — mikroserwisy przy czterech inżynierach to problem skalowania, nie rozwiązanie

4. Dostarczanie i operacje

Bazy kodu nie psują się same; to proces decyduje, jak szybko. Co mierzymy:

5. Dług techniczny: posegregowany, nie wylistowany

Każda baza kodu ma dług. Jego lista jest bezużyteczna. Liczy się podział na trzy kubełki:

1. Blokujący — uniemożliwia roadmapę albo naraża pieniądze/dane. Naprawić teraz.
2. Kumulujący się — spowalnia każdą przyszłą zmianę. Zaplanować świadomie.
3. Kosmetyczny — razi gust, nic nie kosztuje. Zostawić w spokoju.

Celem audytu nie jest znalezienie wszystkiego, co złe. Celem jest znalezienie tych kilku rzeczy na tyle złych, że mają znaczenie, i precyzyjne określenie, ile kosztują.

Co powinniście dostać na końcu

• Priorytetyzowaną listę ustaleń z wagą i wpływem biznesowym — nie katalog
• Do każdego ustalenia: naprawę, realistyczną wycenę pracy i co się stanie, jeśli nic nie zrobicie
• Sekwencjonowaną roadmapę: ten kwartał, następny, później
• Dowody — zapytanie, endpoint, konkretną linię — żeby wasz zespół mógł zweryfikować, a nie uwierzyć

Zamień pierwszy przegląd w sprawdzalny backlog

Ograniczony czasowo przegląd pokazuje pokrycie, a nie brak wszystkich błędów. Każde ustalenie musi być weryfikowalne.

1. Połącz dotkniętą ścieżkę, dowody i warunki odtworzenia.
2. Oddziel zaobserwowane błędy, możliwe ryzyka i niedostępne obszary.
3. Przydziel właściciela poprawki i test regresji.

• ratowanie MVP →
• jak naprawić MVP →