How to report bugs to get them resolved?

13 marca 2021
Jakub Rojek Jakub Rojek
Photo by picjumbo.com from Pexels
Kategorie: Współpraca, Feedybacky, Dla klientów

Niezależnie od tego, jak bardzo zespół IT stara się dopieścić tworzone oprogramowanie, zweryfikować jego poprawność, sprawdzić w kontekście oczekiwań klienta, to i tak praktycznie niemożliwe jest, aby surowa aplikacja (lub jej etap), do której oddawany jest dostęp, była pozbawiony wad. Zresztą, nawet niekoniecznie mówimy tutaj o wadach - mam na myśli zarówno same pomyłki (od typowo technicznych do wynikających z niezrozumienia klienta), ale wraz z rozwojem projektu i klikania w nim, pojawiają się pomysły na modyfikacje, uproszczenie (lub rozszerzenie) procesu, a więc ogólnie pojęte zmiany. Natomiast wspominam o tym w drodze uzupełnienia - nadal dość pokaźny procent zgłoszeń serwisowych od klienta (lub wybranych przez niego użytkowników) dotyczy różnych niedoróbek, a przynajmniej takich, które nimi są według niego.

Niestety, zgłaszający zaskakująco często pamiętają o tym, że "klient płaci więc wymaga", ale zapominają o tym, że nawet najlepszy wykonawca nie zajmie się ich zgłoszeniem należycie, jeśli będzie niestarannie przygotowane. Dlatego chciałem dzisiaj przyjrzeć się temu zagadnieniu i jako ktoś, kto w pracy m.in. zarządza poprawkami (i płacze przy tym), udzielić paru rad, jak zgłaszać błędy i poprawki, aby rzeczywiście istniała szansa szybkiego ich rozwiązania. Niezależnie od tego, czy zawiadomienie kierowane jest stricte do zespołu IT, czy jeszcze do zespołu wsparcia.

Dociekliwi być może znajdą podobny artykuł na moim blogu (który to blog, niestety, "trochę" podupadł i cały czas zastanawiam się, co z nim zrobić), jednak od tego czasu (a więc 2017 roku) wzbogaciłem swoje doświadczenie. Tamten tekst jest dużo luźniejszy w odbiorze (jak wszystko na tamtym blogu - tutaj muszę być Panem Poważnym, co i tak nie wychodzi). Jeśli ktoś ma chwilę czasu - bardzo polecam swoje wypociny sprzed czterech lat.

Reguła pierwsza - testuj, kliencie

To w sumie nie do końca rada dotycząca samych zgłoszeń, ale - niestety - dość często zdarza się, że osoba, której udostępniany jest etap lub gotowe oprogramowanie, nie wykorzystuje danego czasu na zweryfikowanie, czy wszystko jest tak, jak sobie życzył. Zwykle zakłada, że wykonawca zrobił wszystko perfekcyjnie i faktycznie - może mieć takie poczucie, ponieważ płaci za usługę. Natomiast zapomina o dwóch rzeczach - o tym, że zawsze się coś znajdzie, obojętnie ile iteracji testowania będzie (dlaczego tak jest - to temat na osobny tekst), ale także o tym, że po wdrożeniu pewien czas jest przeznaczony na zweryfikowanie systemu i "przeklikanie" go zanim zostanie wystawiona faktura. Do tego dochodzi okres gwarancyjny, a więc klient, nie interesując się swoim systemem na czas, sam sobie strzela w stopę (lub w kolano). Co więcej, jeśli później zgłosi uwagi dotyczące rzeczy z kilku etapów wstecz (na bazie których często budowane są kolejne funkcje oprogramowania), to często koszt ich poprawy jest znacznie większy.

Reguła druga - ustal formę zgłaszania

Wraz z pierwszym oddaniem czegokolwiek do weryfikacji klientowi, on i wykonawca powinni ustalić procedurę, według której zgłoszenia będą przesyłane. Jeśli bowiem zdamy się tutaj na dowolność, to informacje będą przychodzić różnymi drogami - mailem, telefonem, w arkuszu, podczas spotkań itd. Z punktu widzenia klienta to nic zdrożnego i wręcz wygoda, ale dla wykonawcy to horror w późniejszym zarządzaniu tymi zgłoszeniami, zwłaszcza jeżeli potem musi dystrybuować je wśród poszczególnych członków zespołu. Tak nie może być - należy umówić się na jedną, dogodną dla obu stron formę i się jej trzymać. Do tego stopnia, że jeżeli coś nie zostało zgłoszone ustaloną drogą, to uznaje się, że nie było zawiadomienia. Oczywiście, w idealnym scenariuszu - wszystko zależy od wzajemnego szacunku, o którym dzisiaj jeszcze sobie powiemy.

A co wybrać? To zależy od projektu i zespołu. Dla działu IT najlepsze byłoby zautomatyzowanie procesu w postaci jakiegoś Redmine'a, Asany czy JIRY. Klient często chce uprościć tę drogę z powodu braku czasu i zdać się na telefon oraz e-maile. Nie można się temu dziwić i software house lub freelancer musi się z tym liczyć. Kompromisem staje się czasami arkusz kalkulacyjny na Google Drive lub OneDrive i nie jest to złe rozwiązanie, ale - jak wszystko - ma swoje wady. Rozwiązanie idealnie nie istnieje... ale za jakiś czas będę chciał spróbować przedstawić propozycję rozwiązania tego problemu.

Dlaczego jednak ustalenie jednej formy zgłaszania uwag jest takie ważne? Pozwala to trzymać zgłoszenia w jednym miejscu i w nim też od razu śledzić statusy. Jeśli zostanie to dobrze rozegrane, to ten "kontener" będzie też dostępny dla każdego zainteresowanego, więc czas spędzony na komunikacji ulegnie skróceniu.

Reguła trzecia - co trzeba zgłosić?

Ten temat szerzej i na przykładach opisałem w podlinkowanym wyżej swoim artykule z 2017 roku, więc tutaj ograniczę się do wymienianki. Pamiętajmy, że celem zgłoszenia jest uzyskanie możliwie szybkiej odpowiedzi lub rozwiązania od zespołu IT na błąd lub potrzebę zmiany. Z drugiej strony, zespół IT nie "siedzi w głowie" klienta i nie zawsze umie odczytać wszystkie skróty myślowe. Dlatego zgłoszenie powinno zawierać co najmniej:

  • jasny opis błędu - należy prosto, ale wyczerpująco opisać, co się zdarzyło i jaka jest istota zawiadomienia. Warto się tutaj trzymać metodyki SMART, która jest użyteczna przy stawianiu celów oraz definiowaniu wymagań pozafunkcjonalnych, ale może przydać się także przy kontakcie z zespołem wsparcia.
  • dlaczego jest źle - nie zawsze oczywiste dla wykonawcy jest to, gdzie leży błąd i jaki powinien być poprawny wynik. Są to sytuacje, w których klient i wykonawca nie do końca zrozumieli się na etapie projektowania systemu.
  • sposób odtworzenia - nawet, jeżeli zgłoszenie jasno pokazuje, że stało się coś niepoprawnego, to czasami może to występować jedynie w bardzo specyficznych scenariuszach. Warto taki podać, jeśli jesteśmy go świadomi, a przynajmniej udostępnić wszystkie potrzebne informacje (np. który użytkownik był zalogowany czy w jakim obiekcie w systemie to wystąpiło).
  • data i czas - czasami można łatwo zdiagnozować błąd, o ile wie się, które miejsce w logach należy sprawdzić w celu poszukania odpowiedniego komunikatu. Poza tym dzięki temu łatwiej jest dotrzeć do danych, jeśli to ich nieprawidłowa kombinacja jest ważna w danym zgłoszeniu.
  • zrzut ekranu - na pewno znacie powiedzenie, że obraz jest warty tysiąca słów. Czasem trudno opisać problem, a łatwiej go pokazać. Tutaj jednak trzeba zrozumieć sytuację - wystąpienie problemu lub motywacja do zgłoszenia uwagi zazwyczaj jest spontaniczna i nie zawsze człowiek myśli o tym, aby zrobić zrzut ekranu (najczęściej jest zły, że w ogóle taka sytuacja wystąpiła). Tym niemniej, obecność screenshota czasami "załatwia sprawę".
  • informacja o przeglądarce, systemie, urządzeniu - o tym, że różne platformy nie są między sobą jednolite, wszyscy niby wiedzą, ale i tak często jest to zaskoczenie. Natomiast chciałem tutaj zwrócić uwagę na to, że czasami wskazanie dokładnej rozdzielczości ekranu lub typu urządzenia mobilnego może być niezwykle przydatne - bywały sytuacje, w których taka informacja była bardzo pomocna w responsywnych aplikacjach webowych.

Oczywiście, mówimy o idealnym zgłoszeniu błędu (co nie oznacza, że nie będą potrzebne dodatkowe materiały). Tak, jak jednak wspomniałem - klient często nie ma czasu, więc dobrze, gdyby pamiętał chociażby o jasnym opisie błędu i gotowości do późniejszej konsultacji. Resztę można wybaczyć, choć warto starać się kroczyć ku coraz lepszemu.

Reguła czwarta - szacunek ludzi serwerów

Na szczęście, tego typu klientów jest mniejszość, ale na pewno każdemu wykonawcy zdarzyły się mniej miłe sytuacje, w których klient, tonem nieznoszącym sprzeciwu, żąda poprawek, które może i są zasadne, ale są przedstawiane w taki sposób, że aż odechciewa się je robić. Wiadomo, że klientowi się należy, jednak, jak to się mówi, można powiedzieć i powiedzieć (lub napisać i napisać). To jest taki informatyczny odpowiednik prześmiewczego "chcę rozmawiać z kierownikiem". Dodatkowo, faktycznie zdarzają zgłoszenia napisane w stylu krzykacza, który woła o błędzie, ale nie potrafi go jasno wskazać (słynne "ten ekran nie działa, pozdrawiam"). Co ciekawe, często takie zgłoszenia wynikają z niedoczytania instrukcji lub nieznajomości systemu, choć - niestety - zdarzają się też faktyczne poważne niedoróbki.

Drogi kliencie - jeśli naprawdę chcesz, aby współpraca z wykonawcą była dobra i żeby zespół IT Cię szanował oraz odpowiedział na zgłoszenie, powstrzymaj swoje emocje i pamiętaj, że po drugiej stronie też są ludzie. Dotyczy to też wykonawców - obrażanie klienta za jego nieznajomość realiów IT (zrozumiałą, bo inaczej nie wynajmowałby specjalistów) jest mniej więcej tak samo bezczelne i krótkowzroczne jak... A nie, dobrze, nie będę mówił o polityce. Po prostu należy pamiętać o wzajemnym szacunku do siebie.

Podsumowanie

To, oczywiście, nie wszystkie porady dotyczące sztuki zgłaszania błędów tak, aby były one rozwiązane. Tym niemniej, wydaje mi się, że uwypukliłem najważniejsze zasady (i przy okazji trochę moralizatorstwa), którymi powinni kierować klienci i na które powinni zwrócić uwagę wykonawcy. Podobnie jak w wielu innych sferach życia, często chcielibyśmy mieć coś dobrze zrobione, ale brakuje też czasu, wiedzy i wysiłku na stworzenie porządnych fundamentów. Pamiętajcie - w dłuższej perspektywie oprogramowanie jest tym lepsze, im lepiej zespół IT zrozumie potrzeby klienta, a sam klient będzie miał czas i cierpliwość wyjaśniać różne niuanse.

Czy jest narzędzie, które polecam i które samo z siebie rozwiązuje przynajmniej część z tych problemów? Jeszcze nie. Ale mam nadzieję, że już niedługo będę (a raczej będziemy całą firmą) mogli przedstawić Wam przedłużenie wtyczki Feedybacky, a mianowicie zintegrowany z nim portal, w którym będzie mogło nastąpić dalsze zarządzanie zgłoszeniami dodanymi z pluginu. Nie ukrywam, że wszyscy w Wilda Software jesteśmy podekscytowani tym projektem, ale na ten moment muszę jeszcze "powstrzymać konie" i oszczędzić szczegółów. O tym systemie będzie jeszcze okazja powiedzieć - obecnie zajmujemy się dopracowywaniem go i testowaniem we własnych projektach, ale wyniki są obiecujące. Jak to mówią Amerykanie - stay tuned. 

Co nie oznacza, że użycie jakiegokolwiek systemu usunie wszystkie trudności wiążące się z prawidłowym zgłaszaniem i obsługą błędów. Nadal najważniejszy pozostaje czynnik ludzki. I wysokiej jakości tego czynniku wszystkim życzę.

Pozdrawiam - Jakub Rojek

Piszemy nie tylko artykuły na blogu, ale też aplikacje i dokumentację dla naszych klientów. Zobacz, z kim do tej pory współpracowaliśmy.

Komentarze

Wczytywanie komentarzy...

O autorze

Jakub Rojek

Główny programista i współwłaściciel Wilda Software, z wieloletnim doświadczeniem w tworzeniu i rozwoju oprogramowania, ale także w pisaniu tekstów na różnorakich blogach. Zaprawiony w boju analityk i architekt systemów IT. Jednocześnie absolwent Politechniki Poznańskiej i okazjonalny prowadzący zajęcia na tej uczelni. W wolnych chwilach oddaje się graniu w gry wideo (głównie w karcianki), czytaniu książek, oglądaniu futbolu amerykańskiego i e-sportu, odkrywaniu cięższej muzyki oraz wytykaniu innym błędów językowych.

Jakub Rojek