Audyt kodu przed przejęciem projektu

Problem prawie nigdy nie polega na tym, że zastany kod jest brzydki. Polega na tym, że koszt jego utrzymania jest nieznany w momencie podejmowania decyzji. Ktoś obiecuje „dopiszemy tę funkcję w dwa tygodnie”, a po przejęciu okazuje się, że najpierw trzeba odtworzyć środowisko, o którym nikt nie zostawił notatki.

Druga typowa przyczyna to zniknięcie wiedzy. Kod da się odczytać, ale nie da się odczytać powodów, dla których wygląda tak, a nie inaczej. Jeśli poprzedni zespół odchodzi bez okresu przekazania, tracisz kontekst, którego nie odbudujesz z repozytorium.

Trzecia to dostępy. Kod bywa najprostszą częścią do przekazania - gorzej z domeną zarejestrowaną na prywatne konto, produkcyjną bazą, do której hasło zna jedna osoba, i kluczami do usług zewnętrznych rozproszonymi po prywatnych skrzynkach.

Sam kod to najmniej zaskakująca część. Więcej mówi historia i to, czego w repozytorium nie ma:

• Czy historia commitów jest ciągła, czy zaczyna się od jednego commitu „initial import” - brak historii oznacza brak możliwości sprawdzenia, jak system się zmieniał i kto co decydował.
• Czy w repozytorium są sekrety: hasła, klucze API, connection stringi. Jeśli są, trzeba je wymienić w dniu przejęcia, a to jest praca, którą warto wycenić z góry.
• Czy da się uruchomić projekt lokalnie wyłącznie na podstawie tego, co jest w repo. Jeśli potrzebna jest wiedza plemienna, właśnie znalazłeś swój pierwszy koszt ukryty.
• Czy istnieją testy i czy przechodzą na czystym klonie. Testy, które „u nas działały”, w praktyce nie istnieją.
• Czy zależności są aktualne. Framework po końcu wsparcia to nie jest kosmetyka - to zaplanowana migracja, którą przejmujesz razem z projektem.

Ta lista bywa ważniejsza od jakości kodu, bo brak jednego elementu potrafi zablokować wdrożenie na tygodnie. Przed podpisaniem trzeba mieć potwierdzone na piśmie, kto jest właścicielem i kto ma dostęp administracyjny do: domeny, DNS, hostingu i chmury, bazy produkcyjnej, poczty, repozytorium, systemu CI/CD, bramki płatności, kont analitycznych i wszystkich usług zewnętrznych, z których korzysta system.

Osobno sprawdź licencje. Płatne biblioteki, motywy, wtyczki i fonty bywają kupione na konto wykonawcy i nie przechodzą na klienta automatycznie. To samo dotyczy praw autorskich do samego kodu - jeśli w umowie z poprzednim wykonawcą nie ma przeniesienia majątkowych praw autorskich, kupujesz coś, czego formalnie nie możesz rozwijać.

Żadna z tych rzeczy nie przekreśla projektu samodzielnie. Trzy naraz oznaczają, że wycena przejęcia jest znacząco zaniżona:

• Wdrożenie na produkcję odbywa się ręcznie i wykonuje je zawsze ta sama osoba.
• Nie istnieje środowisko testowe - zmiany sprawdza się na produkcji.
• Nie ma kopii zapasowych albo nikt nigdy nie sprawdził, czy da się je odtworzyć.
• Jedna osoba jest jedynym źródłem wiedzy o systemie i tej osoby nie ma w zakresie przekazania.
• Poprzedni wykonawca odmawia dostępu read-only do repozytorium przed podpisaniem umowy.
• Dokumentacja składa się z prezentacji sprzedażowej i pliku README z domyślną treścią frameworka.
• W systemie działają usługi, za które nikt nie potrafi wskazać faktury ani właściciela konta.

Cena przejęcia to nie jest kwota na fakturze od poprzedniego wykonawcy. To suma czterech pozycji: kosztu doprowadzenia systemu do stanu, w którym da się bezpiecznie wdrażać; kosztu spłaty tego długu technicznego, który blokuje najbliższe plany produktowe; kosztu odbudowy wiedzy, której nie przekazano; oraz ryzyka, czyli tego, co się stanie, jeśli w trakcie okaże się, że któregoś elementu po prostu nie ma.

Dobry audyt przed przejęciem wycenia trzy pierwsze pozycje z rozsądnym przybliżeniem, a czwartą nazywa po imieniu. To wystarczy, żeby usiąść do negocjacji z konkretną liczbą zamiast z przeczuciem.

Potrzebuję dostępu read-only do repozytorium, listy usług, z których korzysta system, i pół godziny rozmowy z kimkolwiek, kto zna kontekst. Jeśli po drugiej stronie nie ma zgody nawet na to, jest to już wynik audytu.

Standardowo zajmuje to kilka dni. Na koniec dostajesz dokument z oceną stanu, listą braków w dostępach i własności, wyceną doprowadzenia projektu do stanu używalnego i jednoznaczną rekomendacją: brać, brać po renegocjacji ceny albo odpuścić.

Ten dokument jest napisany tak, żeby dało się go położyć na stole podczas negocjacji - również przed osobami nietechnicznymi.