Jak skutecznie przejąć projekt po poprzednim dostawcy?
Przejęcie projektu IT po poprzednim dostawcy rzadko zaczyna się od czystej dokumentacji, uporządkowanego backlogu i stabilnego środowiska produkcyjnego.
Częściej wygląda inaczej.
Jest system, który „działa”, ale tylko pod warunkiem, że nikt nie dotyka kilku kruchych elementów. Jest dokumentacja, ale fragmentaryczna albo nieaktualna. Są wdrożone funkcje, które działają na happy path, ale nie przechodzą próby realnej produkcji. Są procesy biznesowe, które miały być przeniesione do nowego systemu, ale w praktyce nadal wymagają starego narzędzia. Jest zespół klienta, który słyszał już wiele obietnic i nie chce kolejnej prezentacji z planem naprawczym. On chce odzyskać kontrolę.
Dlatego skuteczne przejęcie projektu nie polega na tym, że nowy dostawca „wchodzi i dowozi szybciej”.
Pierwszym celem jest zrozumienie, co naprawdę zostało przejęte.
Nie zaczynamy od developmentu. Zaczynamy od kontroli sytuacji
Największy błąd w projektach takeover polega na tym, że nowy zespół zbyt szybko próbuje udowodnić wartość przez dowożenie nowych funkcji.
To zrozumiałe. Klient często jest pod presją. Backlog czeka. Biznes chce zobaczyć postęp. Poprzedni dostawca nie dowiózł, więc nowy powinien „w końcu ruszyć temat”.
Problem w tym, że jeśli system jest niestabilny, każda nowa funkcja może zwiększyć chaos.
W praktyce pierwsze tygodnie powinny być poświęcone na odzyskanie kontroli nad kilkoma obszarami:
- produkcją,
- dostępami,
- procesem wdrożeń,
- monitoringiem,
- krytycznymi przepływami biznesowymi,
- backlogiem i priorytetami,
- realnym stanem technicznym systemu.
Dopiero wtedy można odpowiedzialnie mówić o roadmapie.
Bez tego roadmapa jest listą życzeń opartą na niepełnej wiedzy.
Dobry takeover zaczyna się od diagnozy, ale nie kończy się raportem
Audyt techniczny jest potrzebny, ale sam raport nie rozwiązuje problemu.
W projektach po poprzednim dostawcy diagnoza musi być operacyjna. Nie chodzi tylko o odpowiedź na pytanie: „co jest źle?”. Chodzi o odpowiedź na pytanie: „co może zatrzymać biznes jutro rano?”.
To zasadnicza różnica.
Raport, który mówi, że system ma dług techniczny, niewiele wnosi. Prawie każdy starszy system go ma. Ważniejsze jest wskazanie, które elementy długu technicznego realnie blokują rozwój, zwiększają koszt utrzymania albo tworzą ryzyko awarii produkcyjnej.
Przykładowo: brak dokumentacji jest problemem, ale jego konsekwencją biznesową jest wolniejsza analiza, droższe wdrożenie nowych osób i większe ryzyko błędnych decyzji przy zmianach. Rozproszona logika w wielu mikroserwisach nie jest tylko problemem architektonicznym. To oznacza, że jedna zmiana biznesowa może wymagać modyfikacji w kilku miejscach, testowania wielu zależności i większego budżetu. Brak monitoringu nie jest tylko brakiem narzędzia. To sytuacja, w której zespół dowiaduje się o awarii od użytkowników, zamiast wykryć ją wcześniej.
Dobra diagnoza tłumaczy technologię na konsekwencje biznesowe.
Trzeba oddzielić trzy rzeczy: stabilizację, rozwój i sprzątanie długu
W przejętym projekcie wszystko konkuruje o ten sam czas zespołu.
Biznes chce nowych funkcji. Operacje zgłaszają błędy. Developerzy widzą problemy techniczne. Stakeholderzy pytają o terminy. Klient chce przewidywalności kosztów.
Dlatego warto podzielić prace na trzy strumienie.
- Pierwszy strumień to stabilizacja. Tu trafiają rzeczy, które wpływają na działanie produkcji, obsługę użytkowników, bezpieczeństwo danych, monitoring, proces wdrożeń i krytyczne błędy.
- Drugi strumień to rozwój produktu. Tu trafiają funkcje, które realnie poszerzają możliwości biznesowe systemu.
- Trzeci strumień to redukcja długu technicznego. Nie jako abstrakcyjne „refaktoryzacje”, ale jako konkretne działania powiązane z ryzykiem, kosztem lub możliwością dalszego rozwoju.
To rozdzielenie jest ważne, bo pozwala prowadzić uczciwą rozmowę z klientem.
Nie każdy dzień pracy zespołu będzie oznaczał nową funkcję. Czasem największą wartością jest usunięcie ryzyka, które za miesiąc mogłoby zatrzymać operacje albo podwoić koszt kolejnej zmiany.
Transparentność musi być większa niż w normalnym projekcie
W projekcie takeover poziom zaufania jest zwykle obniżony. Klient ma za sobą trudne doświadczenie. Często słyszał już, że „jeszcze chwilę”, „to jest prawie gotowe”, „problem jest po stronie infrastruktury” albo „to tylko drobna poprawka”.
Nowy dostawca nie powinien próbować wygrać tej sytuacji deklaracjami.
Powinien wygrać ją przejrzystością.
To oznacza bardzo konkretne praktyki:
- wszystkie prace widoczne w Jira lub innym narzędziu,
- oddzielne oznaczanie incydentów, hotfixów i prac rozwojowych,
- regularna komunikacja o ryzykach,
- jasne pokazywanie, ile czasu pochłaniają awarie,
- dokumentowanie decyzji technicznych i produktowych,
- krótkie, częste demo zamiast dużych prezentacji raz na miesiąc,
- wspólna priorytetyzacja z biznesem.
Transparentność nie polega na produkowaniu długich statusów. Polega na tym, że klient rozumie, na co idzie budżet i dlaczego dana decyzja ma sens.
W pierwszych tygodniach trzeba zbudować mapę systemu
W wielu przejętych projektach dokumentacja nie opisuje realnego systemu. Czasem opisuje stan planowany. Czasem fragmenty sprzed kilku miesięcy. Czasem nie opisuje najważniejszych wyjątków, bo te były znane tylko poprzedniemu zespołowi.
Dlatego jednym z pierwszych zadań powinno być stworzenie praktycznej mapy systemu.
Nie chodzi o akademicką dokumentację. Chodzi o odpowiedzi na pytania:
- które procesy są krytyczne dla biznesu,
- które komponenty biorą udział w tych procesach,
- gdzie są punkty awarii,
- które dane mają jedno źródło prawdy, a które są duplikowane,
- jak wygląda proces wdrożenia,
- jak odtworzyć problem produkcyjny,
- które funkcje są kompletne, a które tylko częściowo zaimplementowane,
- które elementy nadal zależą od starego systemu,
- gdzie brakuje testów, monitoringu albo logów.
Taka mapa szybko zmienia rozmowę z klientem. Zamiast ogólnego „system jest skomplikowany”, można powiedzieć: „ten proces jest ryzykowny, bo zależy od trzech usług, nie ma monitoringu i w przypadku błędu nie mamy automatycznego odtworzenia stanu”.
To jest konkret.
Nie każdą rzecz trzeba naprawiać od razu
Przejęcie projektu łatwo zamienić w niekończący się remont.
Zespół techniczny widzi złe praktyki, obejścia, nieczytelny kod, brak testów, niespójne nazewnictwo, ręczne procesy wdrożeniowe. Naturalna reakcja: trzeba to poprawić.
Ale klient nie płaci za techniczną elegancję, tylko za odzyskanie kontroli nad produktem i za możliwość bezpiecznego rozwoju biznesu.
Dlatego każda większa naprawa powinna przejść przez filtr:
- Czy to zmniejsza ryzyko operacyjne?
- Czy to obniża koszt przyszłych zmian?
- Czy to skraca czas reakcji na awarie?
- Czy to odblokowuje ważny kierunek biznesowy?
- Czy to poprawia jakość danych lub decyzji operacyjnych?
Jeśli odpowiedź brzmi „nie”, to prawdopodobnie nie jest to priorytet na pierwszą fazę takeoveru.
W pierwszej kolejności naprawia się to, co stabilizuje system i zwiększa przewidywalność.
Klient musi dostać plan, ale plan z warunkami brzegowymi
Po diagnozie trzeba przygotować plan działania. Nie może to być jednak klasyczna roadmapa funkcji na kilka miesięcy, oderwana od stanu systemu.
Dobry plan przejęcia powinien mieć warstwy.
- Pierwsza warstwa: szybkie działania stabilizujące. Co robimy natychmiast, żeby zmniejszyć ryzyko awarii i poprawić obsługę produkcji.
- Druga warstwa: uporządkowanie procesu delivery. Jak zmieniamy workflow, definicję ukończenia, testy, środowiska, monitoring, wdrożenia i sposób raportowania.
- Trzecia warstwa: rozwój produktu. Jakie funkcje mają największą wartość biznesową i kiedy można je bezpiecznie realizować.
- Czwarta warstwa: decyzje architektoniczne. Co wymaga większej inwestycji, jakie są alternatywy, jaki jest koszt niewykonania zmian i jakie ryzyko zostaje zaakceptowane.
To ważne, bo w przejętym projekcie nie każda decyzja ma charakter „czy chcemy tę funkcję?”. Często decyzja brzmi: „czy akceptujemy dalsze rozwijanie produktu na niestabilnym fundamencie?”.
Najlepszy dostawca nie obiecuje cudów. Zapewnia kontrolę.
W projektach rescue i takeover klient często chce usłyszeć, że teraz będzie szybciej, taniej i prościej.
Dobry dostawca nie powinien tego obiecywać zbyt wcześnie.
Uczciwa odpowiedź brzmi: najpierw musimy odzyskać kontrolę nad systemem, potem możemy zwiększać tempo.
To nie jest asekuracja. To odpowiedzialność.
Skuteczne przejęcie projektu po poprzednim dostawcy wymaga jednocześnie kompetencji technicznych, produktowych i komunikacyjnych. Trzeba umieć czytać kod, ale też rozumieć proces biznesowy. Trzeba umieć nazwać dług techniczny, ale też przeliczyć go na ryzyko i koszt. Trzeba umieć powiedzieć klientowi, że kolejna funkcja powinna poczekać, jeśli jej wdrożenie może pogorszyć stabilność systemu.
Największą wartością dobrego takeoveru nie jest to, że po dwóch tygodniach wszystko wygląda lepiej w prezentacji.
Największą wartością jest to, że po kilku tygodniach klient wie:
- co ma,
- co działa,
- co nie działa,
- co jest ryzykowne,
- co trzeba naprawić,
- ile to może kosztować,
- i jakie decyzje musi podjąć.
Dopiero wtedy projekt przestaje być czarną skrzynką.
A to jest pierwszy warunek, żeby znowu zaczął być produktem, którym da się świadomie zarządzać.
Chcesz szybko zobaczyć, co naprawdę przejąłeś?
Diagnoza w projekcie takeover obejmuje nie tylko kod, ale też strategię produktu, discovery, delivery, alignment ze stakeholderami i sposób pracy zespołu. Product Health Checklist to 25 pytań w 5 obszarach – każde z kryteriami weryfikacji i nazwanym ryzykiem, które pomaga przełożyć ogólne „coś tu nie gra” na konkretne luki do omówienia z klientem.
Pobierz Product Health Checklist i przejdź przez nią z zespołem w pierwszym tygodniu przejęcia.
