Jak powinno wyglądać przejęcie projektu [Lista kontrolna]
Zmiana dostawców oprogramowania nie jest łatwą decyzją. Zwykle wynika z frustracji, wolniejszych aktualizacji produktu lub utraty zaufania do zespołu technicznego. Większość klientów wymienia te same powody:
Dostawca nie dostarcza wartości: Łamie dane obietnice. Opóźnienia w terminach powodują, że kluczowe etapy projektu i jego pełne wdrożenie przesuwają się.
Produkt jest niestabilny i wadliwy: Błędy ujawniają się na długo po premierze, często z powodu niewystarczających testów. Klienci doświadczają również powtarzających się regresji, gdy wcześniej działające funkcje przestają działać.
Oprogramowanie jest niebezpieczne: Luki w zabezpieczeniach powodują szkody finansowe lub wizerunkowe.
Dostawcy brakuje przejrzystości i odpowiedzialności: Klient nie wie, co faktycznie dzieje się w projekcie, dostawca ukrywa problemy, a kiedy zostają odkryte, nikt nie bierze za nie odpowiedzialności.
W Pragmatic Coders regularnie przejmujemy projekty, które inni rozpoczęli, ale nie ukończyli – lub ukończyli w sposób, który nie spełniał oczekiwań biznesowych naszych klient. Oto, jak podchodzimy do przejmowania projektów.
Audyt
Zaczynamy od audytu. Co istotne, ten audyt jest głównie dla nas (do zbudowania naszego planu; jednak często zdarza się, że nasi klienci wykorzystują audyt dla swoich interesariuszy) i odbywa się równolegle z początkowymi, priorytetowymi działaniami dla klienta. Przeprowadzamy audyt, aby stworzyć konkretny plan spłaty długu technicznego w sposób, który nadal pozwala nam dostarczać nową wartość biznesową.
Najpierw chcemy zrozumieć produkt, jego cele i jego użytkowników. Zaczynamy od rozmów:
Z klientem: Pytamy, jak produkt działa i jaka jest jego kluczowa wartość.
Z klientem i zespołem klienta: Pytamy, gdzie widzą problemy.
Z użytkownikami (najpierw wewnętrznymi, potem zewnętrznymi): Pytamy, co nie działa w codziennym użytkowaniu.
Te rozmowy ujawniają problemy, których nie da się dostrzec w kodzie. Pokazują, co naprawdę wymaga naprawy, a nie tylko to, co wygląda na zepsute. Na jaw wychodzi również stan emocjonalny klienta – napięcia i frustracje – co może hamować realizację nawet najlepszego planu technicznego.
Plan Przejęcia (Wynik Audytu)
Faza Audytu kończy się konkretnym Planem Przejęcia = planem tego, co musimy zrobić i kiedy. Dokument ten jest wynikiem naszego “dochodzenia” i przedstawiamy go klientowi, aby pokazać, co naszym zdaniem powoduje problemy w projekcie. W kolejnych fazach dokument ten pomaga nam też w zarządzaniu komunikacją z klientem (głównym interesariuszem).
Celem planu jest zaradzenie długowi produktu (nie tylko technicznemu) w określonych ramach czasowych, jednocześnie upewniając się, że kamienie milowe biznesowe klienta nie są blokowane. Innymi słowy: wspólnie z klientem tworzymy backlog, który obejmuje zarówno naprawę krytycznych problemów technicznych, jak i zobowiązania do dostarczania NOWEJ wartości biznesowej.
Na podstawie tego planu jesteśmy w stanie:
Zdefiniować niezbędne kompetencje: Określamy dokładny skład zespołu potrzebny do realizacji planu, włączając w to role takie jak Product Owner, Projektant UX i specyficzne stanowiska deweloperskie.
Przygotować harmonogram i rezultaty dla eliminowania zidentyfikowanego długu.
Sporządzić listę kontrolną bezpieczeństwa i dostępu: Udokumentować i przetransferować wszystkie kluczowe aktywa:
Repozytoria kodu źródłowego (np. Git)
Konta wdrożeniowe i hostingowe (np. AWS, Azure)
Poświadczenia usług stron trzecich (np. bramki płatności, analityka)
Instrukcje konfiguracji środowiska deweloperskiego
Wymienić i uszeregować dług techniczny z audytu: Tutaj ponownie skupiamy się na długu technicznym związanym z CI/CD i testowaniem, aby przyspieszyć rozwój i poprawić jakość.
Elementy długu, które znajdujemy najczęściej, to dokładnie te same problemy, których szukamy podczas audytu: brak dostępu, brak obserwowalności, brak CI/CD i nieodpowiednie testowanie. I te cztery rzeczy staramy się zrobić w pierwszej kolejności:
1. Odzyskanie kontroli technicznej
Zaskakująco często okazuje się, że klient nie ma pełnego dostępu do swojej własności intelektualnej. Klienci mogą nie mieć dostępu do repozytorium czy haseł do serwera, a dokumentacja istnieje tylko „gdzieś w Notion”. Zatem pierwszym krokiem technicznym jest odzyskanie kontroli:
Uzyskanie pełnego dostępu do repozytoriów, środowisk i usług.
Ustalenie jasnych ról i uprawnień.
Potwierdzenie, kto jest właścicielem kodu, danych i infrastruktury.
Zebranie całej dokumentacji w jednym miejscu.
2. Wdrożenie CI/CD
Gdy już wiemy, że produkt działa (lub przynajmniej rozumiemy, gdzie nie działa), skupiamy się na poprawie procesów deweloperskich. Celem jest dostarczanie wartości szybciej i z większą pewnością. Wtedy wdrażamy właściwy proces CI/CD.
Czym jest CI/CD?
CI/CD (Continuous Integration/Continuous Deployment) to proces automatyzacji cyklu życia wydawania oprogramowania. Jest realizowany za pomocą zautomatyzowanego flow, gdzie zmiany w kodzie są automatycznie testowane, automatycznie wdrażane do środowisk i gotowe do wydania na produkcję w dowolnym momencie.
W praktyce oznacza to, że każdy deweloper może wprowadzić zmianę, system automatycznie uruchamia testy (w tym testy end-to-end), a jeśli wszystko przejdzie, kod może trafić na produkcję bez czekania na ręczne wdrożenie.
Mniej błędów, szybsze dostarczania i pełna przewidywalność w procesie dostarczania. Z punktu widzenia klienta, CI/CD oznacza, że każda poprawka, funkcja lub decyzja biznesowa może dotrzeć na produkcję tego samego dnia.
Brak CI/CD jest często cechą charakterystyczną projektów, które się nie powiodły – a jeśli jest już proces ten jest wdrożony, projekty te zazwyczaj* nie potrzebują pomocy. * Czasami CI/CD jest wdrożony, ale używany w niewłaściwy sposób. Typowe przypadki:
CI/CD to tylko flow uruchamiane ręcznie przez zespół, więc tak naprawdę nie jest to ciągła integracja ani dostarczanie.
Firmy nadal używają GitFlow w sposób, który nie wspiera ciągłej integracji (np. kod jest scalany z główną gałęzią dopiero po kilku tygodniach).
W CI/CD brakuje kontroli jakości, więc oprogramowanie musi być testowane ręcznie po wdrożeniu.
Tak było w przypadku platformy do zbierania funduszy opartej na blockchainie, której backend był tak zepsuty, że własny zespół klienta nie mógł go uruchomić – pełen błędów składni i wyłączonych linterów. Odbudowaliśmy go od zera, dodaliśmy CI/CD i nowe smart kontrakty, i przekształciliśmy go w stabilny system gotowy na kampanie o dużym ruchu. Inny case: platforma PropTech z ZEA. Po przejęciu produktu wprowadziliśmy Scrum, obserwowalność i szybsze cykle iteracji. W ciągu kilku tygodni dostępność systemu osiągnęła prawie 100%, a wewnętrzny zespół klienta odzyskał pełną kontrolę nad swoim procesem deweloperskim.
3. Zapewnienie obserwowalności
Dopiero wtedy wdrażamy obserwowalność. Oznacza to gromadzenie i łączenie danych takich jak logi, metryki i ślady, abyśmy mogli zobaczyć, jak system zachowuje się w czasie rzeczywistym: gdzie zwalnia, jakie błędy występują i jak przepływają żądania przez różne usługi.
Obserwowalność i automatyzacja często stanowią różnicę między „gaszeniem pożarów” a solidnym, pewnym dostarczaniem.
W przypadku jednego z naszych klientów bankowych proces wdrożenia trwał dwa dni, a ręczne testowanie spowalniało cykl dostarczania. Po wprowadzeniu zautomatyzowanych linii CI/CD, zarządzania infrastrukturą i monitorowania, czas wdrożenia skrócił się do dwóch godzin, a bank zaoszczędził 400 000 funtów w pierwszym roku.
4. Testowanie charakteryzacyjne
Przyjmujemy podejście, które Michael Feathers opisał w Working Effectively with Legacy Code (2004) – używamy testów charakteryzacyjnych, aby dowiedzieć się, jak system naprawdę się zachowuje i upewnić się, że nie zepsujemy tego, co już działa.
Czym jest testowanie charakteryzacyjne?
Testy charakteryzacyjne są z grubsza tym samym, co testy black-box lub end-to-end. Ich celem jest zrozumienie, co faktycznie robi istniejący, często nieudokumentowany kod. Piszesz testy, które rejestrują obecne zachowanie systemu – nawet jeśli zawiera błędy – abyś mógł później bezpiecznie refaktoryzować bez przypadkowej zmiany sposobu jego działania.
W przypadku przejęcia systemu legacy platformy automatyzacji e-commerce, konieczna była odbudowa testowania i obserwowalności od zera. Gdy tylko wprowadzono monitoring i testy regresyjne, liczba dziennych incydentów zmalała z 1,5 miliona do zaledwie 500, co dało poprawę o 99,97%.
Określenie zasad zarządzania i przebiegu prac
Aby klient mógł mieć pewność, że wywiązujemy się z obietnic, wprowadzamy jasne procesy:
Przejrzyste zarządzanie zakresem prac i budżetem: Wprowadzamy jasny proces zarządzania zmianami zakresu prac, aby uniknąć scope creep. Proces ten jest bezpośrednio związany z monitorowaniem finansowym: jeśli ryzykujemy przekroczenie budżetu, natychmiast inicjujemy otwartą rozmowę, przedstawiając propozycję rozwiązania, która pozwoli nam wrócić do harmonogramu.
Definiowanie naszej pracy i narzędzi: Zobowiązujemy się do pracy w krótkich, jasnych iteracjach. Narzędzia do zarządzania projektami (np. Jira), kontrola wersji oraz kanały komunikacji są wykorzystywane konsekwentnie do monitorowania postępów, bazując na klarownej Definicji Ukończenia (DoD). Ta DoD zawsze będzie obejmować monitorowanie zużycia budżetu i zostanie spełniona poprzez wdrożenie na produkcję albo przejrzystą aktualizację roadmapy, jeśli produkt nie jest jeszcze uruchomiony.
Aktywne i konsekwentne angażowanie klienta: Ustalimy regularny harmonogram spotkań, w tym codzienne spotkania stand-up oraz przeglądy sprintów, aby wszyscy interesariusze byli na bieżąco z postępami w projekcie. Naszym celem jest zaangażowanie klienta w naszą codzienną pracę. Przeglądy sprintów są „rzeczywistymi przeglądami”, a nie tylko demonstracjami. Aktywnie angażujemy w nie klienta i użytkowników, by potwierdzić, czy dostarczony wynik jest zgodny z ich oczekiwaniami.
Podsumowanie
Powszechnie spotykamy się z sytuacją, w której poprzedni dostawca usprawiedliwia braki w jakości czy funkcjonalności wymogami biznesowymi (“nie mieliśmy czasu, bo klient chciał czegoś innego”). Choć jest to trudne do uniknięcia, dobra firma nie powinna w ogóle dopuścić do takiej sytuacji. W Pragmatic Coders nie popełniamy tego błędu.
Rezultat? Klient ma gwarancję sukcesu, a produkt rozwija się we własnym, stabilnym tempie.
Gotowi odzyskać kontrolę nad swoim projektem? Zapraszamy do współpracy.
