Lubię procesy, ale nie zawsze tak było. A już z całą pewnością nie od zawsze lubię metryki. Najmniej lubiłam je kiedy dotyczyły mnie. Było to dawno temu, gdy pracowałam w supporcie, czyli na drugiej linii wsparcia.
Po krótce, czym jest druga linia wsparcia. Otóż, kiedy nowo powstały system trafia do użytkowników, ci wychodzą z siebie, żeby coś w nim zepsuć. (Tak jest. Po cóż inaczej potrzebowaliby wsparcia?). Kiedy taki użytkownik nie potrafi sobie poradzić, zgłasza się do pierwszej linii wsparcia i kiedy tamci nie potrafią sobie poradzić, zgłaszają się do nas.
Dzisiaj do obsługi wsparcia istnieje mnóstwo wymyślnych systemów, które automatycznie liczą i przeliczają co tylko się da. „Za moich czasów” tak nie było. Zgłoszenia spływały mailami, które my czytaliśmy – jeśli akurat nie byliśmy na urlopie albo zwolnieniu – i rozwiązywaliśmy problem.
Z perspektywy czasu, współczuję mojemu przełożonemu, który odpowiadał za wydajność zespołu, nie mając żadnego wglądu ile zgłoszeń obsługujemy dziennie, ile czasu zajmuje jedno zgłoszenie, albo jak długo leży zanim ktoś na nie spojrzy.
Kiedy postanowiono zająć się tym problemem, my musieliśmy każdego maila wprowadzić do systemu, odklikać, że się nim zajmujemy, uaktualniać postęp prac i ostatecznie zamknąć zgłoszenie. Wszystko przy jednoczesnej równoległej komunikacji z klientem.
Koszmar.
Żeby tego było mało, na koniec miesiąca trzeba było sporządzić sprawozdanie, wszystko podsumować i uzupełnić rubryczki w raporcie.
- Ile zgłoszeń obsłużyłe/aś w danym miesiącu?
- Średni czas jednego zgłoszenia.
- Kategoria problemu
- Liczba zgłoszeń per kategoria
- …
Odpowiedzi na wyżej postawione pytania udzielają metryki.
Czym jest metryka?
Metryka albo miara, to para: opis + wartość wyrażona liczbowo. Metryki opisują zjawiska istotnego z perspektywy przedsiębiorstwa – np. Zgłoszenia w danym okresie czasu. Oraz wartość – czyli liczba tychże.
Key Performance Indicator
Wymiawiane „KejPiAje” – KPI – to wskaźniki wydajności. Informuje o tym, czy przedsięwięcie idzie zgodnie z założeniami. Określa się je w postaci celu – a więc, definiuje kierunek, bądź limity dla metryk. Np. Metryką będzie liczba złoszeń obsłużona przez jedną osobę w miesiącu. KPIem, będzie „Liczba zgłoszeń > 80”. Śledząc metryki na przestrzeni kilku miesięcy, wiemy, czy obsługujemy tyle, ile zakładaliśmy. Ponadto, widać trendy, a więc czy liczba zgłoszeń rośnie, maleje albo czy są piki.
Na poniższej grafice mamy przedstawione 2 KPIe. Chcemy obsłużyć minimum 50 zgłoszeń w miesiącu, oraz chcemy aby czas obsługi jednego zgłoszenia był krótszy niż 2 dni.
W styczniu, lutym i marcu nie udało się osiągnąć pierwszego celu, natomiast kwiecień przerósł nasze najśmielsze oczekiwania.
Na ostatnim wykresie w prawdzie brakuje skali, ale jeśli przyjmiemy, że czarne kropki oznaczają średni czas zamknięcia zgłoszenia, to widać, że nasza wydajność kwitnie. Rozwiązujemy więcej i szybciej. Przedsięwzięcie idzie w dobrym kierunku!
Czym jest logpoint?
O ile całkiem łatwo policzyć liczbę zgłoszeń, które powstały w danym okresie czasu (nazywanym równiez oknem czasu – time window), to czas do zajęcia się zgłoszeniem już nie jest taki oczywisty. Żeby go poznać, trzeba sięgnąć wewnątrz konkretnego zgłoszenia. Takie „sięgnięcie” obsługujemy „logpointem”.
Log point, to zdarzenie, które zostanie zalogowane. Zwykle m nazwę i timestamp, czyli moment w czasie (z dokładnością co do sekundy albo jeszcze dokładniej) kiedy nastąpiło.
Żeby policzyć jak długo zgłoszenie „leży” od momentu wpłynięcia, dopóki ktoś nie zacznie nad nim pracować, należy „założyć” logpointa na zdarzenie „Rozpoczęcie pracy” – zwykle to będzie coś w stylu guzika „Start” albo przypisania sobie zgłoszenia.
Nowe zgłoszenie, oczekuje na przypisanie.
Zgłoszenie przypisane. Czas pomiędzy wpłynięciem zgłoszenia, a jego przypisaniem – a konkretnie kliknięciem „Zapisz” po tym, jak użytkownik kliknął „Przypisz” i wybrał osobę, to czas oczekiwania.
Logpointy definiujemy wedle potrzeby i systemu i należy je szczegółowo zdefiniować.
Jak definiować metryki
Metryki definiuje się po to, aby móc podejmować świadome decyzje. W tym celu, nie wystarczą same liczby, niezbędny jest kontekst. Jak liczby zmieniają się czasie? Jak szybko postępują zmiany? Jak jedna metryka wpływa na drugą? Ale przede wszystkim, jak je zbierać?
Ja lubię to wszystko sobie rozpisać w tabelkach:
| ID | KPI | Zbiór wyjściowy | Logpoint | Formuła | Komentarz |
|---|---|---|---|---|---|
| 1 | Liczba zgłoszeń w danym miesiącu | Miesiąc, Liczba złoszeń, które zostały zamknięte w danym miesiącu | Click „Zamknij zgłoszenie” | Id zgłoszenia, Timestamp zamknięcia, | |
| 2 | Średni czas zgłoszenia | Miesiąc zamknięcia zgłoszenia, id zgłoszenia, czas trwania zgłoszenia | Wpłynięcie zgłoszenia (timestamp); Click „Zamknij zgłoszenie” (timestamp) | (Timestamp(zamknięcia) – timestamp(utworzenia)) / liczba zgłoszeń / miesiąc | Dane wejściowe, to wszystkie zgłoszenia w danym miesiącu i czas ich trwania. Średnia jest liczona potem w celu uniknięcia błędów z zaokrągleniami. |
| 3 | Kategoria problemu | Kategoria | Wszystkie wartości z pola „Kategoria” | ||
| 4 | Liczba zgłoszeń per kategoria | Kategoria, liczba zgłoszeń | Liczba wszystkich zgłoszeń, zamkniętych i otwartych per kategoria. Posortowane malejąco. |
Komentarze do tabelki
Liczba zgłoszeń w danym miesiącu
Przyjęłam, że w skład tej metryki wchodzą tylko zamknięte zgłoszenia, niezależnie od tego, kiedy powstały. To nie jest żadna reguła, po prostu w przypadku mojego systemu ma największy sens.
Średni czas zgłoszenia
Do policzenia tej metryki potrzebne są 2 zdarzenia (log pointy): Wpłynięcie zgłoszenia i jego zamknięcie. A konkretnie czas (timestamp) tych zdarzeń. Komentarz precyzuje, że na wyjściu potrzebne są wszystkie zgłoszenia wraz z czasem ich trwania, i liczenie średniej następi później. Innym rozwiązaniem byłby zbiór wejściowy w postaci: miesiąc; średni czas zgłoszenia.
Zobaczcie jak wartościwe jest zestawienie tych miar ze sobą. Można szukać korelacji, czy tam gdzie zgłoszeń było więcej, dłużej trwało ich zamknięcie, czy też nie?
Kategoria problemu
Przede wszystkim, nasz system musi posiadać pole „Kategoria”, z którego będzie można wyciągnąć tę informację. Ponadto, ta metryka tylko wtedy ma sens, jeśli „Kategoria” jest definiowana przez użytkownika i może tam znajdować się dosłownie wszystko. Jeśli kategoria jest czymś wybieranym z predefiniowanej listy, taka metryka nie ma sensu (można poprosić programistów o listę). Będzie ona natomiast przydatna, kiedy nie wiemy jakiego rodzaju zgłoszenia będą wpływać i chcemy dać pracownikom możliwość opisywania ich jak chcą, a następnie, kiedy już uzbieramy trochę danych, przyjrzeć się im i ewentualnie podjąć działania „porządkowe”.
Liczba zgłoszeń per kategoria
Ta metryka czyni poprzednią nadmiarową, natomiast możnaby fajnie zagrać tu UXowo. np. pogrupować w jedną kategorię „Inne” wszystkie te, które mają mniej niż ileś zgłoszeń. Jeśli w naszym systemie istniałyby predefiniowane kategorie (które np. użytkownik wybierałby z listy), możnaby również pokazać te, które mają 0 (zero) zgłoszeń.
Kilka uwag z własnych doświadczeń
Cel zbierania danych
Zdarza się, że zbiera się dane, ale nie ma zdefiniowanych metryk. Wówczas zbiera się jak najwięcej, wmyśl zasady „zobaczymy co nam z tego wyjdzie”. To jest fajne, pod warunkiem, że ktoś gdzieś jest zainteresowany tymi danymi, potrafi je wyciągnąć i przetworzyć – czyli zamienić na informacje. W idealnym świecie zawsze istnieją tzw. „Pytania badawcze”, na które owe dane dostarczą odpowiedzi.
Deptanie sobie po piętach
Przetwarzanie danych do domena „Data scientist’ów”. Poziom szczegółowości przedstawiony tutaj, to już czasami wkraczanie w ich terytorium. Zdarzyło mi się, że nie każdemu się podobało, że wchodzę tak głęboko. Log pointy, to już dość głęboko, zwykle wystarczy zdefiniować metrykę (KPI) i z perspektywy UXa, wskazać miejsce na ekranie, gdzie użytkownik wywołuje zdarzenie (np. kliknięcie w guzik). Niemniej jednak, jak ktoś lubi, to fajnie się dogadać i rozumieć co się dzieje „w bebechach”.
Współpraca z developerami
Jak z każdym designem, dobrze omówić proponowane metryki z programistami, czy w ogóle da się je wyciągnąć z bazy.
Współpraca z biznesem
To biznes powinien wiedzieć czego chce. (W wyobraźni słyszę ten śmiech). W praktyce, czasami trzeba ich wesprzeć, zleceniodawca ma mnóstwo spraw na głowie. Niemniej jednak, trochę trzeba klientów przycisnąć, żeby wyrazili co będą chcieli mierzyć. UX może coś doradzić, ale nie jest naszą rolą decydować w którym kierunku ma zmierzać biznes i wszystkie nasze przypuszczenia powinniśmy potwierdzić. Co chcemy mierzyć i dlaczego istotnie ułatwi pracę z danymi.