Przejęcie aplikacji po poprzednim wykonawcy prawie nigdy nie jest „czystym startem”. Najczęściej dostajesz kod bez kontekstu, środowisko z brakami, napięty termin i oczekiwanie, że „ma działać od jutra”. Da się to zrobić bez chaosu — pod warunkiem, że pierwsze 2–3 tygodnie potraktujesz jak kontrolowany proces: stabilizacja, diagnoza ryzyk i szybkie wygrane, które od razu poprawiają jakość działania produktu.
W tym artykule dostajesz praktyczną checklistę przejęcia aplikacji: co sprawdzić najpierw, czego nie ruszać na ślepo, jak ustawić komunikację i jak zaplanować utrzymanie po handoverze.
Dlaczego przejęcia projektów się wykolejają
Najczęstszy błąd: nowy zespół próbuje od razu „naprawić wszystko”. Efekt? Wysokie ryzyko regresji, przepalony czas i konflikt priorytetów. Drugi typowy problem to brak rozróżnienia między:
- krytyczną stabilizacją (co musi działać dziś),
- długiem technicznym (co boli, ale nie pali się),
- rozwojem funkcji (co daje wartość biznesową).
Jeżeli te trzy koszyki mieszają się w jednym backlogu bez priorytetów, projekt zaczyna żyć pożarami.
Faza 0: przygotowanie przejęcia (przed pierwszym deployem)
1) Dostępy i własność
- Repozytoria kodu (owner, branch protections, secrets, deploy keys).
- Cloud/hosting (AWS/GCP/Azure), DNS, CDN, certyfikaty, SMTP.
- Bazy danych, storage, kolejki, monitoring, analytics, płatności.
- Konta sklepów mobilnych (App Store / Google Play), jeśli dotyczy.
- Narzędzia biznesowe: CRM, mailing, webhooki, integracje zewnętrzne.
Bez pełnej listy właścicieli i uprawnień nie da się bezpiecznie robić utrzymania aplikacji.
2) Artefakty techniczne
- README + runbook + instrukcja lokalnego uruchomienia.
- Schemat architektury (nawet uproszczony).
- Lista środowisk i różnic między nimi.
- Pipeline CI/CD i zasady release.
- Plan backupów oraz test odtworzenia.
Brak dokumentacji nie blokuje przejęcia, ale musi zostać wpisany jako ryzyko wysokie od pierwszego dnia.
3) Definicja „stabilnie działa”
Ustal z biznesem 5–10 metryk, które definiują sukces pierwszej fazy, np.:
- czas odpowiedzi API P95,
- crash-free sessions,
- liczba błędów krytycznych tygodniowo,
- SLA reakcji na incydent,
- czas deployu i czas rollbacku.
Faza 1: pierwsze 72h — stabilizacja bez heroizmu
W pierwszych dniach celem nie jest „idealny kod”. Celem jest przewidywalność i bezpieczeństwo zmian.
Checklist 72h
- Uruchom monitoring błędów (backend + frontend + mobile).
- Włącz alerty dla kluczowych endpointów i zadań cyklicznych.
- Potwierdź, że backupy faktycznie działają.
- Zrób kontrolowany deploy testowy na małej zmianie.
- Przećwicz rollback i opisz go krok po kroku.
- Włącz feature freeze na nowe duże funkcje (czasowo).
Jeśli nie potrafisz bezpiecznie wdrożyć i cofnąć zmiany, projekt nie jest gotowy na rozwój.
Faza 2: techniczny audit przejęcia (1–2 tygodnie)
To moment, w którym zbierasz fakty i zamieniasz je w plan. Audit powinien kończyć się mapą ryzyk oraz listą działań z estymacją.
Obszary audytu
- Architektura — monolit/moduły, granice odpowiedzialności, coupling.
- Jakość kodu — powtarzalność, testowalność, standardy, code smells.
- Bezpieczeństwo — auth, role, sekrety, dependency vulnerabilities.
- Dane — migracje, indeksy, polityka retencji i RODO.
- DevOps — CI/CD, observability, koszty infrastruktury.
- Proces — jak decyzje trafiają do kodu i kto je akceptuje.
Skala ryzyka (prosta i skuteczna)
- R1 Krytyczne — ryzyko awarii, utraty danych, bezpieczeństwa.
- R2 Wysokie — duży wpływ na stabilność lub velocity.
- R3 Średnie — warto poprawić w normalnym cyklu.
- R4 Niskie — kosmetyka, porządki, komfort pracy.
Każde ryzyko powinno mieć: wpływ, prawdopodobieństwo, właściciela i proponowaną akcję.
Szybkie wygrane, które realnie poprawiają utrzymanie aplikacji
W przejęciach liczy się momentum. Potrzebujesz kilku zmian, które szybko obniżają ryzyko i budują zaufanie biznesu.
Top 10 quick wins
- Jedna komenda do uruchomienia projektu lokalnie.
- Automatyczne lint/test w PR.
- Template opisu incydentu i post-mortem.
- Healthcheck endpoint + dashboard statusu.
- Centralne logowanie błędów z kontekstem użytkownika.
- Ujednolicenie .env.example i opis zmiennych.
- Blokada force-push na głównej gałęzi.
- Minimalne testy kontraktowe dla krytycznych API.
- Rotacja sekretów i usunięcie „shared kont”.
- Runbook „co robić gdy płatności nie przechodzą”.
Plan 30/60/90 dni po przejęciu
0–30 dni: Stabilizacja
- Domknięcie dostępów i braków środowiskowych.
- Monitoring + alerting + procedury incydentowe.
- Naprawa R1 i część R2.
- Pierwszy raport stanu technicznego dla biznesu.
31–60 dni: Odzyskanie kontroli
- Refaktoryzacja najbardziej ryzykownych modułów.
- Porządek w pipeline release i testach regresji.
- Plan redukcji długu technicznego per sprint.
- Lepsza przewidywalność estymacji i wdrożeń.
61–90 dni: Skalowanie jakości
- SLO/SLA na poziomie produktu.
- Standardy architektoniczne i code review checklist.
- Automatyzacja powtarzalnych zadań operacyjnych.
- Roadmapa funkcji już na stabilnej bazie.
Komunikacja z biznesem: co raportować, żeby nie było zaskoczeń
W przejęciu produktu biznes nie oczekuje cudów. Oczekuje przejrzystości. Raz w tygodniu raportuj:
- co ustabilizowaliśmy,
- jakie ryzyka zostały i jaki mają priorytet,
- co robimy w następnym tygodniu,
- jaki jest wpływ na cele biznesowe (sprzedaż, obsługa, koszty).
Unikaj technicznego żargonu bez kontekstu. Decydenci potrzebują konsekwencji i decyzji, nie listy klas i bibliotek.
Najczęstsze pułapki przy przejęciu aplikacji
- Brak ownershipu — „wszyscy odpowiadają”, czyli nikt.
- Brak freeze’u — jednocześnie audyt i duży development.
- Niedoszacowanie legacy — „to tylko mała poprawka”.
- Brak testu disaster recovery — backup jest, odtworzenia brak.
- Shadow knowledge — wiedza tylko w głowie jednej osoby.
Checklista końcowa: gotowość operacyjna po handoverze
- [ ] Dostępy uporządkowane i audytowalne.
- [ ] Monitoring/alerty pokrywają krytyczne ścieżki.
- [ ] Procedura deploy + rollback przetestowana.
- [ ] Lista ryzyk R1/R2 ma właścicieli i terminy.
- [ ] Backlog podzielony: stabilizacja / dług / rozwój.
- [ ] Raport statusowy zrozumiały dla biznesu.
- [ ] Dokumentacja „jak utrzymywać ten system” istnieje.
Podsumowanie
Przejęcie aplikacji nie musi oznaczać miesięcy chaosu. Dobrze poprowadzone utrzymanie aplikacji po zmianie wykonawcy to trzy rzeczy: szybka stabilizacja, twarda ocena ryzyk i konsekwentne dowożenie małych, mierzalnych usprawnień. Jeśli potraktujesz pierwsze tygodnie jak operację ratunkową z planem 30/60/90, odzyskasz kontrolę nad produktem szybciej, niż zwykle zakładają zespoły.
FAQ
Ile trwa przejęcie aplikacji?
Pierwsza stabilizacja zwykle 2–4 tygodnie. Pełne uporządkowanie i redukcja największych ryzyk: 2–3 miesiące, zależnie od skali długu technicznego.
Czy warto od razu przepisywać system?
Rzadko. Najpierw stabilizacja i metryki. Re-write ma sens dopiero po danych, nie na bazie frustracji.
Co jest najważniejsze w pierwszym tygodniu?
Dostępy, monitoring, bezpieczny deploy/rollback i jasna lista ryzyk krytycznych.
Zobacz też: Integracje płatności: webhooks, retry, edge-case’y i jak nie wtopić na produkcji
