Jest czwartek, posiedzenie zarządu. Platforma, która miała ruszyć w czerwcu, ma dziś sześć miesięcy opóźnienia. Software house co dwa tygodnie przysyła nowy harmonogram, każda wycena zmiany wraca dwa razy wyższa, niż zakładano, a dwa ostatnie wdrożenia zepsuły moduł płatności. CTO wie, że kontynuacja z tym dostawcą to kolejne miesiące tego samego. Wie też, czego boi się zarząd: że po zmianie dostawcy projekt stanie na pół roku, kod okaże się bezużyteczny, a nowa firma zacznie od „trzeba to napisać od nowa”.
Ten strach jest uzasadniony, ale dotyczy złej sytuacji. Projekty nie giną dlatego, że zmieniły dostawcę. Giną dlatego, że zmieniły go chaotycznie: bez przejętych dostępów, bez praw do kodu, bez okresu zakładkowego i bez oceny, co właściwie przejmują. Dobrze zaplanowane przekazanie to operacja na kilka tygodni z jasnym zakresem, właścicielem i budżetem.
Ten tekst jest dla CTO, który ma już decyzję albo jest o krok od niej. Pokazujemy plan przejęcia rozpisany na 30 dni, listę rzeczy do zabezpieczenia przed wypowiedzeniem umowy, czynniki, które naprawdę wpływają na koszt, pytania do nowego dostawcy i sygnały, że zmiana nie rozwiąże problemu.
Kiedy zmiana dostawcy w trakcie projektu ma sens, a kiedy tylko przesuwa problem?
Zmiana ma sens, gdy przyczyna problemów leży po stronie dostawcy i nie da się jej naprawić rozmową. Typowe sygnały to brak przewidywalności (kolejne harmonogramy przesuwane bez wyjaśnienia przyczyn), rosnąca liczba regresji przy każdym wydaniu, rotacja w zespole dostawcy, przez którą co kwartał tłumaczysz system od nowa, i brak przejrzystości: nie widzisz kodu, nie masz dostępu do backlogu, a raporty statusowe nie mówią nic konkretnego. Jeśli rozpoznajesz trzy z tych objawów i trwają dłużej niż kwartał, rozmowa naprawcza z dostawcą zwykle już się odbyła i nic nie zmieniła.
Zmiana tylko przesuwa problem, gdy jego źródło leży po Twojej stronie. Jeśli zakres zmienia się co sprint, nikt po stronie firmy nie podejmuje decyzji produktowych, a odbiory ciągną się tygodniami, nowy dostawca trafi w te same warunki i po pół roku będzie wyglądał tak samo jak obecny. Uczciwy test przed decyzją: zapisz trzy ostatnie poważne opóźnienia i dla każdego wskaż, kto je spowodował. Jeśli w dwóch przypadkach na trzy odpowiedź brzmi „my”, najpierw napraw proces po swojej stronie.
Jest też trzecia sytuacja: dostawca jest w porządku, ale system nie. Kod zbudowany pod presją czasu, często z dużym udziałem asystentów AI, potrafi tak ciążyć, że żaden zespół nie dowiezie na nim zmian w przewidywalnym tempie. Objawy opisaliśmy w artykule o siedmiu sygnałach, że aplikację z vibe codingu trzeba ratować. W takim przypadku zmiana dostawcy bez oceny stanu kodu jest zakładem: nowy zespół odziedziczy ten sam dług technologiczny i zacznie od tłumaczenia, dlaczego wszystko trwa tak długo.
Dlatego najlepszą pierwszą decyzją nie jest „zmieniamy”, tylko „sprawdzamy, co mamy”. Niezależny audyt kodu odpowiada na pytanie, czy problemem jest zespół, system, czy jedno i drugie, a jego wynik zmienia rozmowę z zarządem z emocjonalnej na rzeczową.
Co musisz zabezpieczyć, zanim powiesz dostawcy, że odchodzisz?
Kolejność ma znaczenie. Moment, w którym dostawca dowiaduje się o zmianie, jest momentem, w którym Twoja pozycja negocjacyjna słabnie, a jego motywacja do współpracy spada. Wszystko, co da się zabezpieczyć wcześniej, zabezpiecz wcześniej, w ramach normalnej współpracy i bez ogłaszania decyzji.
Pierwsza lista to dostępy. Sprawdź, na czyich kontach są: repozytoria kodu (GitHub, GitLab, Bitbucket), konto chmurowe i rozliczenia, domeny i DNS, certyfikaty, narzędzia CI/CD, monitoring, system zgłoszeń, menedżer haseł z sekretami produkcyjnymi, konta w sklepach z aplikacjami, klucze do zewnętrznych API i bramek płatności. Jeśli którekolwiek z nich jest na koncie dostawcy albo konkretnego programisty, przenieś je na konto firmy teraz, tłumacząc to porządkami w uprawnieniach. To normalna praktyka zarządzania ryzykiem i żaden rozsądny dostawca nie powinien się temu sprzeciwiać.
Druga lista to kod i dane. Upewnij się, że masz pełną kopię repozytoriów z historią zmian, nie tylko ostatni stan gałęzi głównej. Sprawdź, czy w repozytorium są skrypty migracji bazy danych, konfiguracja infrastruktury i pipeline’y wdrożeniowe. Zrób kopię zapasową bazy produkcyjnej i sprawdź, że da się ją odtworzyć. Zbierz dokumentację, która istnieje, nawet jeśli jest nieaktualna: każdy diagram architektury i każda strona w wiki skracają późniejsze odtwarzanie wiedzy.
Trzecia lista to umowa, o której piszemy szerzej w następnej sekcji. Przed wypowiedzeniem musisz wiedzieć, jaki masz okres wypowiedzenia, czy umowa przewiduje obowiązek przekazania i transferu wiedzy, kto ma prawa do kodu i na jakich polach eksploatacji oraz czy są kary umowne albo zobowiązania minimalne.
Czwarta rzecz to plan komunikacji. Ustal, kto i kiedy przekaże dostawcy decyzję, jaką propozycję przekazania mu złożysz i co zrobisz, jeśli odmówi współpracy. Dostawca, któremu zaproponujesz płatny, uczciwie wyceniony okres przekazania, współpracuje znacznie chętniej niż ten, którego zaskoczysz wypowiedzeniem i pozbawisz przychodu z dnia na dzień.
Co w umowie z dotychczasowym dostawcą decyduje o tym, czy przejęcie w ogóle się uda?
Trzy obszary umowy decydują o tym, czy przejęcie będzie operacją techniczną, czy sporem prawnym: prawa do kodu, obowiązki przy zakończeniu współpracy i warunki wypowiedzenia.
Prawa do kodu to sprawa pierwsza. Zgodnie z ustawą o prawie autorskim i prawach pokrewnych umowa o przeniesienie autorskich praw majątkowych obejmuje tylko pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2) i wymaga formy pisemnej pod rygorem nieważności (art. 53). W praktyce oznacza to, że zapis „wszelkie prawa do rezultatów prac przechodzą na zamawiającego” bez wyliczenia pól eksploatacji, takich jak modyfikacja, rozpowszechnianie czy łączenie z innym oprogramowaniem, może nie dać Ci tego, czego potrzebujesz. Sprawdź też, od kiedy prawa przechodzą: wiele umów wiąże przeniesienie z zapłatą za dany etap, więc sporne faktury mogą oznaczać sporny kod. To pytanie do prawnika, nie do CTO, ale CTO musi je zadać, zanim padnie słowo „wypowiadamy”.
Obowiązki przy zakończeniu współpracy to druga kwestia. Dobra umowa przewiduje klauzulę wyjścia: obowiązek przekazania kodu, dokumentacji i dostępów, określony czas na transfer wiedzy i stawki za ten czas. Jeśli Twoja umowa tego nie ma, nie wszystko stracone, ale przekazanie staje się przedmiotem negocjacji, a nie wykonaniem umowy. Jakie zapisy warto mieć w umowie od początku, opisujemy w tekście o klauzulach w umowie z software house’em, które chronią zamawiającego. Szerzej o tym, jak takie zależności powstają i jak się przed nimi chronić, piszemy w tekście o unikaniu vendor lock-in.
Dla firm z sektora finansowego dochodzi wymóg regulacyjny. Rozporządzenie DORA (UE) 2022/2554, stosowane od 17 stycznia 2025 roku, wymaga od podmiotów finansowych strategii wyjścia dla usług ICT wspierających funkcje krytyczne lub istotne (art. 28 ust. 8), a w umowach na takie usługi m.in. strategii wyjścia z obowiązkowym, adekwatnym okresem przejściowym (art. 30 ust. 3 lit. f). Jeśli jesteś bankiem, ubezpieczycielem albo instytucją płatniczą, zmiana dostawcy krytycznego systemu jest więc także procesem, który powinien być opisany, zanim stanie się potrzebny.
Warunki wypowiedzenia to trzecia kwestia: okres wypowiedzenia, minimalne zobowiązania, kary umowne i zasady rozliczenia prac w toku. Policz, ile kosztuje wyjście zgodnie z umową, bo ta kwota trafi do budżetu przejęcia obok kosztów nowego dostawcy. Szerszą perspektywę ryzyka związanego z dostawcą porządkuje pojęcie zarządzania ryzykiem dostawcy.
Jak wygląda plan przejęcia projektu w 30 dni, tydzień po tygodniu?
Poniższy plan zakłada, że dotychczasowy dostawca współpracuje przynajmniej w minimalnym zakresie, a system działa na produkcji, choć z problemami. To ramy do zaplanowania własnego przejęcia, nie gotowy harmonogram każdego projektu: duży system z wieloma integracjami albo dostawca, który odmawia współpracy, wydłużą każdy etap.
Tydzień 1: dostęp i inwentaryzacja. Nowy zespół dostaje dostęp tylko do odczytu do repozytoriów, dokumentacji i monitoringu. Powstaje inwentarz: lista repozytoriów, usług, środowisk, baz danych, integracji z systemami zewnętrznymi i zadań cyklicznych. Pierwsze pytanie kontrolne brzmi: czy nowy zespół potrafi zbudować aplikację z kodu w repozytorium? Jeśli nie, to pierwszy, bardzo ważny wynik przejęcia. Równolegle ustalasz harmonogram sesji transferu wiedzy z zespołem odchodzącym.
Tydzień 2: audyt i transfer wiedzy. Nowy zespół przegląda kod, architekturę, zależności, bezpieczeństwo i proces wdrożeń, a zespół odchodzący prowadzi sesje o obszarach, których nie widać w kodzie: dlaczego coś zrobiono tak, a nie inaczej, które moduły są kruche, jakie są znane obejścia i jakie incydenty zdarzały się na produkcji. Każda sesja kończy się notatką w repozytorium, nie tylko nagraniem. Pod koniec tygodnia masz pierwszą listę ryzyk ułożoną według wpływu na biznes.
Tydzień 3: pierwsze wdrożenie pod kontrolą nowego zespołu. Nowy zespół przejmuje pipeline i wykonuje pierwsze wdrożenie, najlepiej małej, bezpiecznej poprawki, przy obecności zespołu odchodzącego. To moment prawdy: jeśli wdrożenie się udaje i da się je powtórzyć, przejęcie ma fundament. Równolegle odtwarzane są brakujące elementy: dokumentacja uruchomienia środowiska, procedura wdrożenia, procedura przywracania kopii zapasowej, minimalny monitoring.
Tydzień 4: przejęcie odpowiedzialności. Nowy zespół przejmuje dyżur i obsługę zgłoszeń, a dotychczasowy dostawca przechodzi do roli konsultacyjnej na kilka godzin w tygodniu albo kończy współpracę. Dostępy dawnego zespołu są odbierane, sekrety rotowane. Powstaje plan na kolejne tygodnie: co stabilizujemy najpierw, które prace rozwojowe wracają i kiedy, jakie ryzyka zostają otwarte.
Po 30 dniach nie masz jeszcze naprawionego systemu. Masz coś ważniejszego: kontrolę nad nim, wiedzę o tym, co przejąłeś, i plan oparty na faktach. Więcej o tym, jak wygląda samo ratowanie po przejęciu, w tym pierwsze 72 godziny przy systemie w kryzysie, piszemy w playbooku stabilizacji nieudanego projektu IT.
Jak przeprowadzić transfer wiedzy, gdy odchodzący zespół nie ma motywacji?
Transfer wiedzy to najtrudniejszy element przejęcia, bo zależy od ludzi, którzy właśnie stracili klienta. Ich motywacja jest naturalnie niska, a wiedza, której potrzebujesz, siedzi głównie w ich głowach. Na szczęście da się to częściowo zaplanować.
Po pierwsze, zapłać za transfer wiedzy osobno i jasno. Zlecenie typu „cztery tygodnie, dwie osoby na pół etatu, płatne godzinowo, z listą tematów do omówienia” jest dla dostawcy zrozumiałym, ostatnim kontraktem, a nie przysługą. Koszt tych godzin jest mały w porównaniu z kosztem odtwarzania wiedzy z kodu.
Po drugie, ustrukturyzuj sesje. Nowy zespół przygotowuje pytania na podstawie przeglądu kodu, a nie prosi o „opowiedzenie o systemie”. Najcenniejsze tematy to: reguły biznesowe zaszyte w kodzie, a nie w dokumentacji, znane problemy i ich obejścia, historia incydentów produkcyjnych, integracje z systemami zewnętrznymi i kontakty po drugiej stronie, zadania wykonywane ręcznie (raporty, poprawki danych, restarty) oraz rzeczy, których zespół odchodzący „nigdy nie zdążył zrobić”.
Po trzecie, zapisuj wszystko tam, gdzie nowy zespół będzie pracował: w repozytorium, w wiki, w opisach zgłoszeń. Nagrania są przydatne jako uzupełnienie, ale nikt nie będzie oglądał dwunastu godzin wideo, szukając odpowiedzi na jedno pytanie o 2 w nocy.
Po czwarte, przygotuj się na scenariusz, w którym transferu nie będzie. Dostawca może odmówić, zniknąć albo przysłać osoby, które systemu nie znają. Wtedy nowy zespół odtwarza wiedzę z kodu, historii zmian, logów, zgłoszeń i rozmów z użytkownikami biznesowymi. To jest wykonalne, ale trwa dłużej i wymaga doświadczonych inżynierów, którzy umieją czytać cudzy kod bez autora obok. Ten scenariusz trzeba uwzględnić w budżecie jako ryzyko, nawet jeśli dostawca zapowiada pełną współpracę.
Co wpływa na koszt zmiany dostawcy IT?
Koszt przejęcia nie jest jedną liczbą. Składa się z kilku pozycji, z których część widać w ofercie nowego dostawcy, a część nie. Poniższa tabela porządkuje czynniki, które przesuwają budżet najmocniej, i pokazuje, jak je sprawdzić przed decyzją.
| Czynnik kosztu | Co go podnosi | Co go obniża | Jak to sprawdzić przed decyzją |
|---|---|---|---|
| Okres zakładkowy dwóch zespołów | Brak klauzuli wyjścia, dostawca rozlicza transfer po stawkach premium | Płatny, zaplanowany transfer wiedzy z listą tematów | Przeczytaj umowę, policz okres wypowiedzenia i minimalne zobowiązania |
| Stan kodu i długu technologicznego | Brak testów, duplikacja logiki, przestarzałe zależności | Testy krytycznych ścieżek, czytelna architektura | Niezależny audyt kodu przed podpisaniem umowy z nowym dostawcą |
| Dokumentacja i odtwarzalność środowisk | Środowiska konfigurowane ręcznie, brak procedury wdrożenia | Infrastruktura jako kod, opisany pipeline | Zapytaj, czy ktoś spoza zespołu zbudował aplikację z repozytorium |
| Dostępy i własność kont | Konta chmury, domeny i narzędzi na dostawcy | Wszystko na kontach firmy | Inwentarz kont, zanim ogłosisz decyzję |
| Prawa do kodu | Brak pól eksploatacji, prawa zależne od spornych faktur | Pisemne przeniesienie praw z wymienionymi polami | Przegląd umowy przez prawnika |
| Liczba integracji | Wiele systemów zewnętrznych, nieopisane interfejsy | Udokumentowane API, środowiska testowe partnerów | Lista integracji z właścicielami po obu stronach |
| Stan produkcji | Cotygodniowe incydenty, brak monitoringu | Stabilna produkcja, alerty | Historia incydentów z ostatnich trzech miesięcy |
| Spadek tempa w pierwszych tygodniach | Duży, nieznany system, brak transferu wiedzy | Mały zakres, dobra dokumentacja | Zaplanuj w budżecie okres bez nowych funkcji |
Najczęściej niedoszacowana pozycja to ostatnia. Nowy zespół przez pierwsze tygodnie uczy się systemu i nie dowozi funkcji w tempie, do którego przyzwyczaiłeś zarząd w najlepszych miesiącach poprzedniej współpracy. Jeśli roadmapa zakłada pełne tempo od pierwszego dnia, budżet przejęcia rozminie się z rzeczywistością już w pierwszym miesiącu.
Druga najczęściej pomijana pozycja to koszt wyjścia z obecnej umowy. Okres wypowiedzenia i minimalne zobowiązania potrafią oznaczać, że przez miesiąc albo dwa płacisz obu dostawcom. To nie jest argument przeciwko zmianie, tylko pozycja, która musi być w arkuszu.
Jak oszacować budżet przejęcia, zanim dostaniesz ofertę?
Zanim nowy dostawca przedstawi wycenę, możesz zrobić własny szacunek z dokładnością wystarczającą do rozmowy z zarządem. Poniższe wyliczenie to przykład metody, nie cennik: liczby zależą od wielkości systemu, a podstawą są stawki z naszego benchmarku na 2026 rok, w którym senior backend developer kosztuje 180–260 zł netto za godzinę.
Weź okres zakładkowy: dwóch seniorów nowego zespołu przez cztery tygodnie to około 320 godzin pracy, czyli przy tych stawkach około 57 600–83 200 PLN netto. Dodaj czas zespołu odchodzącego na transfer wiedzy, wyceniony według jego stawek, oraz koszty wynikające z wypowiedzenia umowy. Dodaj audyt kodu: w ARDURA Consulting audyt kondycji kodu kosztuje od 18 000 PLN i trwa 1–2 tygodnie, a Technical Due Diligence, z oceną zespołu, skalowalności i licencji open source, od 35 000 PLN i trwa 2–3 tygodnie.
Następnie zarezerwuj kwotę na stabilizację, jeśli system ma problemy na produkcji. Według naszego cennika na stronie Software Rescue faza stabilizacji kosztuje 65 000–170 000 PLN i trwa 2–4 tygodnie, a pełne odzyskanie projektu 170 000–650 000 PLN. Rozrzut jest duży, bo zależy od wielkości systemu i skali problemów, dlatego szczegółowy kosztorys przygotowujemy dopiero po audycie. Jeśli nowy dostawca podaje cenę stabilizacji bez zajrzenia do kodu, wycenia ryzyko w ciemno, a koszt tej niepewności i tak trafi do Ciebie, w stawce albo w aneksach.
Na koniec dolicz koszt spadku tempa. Prosty sposób: przyjmij, że w pierwszym miesiącu po przekazaniu nowy zespół dowozi wyraźnie mniej funkcji niż w docelowym rytmie, i policz, co to oznacza dla terminów biznesowych. To nie jest pozycja na fakturze, ale jest realnym kosztem, o którym zarząd powinien wiedzieć przed decyzją.
Taki arkusz ma jeszcze jedną zaletę: pozwala porównać koszt zmiany z kosztem pozostania. Pozostanie przy dostawcy, który dowozi połowę planu i generuje regresje, też kosztuje, tylko rozkłada ten koszt na kolejne miesiące.
Co zrobić z roadmapą i użytkownikami biznesowymi na czas przejęcia?
Przejęcie dzieje się na działającym biznesie. Sprzedaż czeka na funkcję obiecaną klientowi, dział obsługi zgłasza błędy, a zarząd pyta, kiedy wróci normalne tempo. Jeśli tych oczekiwań nie poukładasz przed startem, każdy z tych głosów będzie próbował przejąć priorytety nowego zespołu w pierwszym tygodniu.
Najprostsza zasada brzmi: na czas przekazania zamrażasz duże zmiany funkcjonalne, ale nie zamrażasz poprawek krytycznych ani wdrożeń bezpieczeństwa. Nowy zespół, który w pierwszym tygodniu dostaje do zrobienia dużą funkcję w nieznanym systemie, albo ją zepsuje, albo zrobi ją kosztem audytu i transferu wiedzy, czyli dokładnie tych prac, które decydują o powodzeniu przejęcia. Z kolei zamrożenie wszystkiego, łącznie z poprawkami, oznacza, że użytkownicy płacą za zmianę dostawcy błędami, których nikt nie naprawia.
Zrób listę zobowiązań, które mają twardy termin w najbliższych dwóch miesiącach: umowy z klientami, wymogi regulacyjne, kampanie marketingowe zależne od funkcji. Dla każdego zdecyduj z góry, czy realizuje go jeszcze dotychczasowy dostawca w okresie wypowiedzenia, czy nowy zespół po przejęciu, czy termin trzeba przesunąć. Ta lista jest jednym z pierwszych dokumentów, które powinien zobaczyć nowy dostawca, bo zmienia kolejność jego pracy.
Wyznacz jeden kanał zgłoszeń i jedną osobę, która ustala priorytety. W okresie zakładkowym łatwo o sytuację, w której ten sam błąd trafia do obu zespołów, każdy naprawia go po swojemu, a potem obie poprawki wchodzą na produkcję jednocześnie. Zasada „jedno zgłoszenie, jeden właściciel, jedna gałąź” brzmi banalnie, ale oszczędza kilka nieprzyjemnych dni.
Na koniec poinformuj kluczowych użytkowników biznesowych, co się zmienia i czego mogą się spodziewać. Nie muszą znać szczegółów umowy, ale powinni wiedzieć, że przez kilka tygodni nowe funkcje będą wchodzić wolniej, a błędy krytyczne będą obsługiwane jak dotąd. Zaskoczeni użytkownicy szybko stają się najgłośniejszymi krytykami zmiany, nawet gdy przebiega zgodnie z planem.
Przejąć istniejący kod czy przepisać system od nowa?
To pytanie pada w każdym przejęciu i zwykle za wcześnie. Nowy zespół, który widzi cudzy kod po raz pierwszy, ma naturalną skłonność do oceny „to trzeba napisać od nowa”. Czasem ma rację. Częściej to reakcja na nieznany kod, a nie wniosek z analizy.
Przepisanie systemu od zera oznacza, że przez wiele miesięcy finansujesz dwa systemy: stary, który musi działać, i nowy, który musi dogonić funkcjonalność starego, łącznie z regułami biznesowymi, o których nikt już nie pamięta, a które kod realizuje od lat. Według naszej strony Software Rescue rozpoczęcie od zera kosztuje zazwyczaj 3–5 razy więcej niż ratunek. Dlatego decyzję o przepisaniu warto podejmować na podstawie audytu, moduł po module, a nie dla całego systemu naraz.
Dobre kryteria decyzji to: czy kod da się przetestować i czy da się wokół krytycznych ścieżek postawić testy regresji, czy architektura pozwala wymieniać części systemu niezależnie, czy technologia ma przyszłość i czy da się znaleźć ludzi do pracy z nią, oraz czy reguły biznesowe są w ogóle znane poza kodem. Jeśli odpowiedzi są w większości twierdzące, stabilizacja i stopniowa przebudowa prawie zawsze wygrywają z przepisaniem.
Wzorzec pośredni, który sprawdza się w przejęciach, to stopniowe zastępowanie: nowy zespół stabilizuje to, co działa, a najgorsze moduły przebudowuje kolejno, za każdym razem kierując ruch do nowej części dopiero wtedy, gdy przejdzie testy. To ten sam wzorzec, który stosuje się przy modernizacji systemów legacy; szerzej opisujemy go w tekście o koszcie i etapach modernizacji systemu legacy bez zatrzymywania biznesu.
Jakie pytania zadać nowemu dostawcy, zanim podpiszesz umowę?
Nowy dostawca będzie przekonywał, że zrobi to lepiej. Twoim zadaniem jest sprawdzić, czy ma metodę przejęcia, a nie tylko zespół do dyspozycji. Poniższe pytania szybko oddzielają jedno od drugiego.
Jak wygląda Wasz pierwszy miesiąc w przejętym projekcie? Dobra odpowiedź opisuje kolejne kroki: dostęp, inwentarz, audyt, transfer wiedzy, pierwsze wdrożenie, przejęcie dyżuru. Zła odpowiedź brzmi „zaczniemy od razu pracować nad backlogiem”.
Czy wycenicie stabilizację przed obejrzeniem kodu? Dostawca, który podaje cenę naprawy bez audytu, albo zgaduje, albo zamierza odbić to sobie w zmianach zakresu. Rozsądna odpowiedź to stała cena za audyt i kosztorys dalszych prac po nim.
Kto konkretnie będzie pracował przy przejęciu i jakie ma doświadczenie z cudzym kodem? Przejęcie to praca dla seniorów, którzy umieją czytać kod bez autora. Zapytaj o skład, a nie o liczbę ludzi w firmie.
Co się stanie, jeśli kluczowa osoba odejdzie z projektu? Odpowiedź powinna mówić o gwarancji wymiany i czasie zastępstwa, zapisanych w umowie. W modelu, w którym ARDURA dostarcza specjalistów, każda współpraca zaczyna się od dwutygodniowej gwarancji satysfakcji z bezpłatną wymianą, a jeśli specjalista odejdzie w trakcie, gwarantujemy zastępstwo w ciągu 5 dni roboczych.
Jak zapewnicie, że nie powtórzymy tej sytuacji z Wami? Najlepsza odpowiedź to: kod i konta od pierwszego dnia u Was, dokumentacja jako część definicji ukończenia, prawa autorskie przenoszone na bieżąco i klauzula wyjścia w umowie. Dostawca, który sam proponuje warunki ułatwiające odejście od niego, zwykle nie zamierza dawać powodów do odejścia. Rozbudowaną listę pytań przy wyborze dostawcy znajdziesz w liście kontrolnej pytań do dostawcy usług IT.
Jakie są czerwone flagi w trakcie przejęcia?
Część problemów ujawnia się dopiero w trakcie przekazania. Warto wiedzieć z góry, które sygnały wymagają natychmiastowej reakcji, a nie odnotowania w raporcie tygodniowym.
Kod w repozytorium nie odpowiada temu, co działa na produkcji. Zdarza się, że część poprawek wdrażano ręcznie albo z lokalnych kopii. Jeśli nowy zespół nie potrafi zbudować z repozytorium tej samej wersji, która działa, masz problem z integralnością kodu, który trzeba rozwiązać przed jakimkolwiek kolejnym wdrożeniem.
Dostawca opóźnia przekazanie dostępów administracyjnych. Kilka dni to organizacja, kilka tygodni to strategia. Każdy dzień, w którym kontrola nad produkcją jest u odchodzącego dostawcy, to ryzyko, którego nie kontrolujesz.
Zespół odchodzący wymienia się w trakcie transferu wiedzy. Jeśli na sesje przychodzą osoby, które systemu nie znają, transfer jest pozorny. Zażądaj obecności konkretnych osób albo zmień plan i zarezerwuj czas nowego zespołu na samodzielne odtwarzanie wiedzy.
Nowy dostawca po tygodniu proponuje przepisanie całości. Taka rekomendacja jest możliwa, ale powinna wynikać z audytu z uzasadnieniem dla każdego modułu, a nie z pierwszego wrażenia. Poproś o dowody i o alternatywę w postaci stabilizacji.
Nikt po Twojej stronie nie jest właścicielem przejęcia. Przekazanie wymaga decyzji: co zamrażamy, co przyjmujemy jako ryzyko, kiedy przechodzimy do kolejnego etapu. Jeśli nie ma osoby, która podejmuje te decyzje w ciągu dni, a nie tygodni, przejęcie się rozmyje niezależnie od jakości obu dostawców.
Jak ARDURA Consulting przejmuje projekt od innego dostawcy?
Przejęcia od innych dostawców prowadzimy w ramach usługi Software Rescue i zaczynamy je zawsze od audytu, bo bez niego każda deklaracja co do kosztu i terminu jest zgadywaniem. Proces opisany na stronie usługi ma cztery fazy.
Pierwsza to audyt kondycji kodu: przegląd kodu, architektury, infrastruktury i procesów, zakończony raportem długu technicznego, oceną ryzyka i planem naprawczym. Ma stałą cenę od 18 000 PLN i trwa 1–2 tygodnie; jeśli potrzebujesz też oceny zespołu, skalowalności i ryzyk dla zarządu albo inwestorów, Technical Due Diligence zaczyna się od 35 000 PLN i trwa 2–3 tygodnie. Co dokładnie dostajesz w audycie, rozpisaliśmy w tekście o audycie kodu z AI w dwa tygodnie.
Druga faza to stabilizacja, trwająca 2–4 tygodnie: naprawa krytycznych błędów, łatki bezpieczeństwa i konfiguracja monitoringu. Trzecia to redukcja długu technicznego: systematyczna refaktoryzacja najgorszego kodu, testy automatyczne i dokumentacja. Czwarta, opcjonalna, to długoterminowe utrzymanie z umową SLA.
W ramach przejęcia zajmujemy się przejęciem kodu i dokumentacji z audytem, transferem wiedzy od odchodzącego zespołu, migracją infrastruktury, jeśli jest potrzebna, oraz uzupełnieniem zespołu naszymi programistami, żeby utrzymać tempo prac. W sytuacjach krytycznych możemy zacząć w ciągu 48 godzin. Jeśli po audycie okaże się, że Twój zespół poradzi sobie sam i potrzebuje tylko dodatkowych rąk, rozsądniej będzie dołożyć seniorów w modelu body leasingu niż kupować całą usługę ratunkową. Raport i plan działań należą do Ciebie niezależnie od tego, kogo wybierzesz do ich realizacji.
Co zapamiętać, zanim podejmiesz decyzję o zmianie dostawcy?
Zmiana dostawcy w trakcie projektu nie jest katastrofą, jeśli jest operacją, a nie reakcją. Różnica między jednym a drugim sprowadza się do kilku rzeczy, które da się przygotować z wyprzedzeniem.
Po pierwsze, upewnij się, że problem leży po stronie dostawcy albo systemu, a nie Twojego procesu decyzyjnego. Inaczej nowy dostawca odziedziczy te same warunki. Po drugie, zabezpiecz dostępy, kod, kopie danych i dokumentację, zanim ogłosisz decyzję. Po trzecie, sprawdź z prawnikiem prawa autorskie do kodu, pola eksploatacji i warunki wyjścia z umowy, a jeśli działasz w sektorze finansowym, także wymogi DORA. Po czwarte, zaplanuj przejęcie w czterech krokach: dostęp i inwentarz, audyt i transfer wiedzy, pierwsze wdrożenie pod nową kontrolą, przejęcie odpowiedzialności. Po piąte, budżetuj wszystkie pozycje, łącznie z okresem zakładkowym, kosztem wypowiedzenia i spadkiem tempa w pierwszych tygodniach.
I najważniejsze: nie podejmuj decyzji „przejmujemy” ani „przepisujemy” bez niezależnej oceny kodu. Audyt kosztuje ułamek tego, co kosztuje pomyłka w którąkolwiek stronę.
Jeśli rozważasz zmianę dostawcy, zobacz, jak działa Software Rescue albo umów rozmowę. Powiemy, od czego zacząć w Twojej sytuacji, czy audyt jest potrzebny i jak mógłby wyglądać pierwszy miesiąc przejęcia.