„Nie mogę zatwierdzić dokumentu” daje osobie ze wsparcia więcej informacji niż „wszystko się zepsuło”. W sklepie trudno jednak układać precyzyjny opis, gdy obok czekają klienci, a pracownik próbuje dokończyć zadanie. Pomaga wcześniejsze ustalenie, jakie obserwacje należy zachować i kto przekazuje zgłoszenie. Nie chodzi o samodzielne znalezienie przyczyny, lecz o pokazanie, co wydarzyło się na konkretnym stanowisku i jak wpływa to na pracę.

Opisz czynność, na której zatrzymała się praca

Zacznij od nazwy aplikacji lub jej modułu, wykonywanego zadania oraz widocznego skutku. Czy program się zamknął, nie odpowiedział na polecenie, pokazał komunikat, czy wyświetlił dane inne od oczekiwanych? Są to różne obserwacje. Jeśli nie znasz nazwy ekranu, opisz jego funkcję. Krótkie zdanie o ostatniej wykonanej czynności będzie użyteczniejsze niż przypuszczenie, że trzeba wymienić komputer albo ponownie zainstalować cały system.

Przygotuj także informację o zakresie problemu. Możesz napisać, że wystąpił na jednym stanowisku, a pozostałych jeszcze nie sprawdzono. Nie trzeba w tym celu przerywać pracy wszystkim osobom ani logować się na cudze konta. To, czego nie ustalono, powinno pozostać wyraźnie oznaczone.

• Co próbowałeś zrobić i w którym miejscu aplikacji?
• Jaki był widoczny wynik oraz czego oczekiwałeś po tej czynności?
• Kiedy zauważyłeś problem i czy od tego momentu wystąpił ponownie?
• Którego stanowiska dotyczy obserwacja i jakie zadanie blokuje?

Wyobraźmy sobie, że po wybraniu polecenia zapisu ekran pozostaje bez potwierdzenia. Opis „dokument nie został zapisany” może wyprzedzać ustalenia, jeżeli jego statusu jeszcze nie sprawdzono. Dokładniej będzie wskazać, że użytkownik nie otrzymał potwierdzenia, i poprosić o ustalenie stanu operacji. Taki przykład pokazuje, dlaczego brak komunikatu na ekranie nie powinien sam w sobie prowadzić do wielokrotnego ponawiania czynności.

Odtworzenie zdarzenia ma granice

Wskazówki Mozilli dotyczące zgłaszania błędów podkreślają znaczenie kolejnych kroków, rezultatu oczekiwanego i rzeczywiście zaobserwowanego. Tę zasadę można wykorzystać również przy opisie problemu z narzędziem sklepowym. Zapisz, co zostało wybrane przed wystąpieniem usterki, a następnie co pokazał ekran. Nie musisz znać języka programowania. Istotna jest kolejność czynności, którą rozumie osoba niemająca dostępu do Twoich wspomnień.

Nie odtwarzaj jednak błędu kosztem kolejnych transakcji.

Jeśli ponowne kliknięcie może wysłać zamówienie, wykonać rozliczenie albo zmienić stan dokumentu, poczekaj na właściwą instrukcję i sprawdzenie poprzedniej operacji. Próba diagnostyczna w działającym sklepie nie jest tym samym co ćwiczenie w środowisku testowym. Nie kasuj danych, nie omijaj zabezpieczeń i nie zmieniaj konfiguracji na podstawie przypadkowej porady znalezionej w internecie. Korzystaj z dopuszczonych procedur i poleceń zweryfikowanego wsparcia.

Gdy problem wystąpił tylko raz, również warto to napisać. Sformułowanie „nie udało się ponownie zaobserwować” jest precyzyjniejsze od zapewnienia, że usterka zniknęła na dobre. Zachowaj godzinę zdarzenia i treść komunikatu, jeśli były dostępne. Nie dopisuj brakujących szczegółów po czasie tylko po to, by opis wyglądał na kompletny.

Zrzut ekranu powinien pokazywać problem

Na ilustracji przydatny bywa komunikat wraz z nazwą modułu i elementem, którego dotyczy. Cały pulpit może natomiast ujawnić otwartą pocztę, inne dokumenty lub informacje, których odbiorca nie potrzebuje do pierwszego sprawdzenia. Przed wysłaniem obejrzyj załącznik. Usuń z kopii przeznaczonej do przekazania zbędne dane, a w razie wątpliwości zapytaj, czy wystarczy przepisać sam komunikat. Materiały przesyłaj wyłącznie zatwierdzonym kanałem.

Nie dołączaj hasła ani jednorazowego kodu logowania. Numer identyfikujący dokument może być potrzebny uprawnionemu pracownikowi wsparcia, ale nie oznacza to zgody na opublikowanie całego dokumentu na forum czy w ogólnodostępnej grupie.

Jeżeli pomoc techniczna poprosi o szerszy materiał, ustal jego zakres i bezpieczną drogę przekazania. Raport diagnostyczny lub plik dziennika może zawierać więcej informacji, niż widać na ekranie. Nie generuj go na chybił trafił i nie wysyłaj każdej znalezionej paczki plików. Zgłoszenie ma umożliwić uprawnionej osobie analizę konkretnego zdarzenia, z zachowaniem zasad obowiązujących dla danego narzędzia i danych sklepu.

Oddziel potrzebę pomocy od gotowej diagnozy

Usterka pojawiła się po aktualizacji? Zapisz tę kolejność, ale nie przesądzaj przyczyny. Możesz podać, kiedy ostatnio zadanie udało się wykonać, co zmieniło się od tamtej pory i skąd pochodzi informacja o zmianie. Zdanie „rano działało, po południu wystąpił komunikat” opisuje przebieg zdarzeń. Stwierdzenie „aktualizacja uszkodziła bazę” wymaga znacznie mocniejszych podstaw, których zwykła obserwacja użytkownika nie dostarcza.

W codziennej pracy franczyzobiorcy wsparcie i samodzielna organizacja sklepu występują obok siebie. Taką perspektywę przedstawia materiał: https://dziennikbialystok.pl/franczyza-oczami-przedsiebiorcow-co-franczyzobiorcy-zabki-mowia-o-prowadzeniu-sklepu/. Nie opisuje on szczegółowej procedury zgłoszeń technicznych. Przedstawione tutaj wskazówki są ogólnym sposobem porządkowania informacji, który należy dostosować do zasad konkretnego systemu.

Poinformuj wsparcie o wpływie usterki na zadanie, zamiast nadawać jej dramatyczny opis. Brak możliwości otwarcia jednego raportu i zatrzymanie obsługi na wszystkich stanowiskach wymagają innego przedstawienia sytuacji. Podaj wyłącznie sprawdzony zakres. Jeżeli istnieje zatwierdzony sposób dalszej pracy, wskaż, czy można z niego skorzystać; nie twórz własnego obejścia, które narusza zasady rozliczeń lub bezpieczeństwa.

Zachowaj ciągłość od zgłoszenia do sprawdzenia rozwiązania

Po przekazaniu sprawy zachowaj jej identyfikator, o ile został nadany, oraz uzgodniony sposób kontaktu. Kiedy zmienia się osoba obsługująca stanowisko, przydatna będzie krótka informacja o stanie zgłoszenia. Powinna wskazywać, co nadal nie działa, jakie czynności zalecono i czego nie należy ponawiać. Nie trzeba przy tej okazji rozpowszechniać całej korespondencji ani prywatnych danych pracowników.

• Nową obserwację dopisz do istniejącej sprawy, jeżeli dotyczy tej samej usterki.
• Zaznacz, czy wykonałeś zalecony krok i jaki był jego rezultat.
• Odrębny problem opisz osobno, aby nie mieszać objawów i ustaleń.

Potwierdzenie otrzymania zgłoszenia nie oznacza zakończenia naprawy. Gdy wsparcie poinformuje o rozwiązaniu, sprawdź wskazaną czynność w uzgodniony i bezpieczny sposób. Napisz, czy udało się wykonać pierwotne zadanie, a nie tylko uruchomić aplikację. Jeżeli objaw wrócił, dopisz moment i warunki jego wystąpienia. Dzięki temu dalsza rozmowa zaczyna się od wspólnego stanu wiedzy, zamiast od kolejnego ogólnego „nadal nie działa”.

Materiał zewnętrzny