Formy zgłaszania uwag w projektach IT

27 marca 2021
Jakub Rojek Jakub Rojek
Kategorie: Feedybacky, Zarządzanie

W swoim ostatnim artykule pisałem o rzeczach, o których warto pamiętać w momencie zgłaszania problemów lub feedbacku w projektach IT. Były to rady skierowane zarówno do osób zgłaszających (a więc klientów, użytkowników), jak i wykonawców (zespołów IT bądź wsparcia). Jedna z sekcji była poświęcona ustalaniu formy przesyłania informacji i wspominałem tam o tym, że jest to temat szerszy oraz będę chciał go rozwinąć i coś zaproponować. Dzisiaj nadszedł ten czas.

Jaka powinna być idealna forma?

Zanim przejdziemy do wymienianki sposobów, w jaki zwykle to robimy w świecie IT, chciałem pokazać, jaki byłby idealny system tego typu. Oczywiście, nie mam na myśli science fiction w rodzaju oprogramowania, które wszystko robi samo, poprawia błędy i jeszcze parzy kawę z mlekiem sojowym, po czym samo pójdzie za nas na crossfit. Tak dobrze nie ma, więc skupmy się na tym, czego realnie możemy się spodziewać.

1. Zgłaszanie błędów, które zajmie jak najmniej czasu klientowi - musimy pamiętać, że czasem zauważamy błędy lub mamy pomysł na poprawę, jednak machamy ręką wiedząc, że musimy gdzieś wejść, wytłumaczyć o co nam chodzi i przez to pomijamy drobiazgi. Tutaj wychodzi ludzka, niekiedy leniwa natura. To potem przekłada się na cierpienie, bo często właśnie nagromadzenie się tych detali świadczy o jakości systemu.

2. Składowanie zgłoszeń w jednym miejscu - nikt nie lubi dociekać, gdzie znajdują się zagadnienia i jakie są relacje pomiędzy nimi. Dodatkowo nie każdy wszędzie ma dostęp lub jest w stanie skomunikować się z innymi osobami w projekcie na czas. Efektem może być bałagan w projekcie i zła jakość help desku.

3. Łatwe monitorowanie statusów zgłoszeń - co z tego, że mamy zgłoszenia i je realizujemy, skoro nie mamy jak szerzyć wiedzy o tym, co już zostało zrobione. Wówczas zarówno u wykonawcy może zachodzić duplikowanie zadań i w ten sposób marnowanie czasu, a u klienta niepewność dotycząca tego, co właściwie się dzieje.

4. Dostarczanie wszystkich potrzebnych informacji ze zgłoszeniem - realizacja tego punktu w pełni jest nierealna, ponieważ nigdy nie wiemy, co będzie potrzebne do rozwiązania danego problemu. Jednak można dociekać, że zwykle jest to data i czas zdarzenia, może zrzut ekranu, przeglądarka, wersja systemu itd. Poza tym umówmy się - jeśli klient nie opisze zgłoszenia w wystarczająco precyzyjny sposób, to te dodatkowe informacje mogą nam nie tyle pomóc, co "uratować".

5. Jasną informację o priorytetach - są zgłoszenia pilne i te mniej pilne. Niestety, nie zawsze zespół IT ma wiedzę o tym, co jest w danym momencie najważniejsze dla klienta, a w związku z tym - czym zająć się w pierwszej kolejności.

6. Licznik zgłoszeń pozostałych do końca - monitorowanie statusów zadań ma wpływ nie tylko na wiedzę dot. progresu, ale też znaczenie psychologiczne - stopniowe "czyszczenie" zagadnień daje uczucie, że wszystko zmierza ku lepszemu i robota została wykonana. Tylko że nie osiągniemy tego, gdy nie mamy łatwej możliwości przeliczenia zgłoszeń lub zobaczenia tego na wykresie.

7. Powiadomienia o nowych lub zaktualizowanych zgłoszeniach - nie każdy zagląda co 5 minut na listę zgłoszeń, aby zobaczyć, czy pojawiło się coś nowego. Powiadomienia to konieczność przy zarządzaniu takim zespołem lub nawet zespołami wsparcia.

Nie jest to oczywiście wszystko, ale mamy już niezłe podsumowanie tego, co chcemy osiągnąć. Przyjrzyjmy się teraz formom zgłaszania, z którymi zwykle mamy do czynienia w projektach IT lub jak wyobrażają sobie tę kwestię klienci. Zaczniemy od tych "tradycyjnych", stopniowo przesuwając się w kierunku lepszych (moim zdaniem) i bardziej zautomatyzowanych rozwiązań.

Telefon

Zacznijmy od czegoś, co jest chyba najbardziej znienawidzonym sposobem komunikacji przez programistów. Zdaję sobie sprawę, że generalizuję, ale wiem też, że wiele osób technicznych po prostu nie znosi rozmawiać przez telefon z nieznajomymi i powiem szczerze, że doskonale to rozumiem, gdyż sam do takich gagatków należę. Wiadomo, że rozmowy głosowe mają swoje zalety, ale wady tego środka komunikacji są dość mocno odczuwalne w kontekście naszego tematu.

Rozmowa telefoniczna zwykle jest przeprowadzana pomiędzy dwiema osobami - to nie jest tak, że od razu cały zespół dowie się o zgłoszeniu, gdyż osoba rozmawiająca od strony zespołu IT musi tę wiedzę przekazać. A czasem jest to trudne, ponieważ dyskusja potrafi wyzwolić w zgłaszającym chęć "pogadania" i powiedzenia o paru rzeczach naraz. Co jednak ważniejsze, komunikat podany w ten sposób może być bardzo nieprecyzyjny i będzie wymagał doszczegółowienia lub wysłania materiałów mailem. A to oznacza czasami dłuższą drogę do rozstrzygnięcia i nerwy po obu stronach. O ile nie nagrywamy rozmów, nie mamy też archiwum, a więc nie możemy przypomnieć sobie tego, o czym mówił klient.

Żeby jednak być uczciwym, są też zalety takiej formy komunikacji. Jest ona przede wszystkim szybka i dlatego wykorzystywana przy nagłych, pilnych sprawach jako dodatkowy sposób powiadamiania lub w celu zadania dodatkowego pytania. Nie da się też ukryć, że pewne informacje (np. instrukcję, jak coś odtworzyć krok po kroku) czasem łatwiej uzyskać drogą głosową, szczególnie od osób nielubiących pisać maili. 

Dlatego telefon jako środek komunikacji zawsze będzie i będzie wsparciem. Należy jednak pilnować, aby nie stał się głównym medium przekazywania zgłoszeń, bo to nie ma żadnego sensu, jeśli zespół wykonawczy jest... zespołem.

Maile

Wiadomości e-mail są "tradycyjnym" i często oficjalnym sposobem komunikowania się w projektach, w tym także drogą przekazywania informacji o ustaleniach i problemach. Jest w formie pisanej, więc wiele osób go akceptuje, naturalnie zawiera historię i można nią przekazywać różnorakie pliki. Pozwalają też od razu załączyć wiele osób do konwersacji.

Problem w tym, że maile są "zbyt obszerne" dla krótkich zgłoszeń, gdyż zazwyczaj poruszają wiele spraw naraz, przez co późniejsza dyskusja toczy się w wiadomościach o długości mierzonej w kilometrach. Nie mówiąc już o graficznych ozdobnikach stosowanych przez niektórych, przez co trudno skupić sie na tekście. To jest dobry środek komunikacji do przekazywania informacji i dyskusji, ale nie zgłoszeń, których status musi być monitorowany, gdyż tutaj nie jest to po prostu możliwe w zautomatyzowany sposób - najbliżej tego jest GMail ze swoimi wątkami, ale to raczej próba ratowania sytuacji. Uczestniczyłem kiedyś w projekcie, w którym umówiliśmy się z klientem na przesyłanie uwag w ten sposób pod warunkiem, że jeden mail będzie zawierał tylko jedno zgłoszenie. Do pewnego stopnia to działało, ale śledzenie wątków stało się tak nieintuicyjne, że i tak później przenosiliśmy wszystkie sprawy do wewnętrznego arkusza. 

Komunikatory (Slack itd.)

Ponownie - jest to wspaniały sposób na komunikowanie się w zespole oraz do szybkiego wymieniania wiadomości z klientem. Co więcej, wydaje się mniej oficjalną drogą, przez co osoby po obu stronach są ze sobą "bliżej" i czują się swobodniej. Można też utrzymać porządek dzięki kanałom. Czy dzięki temu jest to dobry sposób zgłaszania uwag?

Nadal mamy tu trochę problemów. Po pierwsze, podobnie jak w mailach, wiadomości ze zgłoszeniami mieszają się z dyskusją o innym charakterze. Być może tutaj nieco łatwiej to ujarzmić poprzez wyznaczenie osobnego kanału na zawiadomienia i zastosowanie wątków, ale w ten sposób nie załatwi się statusowania. Natomiast musimy pamiętać także, że tego typu komunikatory (np. Slack) mają swoje ograniczenia w różnych planach abonamentowych. Nie zawsze tak jest, że rozwiązywanie problemów następuje od pierwszego zgłoszonego, przez co najstarsze wiadomości mogą się ulotnić do czasu przejścia na wyższy pakiet, odblokowujący limit postów. To swego rodzaju tragedia, gdyż dla klienta nie będzie to żadne usprawiedliwienie. Drugi problem związany jest z modelem, w którym zgłoszenia mogą być dodawane przez różne osoby, np. użytkowników portalu. Oczywiście, często odbywa się to tak, że przekazują oni swoje uwagi klientowi, a ten to zbiera i przychodzi do nas, jednak wymaga to przez niego przepisywania wiadomości (co jest krokiem w tył w porównaniu do maili, gdzie wystarczy podać dalej). A użytkowników raczej nie będziemy wpuszczać do Slacka projektowego.

Współdzielone arkusze

Zaczynamy kierować się ku rozwiązaniom, w których zaczyna przybywać zalet w stosunku do wad. Pierwszym z nich są współdzielone arkusze kalkulacyjne w Google Drive lub OneDrive, które umożliwiają dopisywanie, odczytywanie i monitorowanie uwag zgłaszanych w postaci kolejnych wierszy. Jest to forma, która spełnia całkiem dużo warunków z wcześniej przytoczonej przeze mnie wizji idealnego rozwiązania - wszystko jest w jednym miejscu, statusy widać jak na dłoni i można nawet dyskutować za pomocą jakiegoś komentarza. Dzięki temu jest to dość popularne rozwiązanie, zwłaszcza, że możliwe jest też śledzenie historii zmian. Jednak także tutaj znajdziemy trochę słabości takiego systemu.

Po pierwsze, link do takiego arkusza może się komuś zgubić. Nie wydaje się to bardzo prawdopodobne, gdy ktoś dobrze zarządza swoimi notatkami i odnośnikami w systemie, ale nadal jest to możliwe i odtworzenie takiego linku może wymagać "wstydliwej" komunikacji z drugą stroną ("słuchajcie, głupia sprawa..."). Po drugie, w ten sposób trudno jest przekazywać zrzuty ekranów, choć - oczywiście - nadal jest to możliwe. Generalnie załączanie dodatkowych plików w arkuszu kalkulacyjnym nie jest tak naturalne jak choćby w mailach. Po trzecie - tutaj nie mamy do czynienia z żadną formą powiadomień, przez co kontrolowanie zadań musi się odbywać w sposób ręczny.

Tym niemniej, jeśli nie chcemy korzystać z jakiegoś konkretnego systemu lub klient nie jest do niego przekonany, współdzielone arkusze okazują się zwykle dość dobrym kompromisem.

Systemy do zarządzania zadaniami (np. JIRA, Nozbe Teams)

Przechodzimy do cięższej artylerii, jaką są systemy wyspecjalizowane w zarządzaniu zadaniami w projekcie. No właśnie - służące do zarządzania zadaniami, a niekoniecznie zgłoszeniami, jednak do tego też mogą się przydać, zwłaszcza, że w większości przypadków kwestie naprawiane przez zespół IT i tak lądują w tego typu aplikacjach np. w celu monitorowania czasu pracy. Takie programy mają właściwie wszystko, co potrzebne - pozwalają dodawać załączniki, przypisywać osoby, dyskutować oraz powiadamiać o zadaniu i raportować status. A to tylko część ich możliwości.

Natomiast o tym, że jest to "cięższa artyleria" nie wspomniałem przez przypadek - zwykle nie jest to naturalne środowisko klienta i ten może mieć opory, aby zmusić się do nauki obsługi nowego dla siebie programu, w dodatku nie zawsze bardzo wygodnego (przynajmniej na pierwszy rzut oka). Co więcej, dopuszczenie osoby z zewnątrz do takiej aplikacji wewnątrzfirmowej wymaga albo odpowiedniego doboru uprawnień, albo nowej instancji, co zawsze oznacza trochę roboty dla kogoś zajmującego się administracją. Także jest to rozwiązanie dobre, ale tutaj wygoda przechyla się bardziej w kierunku zespołu IT, a chodzi przecież o to, aby każdy był zadowolony.

Są też systemy, które bardziej skupiają się na zgłoszeniach helpdeskowych, będąc kontenerem zadań projektowych bardziej przy okazji. A zatem przejdźmy do tego, co chciałem Wam zaproponować.

Feedybacky

Brak alternatywnego tekstu dla tego zdjęcia

W poprzednim tekście wspomniałem już o naszym firmowym projekcie w Wilda Software, a jeśli kojarzycie moje poprzednie wpisy, to być może pamiętacie też wtyczkę Feedybacky, która ma na celu ułatwienie zbierania uwag od strony aplikacji webowej. Jedno z drugim ma jak najbardziej sporo wspólnego - wtyczka jest dostępna już od ponad roku, a teraz powoli wprowadzamy aplikację, która jest jej dopełnieniem. 

Dlaczego uważam, że Feedybacky z przedstawionych rozwiązań może najbardziej przypaść Wam do gustu? Ponieważ praktycznie odpowiada na każdy punkt, który przywołałem na początku tego tekstu:

Ad 1. Użytkownik nie musi wychodzić z aplikacji, aby zgłosić błąd - formularz jest widoczny na samej stronie, nie zasłania całej treści i sam się zamyka po wpisaniu komentarza.

Ad 2 i Ad 3. Wszystkie zgłoszenia trafiają do systemu, do którego dostęp mają zarówno osoby od wsparcia, programiści, managerowie, jak i sami klienci. Każda pozycja ma osobny status, który jest przez wszystkich widziany.

Ad 4. Wraz ze zgłoszeniem automatycznie dodają się nie tylko czas, ale też zrzut ekranu, informacje o sesji, przeglądarce, rozdzielczości, historia zdarzeń, a także inne dane, które dodatkowo może wymusić programista podczas implementacji wtyczki w systemie. Użytkownik zgłaszający nic nie musi robić - może co najwyżej nie wyrazić zgody na wysłanie określonej informacji.

Ad 5. W samym systemie klient może zmieniać priorytety zgłoszeń, dzięki czemu są one dodatkowo oznaczane i widoczne na górze listy. Oczywiście, widzą to też osoby z zespołu IT.

Ad 6. W samym systemie widać statystykę otwartych i zamkniętych zgłoszeń, dzięki czemu szybko możemy się zorientować, jak daleko mamy posunięte prace i ile jeszcze przed nami.

Ad 7. Każde zgłoszenie lub jego aktualizacja może wygenerować powiadomienie mailowe. Jego wysłanie zależy od każdego użytkownika z osobna - jeśli ktoś ma wiele projektów na głowie, to zwyczajnie może wyłączyć "spamowanie".

Brak alternatywnego tekstu dla tego zdjęcia

Oczywiście, także tutaj użytkownicy mogą dyskutować nad danym zgłoszeniem. Dyskusja podzielona jest na dwa wątki - pomiędzy klientem a zespołem IT, a także wewnątrz samego zespołu IT. Jeśli obsługujemy wiele projektów, wszystko widzimy na kokpicie wraz z wyszczególnieniem rzeczy, którymi powinniśmy zająć się w danej chwili. Jest to system, który rozwijamy już od dłuższego czasu i testujemy na sobie, gdyż sami jesteśmy jego użytkownikami - już kilkukrotnie sprawdził się nam w kontaktach z klientami, znacząco ułatwiając proces testowania oprogramowania. Zdaję sobie sprawę, że mogę nie być specjalnie wiarygodny opisując w ten sposób system, przy którym sam pracuję, ale wierzcie mi, że także sami klienci zwracali uwagę, iż taka aplikacja jest całkiem wygodna.

Brak alternatywnego tekstu dla tego zdjęcia

Sam portal jest w trakcie "etapu dojrzewania" i cały czas jest oraz będzie rozwijany, natomiast mamy nadzieję, że za niedługi czas będziemy mogli go Wam przedstawić i oddać do oceny w postaci zamkniętych betatestów. Mamy nadzieję, że nasze przewidywania okażą się słuszne i rzeczywiście będzie to aplikacja, która bardzo ułatwi porozumiewanie się z klientami i obsługę zgłoszeń, oszczędzając przy tym czas.

Oczywiście, sama wtyczka nadal jest i będzie dostępna i to całkowicie za darmo. Można też korzystać z pluginu nie mając dostępu do portalu - nie ma ku temu żadnych przeszkód poza napisaniem endpointu, na który będą przychodzić zgłoszenia.

Podsumowanie

W tym tekście starałem się przedstawić różne narzędzia, które można teoretycznie lub praktycznie wykorzystać w procesie obsługi helpdeskowej, zbierania feedbacku oraz informacji o błędach. Na pewno nie udało mi się pokazać wszystkich możliwości, ale mam nadzieję, że udało się poruszyć te najbardziej rozpowszechnione. Jednocześnie chciałem przedstawić rozwiązanie, nad którym pracujemy w firmie i niedługo damy wybranym (a później wszystkim) ochotnikom do testowania.

Dziękuję za lekturę i zapraszam do komentowania tego tematu. Jestem bardzo ciekawy, jak to u Was wygląda w firmach IT :)

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.

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