Co robi analityk danych: od pytania biznesowego do decyzji

Ktoś mówi: potrzebujemy dashboardu. Ja chciałbym najpierw wiedzieć, co ta osoba zrobi inaczej, kiedy dashboard już powstanie. Zwiększy obsadę zespołu? Zmieni proces? Sprawdzi zaległe zgłoszenia? Od odpowiedzi zależy, jakie dane zbiorę i czy w ogóle potrzebny będzie dashboard.

Właśnie tak tłumaczyłbym pracę analityka danych. Korzystam z narzędzi, ale muszę też ustalić sens pytania, sprawdzić materiał i przeprowadzić odbiorcę przez wynik. Nawet poprawne zapytanie może odpowiadać na niewłaściwy problem. A wykres, którego nikt nie rozumie i nie używa, ma dosyć ograniczone życie towarzyskie.

Poniżej przejdę przez przykładowe zadanie dotyczące obsługi zgłoszeń. Scenariusz, dane i organizacja dnia są syntetyczne. Nie opisuję tu aktualnego etatu ani projektu klienta. Chcę pokazać sposób myślenia i konkretne rezultaty, których można oczekiwać po kolejnych etapach pracy.

Zakres zawodu jest szerszy niż program do wykresów

Microsoft opisuje rolę analityka przez przygotowanie danych, modelowanie, wizualizację i współpracę z odbiorcami. To użyteczna mapa, choć pisana z perspektywy narzędzi Microsoftu. Nie traktowałbym jej jako obowiązkowej listy programów dla każdej osoby, która chce pracować z danymi.

Z kolei O*NET w opisie analityków BI wymienia także utrzymanie raportów, dokumentowanie wymagań i przekazywanie rekomendacji. Z tego powodu, czytając ofertę pracy, szukałbym konkretnych obowiązków. Dwa stanowiska o identycznej nazwie mogą oznaczać zupełnie inny podział czasu między analizą a utrzymaniem rozwiązania.

Dla siebie rozdzieliłbym trzy rodzaje rezultatu. Analiza jednorazowa odpowiada na określone pytanie. Raport cykliczny ma regularnie pokazywać uzgodniony stan. Rozwiązanie samoobsługowe pozwala odbiorcom zadawać część pytań samodzielnie. Każdy wariant wymaga trochę innej dokumentacji, kontroli i rozmowy o tym, kto będzie z niego korzystać.

Nie chciałbym sprzedawać jednej osoby jako całego działu danych. Przy większym rozwiązaniu potrzebna bywa współpraca z inżynierem danych, administratorem, ekspertem domenowym albo osobą odpowiedzialną za wdrożenie. Analityk powinien rozumieć zależności i umieć poprosić o pomoc. Samotne ratowanie wszystkich warstw systemu nie jest wymaganym dowodem profesjonalizmu.

Pierwsza rozmowa: co oznacza „odpowiadamy za wolno”

W naszym scenariuszu lider obsługi klienta mówi, że zespół odpowiada za wolno. Zanim otworzę dane, zapytałbym, skąd pochodzi ta obserwacja. Z reklamacji, pojedynczej skargi czy regularnego pomiaru? Czy problem dotyczy pierwszej odpowiedzi, rozwiązania zgłoszenia, a może długiego oczekiwania między kolejnymi wiadomościami?

Potem ustaliłbym decyzję. Jeżeli lider rozważa zmianę godzin obsługi, potrzebujemy informacji o porach napływu i oczekiwania. Jeśli zastanawia się nad szkoleniem zespołu, sama pora napływu nie wystarczy. Te pytania mogą korzystać z tej samej bazy, ale prowadzą do innej analizy i innej rozmowy o ograniczeniach.

Na początek zaproponowałbym pytanie: jak długo czekają na pierwszą odpowiedź człowieka zgłoszenia utworzone w wybranym tygodniu? Dopisałbym, czy liczymy czas kalendarzowy, czy wyłącznie godziny obsługi. Automatyczne potwierdzenie otrzymania wiadomości nie byłoby w tej definicji odpowiedzią człowieka. To przykładowa umowa, którą odbiorca musi zaakceptować.

Wynikiem rozmowy powinno być krótkie ustalenie zakresu, odbiorcy i terminu. Chciałbym też wiedzieć, czego obecnie nie rozstrzygamy. W pierwszej wersji możemy opisać rozkład czasu odpowiedzi bez oceny produktywności pracowników. Taka granica chroni przed dokładaniem kolejnych pytań do zadania, które miało być gotowe jutro rano.

Sprawdzenie danych zaczyna się od ich pochodzenia

Poprosiłbym o słownik pól i możliwość prześledzenia kilku zgłoszeń w systemie źródłowym. Potrzebuję identyfikatora zgłoszenia, czasu utworzenia i historii odpowiedzi z informacją o ich rodzaju. Sama kolumna „czas obsługi” może ukrywać gotowy pomiar o definicji, której nie znamy. Nie chciałbym jej bezrefleksyjnie przemianować na potrzebny wskaźnik.

Sprawdziłbym również strefę czasową oraz to, jak źródło zapisuje aktualizacje. Czy dostajemy pełny stan, historię zdarzeń, czy tylko zmiany od ostatniego importu? Czy usunięte zgłoszenia znikają z eksportu? Od tych odpowiedzi zależy, czy później potrafimy odtworzyć ten sam wynik, czy oglądamy wyłącznie bieżący stan systemu.

Na tym etapie rozdzieliłbym dostępność od przydatności. Tabela może zawierać tysiące wierszy i nadal nie mieć informacji pozwalającej odróżnić odpowiedź automatyczną od ludzkiej. Dużo danych nie zastępuje potrzebnego pola. Jeśli go brakuje, nazwę ograniczenie i zaproponuję węższy rezultat zamiast udawać, że problem rozwiąże bardziej skomplikowane zapytanie.

W codziennej pracy właśnie takie pytania często przesuwają zadanie do przodu. Odbiorca nie zawsze zobaczy je na końcowym wykresie, ale powinien dostać ich konsekwencje: co mierzymy, co pomijamy i na jakiej podstawie ufamy wynikowi. To część rezultatu, za który chciałbym odpowiadać jako analityk.

Przygotowanie tabeli do jednego pytania

Załóżmy, że pierwsza tabela zawiera zgłoszenia, a druga wiadomości. Jedno zgłoszenie może mieć wiele wiadomości. Gdybym po prostu połączył tabele i policzył wiersze, długie rozmowy miałyby większy udział w wyniku. Naszą jednostką pozostaje jednak zgłoszenie. Potrzebujemy jednej właściwej pierwszej odpowiedzi dla każdego z nich.

Wybrałbym więc najwcześniejszą odpowiedź człowieka, która spełnia uzgodnione warunki. Zachowałbym także zgłoszenia bez takiej odpowiedzi. Ich brak w tabeli wynikowej mógłby stworzyć bardzo atrakcyjny raport: najdłużej oczekujące sprawy po prostu by zniknęły. O kontrolach takich przypadków piszę szerzej w tekście o złych danych.

Osobno policzyłbym, ile zgłoszeń weszło do populacji i ile odpadło na każdej regule wykluczenia. Sprawdziłbym kilka przypadków na granicy tygodnia, zgłoszenie bez odpowiedzi i rozmowę zaczętą od automatu. To propozycja uzgodnienia logiki na małej próbce. Nie zastępuje późniejszej kontroli całego zakresu potrzebnego do publikacji.

Rezultatem tego etapu byłaby tabela gotowa do konkretnego pomiaru oraz zrozumiały opis przekształceń. Jeśli ktoś pyta, skąd pochodzi liczba, chcę móc przejść od wyniku do identyfikatorów spraw i dalej do źródła. Sama informacja, że formuła jest długa i zawiera trzy zagnieżdżenia, raczej nikogo rozsądnie nie uspokoi.

Analiza: jedna średnia to mało

Przyjmijmy pięć rozstrzygniętych zgłoszeń z czasami pierwszej odpowiedzi 5, 10, 15, 20 i 100 minut. Średnia wynosi 30 minut, bo suma to 150 minut dla pięciu spraw. Mediana wynosi 15 minut: środkowa obserwacja w uporządkowanym zbiorze. Obie liczby są poprawne, ale eksponują inne cechy tej samej małej grupy.

Ja pokazałbym odbiorcy również skrajny przypadek i liczbę spraw. Nie usunąłbym 100 minut tylko dlatego, że psuje wykres. Chciałbym wiedzieć, czy to błąd, nietypowy kanał kontaktu czy rzeczywiste oczekiwanie. Jeśli jeden przypadek ma tak duży wpływ na małą próbkę, warto powiedzieć to głośno przed wyciąganiem szerokiego wniosku.

Dalej porównałbym grupy, które mają sens dla decyzji, na przykład godziny utworzenia i kanał kontaktu. Podejście EDA opisane przez NIST pomaga patrzeć na strukturę i anomalie przed przyjęciem gotowej opowieści. W naszym scenariuszu nie zakładamy z góry, że winny jest konkretny zespół lub brak szkolenia.

Przy każdym podziale sprawdziłbym liczebność. Jeden świetny wynik nocnej zmiany nie wystarcza do porównania jej z setką spraw dziennych. Zwróciłbym też uwagę na różne typy zgłoszeń. Jeśli trudne reklamacje trafiają do innej kolejki niż proste pytania, porównanie średnich może opisywać podział pracy, a nie jakość jej wykonania.

Wniosek i rekomendacja potrzebują granic

Załóżmy, że dłuższe oczekiwanie skupia się przy sprawach utworzonych tuż po końcu godzin obsługi. Mogę opisać tę zależność. Nie mam jeszcze podstaw, żeby stwierdzić, że zatrudnienie kolejnej osoby rozwiąże problem. Potrzebuję znać obciążenie, wymagany poziom obsługi, organizację zmian i to, jakie przypadki mogą poczekać.

Zaproponowałbym kolejny krok proporcjonalny do dostępnych informacji. Na przykład sprawdzenie kolejki według godzin i omówienie możliwej zmiany dyżuru z liderem. To rekomendacja oparta na obserwacji, z wyraźnym warunkiem dalszej oceny. Nie nazwałbym jej dowodem, że organizacja musi zmienić zatrudnienie. Wykres sam nie podejmuje takiej decyzji.

W materiale końcowym rozdzieliłbym obserwację, interpretację i działanie. Obserwacja mówi, co widzimy w danych. Interpretacja proponuje wyjaśnienie. Działanie określa, co odbiorca może sprawdzić lub zmienić. Kiedy te trzy poziomy zlewają się w jedno zdanie, przypuszczenie łatwo zaczyna udawać ustalony fakt.

Pokazałbym również, co mogłoby zmienić moją ocenę. Jeśli część odpowiedzi oznaczono błędnie jako automatyczne, pomiar wymaga poprawy. Jeśli tydzień był nietypowy z powodu awarii, trzeba sprawdzić dłuższy okres. To użyteczna informacja dla odbiorcy. Pozwala rozumieć, jak trwały jest wniosek i kiedy należy do niego wrócić.

Jak przekazałbym wynik odbiorcy

Zacząłbym od odpowiedzi na uzgodnione pytanie oraz definicji okresu. Potem pokazałbym jeden główny wykres, wielkość populacji i informację o nierozstrzygniętych sprawach. Szczegóły techniczne umieściłbym dalej. Odbiorca powinien zrozumieć rezultat bez czytania całej historii przekształceń, a jednocześnie móc ją znaleźć, kiedy będzie potrzebna.

Na spotkaniu poprosiłbym o interpretację wykresu własnymi słowami. Jeśli lider widzi „wszyscy czekają pół godziny”, a średnia 30 minut pochodzi z pięciu mocno różnych czasów, trzeba poprawić komunikat. Zgoda na wygląd slajdu nie jest jeszcze zgodą na znaczenie danych. To da się sprawdzić jednym trafnym pytaniem.

Nie przedstawiałbym każdego dostępnego podziału tylko dlatego, że udało się go zbudować. Materiał ma pomagać w konkretnej decyzji. Dodatkowe analizy zachowałbym jako wsparcie dla pytań i opis ograniczeń. Inaczej odbiorca dostaje dwadzieścia zakładek i nową pracę polegającą na odgadywaniu, która z nich jest najważniejsza.

Po rozmowie zapisałbym ustalenie: kto podejmuje kolejny krok, co trzeba jeszcze sprawdzić i kiedy ocenimy sytuację ponownie. Czasem wynikiem będzie decyzja, żeby niczego na razie nie zmieniać. Jeżeli wiemy dlaczego i jakie sygnały skłonią nas do powrotu, taka analiza też może być użyteczna. Nie każdy raport potrzebuje rewolucji.

Jak mógłby wyglądać dzień z takim zadaniem

W przykładowym dniu rano sprawdziłbym aktualizację danych i odpowiedzi na wczorajsze pytania. Potem odbyłbym krótką rozmowę o definicji pierwszej odpowiedzi. Dłuższy blok czasu przeznaczyłbym na przygotowanie tabeli i analizę przypadków. Po południu pokazałbym roboczy wynik, a na końcu uzupełnił definicję i listę spraw do wyjaśnienia.

To ilustracja organizacji pracy, nie rozkład dnia obowiązujący w zawodzie. Inny analityk spędzi więcej czasu na eksperymencie, kolejny na utrzymaniu raportowania. Także sposób pracy zespołu jest różny. Nie każdy korzysta ze Scruma, a obecność codziennego spotkania nie pozwala automatycznie nazwać całej organizacji zwinną.

Ważniejszy od idealnego kalendarza jest dla mnie postęp zadania. Po rozmowie mamy uzgodnioną definicję. Po przygotowaniu danych mamy tabelę i kontrolę populacji. Po analizie wiemy, które obserwacje warto sprawdzić. Po prezentacji odbiorca rozumie następny krok. Każdy etap powinien pozostawić rezultat, z którego ktoś może skorzystać.

Są też mniej widowiskowe obowiązki: opis kolumny, poprawienie odświeżania, odpowiedź na pytanie użytkownika. Nie traktowałbym ich jako czegoś poniżej godności analityka. Użyteczny raport potrzebuje utrzymania i zrozumiałych definicji. Jeżeli zajmuje to cały dostępny czas, warto jednak omówić z zespołem podział pracy i priorytety zamiast po cichu odkładać analizę bez końca.

Co zostaje po przekazaniu raportu

Jeśli analiza ma być powtarzana co tydzień, ustaliłbym osobę odpowiedzialną za odświeżenie i reakcję na błąd. Zapisałbym też, jak odbiorca rozpozna nieaktualny wynik. W naszym przykładzie stara data ostatniego importu powinna być widoczna. Raport, który pokazuje wczorajsze dane pod dzisiejszą datą oglądania, potrafi niepotrzebnie uspokoić cały zespół.

Sprawdziłbym, czy dokumentacja wystarcza innej osobie do przejęcia zadania podczas mojej nieobecności. Potrzebuje ona źródła, definicji populacji, miejsca obliczeń i kontaktu do właściciela systemu. Nie musi od razu znać wszystkich szczegółów projektu. Powinna jednak umieć ustalić, czy wynik jest świeży i gdzie zgłosić problem bez szukania autora na prywatnym telefonie.

Zmiana definicji pierwszej odpowiedzi wymagałaby osobnej decyzji o porównaniu z historią. Jeśli od następnego miesiąca zaczniemy liczyć wyłącznie godziny obsługi, nowy wynik będzie odpowiadał na trochę inne pytanie. Oznaczyłbym datę zmiany i uzgodnił, czy przeliczamy poprzednie okresy. Inaczej poprawa na wykresie może wynikać wyłącznie z przestawionego zegara pomiaru.

Zapytałbym również, czy raport jest używany. Jeżeli odbiorcy przestali do niego wracać, warto ustalić dlaczego: zmieniła się decyzja, nie ufają danym czy mają już lepsze źródło? Utrzymywanie zbędnego rozwiązania też kosztuje czas zespołu. Analityk może pomóc je uprościć albo wycofać, zachowując potrzebne definicje i świadomie uzgodnione zależności.

W takim zadaniu chciałbym mierzyć własną skuteczność zdolnością odbiorcy do działania i wyjaśnienia wyniku. Liczba przygotowanych zakładek może być informacją o nakładzie pracy, ale niewiele mówi o przydatności. Dlatego po pierwszym przekazaniu wróciłbym do lidera z krótkim pytaniem o to, co rzeczywiście udało się wykorzystać i czego wciąż brakuje.

Narzędzia i pierwszy samodzielny projekt

Do małego, jednorazowego zadania może wystarczyć arkusz. Gdy dane są w bazie, przydaje się SQL. Narzędzie BI pomaga udostępnić powtarzalny widok, a Python może wspierać przygotowanie bardziej złożonej analizy. Dobierałbym narzędzie do źródła, skali i sposobu użycia wyniku. Lista technologii na końcu CV sama nie opisuje sposobu myślenia.

Osobie początkującej zaproponowałbym projekt z jasnym odbiorcą i małym zakresem. Możesz wykorzystać syntetyczne zgłoszenia z tego tekstu, dodać sprawę bez odpowiedzi oraz przypadek z automatycznym potwierdzeniem. Opisz populację, pokaż różnicę między średnią i medianą, a na końcu zapisz jeden wniosek oraz jedno pytanie, na które dane nie odpowiadają.

Do projektu dołącz definicję wskaźnika i krótką instrukcję odtworzenia wyniku. Nie musisz budować całego systemu obsługi klienta. Chciałbym zobaczyć, że potrafisz wyjaśnić wybory: dlaczego zachowałeś brak odpowiedzi, co oznacza wiersz i czemu nie oceniasz pracowników na podstawie pięciu czasów. Takie pytania dobrze oddzielają znajomość przycisków od rozumienia analizy.

Jeżeli zastanawiasz się nad specjalizacją, porównaj ten zakres z tekstem o analityku biznesowym, analityku danych i BI developerze. Potem weź jedną ofertę pracy i wypisz oczekiwane rezultaty. To będzie znacznie konkretniejszy punkt startu niż próba nauczenia się wszystkich narzędzi, które akurat mieszczą się w ogłoszeniu.