Kiedy kod, a kiedy konfiguracja

Każda z nich bywa właściwa. Różnią się czasem realizacji, kosztem i trwałością efektu, a w konkretnym przypadku każdy z tych trzech czynników może zdecydować o wyborze.

O wyborze drogi decyduje więc nie zasada, tylko rozpoznanie: gdzie w systemie leży przyczyna tego konkretnego zgłoszenia. Przeprowadzone przed skierowaniem sprawy kosztuje jedną decyzję. Przeprowadzone później kosztuje wycenę, wdrożenie i czas, który zdążył minąć.

Poniżej cztery warstwy, w których ta przyczyna zwykle się mieści, i sześć zgłoszeń, na których widać, jak je od siebie odróżnić.

Skąd bierze się nieporozumienie

Dział obsługi klienta opisuje objaw, bo tylko objaw widzi. „Nie da się wybrać wysyłki", „zamówienie zniknęło", „klient dostał nie to, co zamawiał". To są rzetelne zgłoszenia, sformułowane najlepiej, jak się da z tego miejsca.

Wykonawca techniczny dostaje opis objawu i szuka rozwiązania w warstwie, którą zna najlepiej. To również jest rzetelne. Widzi zgłoszenie, nie widzi historii zgłoszeń, nie zna ustawienia zmienionego trzy miesiące temu i nie ma powodu zakładać, że przyczyna leży w panelu, do którego zwykle nie zagląda.

Nikt tu nie działa w złej wierze. Brakuje kroku pomiędzy: momentu, w którym ktoś ustala, w której warstwie systemu leży przyczyna, zanim sprawa zostanie skierowana i wyceniona.

Cztery warstwy

Przyczyna zgłoszenia technicznego w sklepie internetowym leży zwykle w jednej z czterech warstw. Każda ma inny właściwy adres i inny koszt.

Ustawienie pojedynczego obiektu. Pole w konfiguracji produktu, kategorii, formy dostawy albo płatności. Zmiana zajmuje minuty i nie kosztuje nic poza czasem osoby, która ją wykona.

Ustawienie domyślne albo szablon. To samo pole, ale w miejscu, z którego dziedziczą wszystkie nowe obiekty. Zmiana trwa dłużej, bo wymaga zrozumienia, co dziedziczy z czego, ale jest jedyną, która działa w przód.

Zachowanie samej platformy. Moduł dostawcy robi coś innego, niż wynika z dokumentacji albo z tego, co pokazuje panel. Adresatem jest dostawca, a nie wykonawca. Naprawa u źródła jest zwykle bezpłatna i obejmuje wszystkich klientów platformy, ale trwa tyle, ile trwa cudzy proces.

Kod. Skrypty na froncie, integracje, logika, której panel nie obejmuje. Rozwiązanie jest wyceniane, wdrażane i wymaga późniejszego utrzymania, ale bywa jedyne możliwe.

Klasyfikacja do właściwej warstwy jest całą treścią etapu, o którym piszę. Nie polega na zgadywaniu, tylko na sprawdzeniu.

Sześć zgłoszeń jako materiał

Poniżej sześć typów zgłoszeń, z jakimi spotkałam się w pracy nad sklepami internetowymi. Podaję objaw, warstwę i to, po czym daną warstwę rozpoznać. Wszystkie mechanizmy występują w większości systemów, bo wszystkie systemy rozwiązują te same problemy w podobny sposób.

Forma dostawy niedostępna przy droższych zamówieniach

Objaw: klient nie może wybrać jednej z metod wysyłki, choć widzi ją na liście.

Warstwa: ustawienie pojedynczego obiektu. Formy dostawy mają w większości systemów warunki zależne od wartości lub wagi zamówienia, bo przewoźnicy mają limity ubezpieczenia przesyłki. Ktoś kiedyś wpisał próg i nikt do tego nie wrócił.

Po czym poznać: opcja nie znika, tylko przestaje być klikalna. To jest sygnatura warunku, a nie braku uprawnień ani błędu skryptu.

Ile zajmuje diagnoza: w tym przypadku kilka godzin i przejście przez cztery poziomy konfiguracji: ustawienia globalne form dostawy, przypisania na poziomie kategorii, dziedziczenie na poziomie produktu, test w koszyku. Do właściwego pola doprowadziło dopiero odtworzenie dokładnej ścieżki opisanej w zgłoszeniu, z tym samym produktem i tą samą metodą składania zamówienia.

Ile zajmuje naprawa: kilkanaście sekund.

Ta dysproporcja jest typowa i warto ją znać, zanim się zacznie. Takie zgłoszenie nie jest trudne. Jest nieoczywiste, a to zupełnie co innego: nie wymaga wiedzy, której nie masz, tylko cierpliwości w miejscu, gdzie wszystko wygląda poprawnie.

Zamówienie anulowane przez system

Objaw: klient złożył i opłacił zamówienie, a system anulował je samodzielnie.

Warstwa: ustawienie domyślne. W większości systemów produkt ma przełącznik decydujący o tym, czy jego dostępność zależy od stanu magazynowego. Przełącznik bywa domyślnie włączony, bo platformy e-commerce projektowano dla towaru. Przy usłudze, prenumeracie, kodzie albo konsultacji stan magazynowy zostaje pusty, więc system uznaje, że produktu nie ma.

Po czym poznać: system zachowuje się poprawnie z własnego punktu widzenia. Nic nie jest zepsute, wszystko działa zgodnie z konfiguracją.

Najszybsza droga: znaleźć wszystkie pozycje z tym samym ustawieniem jednym ruchem, a nie produkt po produkcie. W większości systemów działa przynajmniej jedno z trzech: filtr lub sortowanie listy po polu odpowiadającym za dostępność, edycja masowa obejmująca to pole, albo eksport asortymentu do arkusza i sprawdzenie całej kolumny na raz.

Trwałe rozwiązanie: zmiana wartości domyślnej albo szablonu, z którego powstają nowe produkty. Poprawienie istniejących pozycji usuwa skutki. Zmiana ustawienia domyślnego usuwa przyczynę.

Komunikat o niedostępności na karcie produktu

Objaw: klient widzi informację, że produktu nie ma.

Warstwa: ta sama co wyżej, tylko widziana od strony frontu. To jest ten sam defekt, zgłoszony ponownie, przez inną osobę i pod inną nazwą.

Rozwiązanie zastosowane pierwotnie: ukrycie komunikatu stylem. Warto się przy tym zatrzymać, bo to jest przypadek kodu użytego do objawu, nie do przyczyny. Komunikat znika z widoku, ale status produktu pozostaje bez zmian, więc produkt nadal może zachowywać się jak niedostępny w koszyku, przy płatności albo przy zamówieniu składanym z panelu.

Pytanie, które rozstrzyga: czy produkt faktycznie da się kupić. Nie: czy komunikat jest widoczny.

Możliwość pominięcia wyboru wariantu

Objaw: zamówienia przychodzą bez wskazania wariantu, choć wariant jest niezbędny do realizacji. Każde takie zamówienie oznacza dodatkowy kontakt z klientem i opóźnienie.

Warstwa: ustawienie, ale z zastrzeżeniem, które warto znać. W większości systemów wymagalność wyboru atrybutu jest funkcją natywną, dostępną jako zwykły przełącznik. Bywa jednak obwarowana warunkiem: da się ją ustawić przy tworzeniu nowego przypisania atrybutu, a nie przy edycji istniejącego.

Co z tego wynika dla wyceny: odpowiedź „z panelu się nie da" bywa prawdziwa dla stanu zastanego i nieprawdziwa dla stanu docelowego. Przy kilku produktach odtworzenie przypisań od nowa jest szybsze niż jakakolwiek praca programistyczna. Przy kilkuset przestaje takie być i wtedy wycena kodu jest jedną z dwóch racjonalnych opcji, którą porównuje się kosztem, a nie odrzuca z zasady.

Jak to rozstrzygnąć, zanim ktokolwiek cokolwiek wyceni: duplikat produktu, ustawiony jako wyłączony, przypisania utworzone od nowa z zaznaczoną flagą, test dodania do koszyka na froncie. Kwadrans i wiadomo, o czym rozmawiamy. Kopia produktu jest darmowa i niewidoczna dla klientów, więc pozwala sprawdzić dowolną hipotezę bez dotykania produkcji.

Wariant zaznaczony domyślnie

Objaw: klienci zamawiają nie ten wariant, który chcieli.

Warstwa: i tu sprawa jest ciekawsza, niż wygląda. Kolejność atrybutów w grupie albo automatyczny wybór pierwszej dostępnej opcji rozstrzygają, który wariant jest zaznaczony na wejściu. Nie rozstrzygają, czy którykolwiek ma być zaznaczony.

W większości systemów stan „nic nie wybrano" po prostu nie istnieje jako opcja. Jeśli więc wymaganie brzmi „klient ma dokonać świadomego wyboru", a flagi wymagalności nie da się zastosować, kod jest właściwą drogą, nie obejściem.

Dlaczego to zgłoszenie prawie nigdy nie trafia do rejestru błędów: formalnie nic się nie zepsuło. System pokazał wariant, klient go zaakceptował, zamówienie przeszło. Koszt jest w obsłudze posprzedażowej, nie w systemie.

Niespójne dane w zamówieniu

Objaw: zamówienie zawiera pole, które przy wybranym wariancie nie powinno się w ogóle pojawić.

Warstwa: kod. Odtworzenie ścieżki w przeglądarce z otwartą konsolą pokazało błąd TypeError w funkcji obsługującej zmianę wariantu. Skrypt przerywał działanie, zanim zdążył wyczyścić pole, więc wartość szła do bazy razem z zamówieniem.

Co zmienia sposób zgłoszenia: sprawa poszła dalej z komunikatem błędu i lokalizacją w kodzie, a nie z prośbą o sprawdzenie, czy coś jest nie tak. Zgłoszenie ze wskazanym miejscem skraca pracę po stronie wykonawcy, zamiast ją podważać.

Czas, koszt i trwałość

Poniższe zestawienie jest orientacyjne i ma pokazać rzędy wielkości, a nie cennik. Stawka roboczogodziny przyjęta rynkowo, w przedziale 250 do 350 złotych.

Do tego dochodzi koszt, którego nie ma w żadnej wycenie: czas diagnozy. Sprawa pierwsza pochłonęła kilka godzin, żeby doprowadzić do zmiany trwającej kilkanaście sekund. Ten czas jest realny i trzeba go w rachunku uwzględnić.

Uwzględnić, ale nie mylić z kosztem. To jest jednorazowa inwestycja w wiedzę o systemie, która zostaje. Kolejne zgłoszenie z tej samej rodziny rozpoznaje się w kilka minut, bo wiadomo już, gdzie patrzeć.

Koszt problemu, nie tylko rozwiązania

Stawka roboczogodziny jest liczbą, którą łatwo zestawić z zerem i wyjść na to, że konfiguracja zawsze wygrywa. Takie zestawienie jest niepełne, bo pomija drugą stronę: koszt tego, że problem trwa.

Anulowane opłacone zamówienie to nie tylko utracona marża. To zwrot płatności, czas obsługi, ryzyko negatywnej oceny i klient, który drugi raz nie wróci. Zablokowana forma dostawy przy droższych zamówieniach uderza dokładnie w najbardziej dochodowy koszyk, a nie w przypadkowy. Zamówienie z niepełnymi danymi to telefon, opóźnienie realizacji i przesunięcie w kolejce, które odczuwają także zamówienia złożone po nim.

Żadna z tych pozycji nie pojawia się w żadnej wycenie, bo nikt jej nie fakturuje. Wszystkie mają jednak wartość i wszystkie rosną z każdym tygodniem, przez który przyczyna pozostaje nieusunięta.

Stąd wniosek, który przeczy pierwszemu odruchowi: wycena kodu wygląda na wysoką w oderwaniu, a bywa tania w zestawieniu z miesiącem zwłoki. Właśnie dlatego rozpoznanie warstwy ma sens niezależnie od tego, którą drogę ostatecznie się wybierze. Bez niego porównuje się jedną liczbę z niczym.

Kiedy kod jest właściwą drogą

Warto to nazwać wprost, bo tekst o klasyfikacji łatwo odczytać jako tekst przeciwko wycenom, a to byłoby nieporozumienie.

Kod jest właściwą drogą, gdy funkcji nie ma w panelu i nie ma jej w żadnym ustawieniu domyślnym. Gdy istnieje, ale jej zastosowanie do stanu zastanego wymagałoby pracy przekraczającej koszt wdrożenia. Gdy potrzebne zachowanie zależy od warunków, których konfiguracja nie obejmuje. Gdy rzecz dotyczy integracji z systemem zewnętrznym. I gdy w konsoli widać błąd, bo wtedy nie ma o czym rozmawiać.

W każdej z tych sytuacji wycena jest zasadna, a spieranie się o nią to strata czasu obu stron.

Kiedy konfiguracja wystarcza

Konfiguracja wystarcza, gdy system zachowuje się dokładnie tak, jak go ustawiono, tylko ustawiono go kiedyś inaczej, niż potrzeba dziś. Gdy objaw dotyczy pojedynczych obiektów, a nie całej logiki. Gdy w panelu istnieje pole, które odpowiada dokładnie temu, o co chodzi w zgłoszeniu. I gdy problem da się odtworzyć na kopii, a potem na tej kopii rozwiązać.

Rozpoznanie tych sytuacji nie wymaga umiejętności programistycznych. Wymaga znajomości panelu i gotowości, żeby przez niego przejść.

Świadomość użytkownika systemu

To jest sedno całej rzeczy i warto powiedzieć to bez ogródek.

Osoba, która na co dzień pracuje w panelu sklepu, jest jedyną, która widzi jednocześnie trzy rzeczy: zgłoszenie, konfigurację i historię poprzednich zgłoszeń. Dział obsługi widzi pierwsze. Wykonawca widzi drugie, i to tylko na tyle, na ile mu się pokaże. Trzeciego nie widzi nikt poza nią, bo nikt inny go nie przeżył.

Ta wiedza nie jest kompetencją techniczną. Jest kompetencją operacyjną i buduje się ją przez świadome przejście przez panel administracyjny systemu sklepowego, nie przez kurs. Kilka godzin poświęconych na sprawdzenie, co właściwie da się w tym systemie skonfigurować, zwraca się przy pierwszym zgłoszeniu, które dzięki temu nie trafi do niewłaściwej kolejki.

Pięć rzeczy do sprawdzenia we własnym sklepie

Poniższa lista wynika wprost z opisanych wyżej przypadków. Przejście przez nią zajmuje jedno popołudnie i nie wymaga niczyjej pomocy.

Produkty, które nie są towarem. Usługi, kody, prenumeraty, przedsprzedaże, pozycje realizowane na zamówienie. Czy mają włączoną zależność dostępności od stanu magazynowego przy pustym stanie? Pytanie kontrolne: co zrobi system, jeśli ktoś kupi taką pozycję dziś w nocy.

Progi wartości i wagi przy formach dostawy oraz płatności. Czy któraś metoda ma ustawiony górny albo dolny limit i czy ten limit nadal odpowiada aktualnym cenom w sklepie? Pytanie kontrolne: czy najdroższy produkt w asortymencie da się kupić każdą dostępną metodą.

Warianty i atrybuty niezbędne do realizacji. Czy klient może przejść do płatności bez dokonania wyboru i który wariant jest zaznaczony na wejściu? Pytanie kontrolne: ile zamówień z ostatniego miesiąca wymagało kontaktu w celu uzupełnienia danych.

Ustawienia domyślne nowych pozycji. Z czego dziedziczy nowo zakładany produkt i czy te wartości są takie, jakich oczekujesz? Pytanie kontrolne: załóż produkt testowy, nie zmieniaj w nim niczego i przejrzyj, co dostał bez Twojego udziału.

Rejestr zgłoszeń z ostatniego półrocza. Czy któreś dwa opisy, mimo różnych nazw, dotyczą tego samego pola w konfiguracji? Pytanie kontrolne: czy przy zamkniętych sprawach zapisano przyczynę, czy wyłącznie zastosowane rozwiązanie.

Pierwsze cztery punkty dotyczą każdego sklepu, także takiego, który sprzedaje wyłącznie towar z magazynu. Przedsprzedaż, produkt na zamówienie i personalizacja zachowują się w systemie dokładnie tak samo jak usługa, bo w żadnym z tych przypadków stan magazynowy nie opisuje rzeczywistej dostępności.

Z tej świadomości wynika też druga rzecz, ważniejsza niż oszczędność na pojedynczej wycenie. Sprawę zamyka się zwykle wtedy, gdy objaw znika, a nie wtedy, gdy przyczyna zostaje usunięta. Te dwa momenty bywają odległe o miesiące, a czasem drugi nie następuje wcale. Zarządzanie usługami rozróżnia te dwie rzeczy od dawna: przywrócenie działania to jedno zadanie, usunięcie przyczyny to drugie, osobne, z własnym właścicielem i terminem. W e-commerce ten podział prawie nie występuje.

Dlatego to samo ustawienie potrafi wrócić trzykrotnie, za każdym razem pod inną nazwą i przez inną osobę, a w rejestrze figurują trzy niepowiązane sprawy. Koszt jest niewidoczny, bo rozdrobniony. Żadne pojedyncze wystąpienie nie jest dość duże, żeby ktoś je zakwestionował, a sumy nikt nie liczy, bo formalnie nie ma czego sumować.

Co z tego wynika w praktyce

Sześć zasad, wszystkie do wdrożenia bez zmiany narzędzi i bez czyjejkolwiek zgody.

Zgłoszenie techniczne przechodzi przez klasyfikację, zanim trafi do wykonawcy. Jedna osoba, jeden krok, ustalenie warstwy. To nie jest kontrola wykonawcy, tylko przygotowanie sprawy.

Odtwarzaj ścieżkę zgłaszającego, nie własną. Ten sam produkt, ta sama metoda składania zamówienia, ta sama kolejność kroków. Większość „nieodtwarzalnych" zgłoszeń jest odtwarzalna w warunkach, których nie powtórzono.

Testuj na kopii, nie na produkcji. Kopia produktu jest darmowa, wyłączona i niewidoczna dla klientów. Pozwala sprawdzić hipotezę zamiast o niej dyskutować.

Przy wycenie ustalaj warstwę, nie kwestionuj kwoty. Pytanie „czy to konfiguracja, czy kod" jest pytaniem o zakres pracy, nie o cenę. Rzetelny wykonawca odpowie na nie bez oporu, a odpowiedź bywa niuansowana i wtedy właśnie jest najbardziej wartościowa.

Kieruj sprawę pod właściwy adres. Błąd platformy zgłasza się do dostawcy, gdzie naprawa jest zwykle bezpłatna i obejmuje wszystkich jego klientów. Nowa funkcjonalność idzie do wykonawcy i podlega wycenie. Samo skierowanie bywa całą oszczędnością.

Zapisuj przyczynę źródłową, nie tylko rozwiązanie. Jedno pole w rejestrze zgłoszeń, wypełniane zdaniem, a nie kategorią z listy rozwijanej. Zajmuje kilkanaście sekund i jest jedyną rzeczą, która pozwala zobaczyć wzorzec, zanim wróci po raz trzeci.

Najdroższe zgłoszenie to nie to, które trafiło do programisty. To takie, które wróciło po raz trzeci, pod trzecią nazwą.