Przejęcie projektu po innym software housie — checklista przekazania

Przekazanie projektu kończy się nie na kodzie

Zmieniacie wykonawcę. Umowa wypowiedziana, termin przekazania ustalony, dostęp do repozytorium obiecany. Wszystko wygląda na dopięte — do momentu, w którym nowy zespół próbuje wypuścić pierwszą poprawkę i okazuje się, że nie da się jej podpisać, bo certyfikat leży na koncie, do którego nikt nie ma hasła.

To nie jest scenariusz hipotetyczny. W praktyce kod jest najłatwiejszą częścią przekazania. Blokują rzeczy okołotechniczne: konta, klucze, prawa autorskie, domeny, dostęp do usług, o których nikt nie pamiętał, dopóki nie przestały działać. Każda z nich osobno wygląda na drobiazg. Razem potrafią zatrzymać wydania na kilka tygodni — a w skrajnych przypadkach zmusić do przepisania aplikacji od zera.

Poniżej checklista, którą przechodzimy przy każdym przejmowanym projekcie. Warto ją przerobić zanim podpiszecie protokół odbioru, bo po jego podpisaniu motywacja drugiej strony do pomagania spada gwałtownie.

1. Prawa do kodu — sprawdź, zanim sprawdzisz cokolwiek innego

Najbardziej kosztowny błąd w tej kategorii to założenie, że skoro zapłaciliście za oprogramowanie, to jest ono Wasze. W polskim prawie autorskim tak to nie działa: zapłata za usługę nie przenosi automatycznie autorskich praw majątkowych. Przeniesienie wymaga formy pisemnej i wskazania pól eksploatacji.

Co sprawdzić:

• Czy umowa przenosi prawa majątkowe, czy udziela licencji. Licencja może być ograniczona czasowo albo terytorialnie i może nie obejmować prawa do modyfikacji — czyli dokładnie tego, czego potrzebujecie.
• Czy obejmuje prawa zależne, czyli prawo do wykonywania i korzystania z opracowań. Bez tego formalnie nie możecie legalnie rozwijać kodu.
• Czy wykonawca miał prawa, które przenosi. Jeśli część pracy wykonali podwykonawcy lub kontraktorzy B2B, potrzebna była analogiczna umowa w tamtą stronę. To najczęstsza luka w łańcuchu.
• Licencje otwartego oprogramowania w zależnościach. Biblioteka na licencji copyleft w produkcie zamkniętym potrafi być problemem prawnym, o którym dowiecie się w najgorszym możliwym momencie — przy due diligence. Poproście o wykaz zależności z licencjami.
• Prawa do materiałów, których nie napisał programista — grafiki, ikony, czcionki, zdjęcia. Licencja na font w aplikacji mobilnej bywa wystawiona na wykonawcę, nie na Was.

To jedyny punkt na tej liście, którego nie da się naprawić technicznie po fakcie. Reszta to kwestia czasu i cierpliwości.

2. Kod i historia

• Pełne repozytorium z historią Gita, nie archiwum ZIP z ostatnią wersją. Historia to zapis powodów: dlaczego dany warunek tam jest, co naprawiał dany commit. Bez niej każda dziwna linijka jest zagadką.
• Wszystkie gałęzie i tagi wydań, w tym te odpowiadające wersjom w sklepach.
• Repozytoria poboczne — panel administracyjny, biblioteki współdzielone, skrypty migracyjne, konfiguracja infrastruktury. Bardzo często leżą osobno i wypadają z przekazania.
• Weryfikacja, że projekt się buduje na czystej maszynie. To jedyny wiarygodny test kompletności. Jeśli build wymaga pliku, którego nie ma w repozytorium, właśnie znaleźliście brakujący element.
• Dokumentacja, jeśli istnieje — a jeśli nie, przynajmniej instrukcja uruchomienia środowiska.

Czerwona flaga: „wyślemy paczkę z kodem". Paczka bez historii oznacza, że albo ktoś ma coś do ukrycia, albo repozytorium było prowadzone w sposób, którego nie chce pokazywać.

3. Konta i dostępy — najczęstsze źródło blokad

To lista, którą warto przejść pozycja po pozycji, sprawdzając nie „czy mamy dostęp", tylko „czy jesteśmy właścicielem". Dostęp da się odebrać; własność nie.

Sklepy z aplikacjami:

• Konto Apple Developer — kluczowe pytanie brzmi: kto jest Account Holder. Tylko ta rola może przenieść własność i zarządzać kluczowymi ustawieniami. Konto powinno być zarejestrowane na Waszą firmę, nie na wykonawcę.
• Konto Google Play Console — analogicznie, właściciel konta i uprawnienia administracyjne.
• Certyfikaty podpisujące i klucze. W Androidzie utrata klucza podpisującego oznaczała kiedyś brak możliwości wydania aktualizacji istniejącej aplikacji; dziś ratuje sytuację Play App Signing, ale tylko jeśli był włączony. W iOS certyfikaty można odtworzyć, o ile macie dostęp do konta.
• Klucz APNs lub konfiguracja Firebase do powiadomień push, konta testowe, dane do weryfikacji w sklepach.

Infrastruktura:

• Konto chmurowe wraz z właścicielem rozliczeń. Projekt na koncie wykonawcy to bomba zegarowa — wystarczy nieopłacona faktura po zakończeniu współpracy.
• Domeny: rejestrator, konto właścicielskie, dostęp do DNS. Sprawdźcie też datę wygaśnięcia.
• Certyfikaty TLS i sposób ich odnawiania.
• Bazy danych, magazyny plików, kolejki, cache.

Narzędzia:

• Repozytorium kodu i organizacja, w której się znajduje.
• CI/CD wraz ze zmiennymi środowiskowymi i sekretami.
• Monitoring i zbieranie błędów, analityka, narzędzia produktowe.
• Usługi zewnętrzne: bramka płatnicza, wysyłka maili i SMS-ów, mapy, integracje z systemami klienta.
• Konta pocztowe i aliasy powiązane z powyższymi — bo reset hasła pójdzie właśnie tam.

Praktyczna rada: zróbcie z tego arkusz z kolumnami „usługa / właściciel konta / kto ma dostęp / na jaki mail / status przeniesienia". Bez arkusza gwarantowanie czegoś zostanie pominięte.

4. Sekrety — załóżcie, że wyciekły

Wraz z projektem przejmujecie wszystkie klucze, które znał poprzedni zespół. Nawet przy najlepszych intencjach obu stron jedyną poprawną reakcją jest rotacja wszystkiego: kluczy API, haseł do baz, tokenów integracji, kluczy podpisujących tam, gdzie to możliwe.

Przy okazji warto przeskanować historię repozytorium pod kątem sekretów wrzuconych do kodu. Rzecz, którą wiele zespołów odkrywa za późno: usunięcie sekretu kolejnym commitem go nie usuwa — zostaje w historii i jest dostępny dla każdego, kto ma dostęp do repozytorium. Ten problem szczególnie urósł w projektach rozwijanych z pomocą asystentów AI, o czym pisaliśmy w tekście o kodzie pisanym przez AI w produkcji.

Rotację warto zaplanować jako jedną skoordynowaną operację, a nie rozłożyć na tygodnie — inaczej połowa zostanie zapomniana.

5. Dane, backupy i zgodność

• Gdzie fizycznie leżą dane produkcyjne i kto ma do nich dostęp.
• Czy backup był kiedykolwiek odtwarzany. Istnienie backupu to nie to samo co możliwość odtworzenia; sprawdza się to tylko jednym sposobem — próbą.
• Umowy powierzenia przetwarzania danych osobowych. Po zmianie wykonawcy potrzebna jest nowa umowa z nowym podmiotem i zakończenie starej, wraz z usunięciem danych po stronie poprzedniego zespołu.
• Rejestr podprocesorów — dostawcy chmury, analityki, wysyłki maili. Zmiana wykonawcy bywa okazją, żeby ten rejestr w ogóle powstał.

6. Wiedza — najkrótsze okno w całym procesie

Ludzie, którzy budowali system, przestaną odbierać telefon szybciej, niż zakładacie. Zaplanujcie to, dopóki jeszcze współpracują:

• Sesje przekazania z nagraniem. Dwie do czterech rozmów po 60–90 minut: architektura i decyzje, procedura wydania, obsługa awarii i znane pułapki. Nagranie jest ważniejsze od notatek, bo padają w nich rzeczy, których nikt nie zapisze.
• Przejście krytycznych ścieżek na żywo — jak przebiega płatność, rejestracja, synchronizacja. Prześledzone w kodzie razem z autorem, nie z dokumentacji.
• Lista znanych problemów. Warto zapytać wprost: „czego byście nie ruszali i dlaczego". Odpowiedź na to pytanie bywa najcenniejszym elementem całego przekazania.
• Okno wsparcia po zakończeniu — dwa do czterech tygodni możliwości zadawania pytań, zapisane w umowie. Bez zapisu w umowie to dobra wola, która kończy się w dniu ostatniej faktury.
• Pierwsze wydanie zróbcie jeszcze w trakcie okna wsparcia. Nawet drobną poprawkę. To jedyny sposób, żeby sprawdzić, czy cały łańcuch — build, podpis, wydanie — faktycznie działa po Waszej stronie.

Pierwszy miesiąc po przejęciu

Kiedy dostępy są już Wasze, warto uporządkować obraz sytuacji, zanim zaczniecie planować rozwój:

1. Zbuduj i wydaj — potwierdzenie, że łańcuch wydawniczy działa bez poprzedniego zespołu.
2. Zinwentaryzuj stan — wersje frameworków, podatności w zależnościach, pokrycie testami krytycznych ścieżek, stan monitoringu.
3. Zrób audyt wejściowy. Nie po to, żeby wystawić ocenę poprzednikom, tylko żeby mieć priorytety i punkt odniesienia. Co konkretnie sprawdzamy na tym etapie, opisaliśmy w tekście o audycie kodu źródłowego.
4. Rozstrzygnij pytanie o kierunek — rozwijać stopniowo czy przebudować. Kryteria tej decyzji zebraliśmy w tekście refactor czy przepisać od zera, a to, co z zastanego stanu warto zostawić, opisuje tekst o długu technicznym.

Czerwone flagi w trakcie przekazania

Sygnały, przy których warto zwolnić i domknąć formalności przed podpisaniem odbioru:

• Kod przekazywany bez historii albo z historią „spłaszczoną" do jednego commita.
• Konta w sklepach zarejestrowane na wykonawcę z odmową przeniesienia własności.
• Brak możliwości zbudowania projektu bez pomocy poprzedniego zespołu.
• Produkcja stojąca na koncie chmurowym wykonawcy.
• Dokumentacja tworzona dopiero w trakcie przekazania — zwykle znaczy, że nie odzwierciedla rzeczywistości.
• Odmowa nagrywania sesji przekazania.

Żadna z tych rzeczy nie musi oznaczać złej woli. Częściej oznacza projekt prowadzony bez myśli o tym, że kiedyś zmieni właściciela. Ale każda z nich kosztuje Was czas, więc lepiej wychwycić je w tygodniu przekazania niż w kwartale po nim.

Podsumowanie

Przy zmianie wykonawcy uwaga naturalnie skupia się na kodzie, a blokady prawie zawsze przychodzą z innej strony: z praw autorskich, własności kont i kluczy, których nikt nie zinwentaryzował. Trzy rzeczy warto załatwić przed podpisaniem protokołu odbioru — potwierdzone przeniesienie praw majątkowych wraz z prawami zależnymi, własność wszystkich kont po Waszej stronie i wydanie zrobione własnymi rękami jeszcze w oknie wsparcia.

W Mobilesoft przejmowaliśmy projekty w bardzo różnym stanie — od uporządkowanych po takie, w których pierwszym zadaniem było odtworzenie możliwości zbudowania aplikacji. Jeśli stoicie przed zmianą wykonawcy i chcecie, żeby ktoś przeszedł przez tę listę razem z Wami, robimy to w ramach audytów i konsultacji, a dalej — jako utrzymanie aplikacji lub wsparcie zespołu IT. Zajrzyjcie też do naszych realizacji, napiszcie do nas albo od razu wyceńcie projekt.