Jak zacząć modernizację starszej platformy e-commerce, nie wywracając wszystkiego innego

Zwykle zaczyna się od drobiazgu

Programista wspomina, niemal mimochodem, że nowa funkcja w procesie zakupowym zajmie sześć tygodni. Myślałeś, że dwa. Nie protestujesz – nauczyłeś się już nie dyskutować z estymacjami, bo i tak zawsze okazują się zbyt optymistyczne. Mówisz więc „OK” i idziesz dalej.

Potem w piątkowy wieczór wdrożenie się sypie i zespół spędza weekend na gaszeniu pożaru. W pewnym momencie niedzielny wieczór zostaje nieformalnie zarezerwowany właśnie na to. Potem poniedziałkowy poranek – na naprawianie tego, co popsuła niedziela. Potem do zespołu dołącza nowy programista i potrzebuje trzech miesięcy, zanim zacznie samodzielnie cokolwiek wdrażać. Potem ktoś pyta o integrację jednego z narzędzi AI, o których wszyscy mówią, i słyszy w odpowiedzi: „nasz system raczej tego nie obsłuży”.

W końcu dociera do ciebie, że platforma się nie sypie. Po prostu po cichu sprawia, że wszystko jest trudniejsze, niż powinno. I nie wiesz, od czego zacząć.

To sytuacja częstsza, niż przyznaje większość założycieli firm. I pilniejsza niż kiedyś – bo platforma, która spowalnia rozwój, blokuje dziś także wdrażanie narzędzi zmieniających sposób, w jaki działa e-commerce. Z każdym miesiącem czekania rośnie przepaść między tym, co potrafi twój system, a tym, co budują twoi konkurenci. I ta przepaść narasta coraz szybciej.
Oto, czego nauczyłem się, wchodząc w wiele takich projektów: platforma prawie nigdy nie jest tym problemem, za który się ją uważa. A pierwszy ruch prawie nigdy nie jest tym, który wydaje się oczywisty.

Audyt, którego nikt nie chce robić

Nie szacowanie. Nie zakładanie. Prawdziwe zrozumienie.

Pierwszym krokiem zawsze jest audyt – dokładne przeczytanie kodu, zanim cokolwiek zostanie zmienione. Nie po to, żeby stworzyć dokument, który trafi do szuflady, ale żeby naprawdę zmapować teren: gdzie leży realne ryzyko, które części systemu są strukturalnie w porządku i wymagają tylko uporządkowania, które trzeba traktować ostrożnie i jak wygląda realistyczna droga naprzód.

To ma większe znaczenie, niż się wydaje. W starszych platformach niemal zawsze jest różnica między tym, co wygląda źle, a tym, co naprawdę jest złe. Niektóre rzeczy są nieporządne, ale na razie można je bezpiecznie zostawić. Inne wyglądają dobrze, a po cichu są niebezpieczne. Nie da się priorytetyzować pracy, której się nie rozumie – a jeśli zaczniesz naprawiać bez tej mapy, poświęcisz czas na niewłaściwe problemy i stworzysz nowe.

Audyt daje ci też coś konkretnego. Po nim wiesz, co masz. Możesz podejmować decyzje na podstawie faktów, a nie założeń – w kwestii zakresu, kosztów i ryzyka. To zupełnie inna rozmowa niż „musimy zmodernizować platformę” bez żadnego doprecyzowania.

Efektem jest krótki dokument:

• oto, co znaleźliśmy,
• oto, co jest naprawdę ryzykowne,
• oto, jak wyglądają pierwsze trzy miesiące.

Nie roadmapa zbudowana na domysłach. Plan oparty na faktycznym systemie.

Mało efektowna praca, która umożliwia wszystko inne

Gdy już rozumiesz system, odruchowo chcesz przejść do funkcji. Backlog jest długi. Biznes czeka od dawna. Jest presja, żeby pokazać postępy.

Ten odruch prowadzi do problemów. Pierwszym prawdziwym krokiem – przed jakimikolwiek zmianami w architekturze, przed jakimikolwiek nowymi funkcjami – jest zbudowanie siatki bezpieczeństwa.

To oznacza zautomatyzowane wdrożenia, dzięki którym wydania przestają być wydarzeniami, przy których wszyscy wstrzymują oddech. Monitoring produkcji, dzięki któremu problemy wychodzą na jaw, zanim trafią na nie klienci. Pokrycie testami zwiększasz stopniowo, w miarę pracy z kodem – w przypadku większości platform, które działają od lat bez testów, zaczynając od zera.

Nic z tego nie jest efektowne. Nic z tego nie dostarcza nowych funkcji. Ale zmienia wszystko, co przychodzi potem. Gdy wdrożenia są zautomatyzowane, wydania stają się nudne – to coś, co dzieje się we wtorek po południu i nikt tego nie śledzi. Celem dobrego procesu wydań jest to, żeby nikt nie zauważył, że wydanie w ogóle się odbyło. Jeśli twój zespół gratuluje sobie po każdym wdrożeniu, coś jest nie tak. Gdy działa monitoring, incydenty przestają być niespodzianką. Gdy są testy, kod przestaje być czymś, czego boisz się dotknąć.

Większość projektów modernizacyjnych pomija ten etap albo go odkłada. Łatwo zrozumieć dlaczego – nie wygląda to na postęp, a wszyscy zaangażowani są pod presją, żeby go pokazać. Przechodzą więc od razu do ekscytującej pracy – nowej architektury, nowych funkcji – a infrastrukturę zostawiają na później. To „później” zwykle nie nadchodzi. A bez siatki bezpieczeństwa każda zmiana niesie większe ryzyko, niż powinna.

Większość nie wymaga naprawy. Cała sztuka polega na tym, by ustalić, co jej wymaga

Gdy siatka bezpieczeństwa jest na miejscu, zaczyna się właściwa praca. I to tutaj priorytetyzacja ma znaczenie większe niż niemal cokolwiek innego.

Nie wszystko w starszym kodzie trzeba naprawiać. Niektóre rzeczy są brzydkie, ale nieszkodliwe. Niektóre są błędne od lat, a biznes po cichu się do nich dostosował – do tego stopnia, że ich naprawa wymagałaby najpierw spotkania, na którym trzeba by wyjaśnić, dlaczego w ogóle trzeba je naprawić, co samo w sobie staje się problemem do ogarnięcia. Próba naprawienia wszystkiego – każdego zakamarka systemu, każdego nagromadzonego skrótu – to prosta droga do tego, by modernizacja zamieniła się w roczną mordęgę bez wyraźnego końca i bez wyraźnych efektów.

Właściwe pytanie nie brzmi „co jest nie tak”, tylko „co w tej chwili realnie kosztuje biznes”. Krytyczne ścieżki, na których powolna architektura skraca każdy termin. Moduły, w których odejście jednej osoby wywołałoby prawdziwy kryzys. Integracje, przez które uciekają przychody albo niezawodność. Zmiany, które odblokowują najwięcej przyszłej pracy.

Przykład: platforma e-commerce sprzedająca towary z drugiej ręki na aukcjach na żywo – obsługująca tysiące żądań na minutę – kilka lat temu trafiła dokładnie na ten problem. Pierwszym sygnałem był skok kosztów infrastruktury, którego nikt nie potrafił wyjaśnić. Programiści przyglądali mu się od tygodni. Bez diagnozy.

Gdy kod przeszedł rzetelny audyt, okazało się, że skoki kosztów były tylko objawem. Prawdziwe problemy sięgały głębiej: brak pipeline’u CI/CD, brak testów automatycznych, brak monitoringu produkcji. Każde wydanie było ręczne i wdrażane instancja po instancji. Integracja płatności miała znane błędy, które po cichu obniżały konwersję. Skoki kosztów były tym, co dało się zmierzyć. Pod spodem kryły się rzeczy, których już nikt nie zauważał.

Najpierw naprawiono skoki kosztów – bo to krwawiło od razu. Potem powstała siatka bezpieczeństwa. Potem przyszła kolej na resztę platformy, jedna krytyczna ścieżka po drugiej. Bez przepisywania od zera. Bez zamrażania rozwoju funkcji. Platforma przez cały czas działała, a nowe wersje regularnie trafiały na produkcję.

Liczby na koniec współpracy: przychody podwoiły się w porównaniu z momentem pierwszego wydania. Uptime wzrósł z niespełna 95% – co brzmi akceptowalnie, dopóki nie uświadomisz sobie, że oznacza ponad 400 godzin przestoju rocznie – do ponad 99,99% w ostatnim roku. Każde wydanie zostało w pełni zautomatyzowane. Operacje na danych, które wcześniej trwały minuty, zaczęły trwać sekundy.

Nic z tego nie wymagało zaczynania od zera. Wymagało zajęcia się właściwymi problemami we właściwej kolejności.

Platforma działa przez cały ten czas

Obawa, którą ma większość założycieli, gdy myśli o modernizacji, jest uzasadniona: masz działającą platformę, która generuje przychody, i nie możesz sobie pozwolić na wyłączenie jej na pół roku, aż ktoś ją przebuduje.

Nie musisz.

Opisane wyżej podejście – najpierw audyt, siatka bezpieczeństwa przed funkcjami, stopniowe usprawnienia po jednej krytycznej ścieżce naraz – zostało zaprojektowane właśnie po to, by produkt działał przez cały czas. Prace modernizacyjne toczą się równolegle z normalnym rozwojem. Nowe funkcje wciąż powstają. Biznes działa dalej. Platforma odzyskuje zdrowie krok po kroku, a nie w jednym ryzykownym skoku.

W krótkim terminie to wolniejsze niż przepisanie od nowa. Wymaga dyscypliny – przemyślanych decyzji o tym, co naprawić teraz, a co może poczekać, i budowania prawdziwego zrozumienia przed wprowadzeniem zmian strukturalnych. Ale w przypadku platformy, która już obsługuje prawdziwych klientów i generuje prawdziwe przychody, to właściwa decyzja. Pełne przepisanie od zera niesie większe ryzyko, niż zakłada większość zespołów na starcie, a o wiele mniej takich projektów kończy się w terminie i w zakładanym zakresie, niż ktokolwiek chciałby przyznać.

Od czego zacząć – konkretnie

Pytanie „od czego zacząć” zwykle ma nudną odpowiedź: od sprawdzenia, co tak naprawdę masz. Nie od planowania przepisania systemu, nie od wyceniania półrocznego projektu – tylko od uzyskania rzetelnego obrazu kodu, tego, gdzie naprawdę leży ryzyko, i tego, jaki powinien być pierwszy ruch.

To mniejszy pierwszy krok, niż spodziewa się większość osób. I to właśnie on pozwala podjąć wszystkie kolejne decyzje.

Jeśli jesteś właśnie w tym miejscu, chętnie o tym porozmawiamy. Bez sprzedażowej prezentacji i bez oferty na pierwszej rozmowie – po prostu szczera rozmowa o tym, z czym się mierzysz i czy do siebie pasujemy.