„U MNIE DZIAŁA”, CZYLI STANDARDOWA ODPOWIEDŹ ADMINISTRATORA
„U mnie działa”. Chyba większość z nas choć raz spotkała się z taką odpowiedzią przy zgłaszaniu problemów z oprogramowaniem. Odpowiedź ta znalazła nawet swoje miejsce w polskojęzycznej Wikipedii jako SOA#1.
Właścicielka sklepu internetowego, korzystającego z wiodącego skryptu e-commerce, postanowiła dodać do niego nową wersję językową. Tłumaczenie stron stałych i opisów produktów nie sprawiło kłopotu, nie dało się natomiast wprowadzić obcojęzycznych nazw działów. Po otrzymaniu zgłoszenia (punkt 1. na liście poniżej) i upewnieniu się, że Szanowna Klientka postępuje zgodnie z wymaganą procedurą, poprosiłem o dane przeglądarki i systemu operacyjnego (punkt 2.) Wtedy udało się problem zaobserwować na stanowisku testowym i znaleźć prosty sposób jego obejścia.Taka reakcja, mimo że określana przez Wikipedię jako żartobliwa, jest de facto arogancka i nigdy nie powinna mieć miejsca. Dowodzi niekompetencji, w najlepszym razie przepracowania administratora.
Te trzy słowa ma on/ona prawo powiedzieć lub napisać tylko pod warunkiem, że są początkiem dłuższej wypowiedzi: „U mnie działa, nie jestem w stanie tego błędu zreprodukować. Czy mogę prosić o więcej informacji?”
Niestety, nie zawsze ten ciąg dalszy jest wyartykułowany, ani nawet obecny domyślnie.
W przypadku serwisów internetowych jest to niewłaściwe w dwójnasób. Z założenia nie można oczekiwać od użytkownika ani wiedzy technicznej, ani w ogóle czegokolwiek poza zadowoleniem z odwiedzin na stronie.
Wskazana jest komunikacja, prowadząca do zlokalizowania problemu i jego rozwiązania. Warto postawić się na miejscu użytkownika i z dozą empatii traktować np. zwięzłe niczym haiku zgłoszenia w rodzaju „Nie mogę dołączyć pliku!” Zgłaszający jest w sytuacji dla siebie stresującej, ponadto nie musi znać całego systemu ani mieć świadomości, że dodawanie pliku jest możliwe z różnych formularzy, w kilku kontekstach, i na dodatek obarczone jest wieloma nie wykluczającymi się wzajemnie ograniczeniami.
Zlokalizowanie (odseparowanie) błędu pozwala łatwiej zidentyfikować jego przyczynę. Jeśli przyczyna nie jest oczywista na podstawie samego opisu, trzeba spróbować odtworzyć błąd w kontrolowanym środowisku (np. na testowym serwerze, z bieżącym podglądem logów). Potrzebne są do tego informacje, które należy od użytkownika uzyskać.
-
- gdzie (na której stronie, formularzu) zachodzi błąd;
- jakie są obserwowane objawy (zachowanie się strony www, dokładna treść komunikatu o błędzie, albo brak jakiegokolwiek komunikatu);
Jeśli to nie wystarczy do wyjaśnienia, kolejne informacje: -
- używana przeglądarka (rodzaj, wersja);
- system operacyjny (rodzaj, wersja);
- czy zmieniano ich domyślne ustawienia, i jakie;
Jeśli nadal nie jesteśmy w stanie znaleźć rozwiązania, ani nawet zaobserwować błędu, mogą być przydatne dalsze szczegóły: -
- czy występują u użytkownika inne problemy - z innymi serwisami www, z jego komputerem lub z siecią;
- opis krok po kroku czynności, jakie doprowadzają do wystąpieniem błędu;
- opis stanu systemu i wcześniejszych działań, pozornie nie związanych z zbłędnym działaniem serwisu;
- dokładny czas wystąpienia błędu (pozwoli łatwiej odnaleźć ewentualne wpisy w logach, lub połączyć problematyczną sytuację z zachodzącymi w tym samym czasie w serwisie innymi zdarzeniami, np. pracami konserwacyjnymi).
Zdarza się, że zgłaszająca usterkę osoba ma w nawyku prowadzenie bardzo precyzyjnej komunikacji i wyrozumiałość dla pytań o sprawy pozornie oczywiste. W innym przypadku warto poświęcić zdanie lub dwa wyjaśnieniu celowości tak szczegółowych pytań i znaczenia równie szczegółowych odpowiedzi, oraz delikatnie poruszyć kwestię nie posiadania przez administratora zdolności nadprzyrodzonych (z telepatią i widzeniem przez ściany na czele). Które to zdolności czasem byłyby jak znalazł…
Wpis ozdabia ilustracja Michała Elwiro Andriolliego do „Pana Tadeusza” (Księga V).
