Przejęcie projektu po innej firmie — jak to robimy?

Ten telefon odbieramy kilka razy w roku. „Programista, który robił nasz system, przestał odbierać. Sklep działa, ale boimy się cokolwiek ruszyć." Albo łagodniejsza wersja: wykonawca formalnie jest, tylko na maile odpowiada co dwa tygodnie, a każda poprawka trwa kwartał — współpraca się po prostu wypaliła. W obu przypadkach sytuacja jest ta sama: system pracuje, zarabia albo obsługuje firmę i nie może czekać, aż konflikt się rozwiąże sam. Da się z tego wyjść — przejęcie projektu po innej firmie to dla nas normalna, powtarzalna procedura, nie akcja ratunkowa na oślep. Opiszę, jak wygląda krok po kroku.

Najpierw inwentaryzacja: co w ogóle mamy?

Zanim powiemy cokolwiek o kosztach i planach, musimy zobaczyć, czym dysponujesz. Sprawdzamy po kolei kilka obszarów — i od razu podpowiem, że braki w tej liście to norma, nie powód do paniki:

• Dostępy: panel domeny, hosting lub serwer, baza danych, skrzynki pocztowe, bramka płatności, konta w usługach zewnętrznych (mapy, SMS-y, kurierzy). Zaskakująco często okazuje się, że domena jest zarejestrowana na... poprzedniego wykonawcę. To trzeba prostować w pierwszej kolejności.
• Kod: czy istnieje repozytorium z historią zmian, czy tylko pliki na serwerze produkcyjnym? Jedno i drugie da się przejąć, ale repozytorium mówi nam o projekcie znacznie więcej.
• Baza danych: struktura, rozmiar, czy są w niej rzeczy, których nie widać w aplikacji (stare tabele, ręczne poprawki).
• Dokumentacja: bywa różnie — od porządnych opisów po nic. Częściej nic.
• Licencje: na jakim silniku czy szablonie stoi system, czy komponenty są opłacone i na kogo, co mówi umowa z poprzednią firmą o prawach do kodu.

Z tej inwentaryzacji powstaje pierwszy dokument dla Ciebie: co jest, czego brakuje, co odzyskujemy i jak. Jeżeli dostępów nie ma wcale, też są ścieżki — od kontaktu z usługodawcami po odtworzenie systemu z tego, co dostępne. Dłuższa droga, ale przechodziliśmy ją nieraz.

Od stanu tej listy zależy zresztą koszt całego przejęcia. Komplet dostępów, kod w repozytorium i znośna dokumentacja to szybki start; brakująca domena i kod wyciągany z serwera to więcej godzin na samą archeologię. Dlatego nie podajemy ceny przejęcia w ciemno — najpierw inwentaryzacja, potem konkretne liczby.

Pierwsze tygodnie: zabezpieczyć, nie przebudowywać

Jeżeli z poprzednią firmą jest jeszcze jakikolwiek kontakt, namawiamy na cywilizowane przekazanie: krótka rozmowa techniczna i protokół z listą przekazanych elementów oszczędzają tygodnie zgadywania. Bez pretensji i wypominania — nam zależy na wiedzy, nie na wygrywaniu sporu. A gdy kontaktu nie ma, po prostu radzimy sobie bez niego; kod i baza mówią więcej, niż się ludziom wydaje.

Sama kolejność prac jest u nas nienegocjowalna. Częsty odruch nowego wykonawcy: „wszystko tu jest źle, przebudujemy". My zaczynamy odwrotnie — od nudnego zabezpieczania. Robimy pełne kopie kodu, bazy i plików, przenosimy je w miejsce kontrolowane przez Ciebie, zmieniamy hasła i porządkujemy dostępy tak, żeby od tej chwili nikt niepowołany nie mógł niczego wyłączyć. Dopiero mając zabezpieczony grunt, zaczynamy rozumieć system: rysujemy jego mapę (co z czym się łączy, gdzie są integracje, co jest krytyczne dla sprzedaży), przeglądamy kod i spisujemy listę ryzyk — od przestarzałej wersji PHP po moduły, które trzymają się na taśmę klejącą.

W tym samym czasie bierzemy na warsztat kilka drobnych, odkładanych miesiącami poprawek. Celowo: Ty widzisz pierwsze efekty po tygodniach, nie po kwartale, a my uczymy się systemu na małych, bezpiecznych zmianach, zanim dotkniemy czegokolwiek poważnego. Zaufanie po nieudanej współpracy odbudowuje się konkretami, nie obietnicami.

Uczciwie: czasem taniej przepisać, niż łatać

Po kilku tygodniach wiemy już dość, żeby powiedzieć Ci prawdę o stanie systemu. A prawda bywa różna. Czasem kod po poprzedniej firmie jest zupełnie przyzwoity i wystarczy go pielęgnować — mówimy to wprost, bez wymyślania problemów na siłę, bo naciąganie klienta na przebudowę działającego systemu to krótkowzroczny biznes. Czasem jednak konkretny moduł jest w takim stanie, że każda poprawka w nim kosztuje trzykrotność normalnej pracy i generuje nowe błędy. Wtedy liczymy oba warianty i pokazujemy Ci rachunek: łatanie po 125 zł netto za godzinę w kółko, albo jednorazowe przepisanie modułu i spokój. Zwykle przepisujemy wyspami — pojedyncze fragmenty, bez zatrzymywania całości. Jak podchodzimy do takich modernizacji, opisaliśmy w tekście o przepisywaniu starych systemów PHP na nowe wersje.

Pełne przepisanie wszystkiego od zera? To ostateczność, którą proponujemy rzadko i tylko z wyliczeniem w ręku. Nowy system też trzeba będzie kiedyś utrzymywać — jeśli kultura pracy się nie zmieni, za pięć lat wrócisz do punktu wyjścia, tylko biedniejszy.

Jak nie wpaść w tę pułapkę ponownie?

Na koniec kilka zasad, które oszczędzą Ci powtórki — niezależnie od tego, z kim będziesz pracować, także z nami. Domena, hosting i wszystkie konta usług mają być zarejestrowane na Twoją firmę; wykonawca dostaje dostęp, nie własność. Kod ma leżeć w repozytorium, do którego masz wgląd, a nie wyłącznie na laptopie programisty. Umowa ma jasno mówić o prawach do kodu i o obowiązku przekazania wszystkiego po zakończeniu współpracy. I ostatnia rzecz, najprostsza: komplet aktualnych dostępów trzymaj u siebie, sprawdzony raz na jakiś czas, a nie „gdzieś w mailach sprzed trzech lat".

Zwróć uwagę, że żaden z tych punktów nie wymaga wiedzy technicznej — to kwestia ustaleń na starcie współpracy. Dobry wykonawca zgodzi się na nie bez mrugnięcia, bo nie planuje trzymać Cię zakładnikiem. Opór przy którymkolwiek z nich to sygnał ostrzegawczy. U nas te zasady obowiązują domyślnie: wszystko, co powstaje w Twoim projekcie, jest od pierwszego dnia Twoje i masz do tego stały wgląd.

Jesteś w sytuacji z pierwszego akapitu — wykonawca zniknął albo współpraca ledwo zipie? Opisz nam swój przypadek, najlepiej od razu z informacją, jakie dostępy masz, a jakich nie. Wrócimy z planem przejęcia rozpisanym na etapy i powiemy szczerze, w jakim stanie jest to, co przejmujemy.