Okiem wdrożeniowca: dlaczego sklep internetowy często przypomina motor po domowym tuningu?

Prima Aprilis to dobry moment, żeby coś powiedzieć żartem… a jak wiadomo najlepsze żarty to te oparte na faktach.

W mojej pracy często słyszę: „tu tylko przesunąć przycisk”, „na telefonie samo się dopasuje”
„to już było kiedyś zrobione, proszę tylko przenieść”, i za każdym razem mam przed oczami nie komputer, tylko warsztat, do którego jeżdżę na przegląd motocykla. Bo prawda jest taka, że praca przy sklepie internetowym bardzo często przypomina pracę mechanika. Tyle że mechanik, kiedy mówi „trzeba rozebrać pół maszyny, żeby zrobić jedną rzecz porządnie”, zwykle spotyka się ze zrozumieniem.

A kiedy mówię to samo w kontekście sklepu, u moich rozmówców pojawia się zdziwienie.

To, co chcesz zmienić, to nie jedyna rzecz do zmiany.

Kiedyś mój mechanik opowiadał mi historię, oczywiście w swoim stylu:

„Pani, przyszoł chłop z maszyną, mówi: tylko kierownica krzywo stoi. A my patrzymy - lagi inne, półki inne, zawieszenie jakieś takie zlepione… i jeszcze rama była lekko ‘po przygodach’. No i co? Kierownica to był najmniejszy problem, nie?”

W sklepach internetowych jest dokładnie tak samo. Jeśli zmiana dotyczy na przykład sposobu wyboru wariantu albo dodawania produktu do koszyka, to rzadko kończy się na jednym miejscu. Ten sam mechanizm może działać jednocześnie na karcie produktu, na listach produktów czy w sekcjach polecanych. To jest jeden układ naczyń połączonych, tylko zamiast śrub i przewodów mamy kod, style i logikę.

Dopiero po rozebraniu na części widać, co tam naprawdę siedzi

Wracamy do warsztatu.

„Pani, my to rozebrali i dopiero wyszło…” - zaczyna mój mechanik, a ja już wiem, że będzie ciekawie, bo przyprowadziłam maszynę kolegi po domowym tuningu. „Ktoś tam wcześniej kombinowoł, kabelki na trytytki, jakieś obejścia… Tu już tylu fachowców było, że my najpierw musimy dojść, co oni tu narobili, zanim coś ruszymy.”

I to jest ta sytuacja, która w warsztacie nikogo nie szokuje, a w IT nadal potrafi budzić zdziwienie. Zgłoszenie dotyczy jednego elementu, a po wejściu głębiej w kod okazuje się, że coś było przerabiane, coś nadpisane „na szybko”, coś przestało pasować po aktualizacji i trzeba było na sztywno łatać, a każdą z tych poprawek wprowadzał inny zespół. Niby wszystko działa, ale każdy kolejny fachowiec musi najpierw zrozumieć, co tu właściwie zostało zrobione, co zostało dopisane, co wyłączone, a co „na razie działa, więc lepiej nie dotykać”.

I nagle z „pięciu minut” robi się kilka godzin, bo sytuacja wymaga zrozumienia całej historii zmian, żeby nie tylko naprawić swoją część, ale też nie popsuć wcześniejszych… poprawek?

Podrasowanie to nie jedna śrubka

To samo dotyczy wprowadzania modyfikacji. Z boku wygląda niewinnie: coś ulepszyć, coś przyspieszyć, coś rozbudować. W praktyce rzadko skupia się to na samym elemencie docelowym, bo jeśli modyfikujemy istniejący mechanizm, to trzeba jeszcze sprawdzić, co już jest do niego podpięte, z czego korzysta, co może się z nim zderzyć i co trzeba dostosować, żeby po zmianie nie rozsypała się reszta.

To trochę jak wymiana silnika na większy. Nowy silnik to dopiero początek. Zaraz pojawia się temat przewodów, chłodzenia, osprzętu, mocowań, elektroniki i wszystkiego, co musi wytrzymać nowe warunki pracy.

I dokładnie tak samo bywa w e-sklepie, rozwijając jeden mechanizm, trzeba dopasować inne współzależne elementy, żeby nie naruszyć istniejącego „ekosystemu”

„To to już mieliśmy zrobione, proszę tylko przenieść”

To jedno z moich ulubionych stwierdzeń, bo przypomina próbę przełożenia części z jednego motocykla do drugiego. Niby podobne, niby pasuje. A potem się okazuje, że mocowania są 3 mm nie w tą stronę, a wtyczka na krótkim kablu wychodzi z przeciwnej strony.

Gdy mechanik powie: „to przecie części do innego modelu”, to jest to koniec dyskusji, w odniesieniu do pracy z kodem brakuje tego zrozumienia.

To, że coś kiedyś pasowało, nie znaczy, że dziś da się to przenieść na inną wersję i zapomnieć o temacie. W szablonach i dedykowanych modyfikacjach liczy się kontekst: pod jaką wersję sklepu coś powstało, jak było zbudowane i do czego było dopasowane. Jeśli po drodze zmieniła się struktura szablonu albo wersja systemu, stare rozwiązanie nie zawsze da się po prostu „przekleić”.

Mobile to nie desktop w wersji „mini”

Na koniec coś o pakowaniu, a dokładniej pakowaniu treści w wersję mobilną sklepu. To, że coś dobrze wygląda na komputerze, nie znaczy jeszcze, że „samo się ułoży” na telefonie.

Tak samo, jak nie przełożysz całego bagażu na tygodniową wyprawę z dużego turystyka na miejski skuter, tak samo nie przełożysz treści 1:1 z wersji desktop na mobilną - z czegoś musisz zrezygnować (np. wielki baner powitalny), coś trzeba przeorganizować, a coś przerzucić na inną podstronę.

Na mobile liczy się nie tylko wygląd, ale też układ, kolejność elementów, klikalność czy szybkość ładowania. To jest projektowanie od nowa, a nie skalowanie w dół.

I już bez żartów

Zmiana w szablonie rzadko bywa tylko prostą, szybką poprawką. Często dochodzi do tego dodatkowe dopasowanie, weryfikacja innych elementów albo głębsza analiza, bo to, co z zewnątrz wygląda niewinnie, od środka potrafi okazać się dużo bardziej złożone.

I dlatego w świecie wdrożeń „to tylko pięć minut” brzmi mniej więcej tak samo jak dla mechanika: „Panie… przecie to chwila roboty, nie?”