W skrócie
- Najpierw zabezpiecz dostęp: kod, serwery, domeny, bazy danych, konta w sklepach i usługach.
- Przegląd kodu i architektury pokazuje ryzyka, zanim nowy zespół zacznie zmieniać system.
- Przejmuj stopniowo: najpierw utrzymanie i drobne poprawki, potem nowe funkcje.
- Brak dokumentacji to częsta sytuacja - odtwarza się ją w trakcie przejęcia.
- Nie zaczynaj od przepisania wszystkiego od zera - to rzadko jest najtańsza droga.
Krok 1: zabezpiecz dostępy
Zanim cokolwiek zmienisz, upewnij się, że masz:
- kod źródłowy w aktualnej wersji, która działa na produkcji, razem z historią zmian,
- dostęp administracyjny do serwerów, baz danych i kopii zapasowych,
- domeny i certyfikaty,
- konta w sklepach z aplikacjami i usługach zewnętrznych (płatności, e-mail, SMS, mapy),
- hasła i klucze przekazane w bezpieczny sposób, a potem zmienione.
Krok 2: przegląd kodu i architektury
Nowy zespół powinien najpierw zrozumieć, co przejmuje: jak zbudowany jest system, w jakim stanie jest kod, jakie są zależności i ich wersje, czy są testy i jak wygląda wdrażanie. Wynikiem przeglądu jest lista ryzyk i plan, co poprawić najpierw.
Krok 3: przejmuj stopniowo
- Utrzymanie: nowy zespół uczy się systemu na zgłoszeniach i drobnych poprawkach.
- Porządki: aktualizacje zależności, automatyczne wdrażanie, podstawowe testy w najbardziej ryzykownych miejscach.
- Rozwój: nowe funkcje, gdy zespół zna już system i ma zabezpieczenia przed regresjami.
Produkt działa przez cały czas - użytkownicy nie powinni odczuć zmiany wykonawcy inaczej niż przez szybsze odpowiedzi.
Przepisać od zera czy rozwijać?
Przepisanie systemu od zera kusi, gdy kod jest w złym stanie, ale rzadko jest najtańszą drogą: trzeba odtworzyć wszystkie reguły i wyjątki, które przez lata trafiły do systemu, a w tym czasie stary system dalej wymaga utrzymania. Zwykle lepiej wymieniać fragmenty stopniowo, zaczynając od najbardziej problematycznych.
Jak uniknąć tej sytuacji w przyszłości
Repozytorium na koncie firmy, dostępy administracyjne po Twojej stronie, prawa autorskie uregulowane w umowie i dokumentacja aktualizowana w trakcie projektu. Wtedy zmiana wykonawcy jest kwestią organizacji, a nie ratowania systemu.