Jak bezpiecznie zmienić programistów w trakcie trwania projektu?

To naturalne obawy. Zmiana dostawcy IT w locie przypomina nieco wymianę silnika w samochodzie, który wciąż jedzie autostradą. Jest to ryzykowne, ale czasem niezbędne, by w ogóle dojechać do celu.

Często wspieramy firmy w takich momentach. Wiemy, że to nie jest czas na wytykanie błędów poprzednikom, ale na szybkie i skuteczne działanie, które zabezpieczy Twój biznes. W tym artykule przeprowadzimy Cię krok po kroku przez proces bezpiecznej zmiany partnera technologicznego.

Kiedy powiedzieć „dość”? Sygnały ostrzegawcze

Zanim przejdziemy do tego, jak zmienić dostawcę, zastanówmy się chwilę, kiedy warto to zrobić. Decyzja o „rozwodzie” z obecnym zespołem IT rzadko zapada z dnia na dzień. Zazwyczaj jest to proces narastającej frustracji.

Oto sytuacje, które powinny zapalić w Twojej głowie czerwoną lampkę:

• Terminy są umowne - kolejne "deadline'y" mijają, a Ty słyszysz tylko wymówki zamiast konkretów.

• Brak kontaktu - wykonawca nie odpisuje, nie odbiera telefonów lub znika na całe tygodnie.

• Jakość spada - po każdej poprawce pojawiają się trzy nowe błędy, a aplikacja działa coraz wolniej.

• Brak transparentności - nie masz dostępu do kodu, nie wiesz, co realnie zostało zrobione, a raporty z prac są mętne.

• Dług technologiczny - słyszysz ciągle, że „tego się nie da zrobić”, bo system został źle zaprojektowany na początku (przez ten sam zespół).

Jeśli te punkty brzmią znajomo, prawdopodobnie zmiana jest nieunikniona. Im szybciej przygotujesz się do tego procesu, tym mniej pieniędzy i nerwów stracisz.

Etap 1: Cichy audyt, czyli zanim rzucisz wypowiedzeniem

Największym błędem, jaki można popełnić, jest zerwanie umowy pod wpływem emocji, zanim zabezpieczy się efekty dotychczasowej pracy. Zanim poinformujesz obecnego wykonawcę o zakończeniu współpracy, musisz wiedzieć, na czym stoisz.

Sprawdź, co tak naprawdę masz

Często klienci myślą, że mają gotową w 80% aplikację, podczas gdy w rzeczywistości mają zlepek niedziałającego kodu. Tutaj z pomocą przychodzi niezależny audyt jakości kodu. To trochę jak wizyta u mechanika przed zakupem używanego auta.W Kodiwo realizując audyty przejęcia, sprawdzamy:

1. Jakość kodu - czy jest czytelny, czy da się go rozwijać, czy trzeba go napisać od nowa?

2. Bezpieczeństwo - czy w kodzie nie ma luk, zaszytych haseł lub backdoorów?

3. Własność - czy w ogóle masz fizyczny dostęp do repozytorium (np. GitHub, GitLab)?

To kluczowy moment. Jeśli okaże się, że kod jest bezużyteczny, strategia zmiany dostawcy będzie inna (budowa od nowa) niż w przypadku, gdy projekt wymaga tylko dokończenia.

Etap 2: Zabezpiecz to co masz

To najważniejszy punkt tego poradnika. Nigdy nie informuj o zmianie dostawcy, dopóki nie masz pełnej kontroli nad zasobami. W świecie idealnym rozstania są profesjonalne. W rzeczywistości urażony (z wielu różnych powodów) wykonawca zablokować Ci dostęp do serwerów czy skasować repozytorium.

Doświadczenie uczy nas też pewnej smutnej prawidłowości: im mniejszy software house lub freelancer po drugiej stronie, tym ryzyko komplikacji bywa większe. W małych strukturach, gdzie wszystko zależy od jednej czy dwóch osób, emocje potrafią wziąć górę nad profesjonalizmem, a brak sformalizowanych procedur utrudnia sprawne przekazanie wiedzy.

Dlatego, jeśli czujesz, że sytuacja jest napięta, warto rozważyć zatrudnienie zewnętrznego konsultanta wyłącznie do nadzorowania procesu przejęcia. Taka osoba, działając „na chłodno”, zabezpieczy Twoje interesy techniczne.

W Kodiwo często pełnimy rolę takiego "technicznego mediatora" - pomagamy bezpiecznie odzyskać kody i dostępy, dając Ci pewność, że wszystko jest u Ciebie, zanim definitywnie zamkniesz drzwi za poprzednim wykonawcą.

Lista kontrolna przejęcia:

Upewnij się, że posiadasz dostępy administracyjne (login i hasło z najwyższymi uprawnieniami) do:

• Repozytorium kodu - to serce Twojego projektu. Najlepiej sklonuj repozytorium i wypchnij go do innego miejsca (np. na swój Github)

• Serwery i hosting (AWS, Azure, Google Cloud, OVH itp.) - upewnij się, że faktury są opłacane przez Ciebie i konto jest na Twoje dane.

• Domeny i DNS - klucz do widoczności Twojej usługi w sieci. Upewnij się, że masz u usługodawcy odpowiednie uprawnienia.

• Zewnętrzne usługi (SaaS) - konta typu PayU (płatności), SendGrid (maile), Firebase, narzędzia analityczne.

• Dokumentacja - techniczna, projektowa, makiety w Figmie.

Etap 3: Formalności i umowy - czytaj to, co podpisujesz

Kiedy technicznie jesteś zabezpieczony, czas spojrzeć w papiery. Sprawdź swoją umowę z obecnym dostawcą pod kątem praw autorskich.

W Polsce (i wielu innych krajach) samo zapłacenie faktury nie oznacza automatycznego przeniesienia majątkowych praw autorskich na Ciebie. Musi to być wyraźnie zapisane w umowie.

Upewnij się, że:

• Masz prawa do kodu źródłowego, a nie tylko do skompilowanej aplikacji.

• Nie ma kar umownych za wcześniejsze rozwiązanie współpracy.

• Wszystkie biblioteki i komponenty użyte w projekcie mają odpowiednie licencje komercyjne.

Jeśli masz wątpliwości prawne, warto skonsultować się z prawnikiem specjalizującym się w IT. To mały koszt w porównaniu do ryzyka zablokowania sprzedaży Twojego produktu w przyszłości.

Etap 4: Wybór nowego partnera - nie wpadnij z deszczu pod rynnę

Szukając nowej firmy, nie kieruj się tylko ceną. Skoro zmieniasz dostawcę, to prawdopodobnie „tanio” już było, a teraz ma być „dobrze”.

Nowy zespół musi mieć doświadczenie w przejmowaniu projektów i modernizacji. To zupełnie inna umiejętność niż pisanie od zera. Wymaga pokory (nie krytykujemy bez sensu), analitycznego myślenia (rozgryzamy, co autor miał na myśli) i cierpliwości.

O co pytać nowego wykonawcę?

1. Jak wygląda proces przejęcia kodu? (Powinni wspomnieć o audycie zerowym i konfiguracji środowisk).

2. Czy pracowali już w technologiach, w których napisany jest Twój projekt? (Eksperymenty na żywym organizmie to zły pomysł).

3. Jak raportują postępy? (Tutaj kłania się nasze podejście do monitorowania postępów prac - transparentność to podstawa zaufania).

Etap 5: Przekazanie wiedzy

Moment przekazania pałeczki. Jeśli rozstanie przebiega w cywilizowanej atmosferze, zorganizuj spotkanie (online lub na żywo) ustępującego zespołu z nowym.

Nawet 2-godzinna rozmowa techniczna (Developer-to-Developer) może zaoszczędzić nowemu zespołowi 2 tygodni analizy kodu

O co nowy zespół powinien zapytać starego?

• Jakie są znane błędy i obejścia (workaroundy)?

• Jak uruchomić środowisko lokalne (instrukcja „How to run”)?

• Jak wygląda proces deploymentu aplikacji na środowiska testowe i produkcyjne

• Czy są jakieś nieoczywiste zależności w systemie?

• Gdzie jest "trup w szafie" - czyli co zostało zrobione "na szybko" i wymaga poprawy w pierwszej kolejności?

Jeśli stary dostawca nie chce współpracować, nowy zespół musi polegać na dokumentacji (jeśli istnieje) i analizie kodu (reverse engineering). Jest to trudniejsze, ale wykonalne dla doświadczonych programistów.

Jak zminimalizować ryzyko w trakcie zmiany?

Zmiana dostawcy to operacja na otwartym sercu. Aby pacjent przeżył, zastosuj te zasady bezpieczeństwa:

1. Okres przejściowy - jeśli to możliwe, niech nowy zespół przez 2-4 tygodnie pracuje równolegle, lub przynajmniej ma dostęp do kodu, zanim stary zespół całkowicie odejdzie. Alternatywnie zapłać poprzedniemu zespołowi za bycie na "stand-by" w razie gdyby nowy zespół miał pytania techniczne.

2. Zamrożenie nowych funkcjonalności - w momencie transferu nie dodawaj nowych „ficzerów”. Skup się na stabilizacji i przeniesieniu środowisk. Nowe rzeczy będziemy wdrażać, gdy kurz opadnie.

3. Pełny backup - zanim nowy zespół dotknie czegokolwiek, zrób kopię zapasową wszystkiego: bazy danych, kodu, plików. To Twoja polisa ubezpieczeniowa.

4. Małe kroki - pierwsze zadanie dla nowego zespołu powinno być małe i niekrytyczne. Pozwoli to zweryfikować ich styl pracy bez ryzykowania stabilności całego systemu.

Podsumowanie: To biznes, nie dramat

Zmiana dostawcy IT jest stresująca, ale często jest najlepszą decyzją, jaką możesz podjąć dla swojego projektu. Tkwienie w toksycznej relacji z niesłownym wykonawcą generuje o wiele większe koszty - nie tylko finansowe, ale też wizerunkowe.

Przejmując projekt, dbaj o to, by tym razem standardy były wyższe. Wymagaj dokumentacji na bieżąco, regularnych raportów i dostępu do kodu każdego dnia. Opieranie się od samego początku na "partnerskości" i "zaufaniu" nie jest dobrą metodą.

Jeśli stoisz przed takim wyzwaniem i nie wiesz, od czego zacząć - warto porozmawiać z kimś, kto spojrzy na Twój projekt chłodnym okiem. Czasem krótki audyt czy konsultacja pozwalają uniknąć katastrofy i bezpiecznie doprowadzić projekt do szczęśliwego finału.

Powodzenia! To Twój projekt i masz prawo wymagać, by był realizowany profesjonalnie!