Przejęcie strony po innym wykonawcy: co sprawdzić w pierwszym tygodniu
Lista w kolejności od najpilniejszych spraw: dostępy, próba odtworzenia projektu od zera, kopie zapasowe, bezpieczeństwo i dopiero na końcu kod.
Przejęcie cudzego projektu rzadko zaczyna się spokojnie. Zwykle dzieje się to wtedy, gdy poprzedni wykonawca przestał odpowiadać, zmienił branżę albo współpraca skończyła się źle. Pierwszy tydzień decyduje o tym, czy masz kontrolę nad własnym systemem, czy tylko dostęp do panelu. Poniżej lista rzeczy do sprawdzenia, w kolejności od najpilniejszych.
- Dostępy
- Próba odtworzenia
- Kopie i bezpieczeństwo
- Co robi system
- Porządki i plan
Dzień pierwszy: dostępy
Zanim ktokolwiek zajrzy w kod, zbierz komplet dostępów i sprawdź, czy naprawdę działają. Brakujący dostęp jest większym ryzykiem niż brzydki kod.
- Domena. Na kogo jest zarejestrowana i kto ma konto w rejestratorze. Domena zapisana na wykonawcę to najczęstsza pułapka.
- DNS. Gdzie jest prowadzona strefa i kto ma do niej dostęp. Od tego zależy, czy da się w ogóle przenieść stronę i pocztę.
- Hosting albo serwer. Panel, dostęp po SSH, kto płaci i do kiedy jest opłacony.
- Repozytorium kodu. Czy istnieje i czy masz do niego dostęp jako właściciel, a nie jako gość.
- Baza danych. Dostęp oraz świeża kopia zapasowa pobrana na Twój dysk.
- Poczta. Skrzynki firmowe i konfiguracja wysyłki, często osobna usługa.
- Usługi zewnętrzne. Płatności, mapy, wysyłka SMS, narzędzia analityczne, konta z kluczami API.
- Narzędzia marketingowe. Google Search Console, statystyki, konta reklamowe.
Jeżeli któryś z tych punktów jest w rękach poprzedniego wykonawcy, zajmij się nim natychmiast, w miarę możliwości za pomocą pisemnej prośby o przekazanie. To sprawa administracyjna, nie techniczna, i zwykle najdłużej trwa.
Dzień drugi: czy to w ogóle da się odtworzyć
Najostrzejszy test dla przejmowanego projektu brzmi: czy da się uruchomić go od zera na czystej maszynie, mając tylko to, co zostało przekazane. Jeśli tak, masz projekt. Jeśli nie, masz działającą instalację, której nikt nie umie odtworzyć, i to jest realne ryzyko: jedna awaria serwera kończy się odbudową z pamięci.
Przy tej próbie wychodzą też rzeczy, o których nikt nie wspomniał: ręczne poprawki wprowadzone bezpośrednio na serwerze, pliki konfiguracyjne istniejące tylko na produkcji, zadania uruchamiane z czyjegoś prywatnego konta.
Dzień trzeci: kopie zapasowe i bezpieczeństwo
- Ustaw kopie zapasowe, jeśli ich nie ma, i odtwórz jedną próbnie. Kopia, której nikt nie odtwarzał, jest tylko obietnicą.
- Zmień hasła i klucze, do których dostęp miał ktoś spoza firmy. Dotyczy to także kluczy do usług płatnych.
- Sprawdź, czy w kodzie nie ma zapisanych haseł ani kluczy w wersji jawnej i czy repozytorium nie jest publiczne.
- Sprawdź wersje PHP i frameworka. Jeśli są niewspierane, dopisz to do listy ryzyk i wróć do tego po ustabilizowaniu sytuacji.
- Zobacz, czy działa monitoring i czy ktokolwiek dostaje powiadomienia o błędach.
Dzień czwarty: co system faktycznie robi
Dopiero teraz ma sens patrzenie w kod. Szukam tu nie elegancji, ale miejsc, w których awaria kosztuje najwięcej: logowanie, płatności, wystawianie dokumentów, integracje z systemami zewnętrznymi i wszystko, co wysyła wiadomości do klientów. To one dostają testy w pierwszej kolejności.
Warto przy okazji spisać, co system robi w tle: wysyłki nocne, synchronizacje, generowanie raportów. Te rzeczy bywają niewidoczne przez tygodnie, a potem okazuje się, że przestały działać przy przenosinach.
Dzień piąty: uporządkowanie i plan
Na koniec pierwszego tygodnia masz mieć: komplet dostępów na kontach firmy, działającą kopię zapasową, opis jak uruchomić projekt oraz listę ryzyk uszeregowaną według tego, ile kosztuje ich zmaterializowanie. Ta lista jest podstawą do rozmowy o budżecie, bo pokazuje różnicę między „trzeba zrobić w tym miesiącu” a „można zaplanować na przyszły rok”.
Czerwone flagi, przy których trzeba działać szybciej
- Domena wygasa w ciągu najbliższych tygodni, a dostępu do rejestratora nie ma nikt w firmie.
- Strona działa, ale nie istnieje żadne repozytorium kodu, a jedyna kopia jest na serwerze.
- Płatności albo integracje działają na kluczach zarejestrowanych na konto wykonawcy.
- System stoi na wersji PHP, której hosting zapowiedział wyłączenie.
- Nikt nie wie, czy i gdzie robione są kopie zapasowe.
Każdy z tych punktów potrafi zatrzymać firmę na kilka dni, a wszystkie da się rozbroić wcześniej, w spokoju.
Czego oczekiwać od nowego wykonawcy
Nowy wykonawca nie powinien zaczynać od propozycji przepisania wszystkiego. Powinien zacząć od przeglądu i powiedzieć wprost, co da się uratować, co wymaga poprawek, a co rzeczywiście trzeba napisać od nowa. Powinien też zostawić Cię w lepszej sytuacji niż poprzednik: dostępy na Twoich kontach, dokumentacja pozwalająca komuś innemu przejąć projekt i decyzje opisane tak, żeby nie trzeba było ich odgadywać.
Tak prowadzę przejęcia i modernizacje systemów PHP oraz Laravel: najpierw przegląd i lista ryzyk, potem plan, dopiero na końcu nowe funkcje. Jeśli przejmujesz nie system, a stronę firmową, zwykle kolejnym krokiem jest przeniesienie jej na lekki CMS, żeby zmiana treści przestała wymagać programisty.
Jak rozstać się z poprzednim wykonawcą bez strat
Nawet gdy współpraca kończy się źle, warto poprosić o przekazanie w formie pisemnej i konkretnej: lista dostępów, informacja o tym, gdzie stoi projekt, oraz czy istnieją elementy licencjonowane (szablon, wtyczka, biblioteka), za które ktoś płaci. Krótka wiadomość z listą punktów działa lepiej niż ogólne „proszę o przekazanie projektu”.
Jeżeli w umowie jest zapis o przeniesieniu praw do kodu, przypomnij o nim wprost. Jeżeli go nie ma, to ważna lekcja na przyszłość: przy kolejnym wykonawcy ustal to przed startem, razem z tym, na czyje konta rejestrowane są domena i usługi.
Co zrobić inaczej przy następnym wykonawcy
- Konta na firmę od pierwszego dnia. Domena, hosting i usługi zewnętrzne zakładane na Twoje dane, z dostępem dla wykonawcy, a kod wydawany na żądanie.
- Repozytorium zamiast plików na serwerze. To jedyny sposób, żeby zobaczyć, co się zmieniło i kiedy.
- Dokumentacja jako część odbioru. Nie sto stron, ale instrukcja uruchomienia i opis integracji.
- Kopie zapasowe po Twojej stronie. Niezależne od wykonawcy i sprawdzone przynajmniej raz.
- Zapisane w umowie prawa do kodu i danych. Razem z tym, co się dzieje po zakończeniu współpracy.
Te pięć punktów kosztuje niewiele na starcie, a zamienia przejęcie projektu z awarii w zwykłą czynność administracyjną.
Najczęstsze pytania do tego tekstu.
-
Od czego zacząć przejęcie strony po innym wykonawcy?
Od dostępów: domena, serwer i panel strony mają być na kontach firmy, a kod masz dostawać na żądanie, choćby repozytorium prowadził wykonawca. Dopiero potem sprawdza się, czy projekt w ogóle da się uruchomić od zera z tego, co zostało przekazane.
-
Co zrobić, gdy poprzedni wykonawca nie oddaje dostępów?
Zacząć od tego, co da się odzyskać bez niego: domena u rejestratora, konto hostingowe i skrzynka są zwykle zapisane na firmę. Równolegle warto zabezpieczyć kopię strony i danych, bo to ona daje czas na spokojne rozmowy.
-
Czy brak dokumentacji oznacza, że trzeba pisać system od nowa?
Nie. Dokumentację da się odtworzyć z kodu i z rozmów z zespołem, który system obsługuje. Od nowa pisze się wtedy, gdy kod jest nie do uruchomienia albo tak splątany, że każda zmiana psuje coś innego.
Napisz kilka zdań o swoim przypadku.
Napisz, co masz w ręku: domena, hosting, repozytorium, kontakt do poprzedniego wykonawcy. Powiem, od czego zacząć i co jest naprawdę pilne. Odpisuję zwykle w ciągu 24 godzin, w dni robocze.
Wolisz rozmowę od pisania? +48 511 599 056, w dni robocze.