Przejęcie i dokończenie sklepu Magento 2, który utknął przed uruchomieniem

Tak i robi się to częściej, niż wynikałoby z tego, jak rzadko się o tym mówi. Warunkiem nie jest zgoda dotychczasowego wykonawcy, tylko dostęp do kodu, środowisk i kont w usługach zewnętrznych — te należą do klienta, nie do agencji. Przebieg przejęcia opisujemy krok po kroku w sekcji o zmianie agencji.

Repozytorium wraz z historią, środowiska produkcyjne i testowe, panel administracyjny Magento, serwer i baza danych, DNS oraz konta w usługach zewnętrznych: płatnościach, kurierach, ERP i narzędziach analitycznych. Do tego dokumentacja integracji, jeżeli istnieje. Brak części z nich nie blokuje przejęcia — zmienia zakres analizy, bo tego, czego nie da się przeczytać, trzeba dojść z kodu i konfiguracji.

Zależy przede wszystkim od stanu kodu, zakresu brakujących funkcji, jakości dokumentacji, liczby integracji do naprawy oraz skali testów i przygotowania startu. Wycena powstaje po analizie, bo przed nią byłaby zgadywaniem — a dokładnie takie zgadywanie doprowadziło zwykle projekt do stanu, w jakim trafia do nas. Co waży najwięcej i jakie są trzy możliwe scenariusze, opisujemy w sekcji o koszcie przejęcia.

Brak dokumentacji utrudnia analizę, ale nie wyklucza przejęcia. Potrzebny będzie dostęp do repozytorium, środowisk, konfiguracji oraz osób znających procesy biznesowe. Historia commitów, konfiguracja Magento i sam kod integracji pozwalają odtworzyć większość informacji — analiza trwa wtedy dłużej, a jej wynikiem jest między innymi dokumentacja, której wcześniej nie było.

Tak, to zwykle pierwsza część pracy. Analiza rozdziela błędy na te blokujące uruchomienie, te do naprawy po starcie i te wynikające z decyzji architektonicznych, których nie da się naprawić bez przebudowy obszaru. Każda z tych grup trafia do planu osobno, razem z kosztem — żeby było widać, za co się płaci przed startem, a co może poczekać.

Tak i mówimy to wprost, jeżeli tak wychodzi z analizy. Zdarza się, że utrzymanie istniejącego kodu kosztowałoby więcej niż nowe wdrożenie, a różnicę pokazujemy w liczbach zamiast dokańczać coś, co za rok wróci jako ten sam problem. To jeden z trzech scenariuszy, którymi może zakończyć się analiza.

Tak, tylko kolejność prac jest wtedy inna. Sklep, który już sprzedaje, wyznacza granicę: najpierw stabilizujemy to, co działa, dopiero potem zmieniamy resztę. Analiza musi też objąć dane produkcyjne — zamówienia, klientów i konfigurację, które powstały w trakcie — bo od nich zależy, co da się zmienić bez przerwy w sprzedaży.

Nie. Sprawdzamy każdy obszar osobno. Część kodu może zostać wykorzystana bez zmian, część wymagać poprawy, a pojedyncze elementy mogą kwalifikować się do napisania od początku. Rekomendacja wynika z analizy, a nie z samego faktu zmiany agencji.

Analizujemy kod, architekturę, moduły, integracje, środowiska, sposób wdrażania zmian, dokumentację oraz najważniejsze procesy sprzedażowe. Zakres analizy zależy od stopnia zaawansowania projektu.

Tak, jeżeli obie strony mają jasno określony zakres i sposób przekazania informacji. Potrzebne są dostępy, aktualny backlog, dokumentacja i wskazanie osób odpowiedzialnych za poszczególne elementy.

Odpowiedzialność zależy od architektury i umów z dostawcami systemów. Podczas analizy ustalamy, która część przepływu działa po stronie Magento 2, a która po stronie systemu zewnętrznego. Każda blokada otrzymuje właściciela.

Zakres może obejmować przygotowanie planu wdrożenia, publikację zmian, testy po uruchomieniu i uporządkowanie tematów wymagających dalszej pracy. Dokładna odpowiedzialność jest ustalana po analizie projektu.

Nie da się wiarygodnie określić czasu bez sprawdzenia kodu, integracji i aktualnego zakresu. Po analizie powstaje kolejność prac oraz estymacja uwzględniająca znane zależności i ryzyka.

Po starcie projekt otrzymuje release notes, aktualną dokumentację i backlog dalszych prac. Utrzymanie oraz rozwój działającej platformy Magento 2 może zostać przejęty w ramach AURORA CARE.