Ratowanie i przejęcie projektów Magento

Projekt Magento nie musi być przepisywany od zera tylko dlatego, że obecny wykonawca nie dowozi, błędy wracają, a każda kolejna zmiana staje się coraz trudniejsza.

Przejmujemy problematyczne platformy Magento, diagnozujemy źródła problemów i stabilizujemy kluczowe obszary. Celem nie jest kolejne gaszenie pożaru, ale doprowadzenie projektu do stanu, w którym można ponownie przewidywalnie go rozwijać.

Bezpłatna rozmowa, 30-60 minut. Poznamy stan projektu, najpilniejsze problemy i dotychczasowy model współpracy. Wstępnie określimy, jak bezpiecznie przejąć platformę i od czego zacząć stabilizację.

Kontekst

Kiedy problemem przestaje być pojedynczy błąd

Do projektu Rescue firmy najczęściej trafiają wtedy, gdy problemy zaczynają tworzyć powtarzalny wzorzec.

Poprzedni wykonawca potrzebuje coraz więcej czasu na wprowadzanie zmian.

Backlog rośnie szybciej, niż jest realizowany.

Te same błędy wracają po kolejnych poprawkach.

Nowe funkcje destabilizują inne części systemu.

Sklep ma problemy z wydajnością albo okresowo przestaje działać poprawnie.

Wewnętrznie coraz trudniej odpowiedzieć na podstawowe pytania: czy problem leży w kodzie, integracji, bazie danych, infrastrukturze, czy w sposobie prowadzenia projektu.

Wspólnym mianownikiem jest utrata przewidywalności. Platforma może nadal sprzedawać, ale przestaje być systemem, na którym można bezpiecznie planować dalszy rozwój.

Rescue nie polega na zamknięciu kilku ticketów. Chodzi o odzyskanie kontroli nad platformą.

Diagnoza

Najpierw diagnoza, później deklaracje

Nie zaczynamy od założenia, że wiemy, co trzeba przepisać.

Pierwszą rozmowę wykorzystujemy do poznania obecnej sytuacji, historii projektu i najważniejszych objawów. Na podstawie dostępnych informacji możemy wstępnie ocenić skalę problemu i określić, które obszary wymagają głębszej diagnostyki.

Pełniejsza analiza może być osobnym etapem projektu. Jej zakres dobieramy do sytuacji - nie każdy sklep wymaga takiego samego audytu.

W zależności od problemów analizujemy między innymi:

  • customowy kod i moduły Magento,
  • konfigurację platformy,
  • logi i historię błędów,
  • bazę danych,
  • frontend i checkout,
  • wydajność,
  • integracje z ERP, PIM, CRM i systemami dedykowanymi,
  • cron i kolejki,
  • OpenSearch lub Elasticsearch,
  • Redis i Varnish,
  • infrastrukturę,
  • proces deploymentu,
  • backlog i dokumentację projektu.

Decyzja

Z diagnozy musi wynikać decyzja

Lista znalezionych błędów sama w sobie ma ograniczoną wartość.

Po analizie powinno być wiadomo:

Wynik diagnozy

  • które problemy są krytyczne,

  • które są tylko objawem innego problemu,

  • co trzeba naprawić w pierwszej kolejności,

  • co można pozostawić bez zmian,

  • które obszary warto przebudować zamiast dalej je łatać,

  • jak powinno wyglądać przejęcie i stabilizacja platformy.

Diagnoza powinna kończyć się konkretnym materiałem roboczym: opisem najważniejszych problemów i ich przyczyn, priorytetami oraz rekomendowanym planem działania.

Jeżeli dalsze naprawianie któregoś obszaru nie ma technicznego albo ekonomicznego sensu, mówimy o tym wprost. Czasem właściwym rozwiązaniem jest przebudowa konkretnego modułu, frontendu, checkoutu czy integracji zamiast kolejnej serii lokalnych poprawek.

Rescue nie powinno polegać na obronie istniejącego kodu za wszelką cenę.

Handover

Jak przejmujemy projekt od innego wykonawcy

Sama zmiana agencji nie rozwiązuje problemu. Trzeba jeszcze przejąć wiedzę, dostęp i odpowiedzialność za działającą platformę.

Pomagamy uporządkować między innymi:

  • repozytoria i kod źródłowy,
  • środowiska,
  • serwery, hosting lub chmurę,
  • proces deploymentu i CI/CD,
  • konta i dostępy związane z Magento i wykorzystywanymi usługami,
  • integracje i ich konfigurację,
  • moduły i licencje,
  • dokumentację,
  • backlog,
  • wiedzę o procesach biznesowych.

Jeśli sytuacja tego wymaga, okres przejściowy może obejmować współpracę z dotychczasowym wykonawcą. Twarde odcięcie z dnia na dzień nie zawsze jest najmniej ryzykownym rozwiązaniem.

Najważniejsze jest to, aby po zakończeniu handoveru było jasne, kto odpowiada za platformę, jakie są priorytety i jak wygląda dalszy sposób pracy.

Odpowiedzialność

Wolimy odpowiadać za całość

Możemy przejąć wybrany obszar projektu, ale nie jest to nasz preferowany model Rescue.

W złożonym Magento problemy rzadko kończą się na granicy jednego modułu. Wolny checkout może mieć źródło w customowym kodzie, integracji albo bazie danych. Problemy z importem mogą wpływać na indeksowanie. Błąd infrastrukturalny może wyglądać jak problem aplikacji.

Jeżeli kilka zespołów odpowiada za zależne od siebie części platformy, łatwo rozmywa się odpowiedzialność, a diagnoza kończy się tam, gdzie zaczyna się zakres innego wykonawcy.

Dlatego w projektach Rescue preferujemy przejęcie odpowiedzialności za całą platformę i możliwość zarządzania priorytetami w jednym miejscu.

Przejęcie wybranego obszaru jest możliwe, ale wtedy jasno określamy granice naszej odpowiedzialności.

Priorytety

Najpierw stabilność, potem roadmapa nowych funkcji

Po przejęciu nie zaczynamy od najstarszych ticketów z backlogu.

W pierwszej kolejności zajmujemy się obszarami, które mają największy wpływ na działanie platformy:

  • procesem zamówienia i checkoutem,
  • błędami powodującymi awarie,
  • wydajnością,
  • integracjami,
  • indeksowaniem i wyszukiwarką,
  • cronem i kolejkami,
  • deploymentem,
  • infrastrukturą.

Celem jest ograniczenie ryzyka i stworzenie stabilnego punktu wyjścia.

Dopiero na tej bazie warto wrócić do roadmapy nowych funkcji. W przeciwnym razie kolejny development nadal odbywa się na platformie, której zachowania trudno przewidzieć.

  1. Stabilizacja

  2. Kontrola

  3. Rozwój

Dalej

Rescue nie kończy się na „sklep znowu działa”

Awaryjna poprawka może przywrócić działanie checkoutu w ciągu jednego dnia. Nie odpowiada jednak na pytanie, dlaczego problem wystąpił i czy nie wróci przy kolejnym wdrożeniu.

Dlatego po ustabilizowaniu projektu pracujemy nad przyczynami problemów, a nie tylko ich objawami.

Dalsza współpraca może obejmować:

  • monitoring,
  • aktualizacje Magento,
  • stopniowe usuwanie długu technicznego,
  • poprawę architektury,
  • development nowych funkcji,
  • realizację roadmapy.

Możemy przejąć długoterminowe utrzymanie i rozwój platformy, ale nie jest to warunek realizacji Rescue.

Docelowym rezultatem jest platforma, nad którą firma ponownie ma kontrolę.

Wsparcie techniczne i utrzymanie Magento →

Przykłady

Dwa różne scenariusze przejęcia problematycznej platformy

Przejęcie projektu PWA: kiedy dalsze poprawki przestają mieć sens

W jednym z przejmowanych przez nas projektów Magento frontend został wcześniej zbudowany jako PWA.

Problemem nie była sama koncepcja PWA, ale sposób wykonania konkretnego rozwiązania. Platforma miała wiele błędów implementacyjnych, poprawki powodowały kolejne regresje, a nawet stosunkowo niewielkie zmiany wymagały nieproporcjonalnie dużego nakładu pracy.

Te same problemy wracały po kolejnych poprawkach, a dalszy rozwój frontendu stawał się coraz bardziej kosztowny i trudny do przewidzenia.

Po przejęciu projektu oceniliśmy, że dalsze punktowe naprawianie istniejącego frontendu nie ma uzasadnienia. Backend Magento pozostał, natomiast warstwa frontendowa została zbudowana od nowa w innym rozwiązaniu wraz z przebudową problematycznych obszarów.

Ten projekt dobrze pokazuje granicę pomiędzy naprawą a przebudową. Rescue nie oznacza automatycznego przepisywania całej platformy. Czasem trzeba zachować tę część systemu, która działa poprawnie, i wymienić obszar, którego dalsze utrzymywanie kosztowałoby więcej niż jego ponowne zbudowanie.

Przejęcie sklepu po ataku: najpierw odzyskanie sprzedaży

W innym projekcie przejmowaliśmy sklep Magento po poważnym incydencie bezpieczeństwa. Dostęp do infrastruktury, kodu i informacji o środowisku był bardzo ograniczony, a platformy nie dało się po prostu uruchomić ponownie na podstawie kompletnego, aktualnego backupu.

Pierwszym celem nie był audyt ani uporządkowanie architektury. Trzeba było odzyskać kontrolę nad tym, co było dostępne, zebrać projekt z różnych źródeł i możliwie szybko przywrócić działający sklep.

Wykorzystywaliśmy dostępne kopie kodu, stare backupy i inne zachowane elementy środowiska, żeby odtworzyć platformę oraz najważniejsze dane i procesy potrzebne do ponownego uruchomienia sprzedaży.

Prace obejmowały między innymi:

  • przejęcie i uporządkowanie dostępnych dostępów,
  • zebranie dostępnych wersji kodu i danych,
  • analizę zachowanych backupów,
  • odtworzenie środowiska z różnych dostępnych źródeł,
  • uruchomienie kluczowych procesów sprzedażowych,
  • sprawdzenie działania integracji i usług zewnętrznych,
  • usunięcie krytycznych problemów blokujących sprzedaż,
  • zabezpieczenie oraz stabilizację odtworzonego środowiska.

Priorytetem było skrócenie czasu, w którym sklep nie mógł normalnie sprzedawać.

Nie czekaliśmy więc z uruchomieniem na moment, w którym każdy element systemu będzie idealnie uporządkowany. Najpierw trzeba było odzyskać platformę do stanu pozwalającego bezpiecznie obsługiwać kluczowe procesy biznesowe. Dopiero potem można było kontynuować diagnostykę, porządkowanie infrastruktury i stabilizację.

Ten projekt pokazuje drugi wymiar Rescue. W standardowym przejęciu można zacząć od diagnozy i planu. W sytuacji kryzysowej kolejność bywa inna:

najpierw odzyskać kontrolę, przywrócić sprzedaż i ograniczyć ryzyko, a dopiero potem doprowadzić platformę do docelowego stanu.

Obawy

Zmieniasz wykonawcę po złych doświadczeniach?

Zmiana wykonawcy problematycznego projektu jest trudniejsza niż rozpoczęcie nowego wdrożenia. Firma ma już za sobą poniesione koszty, opóźnienia i często kilka prób naprawy tych samych problemów.

Dlatego przy przejęciu projektu najczęściej pojawiają się trzy obawy.

„Nowy wykonawca będzie miesiącami poznawał projekt”

Nie obiecujemy, że złożony system da się poznać w kilka dni. Nie traktujemy jednak poznawania projektu jako osobnego, wielomiesięcznego etapu przed rozpoczęciem realnych działań. Diagnoza służy jednocześnie zrozumieniu platformy i ustaleniu priorytetów. Jeśli widzimy problemy krytyczne, możemy adresować je równolegle z pogłębianiem wiedzy o pozostałych obszarach systemu.

„Skąd mamy wiedzieć, że z kolejnym wykonawcą nie będzie tak samo?”

Nie oczekujemy zaufania na podstawie deklaracji. Pierwszy etap ma dostarczyć konkretnych podstaw do dalszych decyzji: wskazać problemy i ich przyczyny, oddzielić rzeczy krytyczne od mniej istotnych oraz określić rekomendowaną kolejność działań. Jeśli uważamy, że któregoś obszaru nie warto dalej naprawiać, mówimy o tym wprost. Jeśli można go zachować, również nie proponujemy przebudowy tylko po to, żeby rozpocząć projekt od nowa.

„Zmiana wykonawcy to kolejne koszty, zanim cokolwiek się poprawi”

Przejęcie istniejącego projektu rzeczywiście wymaga pracy, której nie byłoby przy platformie prowadzonej poprawnie od początku. Dlatego po przejęciu nie zaczynamy od kolejnych funkcji ani od najstarszych zadań z backlogu. Pierwsze działania kierujemy tam, gdzie problem powoduje największe ryzyko lub koszt dla biznesu: do awarii, checkoutu i procesu zamówienia, wydajności, integracji czy problemów wpływających na codzienną pracę zespołu. Celem jest możliwie szybko ograniczyć straty i ryzyko, a jednocześnie budować wiedzę potrzebną do dalszej stabilizacji platformy.

Zespół

Dlaczego Velocity

Magento jest głównym obszarem naszej specjalizacji.

Pracujemy nie tylko na poziomie frontendu i funkcji sklepu, ale również integracji, bazy danych, wyszukiwarki, cache i infrastruktury.

W projektach Rescue ma to szczególne znaczenie, ponieważ źródło problemu często znajduje się gdzie indziej niż jego widoczny objaw.

Nasi eksperci patrzą na przejmowaną platformę również z perspektywy jej późniejszego utrzymania. Jeśli po stabilizacji zostajemy przy projekcie, sami będziemy pracować z decyzjami technicznymi podjętymi podczas Rescue.

Dlatego zależy nam nie tylko na tym, żeby naprawa zadziałała dziś, ale również na tym, żeby można było bezpiecznie rozwijać platformę później.

Dopasowanie

Kiedy to nie jest właściwa usługa

Problemem jest wyłącznie wydajność

Jeśli projekt poza tym jest prowadzony poprawnie, właściwym punktem wyjścia będzie usługa poświęcona wydajności Magento.

Optymalizacja wydajności Magento →

Planujecie zmianę platformy

Jeśli obecny system ma zostać wygaszony, a celem jest przejście na Magento lub inną architekturę, potrzebny jest proces migracji i replatformingu.

Migracja i replatforming →

Budujecie nową platformę od zera

Jeżeli nie przejmujemy istniejącego problematycznego Magento, tylko projektujemy nowy system, właściwą usługą jest nowe wdrożenie.

Wdrożenia Magento →

Priorytetem od pierwszego dnia są wyłącznie nowe funkcje

W Rescue najpierw trzeba ustabilizować fundament. Jeśli nie ma przestrzeni na rozwiązanie problemów technicznych przed realizacją kolejnego backlogu, prawdopodobnie nie jest to właściwy model współpracy.

Pytania

FAQ

VLCT

Tak. Przejęcie projektu od innego wykonawcy jest jednym z podstawowych scenariuszy Rescue. Pomagamy uporządkować zarówno stronę techniczną, jak i sam proces handoveru.

VLCT

Nie zawsze. Jeżeli ogranicza to ryzyko, przez pewien czas możemy działać równolegle z dotychczasowym wykonawcą i stopniowo przejmować odpowiedzialność za kolejne obszary.

VLCT

Zakres zależy od projektu. Część diagnozy możemy wykonać podczas pierwszych rozmów i analizy dostępnych informacji. Przy bardziej złożonych problemach potrzebny jest osobny etap techniczny z dostępem do kodu, logów i środowisk.

VLCT

Zależy od wielkości platformy, liczby customizacji, integracji i jakości dokumentacji. Nie traktujemy jednak poznawania projektu jako osobnego, wielomiesięcznego okresu przed rozpoczęciem realnych działań. Krytyczne obszary mogą być adresowane równolegle z pogłębianiem wiedzy o systemie.

VLCT

Nie. Najpierw oceniamy stan poszczególnych obszarów. Część rozwiązania zwykle można zachować, inne elementy wymagają naprawy, a niektóre bardziej opłaca się przebudować niż dalej utrzymywać.

VLCT

Jest to możliwe, ale preferujemy odpowiedzialność za całą platformę. Problemy w Magento często przekraczają granice jednego obszaru, dlatego przy ograniczonym zakresie jasno określamy, za co możemy odpowiadać.

VLCT

Tak. Zakres zależy od sytuacji i dostępnych zasobów. W krytycznych przypadkach pierwszym celem może być odzyskanie dostępów, kodu i danych oraz przywrócenie najważniejszych procesów sprzedażowych. Pełna diagnoza i porządkowanie platformy mogą wtedy następować już po jej ponownym uruchomieniu.

VLCT

Platforma może przejść w normalny tryb utrzymania i rozwoju: monitoring, aktualizacje, stopniowe usuwanie długu technicznego oraz realizację roadmapy nowych funkcji.