Kiedy i dlaczego warto rozważyć zmianę partnera technologicznego?
Zmiana software houseu to decyzja strategiczna, która może znacząco wpłynąć na rozwój Twojego produktu i kondycję firmy, ale także stanu produktu i zadowolenia użytkowników. Warto więc, żeby ta decyzja była przemyślana, świadoma i dobrze zaplanowana. Zmiana partnera technologicznego to wyzwanie dla wszystkich trzech stron takiego przedsięwzięcia, więc na pewno nie powinna być pochopna czy podejmowana z błahych powodów.
Zmianę software houseu warto rozważyć, gdy pojawiają się poważne problemy z komunikacją, opóźnienia w realizacji zadań, spadek jakości dostarczanych rozwiązań lub utrata zaufania do partnera technologicznego – szczególnie jeśli projekt stale przekracza budżet, a wykonywane prace nie przynoszą obiecanego efektu biznesowego. Sygnałami ostrzegawczymi są również brak transparentności, ignorowanie potrzeb klienta, niedostateczne wsparcie techniczne, czy stosowanie przestarzałych technologii, co w dłuższej perspektywie może narazić firmę na dodatkowe koszty oraz utratę przewagi rynkowej.
Decyzję o zmianie warto podjąć, gdy nowy partner jest w stanie zagwarantować lepszą jakość kodu, skuteczną komunikację, profesjonalne podejście do prowadzenia projektu oraz realne wsparcie w rozwoju biznesowym. Odpowiednio przeprowadzona zmiana pozwala poprawić efektywność, bezpieczeństwo i stabilność aplikacji, minimalizując ryzyka biznesowe w przyszłości.
Rozpoznanie sygnałów alarmowych
Rozpoznanie sygnałów alarmowych w dotychczasowej współpracy z software housem wymaga czujnej obserwacji kilku kluczowych obszarów. Należą do nich regularne opóźnienia realizacji zadań, częste zmiany zespołu odpowiedzialnego za projekt czy powtarzające się błędy w dostarczanym oprogramowaniu. Takie symptomy często wynikają z niewłaściwego zarządzania projektem, braku jasno sprecyzowanych wymagań lub niedopasowania kompetencji zespołu do specyfiki realizowanego produktu.
Objawami mogą być także brak przejrzystości w raportowaniu postępu prac, niechęć do wprowadzania uzasadnionych zmian, nieustanne przekraczanie budżetu i przeciągające się wdrożenia nowych funkcji. Jeśli do tego dochodzi zjawisko spadku jakości wsparcia technicznego oraz widoczny brak dbałości o bezpieczeństwo i aktualizacje aplikacji, świadczy to o poważnych problemach organizacyjnych i może oznaczać konieczność zmiany dostawcy.
Szczególnym sygnałem alarmowym jest brak komunikacji, ponieważ pod jego „płaszczem” może być ukryte praktycznie wszystko. Dobry software house – nawet gdy ma problemy, które są naturalnym elementem wytwarzania i testowania nowego oprogramowania – będzie komunikował w miarę na bieżąco ich stan, problemy oraz podjęte środki zapobiegawcze lub naprawcze. Jeśli partner technologiczny ma problemy, ale komunikuje, może być tak że projekt jest problematyczny sam w sobie – na przykład ze względów innowacyjności czy niedowożenia przez zewnętrznych dostawców. W takim wypadku zmiana software houseu może nie poprawić sytuacji projektu.
Znalezienie nowego partnera
Nowy partner powinien mieć przede wszystkim to, czego w Twojej ocenie brakuje obecnemu partnerowi. Ale konieczne jest również, żeby posługiwał się biegle tymi samymi technologiami, z których obecnie korzystasz. Bardzo wartościowe jest przeszukiwanie i analiza portfolio software houseu z uwzględnieniem weryfikowalnych ocen – przykładowo Sailing Byte ma opinie zweryfikowane przez serwis Clutch.
Jeśli chcesz wiedzieć więcej, polecam cały artykuł na temat jak znaleźć odpowiedniego partnera technologicznego dla Twojego biznesu.
Planowanie ryzyka biznesowego w zmianie
Nie warto pomijać tego aspektu, ponieważ zapewnia on ciągłość działania i minimalizuje potencjalne przestoje w biznesie, a także frustrację klientów i pracowników. Stworzenie takiego planu pozwala na szybkie reakcje w sytuacjach kryzysowych, takich jak opóźnienia, problemy techniczne czy utrata kluczowych zasobów. Plan ten powinien zawierać identyfikację możliwych ryzyk, ich analizę jakościową i ilościową oraz przygotowanie strategii ich unikania, redukcji, przenoszenia lub akceptacji, co pozwala na zwiększenie odporności na nieprzewidziane sytuacje podczas zmiany. Taki plan będzie zupełnie inny dla każdego przypadku, ale przykładowo może zawierać takie elementy, jak:
- Regularne tworzenie i testowanie kopii zapasowych danych, wraz z instrukcjami odzyskiwania informacji w przypadku awarii.
- Przypisanie ról i obowiązków zespołu na czas kryzysu oraz ustalenie wielokanałowej komunikacji awaryjnej (telefon, e-mail, aplikacje).
- Opracowanie scenariuszy awaryjnych obejmujących różne typy ryzyk, np. awarie systemów, cyberataki, opóźnienia migracji czy problemy z dostawcami.
- Zapewnienie redundancji krytycznych systemów i infrastruktury, aby uniknąć pojedynczego punktu awarii.
- Mapowanie łańcucha dostaw IT i zapewnienie alternatywnych dostawców lub lokalizacji dla kluczowych usług i zasobów.
- Ustalenie celów RTO (Recovery Time Objective) i RPO (Recovery Point Objective) definiujących dopuszczalne czasy przestojów i utraty danych.
- Przeprowadzanie regularnych testów i aktualizacji planu, w tym symulacji sytuacji kryzysowych, aby utrzymać skuteczność i dostosować do zmieniającego się otoczenia.
- Dokumentowanie i monitorowanie ryzyk wraz z planem ich minimalizacji, redukcji lub akceptacji w zależności od ich wpływu na biznes.
Dla Twojego przypadku może to być zarówno za dużo jak i za mało – wszystko zależy od wielkości i krytyczności systemu – postaraj się więc dostosować taki plan pod Twój konkretny przypadek.
Audyt: dokumentacja, kod i środowisko
Jeśli na tym etapie wciąż skłaniasz się ku zmianie, następnym elementem będzie audyt – wejście nieco głębiej w technikalia projektu. Przygotowanie audytu projektu IT rozpoczyna się od zebrania pełnej i aktualnej dokumentacji – obejmuje ona specyfikację wymagań (zarówno funkcjonalnych, jak i niefunkcjonalnych), dokumentację architektury systemu, instrukcje wdrożeniowe, plany testów, opis użytkowników oraz listę wykorzystywanych technologii. Staranna dokumentacja pozwala zrozumieć założenia projektu, cel biznesowy i ułatwia ocenę, czy zrealizowane funkcjonalności są zgodne z początkowymi wymaganiami i standardami bezpieczeństwa. Dobrą praktyką jest przechowywanie wszystkich materiałów w repozytorium, gdzie są dostępne dla audytorów i zespołu projektowego.
Następnym krokiem po audycie jest analiza kodu źródłowego oraz środowisk wdrożeniowych. Jeśli relacja z software house’m jest zdrowa, to powinieneś bez problemu uzyskać dostęp do systemu kontroli wersji, dokumentacji kodu, informacji o strukturze baz danych, kluczach dostępów i konfiguracjach środowisk (dev, test, prod). Dzięki temu możliwa jest szybka identyfikacja długów technologicznych, potencjalnych zagrożeń oraz ocenienie gotowości projektu do dalszego rozwoju lub przekazania innemu podmiotowi.
Dużym problemem na tym etapie jest wybór audytora. Z oczywistych względów nie może on pochodzić z obecnego software house’u. Nie może to być też osoba niedoświadczona czy freelancer. Powinien to być developer lub zespół, który jest nie tylko doświadczony, ale zna też cały stack technologiczny projektu, oraz nie jest w żaden sposób związany z obecnym partnerem technologicznym. Ewentualnie można przeprowadzić oczywiście audyt samemu, ale trzeba rozumieć wszelkie technikalia aby był on wiarygodny i spójny.
Przygotowanie do zmiany partnera
Nowy partner, zaktualizowane wymagania
Definiując wymagania dla nowego software houseu możemy wykorzystać wszystkie powyższe uzyskane informacje, ale należy je uzupełnić o czynniki jakościowe które zdecydowały o fiasku dostarczenia projektu. Czyli na przykład jeśli problemem była jakość, to przed zmianą partnera warto określić jakiej jakości należy oczekiwać – przez ustawienie odpowiednich KPIs. Wymagania powinny obejmować także oczekiwania dotyczące współpracy, komunikacji i raportowania postępów, co pozwala na jasne ustalenie zakresu prac i sposobu ich realizacji. Ważnym aspektem jest także doprecyzowanie oczekiwań dotyczących wsparcia po wdrożeniu oraz zarządzania zmianami, co ułatwi płynne i efektywne prowadzenie projektu.
Bezbolesny transfer wiedzy
Transfer wiedzy jest jednym z najważniejszych etapów zmiany dostawcy, dlatego niezbędne jest kompleksowe przekazanie dokumentacji projektowej, kodu źródłowego, danych oraz konfiguracji środowisk. Tylko przekazanie kompletu informacji zapewnia maksymalnie łatwy proces oceny stanu projektu oraz możliwości jego przejęcia. Nowy software house powinien poznać nie tylko aspekty techniczne, ale też oczekiwania biznesowe dotyczące projektu. Takie działania sprzyjają szybkiej adaptacji i minimalizują ryzyko utraty informacji, zapewniając płynne kontynuowanie rozwoju projektu bez opóźnień i zakłóceń. Jeśli obawiasz się co do reakcji obecnego software houseu lub powoduje to ryzyko biznesowe, postaraj się przekazać te informacje bez wiedzy obecnego dostawcy. Nie powinno to być żadnym problemem, jeśli posiadasz autorskie prawa majątkowe do kodu.
Upewnij się co do stanu autorskich praw majątkowych
Upewnienie się co do autorskich praw majątkowych jest kluczowe przy zakończeniu współpracy z software housem, aby zapewnić firmie pełną kontrolę nad stworzonym oprogramowaniem i możliwością jego dalszego rozwoju. Należy zadbać, by umowa jednoznacznie przenosiła na zamawiającego majątkowe prawa autorskie do kodu źródłowego, dokumentacji i innych rezultatów prac, co gwarantuje legalne korzystanie, modyfikację i dystrybucję produktu. Brak takich zapisów może prowadzić do ryzyka uzależnienia od dostawcy i ograniczenia możliwości rozwoju oprogramowania bez jego zgody. Jeśli współpraca z obecnym software housem nie układa się najlepiej, może to być jeden z bardziej problematycznych punktów, więc warto się do niego przygotować.
Ustal szczegóły nowej współpracy
Jeśli szczegóły współpracy zostały wstępnie ustalone z nowym software housem, następnym etapem będzie ustalenie harmonogramu zmiany. Powinien on zawierać etapowy plan migracji z uwzględnieniem minimalizacji przestojów i ryzyka przerw w działaniu biznesu. W praktyce oznacza to m.in. realizację migracji podczas okresów niższego obciążenia, wykonywanie testowych migracji na środowiskach zapasowych oraz przygotowanie scenariuszy awaryjnych na wypadek problemów. Kluczowe jest także dokładne przypisanie ról i zasobów, zarówno po stronie klienta, jak i nowego software houseu, oraz stałe monitorowanie postępów i szybkie reagowanie na ewentualne trudności.
Pamiętaj o pułapkach, postępuj ostrożnie
Powyższe akapity opisują jednak najprostszy przypadek, kiedy to obecny dostawca jest rozumiejący i współpracujący. Natomiast niestety, z biznesowego punktu widzenia należy uwzględniać ryzyko stwarzania faktycznych lub wyimaginowanych problemów przez dotychczasowego dostawcę. Jeśli podejrzewasz, że obecny dostawca może „sprawiać problemy”, należy solidnie się przygotować i ściśle współpracować z nowym dostawcą. Ponieważ przetwarzaliśmy już w naszym zespole takie sytuacje, polecam bezpośredni kontakt do Sailing Byte korzystając z formularza na dole strony – każdy przypadek jest inny, a my chętnie pomożemy w takich sytuacjach.
Testowy pilotaż nowego zespołu na małym module (opcjonalnie)
Jest to krok możliwy tylko, gdy z biznesowego punktu widzenia jesteś w stanie ocenić, że tymczasowa współpraca trójstronna jest w ogóle możliwa. W ramach pilotażu nowy zespół realizuje konkretne, niewielkie zadanie lub moduł produktu, co pozwala poznać metody pracy, narzędzia, komunikację oraz sposób rozwiązywania problemów. Taki pilotaż umożliwia identyfikację potencjalnych wyzwań i dostosowanie procesów zanim zostanie podjęta decyzja o pełnym przejęciu projektu.
Podczas testowego pilotażu istotne jest monitorowanie jakości dostarczanego kodu, terminowości realizacji oraz zaangażowania zespołu w komunikację i szybkie reagowanie na feedback. Dzięki temu można zweryfikować, czy nowy partner spełnia oczekiwania i jest w stanie efektywnie współpracować. Ponadto pilotaż może być wykorzystany do transferu wiedzy i integracji zespołów, co ułatwia pełne wdrożenie i dalszy rozwój projektu. Umożliwia to stopniowe przekazanie odpowiedzialności, naukę specyfiki kodu, narzędzi i architektury, a także omówienie oczekiwań i standardów jakościowych.
Optymalizacja procesu przekazania projektu (opcjonalnie)
Ten krok również jest możliwy tylko, gdy współpraca trójstronna jest możliwa, a kod i procesy mają zapewnione jakiekolwiek rozpoznawalne standardy. Optymalizacja procesu przekazania wiedzy i kodu pomiędzy software houseami wymaga ustalenia jasnych standardów kodu i ciągłej integracji (CI/CD). Narzędzia do zarządzania wiedzą i dokumentacją, takie jak repozytoria kodu (np. Git), systemy zarządzania projektami i bazami wiedzy, umożliwiają centralizację informacji i szybki dostęp dla nowego zespołu. Standardy kodu, zdefiniowane na poziomie konwencji, jakości i testowania, pomagają zachować spójność i ułatwiają utrzymanie projektu, a zautomatyzowane pipeliney CI/CD zapewniają sprawny proces wdrożeniowy, z szybkim wykrywaniem błędów i minimalizacją ryzyk w takcie integracji. Przykładowo: nowy software house może przygotować nową infrastrukturę produkcyjną i testową, a obecny zespół może w pipeline dopisać nowe serwery do deploymentu – w ten sposób nowy zespół może przetestować infrastrukturę bez zaburzania obecnych prac i deploymentu.
Podpisanie umowy na polubowne zakończenie współpracy
Ten krok może być czasem wymagany, na przykład gdy obecny dostawca rości autorskie prawa majątkowe do wytworzonego kodu lub dokumentacji. Najczęściej w momencie gdy pojawia się pomysł podpisania umowy polubownej to już wszystkie zainteresowane strony wiedzą o sobie wzajemnie i proces przejęcia kodu przez nową firmę nie jest tajemnicą. Konieczna może być konsultacja nie tylko z prawnikiem, ale też z nowym software housem – choćby co do zakresu wykorzystania starego kodu. Na przykład w Sailing Byte przerabialiśmy takie przypadki, że nie było potrzeby przekazania autorskich praw majątkowych do kodu, ponieważ kod był w stanie nienadającym się do niczego – co było wykorzystywane jako argument przez prawników przy omawianiu odszkodowania. Warto mieć więc na uwadze, że jest to etap angażujący wiele stron.
Rozpoczęcie nowej współpracy
Na tym etapie powinno to już być bardzo proste, lub nawet wydarzyło się już w trakcie poprzednich etapów. Niemniej na koniec i tak warto się upewnić co do kilku elementów, na przykład:
- Czy kanały komunikacji są ustalone między stronami i działają poprawnie?
- Czy najbliższe zadania są jasne dla zespołu i zespół wie jak je dowieźć?
- Czy scrum master lub project manager nie ma żadnych pytań i wie jakie następne kroki podjąć?
- Czy system na produkcji działa?
- Czy wszyscy wiedzą kiedy jest następne spotkanie retrospective lub sprint planning?
Sprawdzenie takich podstaw zajmie tylko chwilę a na pewno da wszystkim stronom więcej pewności co do następnych kroków.
Podsumowanie: jak poszła zmiana software houseu?
Po jakimś czasie warto zrobić ewaluację jak wygląda nowa współpraca. Jeśli uwzględniłeś wszystko co opisałem powyżej, powinno być lepiej niż było. Jeśli nie – dobry scrum master powinien mieć już to wyłapane do omówienia na retrospektywie.
Decyzja o zmianie partnera technologicznego to strategiczny krok, który powinien być podjęty świadomie i w oparciu o konkretne przesłanki. Właściwie przeprowadzony proces zmiany pozwala nie tylko zminimalizować ryzyka biznesowe, ale także zyskać partnera lepiej dopasowanego do potrzeb projektu, który zapewni stabilność, efektywność i wsparcie na dalszym etapie rozwoju produktu. Jeśli jesteś zainteresowany zmianą swojego obecnego partnera technologicznego na Sailing Byte lub chcesz porozmawiać jak taka zmiana mogłaby wyglądać – skorzystaj z formularza pod spodem i odezwij się do nas. Może to być początek nowego pięknego partnerstwa!
