Na początek mam dla wszystkich złą wiadomość. Błędy w oprogramowaniu się zdarzają i zdarzać się będą. Mimo iż programiści obstawieni są kordonem testerów, a aplikacje skanowane są testami automatycznymi od A do Z, zawsze może zdarzyć się, że jednak jakaś mysz się prześlizgnie. Jak pokazuje historia, czasem jest to całe stado myszy, czego doświadczyli nie tak dawno użytkownicy Cyberpunka 2077. Czasem z kolei jest to jedna, tłuściutka i wyjątkowo kosztowna mysz. Mam tu na myśli przypadek sondy NASA Mars Climate Oribiter, która w 1999 roku w wyniku dość prozaicznego błędu – niespójności zastosowanych jednostek przy obliczaniu trajektorii lotu – uległa zniszczeniu w atmosferze Marsa. Wraz z sondą wyparowało niemal 330 mln dolarów, bo tyle kosztowała cała misja.
Ale jest też dobra wiadomość. Każdej firmie, która dostarcza oprogramowanie, bardzo zależy na jak najszybszej i najskuteczniejszej poprawie każdego błędu zgłoszonego przez użytkowników aplikacji. Przyczyn takiego podejścia jest co najmniej kilka. Najbardziej oczywista i chyba najważniejsza to chęć posiadania zadowolonych klientów. To oni, dzieląc się swoimi opiniami i przemyśleniami, mają duży wpływ na to, jak na rynku postrzegana jest dana aplikacja, co z kolei wpływa na decyzje zakupowe potencjalnych użytkowników, czyli w ostateczności na to, czy dostawca oprogramowania zarobi czy nie. Jak w każdej innej branży, zadowolony klient to podstawa. Ale są też inne powody, choćby te operacyjne. Błędy często poprawiane są w pierwszej kolejności, nierzadko przez ten sam zespół, który rozwija aplikację. W związku z tym, jeśli pracujemy nad poprawą błędów, to nie rozwijamy aplikacji, czyli znów nie robimy tego, na czym można zarobić.
Z oczywistych przyczyn użytkownikowi aplikacji również zależy na tym, aby błąd został poprawiony jak najszybciej. Mamy zatem ku temu całkiem solidne podstawy. Czemu więc jest tak, że niejednokrotnie na poprawie błędu upływa więcej czasu, niż wszyscy by sobie tego życzyli? Powodów jest co najmniej kilka, ale dzisiaj chciałbym zwrócić uwagę na jeden, który wydaje się być najczęstszym i najbardziej dotkliwym. Chodzi mianowicie o dwustronną komunikację pomiędzy zgłaszającym a obsługującym, a konkretnie o jej jakość.
Bądźmy precyzyjni
Kluczowym aspektem tej jakości jest precyzja. Precyzja, z którą zgłaszający opisuje błąd i to, jak do niego doszło, oraz precyzja z jaką obsługujący zgłoszenie udziela instrukcji zgłaszającemu. Że precyzja przekazywania informacji to sprawa trudna nawet w codziennej rozmowie wie każdy, kogo wysłano na zakupy z dokładną instrukcją: Kup 6 jajek, a jak będą parówki, to weź 10. Potem człowiek idzie do sklepu, patrzy – są parówki, więc wkłada do koszyka 10 jajek…
Poziom trudności dodatkowo wzrasta, kiedy komunikujemy się pisemnie, a tak najczęściej wygląda to w przypadku obsługi zgłoszeń. Najczęściej bowiem zgłaszamy błąd, wysyłając maila lub wypełniając formularz na różnego rodzaju helpdeskach. W takim przypadku dochodzą dodatkowe utrudnienia choćby w postaci interpunkcji. Za przykład tego, że nawet jeden przecinek może wywrócić sens wypowiedzi do góry nogami, niech posłuży być może znana już niektórym opowieść o człowieku, który chciał wysłać do kolegi wiadomość o treści: Twoja stara piła leży w piwnicy, jednak omsknął mu się palec i napisał: Twoja stara piła, leży w piwnicy.
Widzimy zatem, że precyzja tego, co mówimy i piszemy, jest fundamentalna dla skutecznej komunikacji. Starajmy się zatem zawsze bardzo dokładnie i przede wszystkim jednoznacznie formułować swoje myśli. Dobrą praktyką jest przeczytanie swojego zgłoszenia i zastanowienie się, czy gdybym był inną osobą, która nie wie tego, co wiem ja, to zrozumiałbym wszystko tak samo. Taki rodzaj wewnętrznej zamiany miejsc oczywiście nie jest łatwy, jednak przy odrobinie praktyki można go opanować. Nie jest to oczywiście jedyny sposób, w jaki możemy ułatwić komunikację, ale wydaje się, że jest to podstawa, na której można oprzeć dalsze działania.
Ważna uwaga: precyzja wypowiedzi to niezbędny element skutecznej komunikacji nie tylko po stronie zgłaszającego, ale w równej mierze po stronie obsługującego. Taki ktoś, jako specjalista w swojej dziedzinie i niejednokrotnie osoba techniczna, musi pamiętać, że po drugiej stronie zgłoszenia nierzadko stoi człowiek, który nie ma takiej wiedzy jak on, inaczej rozumie pewne rzeczy i być może nie ma stuprocentowej znajomości systemu. Stąd potrzebuje jasnych wytycznych. Metoda zamiany miejsc czy też po prostu wczucia się w rolę drugiej osoby ma również tutaj zastosowanie.
Dobre praktyki
Tylko helpdesk
Jeśli dostępna jest platforma typu helpdesk, to do zgłaszania incydentów zawsze używajmy jej, a nie maila czy telefonu. Ma to kilka istotnych zalet. Mail może nie zostać odebrany w odpowiednim czasie. Możemy wysłać go do niekoniecznie odpowiedniej osoby. Osoby obsługujące helpdesk są zawsze na miejscu. To najszybsza droga, żeby nasze zgłoszenie trafiło do odpowiedniej osoby.
Ponadto wszystkie potrzebne informacje, screeny czy inne załączniki będą dostępne w jednym miejscu. W przypadku, kiedy po stronie obsługi zmieni się osoba odpowiedzialna za zgłoszenie, będzie miała od razu dostęp do wszystkich potrzebnych danych.
Informacja o zgłoszeniu od razu odkłada się w bazie. Dla dostawcy oprogramowania jest to cenna dana mówiąca m.in. o jakości rozwiązania, które dostarcza. Możliwe jest mierzenie czasu realizacji zgłoszeń i innych czynników mających wpływ na poziom obsługi
Osobiste zgłoszenie
Zakładajmy zgłoszenia osobiście. Każdy głuchy telefon, nawet z jednym pośrednikiem, któremu – jak nam się wydaje – jasno wytłumaczyliśmy, o co chodzi, to potencjalne miejsce na przekręcenie czegoś…
Miałem okazję rozmawiać bezpośrednio z użytkownikiem jednego z naszych rozwiązań, który przekazał mi potrzebę rozbudowy aplikacji. Chodziło o to, żeby listy systemowe, które obecnie mogą być eksportowane tylko przez użytkowników z rolą menadżera, mogły być eksportowane również przez użytkowników z innymi rolami. Kolejnego dnia ta potrzeba została zakomunikowana przez helpdesk przez innego użytkownika i została opisana tak: „bardzo proszę o możliwość dodania zakładki importuj do Excela w wykazie szkód wpisanych do systemu”. Tylko dzięki wcześniejszej rozmowie z innym użytkownikiem można było zrozumieć, o co chodziło w zgłoszeniu.
Zatem zgłaszajmy osobiście, a jeśli nie mamy dostępu do helpdesku, napiszmy zgłoszenie i poprośmy o zgłoszenie dokładnie tak, jak to opisaliśmy sami.
Więcej informacji
Na helpdesk wpada zgłoszenie o treści „VSoft nie działa”. Rozglądam się wkoło. Ludzie siedzą przy biurkach i pracują. Firma w KRS wciąż widnieje. Ekspres do kawy działa. Nie – myślę sobie – to nie to. VSoft jednak działa. Po zadaniu całej serii pytań okazało się, że użytkownik miał problem z resetowaniem swojego hasła do aplikacji. I tak zgłoszenie, które można było rozwiązać w 5 minut, rozciągnęło się na kilka godzin. Tylko dlatego, że brakowało podstawowych informacji.
Poprawę i poszukiwanie przyczyny błędu można bowiem przyrównać do policyjnego śledztwa: wszystko może mieć znaczenie. Dlatego nie bójmy się, że przekażemy jakieś niepotrzebne informacje. Nigdy nie wiadomo, co może być pomocne. Osobiście znam przypadek, w którym kluczem do rozwiązania problemu była użyta przez użytkownika czcionka.
Przede wszystkim opisujmy krok po kroku, co kliknęliśmy, jakie pola wypełniliśmy, jakie operacje wykonaliśmy zanim wystąpił błąd. Napiszmy, na jakiej wersji oprogramowania działamy, jakiej używamy przeglądarki (jeśli korzystamy z rozwiązania przeglądarkowego), jaki mamy system operacyjny, czy błąd się powtarza czy wystąpił tylko raz, kiedy się zdarzył, jakich użytkowników dotyczy itp. To naprawdę bardzo ważne!
Nowe poszlaki
Informujmy o nowych okolicznościach. Kontynuując metaforę śledztwa. Policja zawsze wręcza wizytówkę, aby dzwonić do nich, kiedy coś sobie przypomnimy. Tutaj jest tak samo. Jeśli coś się nam przypomni albo w trakcie dalszej pracy pojawią się jakieś dodatkowe informacje, coś zauważymy, od razu dajmy znać. Śledztwo bowiem sprowadza się do stawiania hipotez i szukania sposobów na ich potwierdzenie lub obalenie. Nie należy tego robić chaotycznie, należy przygotować plan – zestaw hipotez, zestaw eksperymentów, które pozwalają je potwierdzać lub obalać, zestaw danych, informacji niezbędnych do przeprowadzenia eksperymentów. Każda nowa dana czy informacja może pomóc szybciej coś wykluczyć lub potwierdzić.
Wizualizacje
Używajmy rysunków, zrzutów ekranu, nagrań. Prawdą jest, że obraz potrafi powiedzieć więcej niż tysiąc słów. Czy to może jednak było Rafaello? W każdym razie nierzadko zamiast opisywać sytuację wieloma zdaniami, można dołączyć zrzut ekranu z naniesionymi uwagami.
Możemy do tego wykorzystać wbudowane w Windows 10 narzędzie. Wystarczy kliknąć shift+Windows+S i wybrany wycinek ekranu zostanie skopiowany do schowka. Świetnym narzędziem jest również darmowy Greenshot, który pozwala na wykonywanie precyzyjnych zrzutów ekranu i wprowadzanie do nich od razu prostych modyfikacji graficznych. Możemy coś dopisać, dorysować strzałkę, zaznaczyć fragment – super sprawa.
A jeszcze lepiej, jeśli możemy nagrać film, na którym pokazujemy całą ścieżkę, którą przeszliśmy, zanim wystąpił błąd. Tutaj z pomocą również spieszy nam Windows 10. Windows+alt+R i voila! Możemy nagrywać ekran.
Analiza biznesowa
Róbmy wewnętrzną analizę biznesową. Chodzi o to, aby zanim zrobimy zgłoszenie w jakiejś sprawie, przeanalizować ją i np. na wstępie sprawdzić, czy błąd się powtarza czy może było to jednorazowe zdarzenie. Warto też skonsultować się ze współużytkownikami aplikacji. Być może ktoś miał podobną sytuację i wie, jak sobie z nią poradzić, zna obejście. Może po analizie okaże się, że to, co chcieliśmy zgłosić, wcale nie jest błędem. Zdarza się, że inni użytkownicy lepiej znają system od nas i mogą nam pomóc. Opcji jest wiele. Pamiętajmy, że zgłoszenie niezasadne również musi być podjęte przez obsługę i również zabiera czas, który być może przydałby się na rozwiązanie rzeczywistego błędu.
Własne IT
Angażujmy własny dział IT (jeśli takowy posiadamy). W wielu przypadkach problem leży w sprzęcie, w konfiguracji, w infrastrukturze, oprogramowaniu dodatkowym (np. przeglądarki). Znaczną liczbę incydentów można rozwiązać własnymi siłami. Dobrze jest więc najpierw zgłosić incydent wewnętrznie i jeśli to zawiedzie, przekazać sprawę do dostawcy oprogramowania. Tym bardziej, że wiedząc, o co chodzi, wewnętrzny dział IT będzie w stanie udzielić dodatkowych informacji lub przekazać dane, które pomogą w rozwiązaniu sprawy.
Checklista
Stwórzmy wraz z dostawcą checklistę zawartości zgłoszenia. Ustrukturalizowane zgłoszenie można znacznie szybciej i skuteczniej obsłużyć. Mamy wtedy jasność tego, co otrzymujemy i czego się spodziewać w zgłoszeniu. Przed wysłaniem zgłoszenia możemy łatwo sprawdzić, czy wszystkie wymagane na początek elementy zgłoszenia są uzupełnione. Przydaje się ona bardzo, kiedy rzadko zgłaszamy incydenty i nie mam nawyku dołączania od razu wszystkich potrzebnych elementów.
Rozwiązanie tymczasowe nie gryzie
Najważniejsza jest ciągłość działania i to, żeby jak najszybciej wrócić do pracy. Nierzadko użytkownicy sami odnajdują obejścia. Obsługujący zgłoszenia często proponuje działania, które tymczasowo pozwolą wykonywać daną operację, z którą pojawił się problem. Czasem te działania mogą sprawić, że wykonywanie danej czynności będzie np. trwało dłużej. Będzie jednak możliwe. Pamiętajmy, że nie jest to rozwiązanie docelowe i taki stan nie potrwa wiecznie. W czasie, kiedy będzie stosowane rozwiązanie tymczasowe, trwają prace nad realizacją rozwiązania docelowego.
Emocje na bok
Doskonale wiemy, że nie ma nic gorszego, kiedy spieszymy się z pracą, terminy gonią, szef stoi nad głową, chcemy iść do domu, pies szczeka, mleko kipi, dzieci płaczą (niepotrzebne skreślić w zależności od tego, czy pracujemy zdalnie), a tu nagle… Błąd 500. System wykonał nieprawidłową operację. Skonsultuj się z administratorem. I tu cali w nerwach logujemy się na helpdesk i próbując OPISAĆ BŁĄD!!!!!!!!!! WRZUCAMY!! WIELKIE LITERY!!!!!!!!! I MNÓSTWO WYKRZYKNIKÓW!!!!!!!!!!! i przerywamy naszą wypowiedź inwektywami i jeszcze większą liczbą WYKRZYKNIKÓW!!!!!!!!!!!!!!!!!
Oczywiście nie da się ukryć, że może mieć to działanie oczyszczające, a nawet terapeutyczne, jednak oddala nas od realizacji celu, jakim jest jak najszybsza poprawa incydentu. Ciężko bowiem w tak napisanym zgłoszeniu odnaleźć meritum i skupić się na istotnych kwestiach. Dlatego zawsze przed zredagowaniem opisu incydentu weźmy głęboki oddech i skupmy się na analizie problemu oraz merytorycznej zawartości zgłoszenia, a na koniec przeczytajmy całość i zastanówmy się, czy jest ona zrozumiała.
Ewentualny upust naszym emocjom możemy zawsze dać w odrębnym zgłoszeniu.
Na koniec
Jak widać, z pozoru trywialny proces wcale nie jest taki prosty i można go usprawnić na wiele sposobów. Myślę jednak, że warto podjąć to wyzwanie, ponieważ może ono znacząco wpłynąć na efektywność realizacji zgłoszeń w systemach, na których pracujemy. Najważniejsze, że wszystkie powyższe uwagi z powodzeniem mogą być stosowane nie tylko przez użytkowników, którzy zgłaszają incydenty, ale również przez osoby obsługujące je ze strony dostawcy oprogramowania. Rozwiązanie błędu to wspólna sprawa, dlatego konieczna jest skuteczna współpraca w tym zakresie.
Dla ułatwienia wdrożenia opisanych tutaj rozwiązań załączamy infografikę, którą można skopiować, wydrukować i powiesić nad łóżkiem biurkiem, a także podzielić się nią ze znajomymi. Na pewno posłuży pomocą w skutecznym zgłaszaniu incydentów.
A każdemu użytkownikowi systemów komputerowych życzę, aby nie doprowadziły one do tego, że będzie znał tę listę na pamięć.
Konrad Jakubowski
Analityk w obszarze ubezpieczeń VSoft, odpowiedzialny m.in. za system VSoft Insurance Broker. Kiedy trzeba również handlowiec, marketingowiec, product owner. Wierzy, że dobre relacje są ważniejsze niż zapisy umowy. Czas wypełnia książkami, serialami, grami planszowymi i ciężkim brzmieniem.
