Jak bezpiecznie zmienić software house w trakcie projektu? Praktyczny przewodnik

Wielu klientów, mimo narastających problemów, tkwi w toksycznej relacji z obecnym software house’em. Dlaczego? Boją się utraty ciągłości projektu, ogromnych kosztów wdrożenia nowej firmy lub tego, że nowy dostawca „pogubi się” w zastanym bałaganie. To klasyczna “pułapka kosztów utopionych” (z angielskiego tzw. sunk cost fallacy).

Prawda jest jednak brutalna: pozostanie w relacji, która nie dowozi, jest bardziej kosztowne i ryzykowne niż sama zmiana.

Z tego artykułu dowiesz się, jak przeprowadzić „rozwód” z obecnym dostawcą z klasą, zachowując pełną kontrolę nad swoim produktem.

 Zamów audyt

Kiedy zmiana jest koniecznością? Red flagi

Zanim podejmiesz decyzję, sprawdź, czy Twój projekt wykazuje poniższe sygnały:

• Brak dostarczanej wartości: Obietnice mijają się z rzeczywistością. Spritny kończą się bez widocznych efektów, a milestone’y są przesuwane w nieskończoność.
• Niestabilność i błędy: Regresje to codzienność – naprawa jednego błędu powoduje pojawienie się trzech nowych.
• Brak transparentności: Nie wiesz, co dokładnie dzieje się w kodzie, a dostawca unika odpowiedzi na trudne pytania lub po prostu ukrywa problemy.
• Vendor Lock-in: Odkrywasz, że bez obecnego dostawcy nie masz dostępu do własnej infrastruktury, baz danych czy pełnej dokumentacji.

Jeśli rozpoznajesz te sygnały, czas na planowanie transferu. Ale uwaga: nie rób tego gwałtownie.

Krok 1: Audyt „Przedrozwodowy”

Zmiana dostawcy wymaga dobrego przygotowania. Przed zakończeniem współpracy sprawdź wewnętrznie sytuację i zabezpiecz dostęp do kluczowych zasobów, by zachować ciągłość operacyjną.

Zabezpieczenie IP i dostępu

W teorii jesteś właścicielem kodu, ale w praktyce bywa różnie. Upewnij się, że posiadasz:

• Pełny dostęp do repozytoriów (np. GitHub, GitLab, Bitbucket): Czy masz uprawnienia administratora? Czy możesz samodzielnie „odpiąć” obecnego dostawcę w dowolnym momencie?
• Dostęp do środowisk i chmury (AWS, Azure, GCP): Czy konta są na Twoją firmę, czy na dostawcę?
• Klucze i hasła do usług zewnętrznych: Bramki płatnicze, systemy analityczne, narzędzia do wysyłki e-maili.

Cicha ewidencja dokumentacji

Sprawdź, co faktycznie posiadasz. Dokumentacja „gdzieś w Notion” to nie dokumentacja. Szukaj schematów architektury, opisów API i instrukcji konfiguracji środowisk. Jeśli ich brakuje, zacznij ich wymagać jako „rutynowego uzupełnienia braków”, zanim ogłosisz odejście.

Krok 2: Audyt Zerowy – Spojrzenie Nowego Partnera

Gdy znajdziesz potencjalnego następcę, nie oczekuj, że złoży ofertę „na ślepo”. Poważna firma technologiczna, taka jak Pragmatic Coders, zawsze zaczyna od Audytu Zerowego.

Dlaczego nowy dostawca musi przeprowadzić audyt?

Abyś nie płacił za błędy poprzednika. Nowy zespół musi zrozumieć:

1. Dług techniczny: Co jest do natychmiastowej poprawy, a co może poczekać?
2. Obserwowalność (Observability): Czy system pozwala na monitorowanie błędów w czasie rzeczywistym?
3. Procesy CI/CD: Jak szybko można bezpiecznie wdrażać nowe funkcje?

Plan Przejęcia (Takeover Plan)

Wynikiem audytu nie jest tylko lista błędów, ale konkretna koncepcja. Dobry wykonawca przedstawi Ci plan, który balansuje dwie rzeczy:

• Remediacja (Fixing): Naprawa krytycznych błędów i uszczelnienie bezpieczeństwa.
• Nowa wartość biznesowa: Dowożenie nowych funkcji, aby Twój biznes nie stał w miejscu podczas tranzycji.

Krok 3: Exit Plan i Transfer Wiedzy

Ostatnim etapem jest ułożenie procesu wyjścia i transferu wiedzy w taki sposób, aby stary dostawca współpracował (lub przynajmniej nie uprzykrzał życia).

Checklista Kontroli Technicznej

Zanim ostatni deweloper starej firmy wyloguje się z systemu, musisz potwierdzić transfer. W idealnym świecie, wyglądałoby to tak:

• Testy Charakteryzacyjne: Nowy zespół napisze testy, które „opisują” obecne działanie systemu (nawet to błędne), aby upewnić się, że nie popsuje niczego podczas refaktoryzacji.
• Wspólne sesje Pair Programming: Nowy zespół będzie obserwować, jak obecny deweloper porusza się po kodzie.
• Przekazanie Governance: Ustalisz nowe zasady raportowania, zarządzania budżetem i transparentności.

Zarządzanie Relacją

Skonstruuj plan wyjścia tak, aby stary dostawca był rozliczany za wsparcie procesu przejścia. Jasna komunikacja „kończymy współpracę ze względu na zmianę strategii” (nawet jeśli powody są inne) często pomaga zachować poprawną atmosferę na finiszu.

Podsumowanie

Zmiana dostawcy oprogramowania to nie porażka; postrzegaj to raczej jako dojrzałą decyzję biznesową. Pozwala ona zatrzymać spalanie pieniędzy na projekt, który nie rokuje, i zainwestować je lepiej. Być może projekt trzeba, mówiąc kolokwialnie, “ubić”, a może wyjściem jest nawiązanie współpracy z innym dostawcą oprogramowania?

Jeśli zdecydujesz się na to drugie, zdecydowanie przeczytaj nasz artykuł o tym, jak wygląda wzorcowe przejęcie projektu IT.

Potrzebujesz zewnętrznej perspektywy, żeby zrozumieć, na czym stoisz? Skontaktuj się z nami, aby umówić się na Audyt Zerowy. Pomożemy Ci odzyskać panowanie nad produktem, spłacić dług techniczny i wrócić na właściwe tory. W Pragmatic Coders nie tylko ratujemy projekty, ale budujemy fundamenty pod ich przyszły sukces.

Często Zadawane Pytania

Summarize this article with AI

ChatGPT

Claude

Perplexity