Jak przejąć aplikację po innym software house?

Co przekazać nowemu zespołowi?

Repozytorium jest punktem wyjścia, ale samo nie wystarcza do utrzymania aplikacji. Potrzebny jest także opis sposobu jej uruchomienia i zależności od zewnętrznych usług. Lista braków pomaga ustalić zakres pierwszych prac, zamiast odkrywać je dopiero przy awarii.

• Kod i historia zmian: repozytoria wszystkich części aplikacji, informacja o wersji produkcyjnej oraz komponentach, których kod znajduje się gdzie indziej.
• Uruchamianie i wdrożenia: wymagane wersje środowiska, konfiguracja bez sekretów, proces budowania, migracje bazy i sposób publikacji.
• Dostępy i właściciele kont: hosting, domena, baza danych, usługi pocztowe, integracje i monitoring. Ustal, które konta należą do firmy, a które do dotychczasowego wykonawcy.
• Dane i odtwarzanie: struktura bazy, zanonimizowane dane testowe, kopie zapasowe i instrukcja ich przywracania.
• Wiedza o produkcie: kluczowe procesy, role użytkowników, otwarte błędy, niedokończone zadania i ograniczenia licencyjne.

Nie wysyłaj haseł ani pełnej bazy klientów w pierwszej wiadomości. Nowemu zespołowi udostępniaj osobne konta z uprawnieniami odpowiednimi do uzgodnionego zakresu. Przekazanie sekretów i danych wymaga ustalonego, bezpiecznego kanału.

Co sprawdzić przed przejęciem?

Najważniejszy sprawdzian: czy nowy zespół potrafi uruchomić aplikację i opublikować kontrolowaną zmianę poza produkcją? To pozwala znaleźć brakujące ustawienia, niedostępne zależności i kroki wdrożenia znane dotąd tylko jednej osobie.

Przegląd powinien objąć najważniejsze ścieżki użytkownika, połączenia z innymi systemami oraz sposób wykrywania awarii. Warto sprawdzić odtworzenie kopii w izolowanym środowisku i możliwość wycofania wdrożenia. Sam fakt istnienia pliku z kopią nie potwierdza, że system można z niego odtworzyć.

Gdy stan aplikacji jest niejasny, audyt kodu, architektury i infrastruktury pomaga oddzielić ryzyka pilne od usprawnień, które można zaplanować później. Zakres badania dobiera się do decyzji, którą ma umożliwić.

Jak ustalić odpowiedzialność?

W okresie przejściowym trzeba jasno wskazać, kto publikuje zmiany, reaguje na awarie i zatwierdza operacje na danych. Jeśli oba zespoły pracują równolegle, potrzebują wspólnych zasad, aby nie nadpisywać sobie zmian.

Uzgodnij termin przejęcia utrzymania, listę znanych problemów oraz właściciela każdego brakującego elementu. Po przekazaniu uporządkuj dostęp byłych wykonawców i zmień współdzielone sekrety w sposób, który nie przerwie działania integracji. Przejęcie kodu nie jest automatycznym potwierdzeniem, że wszystkie wcześniejsze błędy zostały usunięte.

Jak wybrać pierwszy etap?

Dobrym pierwszym rezultatem jest uruchomione środowisko testowe, lista ryzyk i plan najbliższych zmian. Następnie można wybrać niewielkie zadanie, które pozwoli sprawdzić współpracę, testowanie i wdrożenie w praktyce.

Przykładowo: zamiast od razu wymieniać cały moduł sprzedaży, zespół najpierw odtwarza jego działanie i poprawia jeden jasno opisany problem. To scenariusz do dopasowania, nie obowiązkowy etap każdego przejęcia.

W Codefellow możemy zacząć od przeglądu, a następnie przejść do rozwoju i utrzymania istniejącej aplikacji. Jeśli masz własny zespół prowadzący produkt, możliwe jest również wsparcie specjalisty w Twoim projekcie. Najpierw ustalamy potrzebę i dostępność.