Zmiana firmy IT w trakcie trwania projektu - 5 najczęstszych błędów
Doradca IT to artykuły i kanał YouTube, w których wyjaśniam IT w biznesowy sposób.
Kategorie:
Współpraca z wykonawcą ITProjekty ITZobacz kanał na YouTube
Zmiana firmy IT w trakcie trwania projektu to jeden z trudniejszych momentów, jakie mogą Cię spotkać jako właściciela firmy lub managera odpowiedzialnego za projekt. Z jednej strony czujesz, że coś nie działa — projekt się przeciąga, komunikacja kuleje, pojawiają się błędy i obietnice bez pokrycia. Z drugiej — zmiana wykonawcy to zawsze ryzyko, przestój i potencjalne koszty. Z mojego doświadczenia — mieliśmy kilku klientów, którzy przychodzili do nas z projektem w połowie drogi, często w stanie “krytycznym”. I prawie zawsze problemy wynikały z tych samych błędów, które można było łatwo uniknąć.
W artykule:
- najczęstsze błędy przy zmianie firmy it
- jak przygotować projekt do przekazania nowemu zespołowi
- jak uniknąć utraty wiedzy i ciągłości prac
- jak zapobiec powstawaniu długu technologicznego w trakcie zmiany
- co powinno znaleźć się w umowie i dokumentacji
Błąd 1: Brak zapisów o etapach projektu w umowie
To chyba najczęstszy problem, który widzę u nowych klientów. Projekt rozpoczął się „na zaufanie”, a w umowie nie ma jasno określonych etapów, kamieni milowych ani warunków odbioru prac. W efekcie, gdy pojawia się konieczność zmiany firmy IT, trudno ustalić, co zostało faktycznie zrobione, co wymaga poprawek, a co było tylko w planach. W jednym z projektów SaaS, który przejęliśmy, klient zapłacił 80% budżetu, a system był gotowy w połowie. Nie było jak tego rozliczyć — brakowało punktów odniesienia.
Jak temu zapobiec:
- określ w umowie jasne etapy projektu i warunki odbioru
- ustal, które funkcje muszą być ukończone, aby etap uznać za zakończony
- dbaj o dokumentację postępów – nawet prostą w Google Docs
Błąd 2: Brak spotkania przekazującego projekt nowej firmie IT
Często nowy zespół po prostu “dostaje” dostęp do kodu i ma dalej pracować — bez kontekstu i bez wiedzy o decyzjach architektonicznych czy zależnościach. Efekt? Zamiast kontynuować rozwój, zaczynają od audytu, cofania błędów i gaszenia pożarów. Z mojego doświadczenia — najlepsze przekazania to te, które zaczynają się od wspólnego spotkania starej i nowej firmy. W jednym projekcie webowym z branży finansowej takie spotkanie pozwoliło nam zaoszczędzić tygodnie pracy. Dowiedzieliśmy się, czemu poprzedni zespół podjął pewne decyzje i uniknęliśmy niepotrzebnego refaktoringu (poprawek w kodzie, ulepszania).
Jak zorganizować dobre przekazanie:
- zrób spotkanie online z oboma zespołami – nawet 2 godziny robią różnicę
- ustal kto odpowiada za wprowadzenie w projekt
- stwórz checklistę przekazania – kod, dokumentacja, dostęp, infrastruktura
- zadbaj o ton rozmowy – to nie ma być obwinianie, tylko transfer wiedzy
Błąd 3: Brak dokumentacji technicznej
Brak dokumentacji to prawdziwy klasyk. Kod może działać, ale bez opisów architektury, zależności czy procesów wdrożenia, nowy zespół działa po omacku. To nie tylko spowalnia rozwój, ale też zwiększa dług technologiczny — bo kolejne decyzje podejmowane są bez pełnego zrozumienia systemu. W jednym z projektów mobilnych klient nie miał żadnych notatek o tym, jak działa backend. Zajęło nam ponad miesiąc, żeby to wszystko rozgryźć. To czas, który mógł być poświęcony na rozwój, a nie na archeologię kodu.
Jak temu zapobiec:
- zadbaj aby firma IT tworzyła nawet prosty dokument techniczny – nawet 2 strony w Word lub Google Docs to już coś
Błąd 4: Brak dostępu do repozytorium kodu
Zaskakująco często spotykam się z sytuacją, że klient nie ma dostępu do swojego własnego repozytorium. Kod jest na koncie poprzedniego wykonawcy, a klient dostaje paczkę ZIP na koniec współpracy. To ogromny błąd, bo traci kontrolę nad swoim projektem. Repozytorium to nie tylko miejsce na kod, ale też historia zmian, komentarze, zgłoszenia błędów. Bez tego trudno ocenić, jak projekt się rozwijał.
Nigdy nie rozstawaj się z firmą IT w konflikcie.
Błąd 5: Zła komunikacja i brak relacji przy zmianie zespołu
Zmiana firmy IT to nie tylko kwestia techniczna — to proces, który wymaga zaufania i kultury współpracy. Jeśli przejście odbywa się w atmosferze konfliktu, nowy zespół startuje z problemem od pierwszego dnia. Zdarzyło mi się, że klient pożegnał poprzedni software house w bardzo emocjonalny sposób. Efekt? Nie dostaliśmy pełnych danych, dostępy były blokowane, a część dokumentacji po prostu „zniknęła”. Straciliśmy tygodnie na odzyskiwanie rzeczy, które można było przekazać w godzinę.
Jak tego uniknąć:
- zachowaj profesjonalizm – nawet jeśli współpraca się nie udała
- umów się na spokojne przekazanie projektu, najlepiej z osobą techniczną po stronie starego zespołu
- traktuj zmianę jako proces, nie jako zerwanie – chodzi o ciągłość biznesu
Podsumowanie
Zmiana firmy IT w trakcie projektu nie musi kończyć się katastrofą. Kluczowe jest przygotowanie, dokumentacja i dobra komunikacja. Jeśli zadbasz o te elementy, nowy zespół wejdzie w projekt płynnie, a Ty unikniesz utraty czasu, pieniędzy i nerwów. Nasi klienci, którzy przeszli przez taką zmianę świadomie, wychodzili z niej z mocniejszym projektem i lepszymi procesami. Pamiętaj, że każdy kryzys w IT można przekuć w okazję — jeśli potraktujesz go jak inwestycję w porządek, standardy i długofalowy rozwój Twojego systemu.
