Dzisiaj zajmiemy się tematem, który czasami niestety się pojawia. Szkoda, że się pojawia, ponieważ jest on związany z zawalonymi wdrożeniami Magento 2.
Odpowiemy sobie na pytanie jakie są symptomy zawalonego projektu, jakie są przyczyny nieudanych projektów, jak dokończyć wdrożenie oraz ile może kosztować dokończenie takiego zawalonego projektu na Magento 2.
Jak naprawić zawalone wdrożenie Magento?
Symptomy nieudanego wdrożenia Magento
Co zrobić gdy projekt idzie źle?
Najczęstsze przyczyny nieudanych wdrożeń Magento
Audyt – plan naprawczy zawalonego wdrożenia Magento
Kto powinien dokończyć zawalone wdrożenie Magento?
Zawalone Wdrożenie Magento – podsumowanie
Jak naprawić zawalone wdrożenie Magento?
Jeżeli dotarłeś do punktu, w którym współpraca z obecnym Software Housem nie układa Ci się, widzisz, że efekty ich pracy są takie sobie i nie spełniają Twoich oczekiwań, a na pewno nie spełniają początkowej wizji tego projektu, to po prostu nadszedł czas na to, żeby przeprowadzić audyt z jakąś zewnętrzną firmą, która specjalizuje się w Magento. Będzie mogła ona ocenić jak rzeczywiście zostało zakodowane to Magento, na jakim etapie jest projekt i wypracuje plan, który doprowadzi Cię do zakończenia tego projektu.
Jest to prosta odpowiedź na to trudne biznesowe pytanie. Receptą na zepsute wdrożenie Magento jest po prostu przeprowadzenie audytu i wypracowanie planu działań, który doprowadzi do końca tego projektu.
Natomiast teraz przechodzimy do części bardziej mięsistej, gdzie dokładniej porozmawiamy i omówimy:
- z czego bierze się takie nieudane wdrożenie Magento
- jakie są symptomy tego, że to wdrożenie Magento nie idzie
- jak powinien wyglądać i przebiegać taki audyt, który powie nam w jakim rzeczywiście stanie jest wdrożenie Magento
- jak dokończyć ten projekt
Symptomy nieudanego wdrożenia Magento
Zacznijmy sobie od symptomów.
- Pierwszy punkt — nawracające błędy.
Przykładowo jest pewien błąd, który kiedyś tam się pojawił. Wy sprawdzając sklep internetowy mówicie Software House’owi o tym błędzie. Oni naprawiają ten błąd no i miesiąc czy półtora miesiąca później ten błąd znowu się pojawia. W sumie po każdej kolejnej aktualizacji systemu Magento znowu ten błąd się pojawia.
To jest jasny sygnał, że coś z tym wdrożeniem jest nie tak.
- Drugi taki symptom — wygląd sklepu jest inny niż to sobie wyobrażaliście na samym początku.
To jest całkiem ciekawe, bo po fazie discovery powinniście mieć gotowe projekty graficzne.
Ale nie zawsze tak jest. Czasami projekty graficzne powstają w trakcie rozpoczętych prac programistycznych. W wyniku tego, coś co jest kodowane, czasami jeszcze na podstawie szkiców przed projektami graficznymi, okazuje się, że po prostu nie spełnia Waszych potrzeb.
Więc jeżeli pojawia się u Was taka myśl, że “hmm jakby nie tak to sobie wyobrażałem, miało to wyglądać trochę inaczej” to jest już kolejny sygnał, że “coś jest nie tak”.
- Trzeci symptom — naprawiamy jeden błąd i przez to pozornie niepowiązany element w innej części serwisu się sypie.
Na przykład modyfikujemy moduł naliczania rabatów w procesie składania zamówienia, a tu nagle pojawia się błąd z wyliczaniem kosztów dostawy.
- Czwarty symptom — serwis nie działa tak, jak to sobie wyobrażaliście sobie.
Przykładem może być walidacja. Wyobrażaliście sobie jej działanie w zupełnie inny sposób niż to ma faktycznie miejsce. Pewnie problem jest to, że analiza biznesowa (a dokładnie storki i kryteria akceptacyjne) nie opisywały wystarczająco dokładnie działania tego mechanizmu.
- Piąty symptom — niedziałające integracje z różnymi systemami.
Magento możemy połączyć z Baselinker’em, PIM’em czy ERP’em.
Jeżeli pojawiają się błędy w integracjach, przykładowo, mimo tego, że Magento powinno pobierać i włączyć informacje o rabatach z ERP’a, to dodatkowo tworzy nowe i niepoprawne kartoteki w systemie księgowo-rachunkowym.
Klasyka gatunku wygląda tak — projekt miał się zmieścić w mniej więcej 600.000 PLN i 8 miesiącach. Obecnie masz na liczniku 1.300.000 PLN i mija już 18 miesiąc wdrożenia. Nie chcę Cię martwić, ale coś tutaj jest grubo nie tak.
Najczęstsze przyczyny nieudanych wdrożeń Magento
Skoro wiemy jakie są częste symptomy zawalonego wdrożenia Magento, to warto poznać najczęstsze przyczyny wysypywania się projektów Magento.
Będę bazował na swoim doświadczeniu i na rozmowach z różnymi dyrektorami ecommerce, którzy uczestniczyli we wdrożeniach Magento. Poniżej znajdziesz elementy, które zwiększają ryzyko tego, że wdrożeniowy projekt Magento może się nie udać.
Mam tych przyczyn cztery.
- Pierwsza przyczyna — błędnie wykonana analiza biznesowa.
Czasami po prostu może ona zawierać proste błędy, przykładowo opis funkcjonalności pojawił się w dwóch miejscach tej analizy biznesowej. W obu miejscach opisany mechanizm funkcjonowania jest inny.
Jednak z mojej perspektywy większym problemem z analizą biznesową, jest zwyczajnie jej niepełność.
Często ma ona tylko ogólne założenia spisane w formie smutnego pliku tekstowego. Na jego podstawie ruszają prace programistyczne.
Jeżeli programista nie wie dokładnie co ma zakodować, to prawdopodobnie końcowy efekt minie się z Twoją wizją i jednocześnie koszty wdrożenia Magento urosną.
Budżet zaczyna szybko rosnąć — początkowo miało być to 800.000 PLN, poźniej 1.500.000 PLN, otrzymujemy kolejną informację o konieczności zwiększenia budżetu i końca nie widać.
Powodem jest analiza biznesowa, która w niepełny sposób opisywała to, jak ma docelowo wyglądać i działać system.
Jak się domyślasz problemem jest też to, że w czasie analizy biznesowej, nie przygotowuje się projektów graficznych. Jest to niewłaściwe, ponieważ projekty graficzne, storki i kryteria akceptacyjne dobrze obrazują końcowy system i minimalizują obszar dowolnych (i niezgodnych z Twoją wizją) interpretacji założeń.
Jeżeli nie ma tych projektów graficznych, to możesz spotkać się z sytuacją, że przeczytasz sobie storki i kryteria akceptacyjne, ale przez brak projektów graficznych ciężko będzie Ci wyobrazić sobie jak miałby wyglądać dany element systemu.
Może się Wam więc zdarzyć taka sytuacja, że nie mieliście projektów graficznych pokazujących, jak ma wyglądać podstrona z wynikami wyszukiwania. Programista coś zakodował, co wydawało mu się, że będzie dobre. Ty to oceniasz i mówisz, że wyobrażałeś sobie tą stronę zupełnie inaczej.
W efekcie Software House cofa te zmiany i wdraża coś jeszcze raz. Zapłaciliście więc za pierwotne zakodowanie strony, za wywalanie tej strony i za ponowne jej zakodowanie. Budżet x2 za ten element, który byłby zrobiony poprawnie za pierwszym razem, gdyby na etapie analizy biznesowej były gotowe projekty graficzne.
W ten sposób wydłuża się też czas wdrożenia ecommerce’u.
To jest podwójnie trudna sytuacja ponieważ, nie macie też punktu odniesienia w rozmowach z Software Housem.
W momencie, w którym Wy powiecie temu Software House’owi, że coś miało wyglądać inaczej, Software House odpowie, że w analizie biznesowej to nie było opisane, więc zrobili to tak jak uważali najlepiej. Kto ma w takiej sytuacji rację? Nie wiadomo.
W tym wypadku nie możecie po prostu powiedzieć: “dobra, wróćmy do analizy biznesowej, zobaczmy jak to miało działać”. Jeśli po sprawdzeniu Wy mielibyście rację, to przynajmniej możecie rozmawiać, że ten błąd jest ewidentnie po stronie Software House’u więc dobrze byłoby porozmawiać o tym jak rozliczyć niepotrzebnie przepracowane godziny.
Podsumowując — bez analizy biznesowej macie mniejszą kontrolę nad budżetem i czasem wdrożenia oraz utrudniacie sobie rozmowy z Software Housem.
W mojej ocenie błędy i niepełna analiza biznesowa jest źródłem większości problemów w zawalonych projektach Magento.
- Drugą przyczyną jest używanie zbyt dużej liczby zewnętrznych modułów.
Często zdarza się tak, że instalujemy trzy moduły, one są bardzo rozbudowane i te trzy moduły wpływają na jedną i tą samą funkcję w Magento.
Ta funkcja przestaje działać poprawnie. Przykładowo wyliczanie kosztów dostawy.
Rozplątanie tego i dowiedzenie się, który to moduł, w jaki sposób wpływa na inny i sprawia, że całość nie działa poprawnie, jest naprawdę trudne (a więc i czasochłonne).
Jeżeli macie wdrożenie Magento, gdzie ktoś przewidział, że wykorzysta 14 zewnętrznych modułów, to zwiększyłbym swoją czujność przy testowaniu działania sklepu.
Dodam, że pewnie pojawią się problemy związane z bezbłędnym utrzymaniem tego systemu i że koszty utrzymania będą względnie wysokie.
- Trzecia przyczyna to wykorzystywanie PWA.
Niektórzy pomyślą, że nie mam racji, i że PWA jest super.
PWA rzeczywiście jest super. Problem z PWA jest taki, że nie pisze się zbyt łatwo aplikacji w PWA i mało widziałem front-endów Magento na PWA, które rzeczywiście były świetnie napisane, pozbawione błędów i dowoziły obietnicę niesamowitej szybkości.
Załóżmy, że tworzycie nowy sklep internetowy na Magento, wykorzystujcie PWA i wydajecie mnóstwo pieniędzy. PWA kosztuje sporo. A na koniec projektu przykładowo filtrowanie nie działa poprawnie, albo w ogóle filtrowania… nie ma.
Nie zrozumcie mnie źle, PWA samo w sobie jest świetne. Jeżeli mamy adekwatny budżet, wybraliśmy sobie świetny Software House, który nie obiecuje, że zrobi PWA w budżecie Lumy, a dodatkowo istnieje biznesowe uzasadnienie wybrania PWA — wtedy idźmy w PWA.
Natomiast nie jest przypadkiem, że większość zawalonych wdrożeń Magento, z którymi miałem do czynienia w czasie rozmów z Dyrektorami Ecommerce wykorzystywało PWA.
Może to jest przypadek, ale nie sądzę.
- Czwartą przyczyną jest zbyt duży zakres projektu do początkowego wdrożenia.
Jeśli ktoś zaprojektował i wymyślił, że wdroży Magento w półtora roku, to jest bardzo duże ryzyko, że to nie będzie półtora roku, tylko dwa lata, albo dwa i pół roku. Początkowy zakres projektu jest po prostu za duży.
Im więcej i bardziej skomplikowanych funkcjonalności mamy, tym większe ryzyka projektowe, a co za tym idzie, większe prawdopodobieństwo, że projekt gdzieś utknie.
Zawsze zachęcamy jako Growcode, aby zmniejszyć zakres funkcjonalny wdrożenia, by wdrożenie zakończyć w mniej więcej 7-9 miesięcy.
Z naszego doświadczenia to jest optymalna wielkość wdrożenia. 10 miesięcy też ujdzie. W takie sytuacji mamy niewielkie ryzyko projektowe.
Ryzyko, że budżet nam urośnie, jest niewielkie. Ryzyko, że nie wyrobimy się w terminie z wdrożeniem tego projektu, również jest zmniejszone. Ogólnie, są same korzyści.
Natomiast często dostaję taką odpowiedź, że jak ograniczymy liczbę funkcjonalności, to serwis na Magento, na który wydamy niemało pieniędzy, będzie gorszy niż ten obecny. A przecież biznes ma się rozwijać a nie zwijać. Ostatecznie mniejsza liczba funkcjonalności wpłynie na spadek przychodów.
Guzik prawda.
Weźmy dane, które zbieramy za pomocą Google Analytics. Przeanalizujmy je. Sprawdźmy, które funkcjonalności obecnego serwisu użytkownicy faktycznie wykorzystują. Oceńmy, które wpływają na generowanie przychodów, zwiększają współczynnik konwersji, LTV lub średnią wartość zamówienia.
Zróbmy takie analizy i zobaczmy, które funkcjonalności nie wpływają na przychód biznesu. Te funkcjonalności bezpiecznie możemy przerzucić do wdrożenia na etapie rozwojowym (czyli już po uruchomieniu produkcyjnym nowego serwisu).
Nasze doświadczenie w zakresie optymalizacji konwersji mówi, że podczas projektowania nowego serwisu (szczególnie na Magento, które jest niesamowicie elastyczne) możemy zaprojektować taki sklep internetowy, który pomimo mniejszej liczby funkcjonalności będzie świetnie konwertował, miał genialną komunikację sprzedażową i promocyjną. W efekcie będzie generował wyższy współczynnik konwersji i przychody.
Przy okazji — taka analiza to mądry sposób na zmniejszenie zakresu wdrożenia. Tym bardziej, że jeśli zmniejszysz skalę projektu, to z punktu widzenia finansowego cały projekt będzie bardziej opłacalny. Jak? Zamrozisz mniej gotówki na krótszy czas, a projekt zacznie szybciej się zwracać.
Co zrobić gdy projekt idzie źle?
Znasz już symptomy i przyczyny zawalonego projektu wdrożeniowego Magento. No i teraz, co możesz zrobić?
Prawdopodobnie, jeżeli coś takiego wystąpiło, to rozmawiałeś już kilka razy z Project Managerem po stronie wykonawcy.
Pewnie były podejmowane plany naprawcze. Software House zapewniał, że teraz będzie już dobrze. I mimo tych kolejnych rozmów, nic nie uległo zmianie.
Wtedy właśnie prawdopodobnie szukacie rozwiązania na te zawalone wdrożenie Magento.
Audyt – plan naprawczy zawalonego wdrożenia Magento
Jak żyć? Co zrobić?
Na samym początku należy znaleźć Software House, który wykonuje tego typu projekty. Mówiąc wprost ratuje zawalone wdrożenia Magento.
Dobrze byłoby znaleźć taką firmę, która:
- po pierwsze ma zrealizowane case’y tego typu
- firma poda dokładny skład osobowy zespołu audytowego
To, kto wykona audyt, będzie miało największy wpływ na jakość wypracowanych rekomendacji. Dla formalności napiszę, że powinny to być osoby co najmniej na poziomie zaawansowanego mida. A najlepiej seniora.
Firma, którą wybierzecie, zrobi na samym początku krótki audyt kodu i sprawdzi, czy jest on do przyjęcia. Innymi słowy, czy jakość kodu jest taka, że projekt można dalej rozwijać. W najgorszym wypadku po tym etapie otrzymasz informację, że kod jest takiej jakości, że najlepiej zacząć projekt do początku.
Ile taki audyt będzie kosztował?
Początkowy sprawdzenie kodu zajmie prawdopodobnie od 16 do 20 godzin.
Jeśli otrzymasz pozytywną odpowiedź, że dotychczas stworzone części sklepu mogą być wykorzystane to czeka Cię druga część audytu.
Wszystkie kolejne kroki zajmują w sumie od 40 do mniejszej 70 godzin. Zależeć to będzie od tego, ile zadań już zostało zakończonych oraz jak duży jest zakres projekt.
W tym korku Software House prawdopodobnie weźmie początkowy brief, na podstawie którego powstała pierwotna estymacja kosztów i budżetu wdrożenia Magento.
Następnie zespół audytowy przeprowadzi z Wami jeden lub dwa warsztaty, gdzie doprecyzuje zakres funkcjonalny i rozpisze, jak funkcjonalnie powinien wyglądać Wasz ecommerce. Na tym etapie Software House zaprojektuje docelową architekturę systemu.
Na tym etapie będziecie wreszcie wiedzieli jak powinien wyglądać od strony funkcjonalnej stan końcowy.
Teraz czas na to, żeby porównać to co zostało zakodowane do tej pory z tym jak docelowo powinien wyglądać Wasz sklep. Audyt będzie składał się z kilku kroków:
- uzyskanie dostępów do kodu sklepu przez zespół audytowy
- sprawdzenie, które funkcjonalności zostały już zakodowane, a które nie
- ocena zakodowanych funkcjonalności pod względem poprawności działania
- jeżeli funkcjonalność wymaga poprawek to ocena w jakim zakresie konieczna jest poprawa (w jakim procencie można uznać, że funkcjonalność jest zakodowana) i estymacja kosztów
- estymacja kosztów wdrożenia funkcjonalności, których do tej pory Software House nie zaczął kodować
Po tych krokach zespół audytowy będzie mógł bezpiecznie estymować czas i budżet potrzebny do zakończenia Waszego sklepu internetowego lub platformy B2B.
Podsumowując, co powinniście otrzymać od zespołu audytowego do tego momentu?
Musicie mieć:
- listę funkcjonalności, nad którymi prace w ogóle się nie zaczęły
- listę funkcjonalności już wdrożonych, ale niedziałających poprawnie
- ocenę w jakim zakresie niedziałające poprawnie funkcjonalności są ukończone
- kolejną rzeczą jest opracowanie planu naprawy i dokończenie projektu
- oszacowanie kosztów naprawy tych błędów i dokończenia audytu
Kto powinien dokończyć zawalone wdrożenie Magento?
Decyzja jest trudna. Musicie zdecydować, czy naprawę wykona Software House, z którym obecnie współpracujecie, czy ten, który wykonuje audyt, a może jeszcze jakiś inny. Tutaj nie ma prostej odpowiedzi. Musicie ocenić jak duże zaufanie macie do obecnego partnera i czy jesteście w stanie wrócić do normalnych relacji partnerskich. Doświadczenie mówi, że jeżeli problem z wdrożeniam Magento został wyeskalowany do takiego poziomu, że audyt wykonywała firma trzecia to powrót do “business as usual” może być ciężkie.
Następnie wznawia się prace projektowe. Chciałbym zwrócić uwagę, że bez względu to kto będzie realizował prace projektowe, koniecznie do niedokończonych funkcjonalności powinny zostać stworzone kryteria akceptacyjne oraz projekt graficzny. I to jeszcze przed rozpoczęciem prac kodowych.
Pilnujcie, żebyście podczas fazy developmentu co dwa tygodnie otrzymywali przyrost funkcjonalności w Waszym sklepie internetowym. I na bieżąco kontrolujcie jakość realizowanych zadań. Dzięki temu unikniecie powtórki z rozrywki.
Zawalone Wdrożenie Magento – podsumowanie
Podsumowując, wiesz już, jakie są symptomy, przyczyny oraz jak powinien wyglądać plan działań przy zawalonym projekcie Magento.
Wiesz też mniej więcej, ile ten audyt może kosztować.
Jeżeli masz do czynienia z zawalonym wdrożeniem Magento to mam nadzieję, że przynajmniej odrobinę zmniejszyłem poziom Twojego stresu i że wiesz jakie działania możesz podjąć. Jeżeli jesteś przed wdrożeniem Magento to zwróć koniecznie uwagę na najczęstsze przyczyny zawalonych wdrożeń Magento i jeżeli tylko możesz—unikaj ich.
Jeśli uważasz, że wiedza zawarta w tym artykule jest wartościowa, to koniecznie sprawdź artykuł mówiący o tym jak przeprowadzić skuteczną analizę biznesową przed wdrożeniem Magento!
