5 lutego 2023 45:14 Odcinek 085

Zanim zdecydujesz się na wdrożenie Magento

Jeśli źle wybierzesz silnik sklepu internetowego, to konsekwencje tego wyboru będą się ciągnąć za Tobą całymi latami. Dlatego warto się do tego procesu przyłożyć i dokładnie przeanalizować wszystkie „za” i „przeciw” każdej popularnej platformy, którą bierzesz pod uwagę.

Na tej liście w większości przypadków będzie też Magento. I nic w tym dziwnego, bo jest to jedna z najpopularniejszych platform e-Commerce, z której korzystają najwięksi gracze w Polsce i na świecie. Jednak jak każde rozwiązanie – ma też swoje wady i ograniczenia, przez co nie będzie pasować do wszystkich wdrożeń. W tym odcinku dzielę się swoimi przemyśleniami po ponad 150 000 godzin, które razem z Satisfly poświęciliśmy na wdrożenia i rozwój sklepów internetowych opartych o Magento. Posłuchaj i dokonaj świadomego wyboru.

Listen to „085 – Zanim zdecydujesz się na wdrożenie Magento” on Spreaker.

Dodatkowe materiały

Jeśli zainteresował Cię ten odcinek, sprawdź również:

Odcinek 083 – Jak planować cele w biznesie?, z który pomoże Ci zaplanować realizację celów Twojego e-Commerce
https://marekkich.pl/sztuka-ecommerce/083-jak-planowac-cele-w-biznesie-pawel-palka/
Odcinek 077 – Zmiana sklepu internetowego – jak zrobić ją dobrze?, z którego dowiesz się jak sprawnie zmienić silnik Twojego sklepu
https://marekkich.pl/sztuka-ecommerce/077-zmiana-sklepu-internetowego-jak-zrobic-ja-dobrze
Odcinek 061 – Gdy przyjdzie czas na zmianę firmy wdrożeniowej, dzięki któremu dowiesz się co zrobić, gdy Twoja współpraca z obecną firmą wrożeniową nie idzie po Twojej myśli
https://marekkich.pl/sztuka-ecommerce/061-gdy-przyjdzie-czas-na-zmiane-firmy-wdrozeniowej/
Artykuł na blogu Satisfly – Ile kosztuje sklep na Magento?, który pomoże Ci zaplanować budżet swojego wdrożenia
https://satisfly.co/pl/blog/ecommerce/koszt-sklepu-internetowego-magento/
Artykuł na blogu Satisfly – Czym jest Composable Commerce i jak może wpłynąć na Twój biznes?, który pozwoli Ci lepiej zrozumieć rodzaje architektury, w których budowane są sklepy internetowe
https://satisfly.co/pl/blog/ecommerce/composable-commerce/
Artykuł na blogu Satisfly – Czy Magento jest bezpieczne?, z którego dowiesz się, czy silnik ten wystarczająco zabezpieczy Twój e-Commerce
https://satisfly.co/pl/blog/ecommerce/czy-magento-jest-bezpieczne/

Kiedy zabierzesz się za wdrożenie nowego sklepu internetowego, to na którymś etapie będziesz musiał zmierzyć się z wyborem konkretnego silnika. Nie trzeba chyba nikogo przekonywać, że odpowiedni wybór jest szalenie istotny, bo jeżeli nie znajdziesz właściwego dopasowania do Twojego biznesu, to ryzykujesz tym, że, na przykład, odbijesz się od ściany w możliwościach rozwoju i skalowania biznesu albo zakopiesz się w takim długu technologicznym, że bez różańca nikt nie będzie chciał siadać do kodu, albo w którymś momencie wszystko będzie do zrobienia od nowa, albo znacząco przepłacisz za rozwiązanie, którego tak naprawdę nie potrzebujesz.

Kwestię odpowiedniego przygotowania do wdrożenia, rozpisania briefu, wyboru narzędzi i agencji omawiałem już w kilku poprzednich odcinkach Sztuki e-Commerce, więc jeżeli jesteś na takim etapie, że w ogóle nie wiesz, od czego zacząć, to gorąco zachęcam do przesłuchania poprzednich odcinków. Natomiast w tym odcinku opowiem Ci o Magento – niewątpliwie jednym z najbardziej popularnych rozwiązań e-Commerce w Polsce i na świecie. Na pewno na tyle popularnym, że trudno przejść obok niego obojętnie niezależnie od tego, jaki masz budżet, terminy, czego oczekujesz od wdrożenia i co słyszałeś o tym rozwiązaniu.

Uprzedzam, że to nie będzie odcinek, w którym mam zamiar jakoś przesadnie zachwalać Magento i na siłę przekonywać Cię do jedynego słusznego wyboru. Raczej po prostu podzielę się z Tobą wnioskami, które wyciągnąłem z ponad 150 000 godzin, które razem z Satisfly poświęciłem na wdrożenia i rozwój sklepów na Magento – najpierw w wersji z jedynką z przodu, a potem, i obecnie też, w wersji 2.0 i w górę. Zapraszam do przesłuchania.

Magento w liczbach

Zaczniemy od takiej perspektywy z lotu ptaka na samo Magento. Jest to rozwiązanie open source, co oznacza możliwość swobodnej edycji kodu przez dowolną osobę i firmę na świecie, co już wielokrotnie też w podcaście było mówione, że jest dość przydatną sprawą. Wydaje mi się, że od samego początku jest też oczywiście wersja płatna poza tą darmową. Wcześniej, jeszcze kiedy to była wersja z jedynką z przodu, można było słyszeć o Magento w wersji Community i Enterprise. Teraz mówi się bardziej o Magento Open Source i Adobe Commerce, a Adobe jest firmą, która jakiś czas to Magento kupiła. To, że to jest open source, oznacza dokładnie tyle, że jeżeli wybierzesz darmową wersję, możesz sobie ten sklep pobrać i on jest Twój, możesz go sobie rozwijać i robić z nim, co chcesz.

Jeżeli chodzi o kalendarium, to pierwsza stabilna wersja Magento powstała w 2008 roku. Od 2008 do końcówki 2015 roku była rozwijana wersja z serii 1 i nie można powiedzieć tak naprawdę, że to był jakiś bardzo intensywny rozwój, że co numerek pojawiały się nowe wodotryski, ale co wersję coś tam delikatnie dochodziło. Ostatecznie skończyło się na wersji 1.9 z haczykiem (chyba 1.9.3, może 1.9.4) i w którymś momencie w międzyczasie zaczęła powstawać wersja 2.0, która właściwie sprowadzała się do tego, że Magento zostało przepisane w zupełności od nowa i premiera wersji 2.0 miała miejsce w listopadzie 2015 roku, i dziś na moment nagrywania jesteśmy w momencie, w którym Adobe może się pochwalić wersją Magento 2.4.5.

Mówię o tym Adobe, bo wydaje się, że jest to dla samego Magento i ogólnie dla e-Commerce dość ważny moment i dość ważna sprawa. We wrześniu 2016 Magento zostało wykupione przez Adobe. To był taki moment, w którym wszyscy zaczęli panikować, czy w ogóle ta darmowa wersja zniknie, czy ona się utrzyma. Na razie nie zniknęła, aczkolwiek widać, że pojawiają się tam dwa nurty, jeżeli chodzi o rozwój tych wersji, czyli płatnej i darmowej. Ewidentnie widać, że wersja płatna rozwija się szybciej, jest w nią pchany pewnie większy budżet i też trudno się dziwić, bo w końcu z tego są po prostu pieniądze. Natomiast wersja darmowa nie rozwija się aż tak szybko, ale rzeczywiście jakiś rozwój ma. Jest to na tyle istotny rozwój, że o ile ja jakoś specjalnie wersji 2.1 czy nawet 2.2 jakoś mocno nie polecałem, bo ona nie wyglądała na jakąś superstabilną, tak teraz 2.4.5 to już jest naprawdę ustabilizowana platforma i cały czas coś tam nowego dochodzi.

Jeżeli chodzi o pozostałe liczby, takie już troszeczkę mniejsze, to trochę pogrzebałem i wychodzi tak: prawie 3,5 tysiąca dodatków, dokładnie 3496 na oficjalnym marketplace magentowym. Na Themeforest 366 szablonów, 436 oficjalnych partnerów, 906 partnerów technologicznych. Różnica pomiędzy partnerem a partnerem technologicznym sprowadza się do tego, że ten pierwszy to firmy wdrożeniowe, zaś ten drugi to te, które dostarczają rozszerzenia, czyli na przykład vendorzy płatności mogą być takim partnerem technologicznym. Są to, oczywiście, tylko oficjalne liczby, czyli takie, które znajdują się na stronach Magento czy w okolicach, natomiast na portalu Clutch pod hasłem „Magento” zgłasza się 4577 firm, więc widać, że poza tym oficjalnym kręgiem partnerów Magento tych firm jest całkiem dużo. Zresztą nie tylko firm, bo community też jest całkiem spore. To community, które angażuje się w rozwój Magento, zgłaszanie błędów, wymianę myśli. No cóż, na samym Stack Overflow, jeżeli poszukasz tagu „Magento”, to znajdziesz 37840 wątków (to wszystko na moment nagrywania).

Wniosek, który powinien płynąć z tej części – historycznej i metryczkowej – jest taki, że myślę, że śmiało można powiedzieć, że Magento to jest platforma dojrzała, obudowana w porządny ekosystem, w którym po prostu biznes może czuć się bezpiecznie. Z jednej strony wersja już dobrych naście lat na rynku jest (najpierw jedynka, później dwójka). Rzeczywiście, z tą 2 można powiedzieć, że był trochę falstart i tak naprawdę wersja 2 liczy się, przynajmniej w mojej ocenie, od bardziej nawet wersji 2.3, bo te poprzednie miały swoje różne historie i problemy. Dzisiaj natomiast można śmiało powiedzieć, że jest to platforma stabilna, obudowana dość sporym community i dość sporą ilością firm, dodatków, różnego rodzaju rozwiązań, które powodują, że masz tak naprawdę komfort wyboru.

Jeżeli wybierzesz sobie Magento do wdrożenia, to gdybyś wybrał jedynkę, to pewnie byłoby trudno, ale jeżeli wybierzesz dwójkę, to prawdopodobnie zbyt szybko nie spotka Cię sytuacja, że zostaniesz z tym systemem sam i nikt nie będzie chciał tego rozwijać. Aczkolwiek na pewno jeszcze powiemy sobie o tej drugiej stronie medalu związanej z tymi wszystkimi liczbami, ale to troszeczkę później.

Dlaczego wybrałem Magento?

Troszeczkę później dlatego, że zanim przejdziemy do złych rzeczy i takich, powiedzmy sobie, trochę bardziej budzących wątpliwości, jeśli chodzi o Magento, to najpierw przedstawię Ci mój proces myślowy, który już ponad 10 lat temu doprowadził mnie do wyboru Magento jako główną technologię wdrożeniową do moich projektów e-Commerce.

Kiedy zaczynałem prowadzić software house (już o tym mówiłem kiedyś w podcaście), to na początku, można powiedzieć, że model biznesowy był taki, że co się przyklei, można to kodować, to będziemy to kodować, w związku z czym, poza tym, że pojawiało się dużo różnych projektów, to pojawiało się też całkiem sporo projektów e-Commerce. Mimo że to było dobrych grubych parę lat temu, to e-Commerce już wtedy zaczynał się pomału rozpychać na rynku. W związku z tym, biorąc pod uwagę, że trochę się tego pojawiło, to grzebałem w naprawdę wielu różnych rozwiązaniach. Z tych, powiedzmy, bardziej popularnych, to bym wymienił OSCommerce, Zen Cart, OpenCart, jakieś moduły do Joomli, WooCommerce oczywiście do WordPressa, PrestaShop z tych abonamentowych, Idosell, Shoper, Shopify. Jeszcze przy okazji wypadałoby do tego dodać kilka dedykowanych rozwiązań. Tak że było tego całkiem sporo. Mówiąc „grzebałem”, mam też na myśli tę stronę techniczną, bo przecież z wykształcenia jestem programistą, a kiedyś temu pisaniu kodu poświęcałem zdecydowanie więcej czasu, więc większość tych rozwiązań znam od strony technicznej, rozwoju, pisania customowych rozwiązań.

Pamiętam, że moim pierwszym projektem na Magento był projekt dość specyficzny, bo był to sklep z kartami kolekcjonerskimi typu Magic: The Gathering, gdzie występował taki trochę odwrócony proces zakupowy. Firma prowadziła tak naprawdę skup takich kart, katalog produktowy służył temu, żeby po prostu wylistować te karty czy produkty, które ta firma jest gotowa kupić. Klient mógł sobie dodać do koszyka taką kartę, co oznaczało, że on ją po prostu ma, mógł wpisać sugerowaną cenę, po której jest ją w stanie sprzedać, no i przechodził proces… Normalnie byłby to proces zakupowy, w tamtym biznesie był to raczej proces sprzedażowy i gdzieś tam już ta faktyczna transakcja dochodziła do skutku poza sklepem. To pierwsze wdrożenie Magento nie było więc takim klasycznym sklepem internetowym, ale myślę, że to też pokazuje, że już wtedy wychodziło, że to Magento można dość dobrze i w ciekawy sposób rozwijać. Wtedy to była prawdopodobnie wersja 1.3, być może 1.4, ale na pewno jedna z tych wcześniejszych.

Był taki moment w rozwoju firmy, że (przynajmniej w moim odczuciu i rozumieniu prowadzenia biznesu) pojawiła się taka dość naturalna potrzeba specjalizacji, czyli już nie będziemy robili może wszystkiego, co się tylko da, tylko postawimy na jakiś silnik, który będzie dla nas tym silnikiem pierwszego wyboru. Mając te wszystkie doświadczenia z różnego rodzaju sklepów internetowych i silników sklepów internetowych pojawił się pewien proces myślowy, który, myślę, że gdyby przejść to ćwiczenie dzisiaj jeszcze raz, to prawdopodobnie skończyłbym dokładnie tak samo, mimo tego, że jestem już o parę lat doświadczenia mądrzejszy.

Najpierw nastąpił taki pierwszy odsiew, który polegał na wyborze tak naprawdę półki, z której chcemy zdjąć to rozwiązanie. Na pierwszej półce były, oczywiście, rozwiązania dedykowane. Jeżeli słuchasz Sztuki e-Commerce dość uważnie, to wiesz, że nie jestem zbyt wielkim fanem rozwiązań dedykowanych przede wszystkim dlatego, że może się pojawić vendor-lock, czyli uzależnienie od producenta takiego oprogramowania, szczególnie jeżeli to jest obarczone jakąś licencją, a już nie daj Boże zamkniętym kodem. Często też pojawia się problem wyważania otwartych drzwi, bo jeżeli, na przykład, pojawia się nowa metoda płatności, która zbuduje sobie jakąś popularność, to większość sklepów internetowych dostanie swoją oficjalną wtyczkę producenta, a Ty będziesz musiał ją sobie pisać sam i będzie to po prostu dużo droższe. Wydaje się więc, że rozwiązanie dedykowane jest obarczone tyloma problemami, że to nie do końca było coś, co mi pasowało.

Z drugiej strony i na drugim biegunie są, oczywiście, rozwiązania abonamentowe. Z nimi był wtedy taki problem, że nie do końca nam pasowały, jeżeli chodzi o rozmiar wdrożeń. Chcieliśmy iść w kierunku dużych wdrożeń, fajnych projektów e-Commerce’owych, takich, gdzie można się wykazać, coś fajnie zcustomizować i, można powiedzieć, odcisnąć trwały ślad na tym krajobrazie e-Commerce’owym i tak romantycznie coś po sobie zostawić. Rozwiązania abonamentowe niespecjalnie na to pozwalały, bo ani nie ma tam jakiejś ogromnej elastyki, której my wtedy potrzebowaliśmy i czuliśmy, że to jest fajna droga. Tak naprawdę poza frontendem tam niespecjalnie można było coś zrobić.

W tej matrycy na jednym wymiarze zostały tak naprawdę już tylko rozwiązania open source’owe, gotowe, które można po prostu modyfikować. Na tamte czasy właściwie można było wybrać jedno z trzech rozwiązań, bo umówmy się, że poważni ludzie nie będą rozmawiali o tym, czy warto używać OSCommerce do wdrożeń (bo pewnie nie warto, dzisiaj pewnie też nie), natomiast wtedy poza różnego rodzaju rozwiązaniami właściwie były takie trzy, które warto było wziąć pod uwagę. To był WooCommerce, PrestaShop i Magento, aczkolwiek był taki moment, że pojawiło się OroCommerce. Ja bardzo mocno na ten system stawiałem i bardzo kibicowałem jego rozwojowi. Nie można powiedzieć, że ten rozwój udał się jakoś mocno i podejrzewam, że mogłeś nawet o OroCommerce nie słyszeć, natomiast był moment, w którym bardzo mocno czekałem, aż ta platforma dojrzeje. Niestety, to się nie wydarzyło, więc została bitwa między WooCommerce, PrestaShop a Magento.

Teraz pytanie: dlaczego odpadły WooCommerce i PrestaShop, bo w ten sposób zostało Magento? Przede wszystkim WooCommerce ze względów technicznych. Co by nie mówić o WordPressie, jego popularności, to od strony technicznej nie można powiedzieć, że to jest jakieś piękne rozwiązanie. Raczej bym powiedział (tak bardzo dyplomatycznie), że jest niepiękne. Nie wyobrażałem sobie robienia czegoś dużego na WooCommerce, jakichś bardzo zaawansowanych customizacji, bo to nie jest najbardziej wdzięczny system, jeśli chodzi o rozwój.

Z PrestaShop było dość podobnie. Tam ta technologia – nie było od niej czuć, że jakoś bardzo mocno można ją sobie dostosować do potrzeb. Raczej się w niej szlifuje, a mówimy też oczywiście o takim rozwoju, który nie pozostawia po sobie bardzo dużego długu technologicznego. Nie miałem poczucia, że WooCommerce i PrestaShop naprawdę do dużych wdrożeń typu B2B, gdzie pojawiały się dość zaawansowane integracje, customowe rozwiązania typu jakieś ceny na poziomie Index Client czy jakieś zaawansowane kalkulatory, ofertowniki czy jakaś poważna rozbudowa panelu klienta, czy chociażby jakieś skomplikowane sieci multistore’owe – nie czułem, że PrestaShop będzie najlepszym rozwiązaniem do tego typu przedsięwzięć. Właściwie dość naturalnie zostało to metodą eliminacji sprowadzone do tego, że zostawiamy Magento.

Tak naprawdę po tych kilkunastu latach i kilkudziesięciu projektach później wychodzi na to, że to była całkiem dobra decyzja. Ja jej absolutnie nie żałuję, biorąc pod uwagę, że to były fajne wdrożenia – oczywiście nie wszystkie. Nie będę z tych, którzy mówią, że 100% wdrożeń mi się w życiu udało, ale wszystkie łączyło to, że na pewno były fajne i dawały dużo wyzwań. Magento po prostu się sprawdziło i przez te wszystkie lata myślę, że zebrałbym te wszystkie zalety w kilka punktów.

Zalety Magento

Po pierwsze – to już dzisiaj padło – ale open source. Ja cały czas tłukę i mówię, że warto inwestować w rozwiązania, które będzie można rozwijać nawet w najgorszym wypadku i zawsze trzeba brać pod uwagę ten najgorszy wypadek. Znam sytuacje, że firma zniknęła w międzyczasie rozwoju sklepu i nie sądzę, żeby to była jakaś bardzo egzotyczna historia, bo takie rzeczy się dzieją: możesz się pociąć z wykonawcą, może Ci się ten wykonawca nie spodobać, w drugą stronę – wykonawca może stwierdzić, że jesteś za małym klientem, żeby Cię jakoś mocno wspierać w rozwoju… Nie wiem, może Ci robić jakiś mocny pressing cenowy, cokolwiek, i okaże się, że fajnie mieć możliwość zmiany takiego dostawcy, fajnie mieć możliwość podjęcia chociażby próby rozbudowywania swojego działu rozwoju oprogramowania in house i właściwie open source wydaje się jedyną drogą, która po prostu na to pozwoli.

Drugą, ważną (wydaje mi się) zaletą i cechą Magento jest jego elastyczność. To wynika tak naprawdę wprost z tego, w jaki sposób Magento jest napisane. Tam można się właściwie podpiąć pod każde miejsce w logice kodu i swobodnie modyfikować, nie naruszając przy tym core’u, co jest istotne w kontekście, na przykład, aktualizacji Magento, bo jeżeli byśmy zmodyfikowali core i pojawiłyby się aktualizacje, to by się to po prostu posypało. To oczywiście nie oznacza, że te aktualizacje są jakieś superłatwe, bo bywa różnie, szczególnie przy tych dużych wersjach, ale core jest nienaruszony. Ta możliwość wpinania się tak naprawdę w każde miejsce w logice kodu powoduje, że my naprawdę mamy bardzo mało ograniczeń, jeżeli chodzi o rozwój. Jeżeli, na przykład, na karcie produktu jest wyświetlana cena, to my możemy się pod tę logikę, która to jest cena i w jaki sposób ona została wyliczona, podpiąć i na przykład coś tam od siebie doliczyć. Pomijając, że to jest najbardziej elegancki pomysł, bo akurat w przypadku Magento takie doliczanie na karcie to pewnie nie jest najlepszy pomysł, bo tam jest jeszcze kwestia indeksowania i wielu innych rzeczy po drodze, ale, tak czy inaczej, możemy dopchać się z zewnątrz do tego, w jaki sposób jest wyliczana cena produktu i po prostu to zrobić po swojemu. Oczywiście, nie tylko ceny, bo właściwie wszystko tak możemy sobie modyfikować, w związku z czym, biorąc pod uwagę, że nie modyfikujemy core’u i robimy to w dość elegancki sposób, czyli nie drutując, jak popadnie, to przy odpowiednim zespole, odpowiednich kompetencjach jesteśmy w stanie utrzymać całkiem sensowny poziom długu technologicznego. Na dobrą sprawę, jeżeli będziemy mieli rozwój, który pochłonie dziesiątki tysięcy godzin, to jest duża szansa, że jak się za to dobrze zabierzemy, to nie będzie później takiego problemu, że właściwie strach coś ruszać.

Kolejną rzeczą, którą warto wymienić, jest na pewno fajne, rozbudowane API. Jest to istotne pod kątem integracji, jeżeli ktoś się integruje z nami, a nie my z nim. Jest to też dość istotne pod kątem wdrożeń PWA, bo większość metod, które są potrzebne, po prostu mamy, więc to API jest po prostu kompletne. Tutaj nie ma co się rozwodzić. Uważam, że każdy system powinien być budowany z myślą o tym, że jakoś się do niego trzeba dostać. Tutaj Magento tę cechę po prostu ma, i fajnie.

Kolejną rzeczą, czwartą na tej liście, jest wsparcie dla multistore’u, czyli możliwość postawienia wielu różnych sklepów w oparciu o jeden silnik. Jest to o tyle fajne, że te sklepy są bardzo autonomiczne względem siebie, to znaczy nie muszą być i tak naprawdę postawienie nowego sklepu może się sprowadzać do konfiguracji panelu administracyjnego, natomiast jeżeli chcemy, to te sklepy mogą się od siebie różnić całkowicie, łącznie z frontendem. Możemy sobie zrobić na przykład na jednej instancji sklep B2C dla klienta końcowego i jakiś panel hurtowy B2B, który będzie miał zupełnie inny szablon, inne funkcje dla klienta, inny proces zakupowy i tak dalej. To są też sklepy, które mogą mieć na przykład zupełnie inne cenniki czy różne dane produktowe, bo tam ta możliwość dość swobodnego nadpisywania różnych wartości bądź utrzymywania domyślnych, włączania i wyłączania różnych rozwiązań w obrębie różnych sklepów jest dość elastyczna. Właściwie możemy sobie zrobić naprawdę porządną instancję na wiele różnych kanałów sprzedaży i utrzymywać to na jednym silniku, co jest o tyle istotne, że jeżeli mamy jakieś integracje czy customizacje, które chcemy mieć w każdym sklepie, to to jest koszt, którego nie ponosimy tyle razy, ile mamy sklepów. Jest to oczywiście uproszczenie, bo ten kod, nawet jak mamy kilkanaście sklepów, to byśmy pisali raz, ale utrzymywanie zgodności pomiędzy różnymi sklepami jest po prostu trudne. Jedna instancja nam to trochę ułatwia. Oczywiście, jedna instancja ma też to do siebie, że jak padnie, to razem ze wszystkimi tymi kanałami, ale to, powiedzmy, temat na inną rozmowę. Tak czy inaczej, wydaje się, że można naprawdę dość sporo fajnych rzeczy na tym Magento zbudować.

Kolejną rzeczą jest skalowanie, bo wbrew obiegowej opinii to chyba nie do końca jest tak, że Magento jest jakimś tam wolnym klockiem, który nie dźwignie ani skali produktów, ani jakiejś większej skali ruchu. Widziałem bardzo duże instancje na sześcio- i siedmiocyfrowych liczbach, jeżeli chodzi o produkty i ruch na poziomie kilku tysięcy użytkowników na stronie na raz. Jak się odpowiednio to Magento napisze, posadzi na serwerze, to nie wydaje się, żeby to było jakieś bardzo duże wyzwanie. Myślę, że opinia o tym, że Magento jest powolne, wynika tak naprawdę (o tym jeszcze sobie trochę powiemy) z jakości tego kodu, który jest napisany.

Wiele rzeczy można zrobić na skróty, co nie oznacza, że będą one zrobione dobrze, w związku z czym, jeżeli na przykład źle wykorzystamy w kodzie pobieranie produktów i zrobimy to w jakiejś chorej pętli, produkt po produkcie, i będziemy ładowali wszystkie dane, to jest szansa, że lista produktów nam tak spuchnie, że będzie się ładowała kilkadziesiąt czy kilkanaście sekund. Ale gdybyśmy to zrobili dobrze, ładowałaby się w sekundę. Najczęściej wydaje się, że problemy wydajnościowe to jest tak naprawdę tylko problem jakości kodu, czasami zbyt wolnego serwera, ale też nie wiadomo jakich maszyn nie trzeba tam mieć postawionych, więc ja bym się akurat nie zgodził z tym, że Magento jest jakieś superpowolne. Być może wypadnie gorzej niż inne rozwiązania, tak, powiedzmy sobie, domyślnie na tej samej maszynie, ale wydaje się, że jest to koszt, który przy dużych wdrożeniach nie stanowi aż tak dużego wskaźnika.

Ostatnia rzecz, uważam, że ważna, to rozbudowane community, o którym mówiłem, czyli mnogość dodatków, agencji, co zawraca nas w jakimś tam stopniu do vendor-locka, bo jeżeli się w którymś momencie pokłócisz z agencją, to po prostu sobie ją możesz zmienisz. Chętnych w kolejce będzie na pewno więcej niż tylko ta jedna agencja. Z kolei moduły, szablony czy wsparcie community na różnego rodzaju forach powoduje, że ten koszt i czas wdrożenia w wielu przypadkach można sobie obniżyć. To jest takich sześć punktów, które, wydaje mi się, zbierają się na opinię dość pozytywną – 8/10, pewnie bym Magento wystawił.

Magento – wady

No ale 8/10 to nie 10/10 i rzeczywiście nie chciałbym, żeby po tym odcinku ktokolwiek odniósł wrażenie, że kupę kasy pod stołem poszło, żebym się nachwalił, jakie super to Magento i jakie to ono nie jest. Tak naprawdę myślę, że każda technologia Magento ma swoje wady i nie są to wady, obok których można przejść obojętnie i machnąć na nie ręką. W tej kalkulacji – czy wybierać Magento, czy coś innego – warto je wziąć pod uwagę i poważnie się nad tym zastanowić, bo są to sprawy ważne.

Przede wszystkim warto tutaj chyba powiedzieć o dostępie do specjalistów, bo tak – z jednej strony Magento nie jest najłatwiejszą technologią do przyswajania, a już na pewno nie jest łatwą technologią do osiągnięcia wysokiego poziomu specjalizacji, więc żeby robić naprawdę dobry kod i pisać zgodnie ze sztuką, to trzeba trochę czasu na rozwój poświęcić. Na dzień dobry to nam trochę odcina liczbę specjalistów w porównaniu, na przykład, do takiego WooCommerce, gdzie freelancerów, małych agencji, kilkuosobowych firm, które rozwijają WordPressa, jest po prostu dużo więcej, a że bariera wejścia i, powiedzmy sobie, osiągnięcia takiego przyzwoitego poziomu specjalizacji jest niższa, to automatycznie takich ludzi po prostu na rynku będzie więcej. W związku z tym, biorąc pod uwagę, że popyt jest duży, trzeba być też gotowym na to, że może to rzutować na stawki godzinowe, a przy okazji też na dostępność takich programistów, bo o nich też się będą bili najlepsi. Jeżeli więc będziesz próbował budować sobie zespół in house, to musisz się liczyć z tym, że tych ofert pracy z innych firm może się pojawić sporo, ale rzeczywiście nie jest to aż tak popularne, jak WooCommerce. Nie będzie też łatwo zatrudnić człowieka, który umie robić coś w PHP (nawet bardzo dobrze) i dosłownie w dwa dni przezbroić go na pracę na Magento. To jest troszeczkę bardziej skomplikowany proces i on po prostu będzie trwał dłużej niż w przypadku innych rozwiązań.

Z drugiej strony to też powoduje, że jeżeli masz problem, żeby na poziomie merytorycznym ocenić agencję, którą będziesz zatrudniał do Twojego projektu, a okaże się, że zatrudnia ona właśnie takich średniaków, którzy niespecjalnie mają duże doświadczenie, a Twoje wdrożenie akurat nie jest małe, to możesz nawet nie zauważyć, jak władujesz się w dość duży dług technologiczny, który po prostu później będzie trzeba odgruzowywać i bywają momenty, że jest to… No, nie powiem: „niemożliwe”, bo wszystko jest możliwe, ale jest to na tyle trudne, że niewiele firm się na to w ogóle decyduje. Trochę więc jest to taki pseudo vendor-lock, można nawet powiedzieć.

Drugą wadą, którą warto wziąć na pewno pod uwagę, jest sam rozwój tej platformy. Umówmy się – jeżeli liczysz na jakąś bardzo rozbudowaną road mapę i na bardzo intensywny rozwój Magento, to prawdopodobnie grubo się zawiedziesz. Na dobrą sprawę nie widzę jakichś bardzo dużych różnic w feature’ach między wersją obecną a wersją np. 1.4, oczywiście nie licząc tego, że w międzyczasie się projekt przepisało od nowa i rzeczywiście to rzutowało, na przykład, na wygląd panelu administracyjnego czy na szablon, ale od strony takich funkcji w sklepie te zmiany nie są jakieś bardzo duże. Przykładowo: jeżeli pracowałeś w panelu administracyjnym na jedynce, to, mimo że w dwójce zakładki są poukładane delikatnie inaczej, to tak naprawdę odnajdziesz się, myślę, w godzinę, i będziesz mógł sobie już spokojnie pracować na dwójce. Właściwie niewiele Cię już tam zaskoczy od strony, na przykład, konfiguracji czy przepływu zamówienia.

Gdyby to tak porównywać, na przykład, chociażby z tym WordPressem, który parę razy już tutaj zabrzmiał, to w Magento nie kojarzę takiej rewolucji, jaką na przykład był Gutenberg. Nie sądzę, żeby to się jakoś mocno w przyszłości zmieniło. Trzeba też sobie powiedzieć, że gołe Magento to nie jest jakiś potwór z kosmosu, który lata na jakimś statku pełnym wodotrysków. To jest system przyzwoity na start, natomiast gdyby porównywać tę roadmapę, to wypadłby dość blado.

Jeżeli chodzi o trzecią rzecz, która sprawia, że Magento nie dostanie maksymalnej oceny, to jest ta druga strona medalu pod tytułem – szablony i moduły. Obiecałem o tym powiedzieć i teraz jest właśnie ten moment. One oczywiście są. Niektóre są darmowe, a niektóre płatne – tańsze, droższe, ale są, natomiast podczas researchu trzeba uważać. Dzieje się tak dlatego, że nie wszystkie z tych modułów są równej jakości, a poza tym one mogą się między sobą żreć. W związku z tym, jeżeli, na przykład, załadujesz sobie pięć różnych modułów do koszyka, z czego jeden dodaje gratis, drugi oblicza jakieś promocje bardziej zaawansowane, a trzeci umożliwia wpisywanie wielokrotnych kodów rabatowych, to może się okazać, że cena produktu będzie dość specyficzna, a na pewno nie taka, jak byś chciał, a przy okazji ten koszyk przestanie działać. Jeżeli sobie tak polepimy ten sklep na 30 różnych modułów, to ja niezbyt zazdroszczę firmie, która będzie to potem rozwijać. Tak naprawdę skala takich współzależności może być tak duża i poziom długu technologicznego może być tak duży, że to rzeczywiście na start było tańsze, ale w długiej perspektywie już niespecjalnie. Tak jest też na przykład w przypadku szablonów graficznych.

W którymś odcinku, co prawda chyba o WordPressie, w kontekście SEO była o tym mowa, że jak sobie kupimy szablon do WordPressa, to później okazuje się, że vitalsy leżą, bo na bardzo prostej stronie statycznej ładuje się 50 różnych kodów JS-owych na wypadek, gdybyś chciał sobie na stronie o firmie uruchomić 15 różnych feedów z Pinteresta. Pewnie mało kto chce, ale już te JS-y są, to niech już sobie będą. W Magento będzie podobnie. Jeżeli się nawali tych modułów, szablonów, to może być tak sobie, więc radziłbym unikać, a już na pewno unikać researchu na własną rękę, bo są firmy, o których jakości krążą legendy – chociażby hinduskie, które te moduły naprawdę robią takiej jakości, że wydaje się, że dużo tam jest, a później się okazuje, że nic nie działa, a krew, pot i łzy, które się zostawia na podłodze po próbie ich naprawienia wydają się niewarte tego, jakie są korzyści płynące z ich wdrożenia. Czasami lepiej niektóre rzeczy po prostu zrobić samemu.

Tutaj taka moja mała uwaga i osobista refleksja, i rada, którą mam dla Ciebie: ja traktuję Magento przede wszystkim jako framework, czyli nie takie pudełkowe rozwiązanie, że zainstalujesz, poklikasz i jest, tylko raczej jako system, który w podstawie jest tak dobrze napisany, że przy tych wdrożeniach, które ja realizuję, Magento się po prostu nie wyłoży. Jeżeli więc mamy do czynienia z jakimś dużym wdrożeniem, systemem, który nie będzie robiony metodą takiego smutnego ulepa, że nadrutujemy modułów, to ewidentnie widać te przewagi Magento nad innymi rozwiązaniami. Ja zawsze mówię, że Magento po prostu zaczyna się tam, gdzie inne sklepy zaczynają się już pomalutku kończyć, ze względu chociażby na dług technologiczny. Mówię więc o tych modułach i szablonach, bo one rzeczywiście są i są bardzo przyzwoite rozwiązania, i wiele firm z nich korzysta, szczególnie te backendowe. Jest więc taki zestaw modułów, który nawet warto mieć w tym sklepie, natomiast trzeba do tego podchodzić dużą uważnością, żeby, zyskując sporo pieniędzy na start, nie zrobić sobie krzywdy w długiej perspektywie.

Na koniec wad warto powiedzieć o tej, która chyba jest poruszana najczęściej, a ja się z nią kolei nie zgadzam praktycznie w całej rozciągłości. Mowa oczywiście o kosztach. Przyjęło się, że Magento jest drogie w rozwoju i osobiście uważam, że jest to zbyt duże uproszczenie i raczej nie powinno się o tym w ten sposób mówić, a już na pewno nie powinno się w ten sposób myśleć. Otóż koszt sklepu, w bardzo dużym uproszczeniu, jest pochodną tego, jaka jest różnica pomiędzy wersją docelową Twoich potrzeb a wersją sklepu dostępnego na start. Jest ona najczęściej wyrażona iloczynem liczby godzin i stawki godzinowej. Dość prosty wzór – mamy sklep w punkcie A, chcemy zrobić do punktu B i liczba godzin, którą potrzebujemy, wyrazi nam koszt tego sklepu. Im bliżej będzie ten sklep, tym pewnie będzie taniej, i oczywiście trzeba wziąć pod uwagę stawkę godzinową. Oznacza to dokładnie tyle, że sklep na PrestaShop od sklepu na Magento będzie tańszy wtedy, gdy albo tych godzin z jakiegoś powodu będzie mniej, albo stawka godzinowa będzie niższa. Inaczej nie będzie, bo to jest tak naprawdę pochodna kosztu sklepu i w taki sposób się te projekty wycenia. Niezależnie od tego, czy na koniec dostaniesz kwotę, czy liczbę godzin – jest to tylko inaczej wyrażony koszt usługi.

Teraz pytanie – czy taki scenariusz jest możliwy, że tych godzin będzie mniej albo stawka godzinowa będzie niższa? Oczywiście tak, bo mówiliśmy o tym, że specjaliści mogą być tańsi w przypadku innych rozwiązań, bo jest ich więcej, bariera wejścia jest niższa. W związku z tym ekonomia też trochę powoduje, że ta stawka może być niższa, bo też mniej energii trzeba poświęcić na to, żeby być specjalistą w przypadku innych rozwiązań.

Trzeba sobie też powiedzieć, że taki scenariusz dotyczy raczej tych małych projektów, a już było dzisiaj mówione, że Magento zaczyna swoją przewagę wykazywać tam, gdzie inne rozwiązania już się raczej kończą i to nie w takim sensie, że się nie da, tylko da się, ale będzie to: a) pochłaniało bardzo duże ilości godzin i wymagało dość dużej specjalizacji, więc automatycznie liczba godzin nam wzrośnie i być może stawka godzinowa też. No i b) – można się władować w taki dług technologiczny, że będzie trudno się z niego po prostu wygrzebać. W związku z tym, jak już ten dług technologiczny zacznie nam narastać, to w długiej perspektywie okaże się, że tych godzin na inne rozwiązania będzie trzeba poświęcać jeszcze więcej niż w przypadku Magento. Trochę więc upraszczając, można sobie założyć, że im większy projekt, tym albo pojawi się większy rozjazd godzinowy pomiędzy tymi dwoma rozwiązaniami i w długiej perspektywie Magento może wygrać, albo może się okazać, że nadal mit zostanie zachowany i duży projekt na Magento będzie droższy, a na innym rozwiązaniu będzie tańszy, ale będzie się to wiązało z takim ukrytym kosztem, który będzie związany z długiem technologicznym. Z tym kosztem więc można powiedzieć, że to trochę prawda, ale tak nie do końca i trzeba mieć to po prostu na uwadze, a jeżeli byśmy patrzyli na to tylko od strony liczb przy projektach o odpowiedniej skali, to myślę, że nawet mogłoby być odwrotnie.

XXX

Warto by było chyba zrobić jakieś podsumowanie i dojść do jakiegoś sensownego werdyktu, jakiejś konkluzji. Gdybym miał bardzo mocno uprościć i odpowiedzieć, dla kogo jest Magento i czy jest dobrym wyborem, to niestety nie odpowiem na to pytanie. Jednak, jeżeli słuchasz Sztuki e-Commerce, to wiesz, że na to pytanie nie ma tak naprawdę jednoznacznej odpowiedzi, bo zbyt wiele czynników wpływa na podjęcie decyzji: to, jaką masz skalę projektu tu i teraz, plus, jakie masz potrzeby rozwojowe w perspektywie trzech, pięciu lat, czy to jest duży, mały projekt, jakie tam są integracje, czego potrzebują Twoi klienci – czy to jest B2B, B2C, czy tam będzie dużo różnych sklepów, czy raczej celujemy na jeden sklep. Jest tych pytań, które trzeba sobie zadać, dość dużo. Tu znów zachęcam do przesłuchania innych odcinków, natomiast gdyby na to patrzeć, pomijając w ogóle kontekst tego, z czym mierzysz się na wdrożeniu, to biorąc pod uwagę stawkę godzinową, dostępność programistów, możliwości na start, raczej bym nie rekomendował tego rozwiązania, jeśli celujesz w coś naprawdę prostego. Może się okazać, że rzeczywiście (i prawdopodobnie się okaże) inne technologie będą po prostu tańsze.

W tym wypadku warto się też zastanowić, czy na pewno open source jest jedynym koniecznym rozwiązaniem, bo może warto by było się zakotwiczyć na jakimś rozwiązaniu abonamentowym. Jednak jeżeli masz mały sklep i to jednak będzie open source, bo chcesz się sam rozwijać, to nie czuję, że Magento Ci się jakoś mocno przysłuży. Oczywiście, jeżeli się pojawią potrzeby rozwojowe, to jak najbardziej, ale na start to może niekoniecznie, chociaż nie uważam, że dużym błędem w sztuce byłoby wdrożenie małego projektu na Magento, bo właściwie czemu nie? Jeżeli masz odpowiednie kompetencje i chcesz, no to why not? Da się to zrobić, da się postawić nawet samodzielnie taki sklep na serwerze i go skonfigurować, poustawiać parę modułów. To nie jest tak, że się nie da albo że wręcz nie wolno, co też często próbuje być forsowane, natomiast wydaje się, że w tym równaniu raczej bym rekomendował coś innego.

Jeżeli masz tę skalę zmian systemu większą teraz lub w niedalekiej przyszłości, to na pewno szala przechyla się w kierunku rekomendacji właśnie Magento ze względu na to, że ten rozwój może się odbywać w warunkach, w których dług technologiczny po prostu nie wybije pod sufit i po czterech, pięciu, siedmiu latach okaże się, że dalej się da ten system rozwijać i nikt nie roni łez, jak musi otworzyć edytor kodu.

Należy też na pewno pamiętać o tym, że trzeba się wykazać bardzo dużą uważnością w wyborze agencji, bo jeżeli wybierzesz źle, to właściwie wszystkie przewagi Magento szlag trafia i pakujesz się po prostu w problemy, ale myślę, że tego też koneserom i wytrawnym słuchaczom Sztuki e-Commerce nie trzeba mówić i tłumaczyć, bo doskonale to wiedzą. Jeżeli nie, no to znowu – zachęcam do nagrań archiwalnych.

Na koniec chciałbym zostawić Cię z taką myślą, żebyś pamiętał, że zawsze w tym pochodzie pierwsze zawsze idą potrzeby biznesowe, a potem dopiero szukanie rozwiązań. Nigdy odwrotnie.