Każdy kto kiedykolwiek tworzył, współtworzył lub administrował jakąkolwiek projekt wie, że błędy w web aplikacji się zdarzają. To naturalna kolej rzeczy, tak było, jest i będzie. Oczywiście, co innego oznacza 100 błędów dziennie (mam na myśli średnie i mniejsze aplikacje) a co innego 100 rocznie. W tym pierwszym przypadku odważyłbym się określenia, że oprogramowanie zostało wykonane po prostu niedbale. Bez względu jednak na wszystko zarządzać zgłoszeniami jednak jakoś trzeba. W tym artykule napiszę troszkę o naszych doświadczeniach związanych z ich obsługą.

Kanały zgłoszeń błędów

Pewnie wielu z Was ma doświadczenia kiedy to użytkownicy aplikacji (często klienci końcowi) zgłaszają swoje uwagi i zauważone błędy przez:

• Telefon do firmy
• E-mail
• System ticketowy
• Google Docs czy dokumenty typu Word/Excel udostępniane on-line
• Podczas bezpośrednich spotkań

Gorzej, jeśli wykorzystują oni wszystkie te kanały komunikacji w stosunku do jednego projektu na raz a zespół odpowiedzialny za jego obsługę się po prostu gubi. Co rekomenduje? Przede wszystkim ustalenie jednego kanału komunikacji, najlepiej jeśli będzie to system ticketowy albo dopasowane do potrzeb narzędzie. W zależności od charakteru projektu może to być przykładowo:

• Zendesk
• Atlassian JIRA ((przy założeniu, że wykorzystuje się je do bardziej zaawansowanych operacji, np. prowadzenia całego projektu)
• Redmine (Popularne darmowe narzędzie)
• Jakikolwiek inny system zgłoszeniowy w którym możemy utworzyć workflow i zintegrować to z platformą do zarządzania zadaniami w firmie

Należy się wtedy sztywno trzymać zasady jednego źródła zgłoszeń i błędy spływające np. telefonicznie po prostu odrzucać. Ważne: osoba zgłaszająca powinna mieć stały wgląd do statusu swojego zgłoszenia bez konieczności pisania e-maili i dzwonienia do Project Managera.

Typy błędów i czas reakcji

Błędy możemy podzielić na kilka rodzajów:

• Krytyczne – Jest to błąd uniemożliwiający realizację podstawowych funkcjonalności web aplikacji. Dla przykładu: w e-sklepie nie działa proces zamawiania produktu.
• Pilne – Jest to błąd znacząco utrudniający prace w web aplikacji. Dla przykładu: w e-sklepie nie działa opcja płatności on-line (jedna z wielu). Użytkownik może zakończyć transakcje ale jest zmuszony wybrać inną opcję płatności.
• Normalne – Jest to błąd utrudniający poprawne korzystanie z systemu. Dla przykładu w e-sklepie nie można posortować produktów po cenie rosnąco, działa tylko opcja malejąca. Oczywiście użytkownik sobie poradzi ale wpłynie to negatywnie na wygodę korzystania z narzędzia.
• Mało istotne – Są to drobne błędy, często nawet niezauważalne dla użytkowników korzystających z aplikacji. Dla przykładu: brakujące przecinki, drobne błędy wizualne (lekkie przesunięcia) etc.

Rodzajów oczywiście można by było znaleźć jeszcze kilka ale w większości przypadków te powinny zaspokoić potrzeby. Następnie w zależności od poziomu ważności błędu należy odpowiednio szybko zareagować. Czas reakcji powinien być jasno sprecyzowany pomiędzy wykonawcą/zespołem IT a operatorem aplikacji. Oczywiście błędy krytyczne powinny być naprawione prawie, że natychmiastowo, natomiast te mało istotne czasem leżą nawet tygodniami. Często właściciele web aplikacji życzą sobie aby wszystkie ich zgłoszenia były traktowane priorytetowo i rozwiązywane natychmiastowo natomiast w momencie, kiedy oprogramowanie nie posiada stałego zespołu wsparcia i obsługi technicznej takie podejście jest nierealne. Jest to popularny przypadek wśród podwykonawców wszelkiego rodzaju web aplikacji, których obsługa błędów odbywa się tylko na zasadach gwarancyjnych, ponieważ niestety cały czas w Polsce rozszerzoną i stałą obsługę techniczną aplikacji traktuje się jako zbędny koszt.

Jak zgłosić prawidłowo błąd?

„Zamówienie nie działa”, „Strona się nie ładuje”, „Sortowanie nie działa”, „Źle się wyświetla produkt” – skąd my to znamy? Zgłaszający błędy piszą tylko to co widzą bez wszystkich informacji tak bardzo potrzebnych zespołowi, który ma te błędy naprawić. Pamiętaj – źle opisany błąd wydłuży proces jego realizacji a niekiedy go nawet uniemożliwi. Jak więc opisać najlepiej zgłoszenia?

• Napisz jak uzyskałeś ten błąd, najlepiej przez powtarzalną ścieżkę (np.: „wchodzę na stronę główną, klikam zakładkę produkty, wybieram producenta XYZ, klikam sortuj po dacie i widzę komunikat błędu”
• Dołącz screen a najlepiej filmik (jeśli błąd występuje na przykład tylko na jednym urządzeniu i ciężko go powtórzyć) i go dołącz do zgłoszenia
• Napisz informacje o systemie operacyjnym, przeglądarce i jej wersji (pomoże to odtworzyć błąd)
• Napisz o dodatkowych uwarunkowaniach w samej aplikacji, np: „tylko w przypadku gdy jestem zalogowany”, „sortowanie nie działa tylko w przypadku jak zmieniłem ilość wyświetlanych produktów na ekranie z 25 na 50”
• Jeśli np. nie możesz wgrać zdjęcia to nie pisz tylko „nie działa wgrywanie zdjęć” ale w zgłoszeniu dołącz też zdjęcie z którym masz problem (niekiedy to ono jest „wadliwe”)
• Jeśli błąd dotyczy bardziej złożonego procesu, napisz też jakie zachowanie jest przez Ciebie oczekiwane (co chciałbyś uzyskać). Dla przykładu: „Obliczona wartość rozliczenia z kontrahentem XYZ jest błędna, oczekiwana wartość powinna wynosić 157,23 zł a jest 2,10zł”

Proces obsługi błędu

Pojawia się zgłoszenie. Co dalej? My jesteśmy zwolennikami dobrej komunikacji ze zgłaszającym i proponujemy taki proces, kolejno:

• Spływa zgłoszenie
• Project Manager przypisuje je do odpowiedniego developera
• Zgłoszenie jest opisywane pod kątem szacowanego wstępnie czasu realizacji, terminu wykonania, niekiedy komentarza zespołu IT
  • W przypadku nieuzasadnionego zgłoszenia konieczne jest odrzucenie zadania wraz z opisem czemu zostało ono odrzucone
  • W przypadku niepełnego opisu uniemożliwiającego realizację – konieczność doprecyzowania. Do tego momentu zadanie powinno być wstrzymane.
• Wychodzi informacja zwrotna do zgłaszającego dotycząca przyjęcia ticketu oraz informacja o prawdopodobnym terminie naprawy
• Project Manager wyznacza w zespole okienko supportowe (np. w kolejnym tygodniu dla zadań o normalnym priorytecie)
• Zespół w ustalonym terminie naprawia błędy (tu zaznaczam „błędy” w liczbie mnogiej ponieważ najwydajniej jest realizować wszystkie zgłoszenia jeden po drugim nagromadzone w określonej przestrzeni czasu)
• Po wykonaniu napraw, tickety są przekierowywane do testowania do działu Q&A
• Po pomyślnych testach wykonywana jest aktualizacja (czy będzie to środowisko testowe „stage” czy też produkcja to zależy od ustaleń)
• Na końcu niezależnie od zmiany statusu zgłoszeń (do których klient ma dostęp) Project Manager informuje zgłaszającego o zakończeniu czynności naprawczych

To jest oczywiście przykład obsługi, nie mniej jednak jaki by on nie był najważniejsze cechy zarządzania błędami z operatorem serwisu (klientem) to:

• Jasna i przejrzysta komunikacja
• Ustalony z góry proces obsługi błędów
• Czasy reakcji i realizacji uzgodnione na samym początku pomiędzy operatorem a wykonawcą
• Konsekwencja w realizacji i obsłudze
• Rzetelnie i dokładnie opisane zgłoszenia

Czemu używa się określenia czas reakcji a nie czas realizacji? Z prostego powodu, jedno zgłoszenie zajmie zespołowi 5 minut a inne tydzień czasu pracy. Są przypadki bardziej i mniej skomplikowane, dlatego też Project Manager powinien informować zgłaszającego o skali błędu w opisie zgłoszenia (miedzy innymi przez estymację czasu realizacji). Tak jak pisałem na początku – błędy to całkowicie normalna kolej rzeczy w obsłudze i realizacji web aplikacji. Zadbajmy w takim razie o to aby nie spędzało to snu z powiek zespołowi zaangażowanemu w projekt i było realizowane i obsługiwane szybko i przejrzyście dla wszystkich.