Jak zaplanować projekt analityczny: od pytania do kryteriów odbioru

Masz wolny weekend, otwierasz zbiór danych i zaczynasz budować dashboard. Po kilku godzinach są trzy zakładki, mapa i wykres, który bardzo przyjemnie zmienia kolor. Potem ktoś pyta, czego właściwie się dowiedziałeś. I nagle najtrudniejszą częścią projektu okazuje się odpowiedź jednym zdaniem.

Ja wolę ustalić to zdanie wcześniej. Nie musi być gotowym wnioskiem, bo wyniku jeszcze nie znam. Powinno jednak mówić, na jakie pytanie szukam odpowiedzi, komu ta odpowiedź pomoże i po czym poznam, że wykonałem pracę. Dzięki temu mogę wybierać dane i narzędzia według zadania, zamiast dopasowywać zadanie do świeżo poznanej funkcji.

Pokażę to na fikcyjnym projekcie dotyczącym terminowości wysyłek. Wszystkie liczby, role i ustalenia są syntetyczne. Nie opisuję klienta ani efektów konkretnego wdrożenia. Ten przykład możesz przełożyć na portfolio, małe zadanie w obecnej pracy albo rozmowę z osobą, która zamawia raport.

Najpierw nazwij zastosowanie wyniku

„Chcę przeanalizować zamówienia” to opis obszaru. Można pod nim zmieścić sprzedaż, zapasy, reklamacje, dostawy i zachowania klientów. Taki zakres bardzo szybko rośnie. Ja zawęziłbym go do pytania: które grupy zamówień warto sprawdzić, żeby lepiej zrozumieć opóźnienia wysyłki? Odbiorczynią wyniku byłaby osoba planująca pracę magazynu.

Zastosowanie jest konkretne: wybrać obszar do dalszego sprawdzenia. Na tym etapie nie obiecuję wskazania winnego ani obniżenia kosztów. Raport może pokazać koncentrację opóźnień, ale sam nie rozstrzyga, czy odpowiada za nią obsada, brak towaru, zmiana systemu czy inny skład zamówień. Tę granicę zapisuję już w planie.

W opisie etapu Business Understanding w CRISP-DM IBM podkreśla ustalenie oczekiwań organizacji, rozmowę z kluczowymi osobami i zapisanie ustaleń przed planowaniem pracy. W małym projekcie stosuję tę zasadę w lekkiej formie: kilka uzgodnionych zdań zamiast wielkiego dokumentu, którego nikt później nie otworzy.

Sprawdź, kto będzie korzystać z odpowiedzi

Ten sam zbiór może służyć różnym odbiorcom. Kierowniczka magazynu potrzebuje rozpoznać problem operacyjny. Osoba prowadząca obsługę klienta chce wiedzieć, którym zamówieniom grozi przekroczenie terminu. Zarząd może pytać o długoterminowy trend. To trzy różne zadania, nawet jeśli wszystkie zaczynają się od tabeli zamówień.

Pytam więc o moment użycia wyniku. Czy ktoś otworzy go na cotygodniowym spotkaniu? Czy będzie na jego podstawie codziennie wybierać zamówienia do interwencji? Czy wystarczy jednorazowa odpowiedź? Częstotliwość użycia zmienia wymagania wobec aktualności danych, automatyzacji i sposobu prezentacji. Jednorazowej analizy nie trzeba od razu przebudowywać w system raportowy.

W portfolio nie musisz mieć prawdziwego zamawiającego. Możesz jasno napisać, że przyjmujesz rolę hipotetycznego odbiorcy. Ważne, żeby zachować konsekwencję. Jeżeli planujesz raport dla osoby zarządzającej magazynem, wniosek powinien dotyczyć działań, które taka osoba może rozważyć. Sama informacja o liczbie wszystkich klientów niewiele pomaga w ustalonym zadaniu.

Zapisz pytanie tak, żeby mogło dać niewygodną odpowiedź

Dobre pytanie dopuszcza wynik, którego nie oczekujesz. „Jak udowodnić, że nowy proces przyspieszył wysyłkę?” zakłada sukces przed sprawdzeniem danych. Wolę: „Jak zmienił się udział opóźnionych wysyłek w porównywalnych zamówieniach?”. Możliwe odpowiedzi obejmują poprawę, pogorszenie, brak wyraźnej zmiany oraz brak danych wystarczających do porównania.

Jeżeli masz hipotezę, zapisz ją osobno. W naszym przykładzie może brzmieć: zamówienia zawierające produkty z różnych stref magazynu częściej przekraczają termin. To kierunek sprawdzenia, a nie gotowy fakt. Potrzebuję danych o strefach, terminach i strukturze zamówień. Samo znalezienie różnicy jeszcze nie wyjaśni mechanizmu.

Dopisuję również, co mogłoby podważyć interpretację. Może większe zamówienia częściej trafiają do wielu stref? Może jedna grupa ma inny obiecany termin? Taka lista nie musi blokować pierwszej analizy. Pomaga uczciwie nazwać jej zasięg i zaplanować następny krok. W ten sposób projekt nie zamienia się w konkurs na najbardziej pewny siebie podpis pod wykresem.

Ustal, co oznacza jeden wiersz

Zanim wybiorę wykres, ustalam jednostkę obserwacji. W tym projekcie liczę zamówienia. Jedno zamówienie może mieć kilka pozycji produktów, kilka zmian statusu i więcej niż jedną paczkę. Jeżeli połączę te tabele bez kontroli, dostanę wiele wierszy dotyczących tej samej sprawy. Procent opóźnień policzony na takich wierszach może odpowiadać na zupełnie inne pytanie.

Przyjmuję na potrzeby ćwiczenia, że zamówienie ma być wysłane w całości przed zapisanym terminem. Momentem wysyłki jest nadanie ostatniej paczki. Identyfikator zamówienia występuje raz w tabeli wynikowej. Gdyby firma mierzyła terminowość paczek, należałoby zbudować inną definicję. Żadna nazwa kolumny nie rozstrzygnie tego za nas.

W briefie zapisuję też strefę czasową i sposób porównania terminów. Czy „do wtorku” znaczy konkretną godzinę, koniec dnia, czy dzień roboczy według kalendarza firmy? Nie potrzebujesz rozbudowanego kodu, żeby zauważyć ten problem. Potrzebujesz rozmowy albo jawnego założenia w projekcie edukacyjnym. Więcej o takich kontrolach znajdziesz w tekście o czyszczeniu danych.

Zrób mały audyt danych przed obietnicą terminu

Sprawdzam, czy mam pola potrzebne do odpowiedzi: identyfikator zamówienia, obiecany termin, rzeczywisty moment pełnej wysyłki i wybrany podział. Oglądam kilka rekordów oraz proste zestawienia kompletności. Interesują mnie powtórzenia identyfikatorów, brakujące daty, nieznane statusy i wartości, które przeczą kolejności zdarzeń.

Dostęp do pliku nie oznacza jeszcze, że dane nadają się do pytania. Historia może zawierać tylko ostatni status, bez wcześniejszych zmian. Obiecany termin mógł zostać nadpisany po opóźnieniu. W takim zbiorze bardzo trudno uczciwie ocenić dotrzymanie pierwotnej obietnicy. Opisanie tej luki jest wartościowym wynikiem audytu, nawet jeśli opóźnia przygotowanie wykresu.

Dla każdego problemu zapisuję konsekwencję. Brak kolumny o strefie uniemożliwia planowany podział, ale niekoniecznie całe porównanie terminowości. Brak obiecanego terminu dotyka samej definicji wskaźnika. Dzięki temu wiadomo, co można wykonać niezależnie, a co wymaga zmiany pytania. Ogólne „dane są słabe” nie daje podobnej możliwości.

Zdefiniuj wskaźnik razem z wykluczeniami

W prostym wariancie dzielę liczbę opóźnionych zamówień przez liczbę zamówień z kompletnymi danymi, objętych analizą. Zamówienie jest opóźnione, jeżeli moment pełnej wysyłki przekracza obiecany termin. Wybieram zamknięte grupy zakończonych zamówień i wyraźnie zaznaczam, że nie mierzę w ten sposób bieżącego zaległego backlogu.

To ostatnie zastrzeżenie ma znaczenie. Gdybym pominął niewysłane zamówienia i napisał, że mierzę terminowość wszystkich zamówień, obraz mógłby być zbyt optymistyczny. Otwarte sprawy po terminie potrzebują osobnego zestawienia. Do pierwszej wersji projektu mogę je dopisać jako liczebność i ograniczenie, a później rozszerzyć analizę o czas oczekiwania.

Osobno pokazuję rekordy wyłączone z powodu braków. Nie przypisuję im automatycznie statusu „na czas”. Brak informacji i poprawny wynik to różne stany. Właśnie dlatego definicja zawiera zarówno licznik, jak i mianownik, okres oraz reguły wykluczenia. Bez tych elementów nawet prawidłowe dzielenie może prowadzić do mylącego wniosku.

Przejdź przez liczby na małej próbce

W syntetycznym zestawieniu grupa A ma 500 zakończonych zamówień z pełnymi danymi. Wśród nich 40 wysłano po terminie. Grupa B ma 600 takich zamówień, z czego 72 opóźnione. Udziały wynoszą odpowiednio 8% i 12%. Różnica to 4 punkty procentowe. Względnie drugi udział jest o 50% większy od pierwszego.

Obok tego pokazuję 20 zamówień z brakującą datą w grupie A i 60 w grupie B. Przed wykluczeniem było więc 520 oraz 660 zakończonych zamówień. Braki stanowią około 3,85% i 9,09% tych grup. Nie dodaję ich do mianownika terminowości bez wyjaśnienia, bo w przyjętej definicji nie znam ich wyniku.

Najpierw odtwarzam obliczenie na kartce albo prostym arkuszu. Potem porównuję je z wynikiem narzędzia. Jeżeli podstawowa próbka się nie zgadza, automatyzacja tylko szybciej wyprodukuje błędne liczby. Nie potrzebuję jeszcze zaawansowanego modelu, żeby sprawdzić sumy, mianowniki i sens opublikowanego procentu.

Zaplanuj porównanie, które nie ukrywa różnic

Grupy A i B w naszym ćwiczeniu mogą oznaczać dwa okresy. Przed interpretacją sprawdzam, czy obejmują podobny zakres działalności. W jednym okresie mógł wzrosnąć udział większych zamówień albo produktów sprowadzanych od dostawcy. Mogła też zmienić się kompletność rejestrowania dat, co już widać w zestawieniu braków.

Nie próbuję rozwiązać wszystkich problemów na jednym wykresie. W pierwszej wersji opisuję różnicę i proponuję jeden uzasadniony podział, na przykład według wielkości zamówienia. Sprawdzam liczebności w podgrupach. Bardzo mała grupa może dać efektowny procent, który zależy od zaledwie kilku przypadków. Same kolory na dashboardzie tego nie pokażą.

Wniosek brzmiałby: w kompletnych zakończonych zamówieniach udział opóźnień jest wyższy w grupie B, przy większym udziale braków danych. Przed rekomendacją zmiany procesu trzeba sprawdzić strukturę grup i brakujące rekordy. To mniej widowiskowe niż wskazanie jednej przyczyny, ale daje odbiorcy uczciwą podstawę do następnego działania.

Ogranicz pierwszą wersję projektu

Zakres pierwszej wersji obejmuje jedno pytanie, dwa okresy, definicję terminowości, kontrolę kompletności i jeden podział pomocniczy. Rezultatem jest krótkie zestawienie oraz komentarz. Poza zakresem pozostają prognoza opóźnień, ocena pracowników, integracja z systemem magazynowym i codzienne powiadomienia. Każdy z tych pomysłów może być sensowny, ale wymaga dodatkowej pracy.

Gdy pojawia się nowe pytanie, zapisuję je na później. Pytam, czy ma zastąpić część obecnego zadania, czy wejść do kolejnej wersji. Nie dopisuję go bez końca do listy „jeszcze tylko”. To szczególnie przydatne w portfolio, gdzie brak zewnętrznego terminu potrafi zamienić mały projekt w niekończący się remont.

Ograniczenie zakresu pomaga także dobrać narzędzie. Jeśli wystarczy arkusz i kilka czytelnych obliczeń, nie buduję hurtowni tylko po to, żeby wymienić więcej technologii w opisie. Jeżeli celem edukacyjnym jest SQL, zapisuję ten cel osobno. Wtedy projekt ma zarówno pytanie analityczne, jak i świadomie wybrany element ćwiczenia warsztatu.

Ustal kryteria odbioru przed budową

Warunek „dashboard wygląda profesjonalnie” jest zbyt niejasny. Ja chciałbym móc sprawdzić, czy wszystkie liczby mają definicję i okres, tabela wynikowa zachowuje jedno zamówienie na wiersz, wykluczenia są policzone, a próbka kontrolna daje oczekiwany wynik. Odbiorca powinien znaleźć odpowiedź bez przeglądania wszystkich zakładek i bez domyślania się skrótów.

Dodaję warunek odtwarzalności. Osoba z tym samym syntetycznym plikiem wejściowym powinna umieć powtórzyć obliczenie. Opisuję kolejność kroków, potrzebne narzędzie i znaczenie kolumn. Nie obiecuję, że wynik będzie identyczny po zmianie danych. Chodzi o możliwość zrozumienia procesu i sprawdzenia tej samej wersji materiału.

Na koniec kryterium interpretacji: obserwacja, hipoteza i rekomendowany następny krok są wyraźnie rozdzielone. Jeżeli nie udało się odpowiedzieć na pytanie, opis wskazuje konkretną brakującą informację. Projekt może wtedy zakończyć się użytecznym rozpoznaniem ograniczeń. Nie trzeba produkować pewnego wniosku tylko dlatego, że ostatni slajd ma miejsce na podsumowanie.

Rozpisz pracę według niepewności

Zamiast planować „poniedziałek: dashboard”, zaczynam od sprawdzenia ryzyka, które może unieważnić cały pomysł. W naszym przykładzie jest nim dostępność pierwotnego terminu i możliwość uzyskania jednego wiersza na zamówienie. Dopiero potem poświęcam czas na czyszczenie całego zbioru i projektowanie prezentacji.

Przykładowy plan pięciu krótkich sesji wygląda tak: brief i próbka, audyt danych, obliczenie z kontrolą, interpretacja z pierwszym odbiorem, poprawki i instrukcja odtworzenia. To propozycja organizacji ćwiczenia, a nie obietnica konkretnej liczby godzin. Jeśli w audycie wychodzi brak kluczowego pola, wracam do zakresu i aktualizuję plan.

Rezerwuję czas na informację zwrotną. Pokazanie szkicu jednej tabeli przed dopracowaniem wyglądu może ujawnić źle zrozumiane pytanie. Proszę o ocenę konkretnego elementu: czy definicja odpowiada potrzebie, czy podział jest użyteczny, czy opis ograniczeń jest jasny. Pytanie „podoba się?” zwykle nie rozwiązuje najważniejszego problemu projektu.

A jeśli zaczynasz od ciekawego zbioru?

Projekt eksploracyjny też ma sens. Możesz najpierw obejrzeć dostępny zbiór, poznać jego strukturę i poszukać pytań, na które pozwala odpowiedzieć. Nie musisz wymyślać firmy zamawiającej analizę, żeby usprawiedliwić naukę. Ja zapisałbym wtedy cel rozpoznawczy: sprawdzam zakres danych, ich jakość i trzy możliwe kierunki dalszej analizy.

Ustalam jednak granicę eksploracji. Po pierwszym przeglądzie wybieram jedno pytanie albo kończę krótką notatką wyjaśniającą, dlaczego zbiór nie nadaje się do planowanego zastosowania. Inaczej można przez tydzień produkować kolejne wykresy bez żadnego kryterium zakończenia. Ciekawość jest dobrym początkiem, ale plan pomaga zamienić ją w rezultat, który da się komuś pokazać i samodzielnie ocenić.

Zapisz brief na jednej stronie

Mój przykładowy brief zaczyna się tak: „Porównuję terminowość pełnej wysyłki zakończonych zamówień w dwóch okresach. Wynik pomaga kierowniczce magazynu wybrać obszar do dalszego sprawdzenia. Liczę zamówienia z kompletem dat, osobno pokazuję braki i otwarte sprawy po terminie. Nie przypisuję przyczyny różnicy samemu porównaniu”.

Dalej dopisuję plik źródłowy, definicje pól, regułę jednostki obserwacji, kryteria odbioru i termin pierwszego przeglądu. W osobnym zdaniu wymieniam rzeczy poza zakresem. Taki dokument można szybko przeczytać i poprawić. Jeżeli powstaje kilka sprzecznych wersji ustaleń, wskazuję jedną aktualną i zapisuję, co zmieniło się po rozmowie.

Brief ma być narzędziem pracy. Kiedy odkryjesz, że dane nie odpowiadają pytaniu, zmień go jawnie. Nie udawaj, że od początku planowałeś dokładnie to, co udało się policzyć. W portfolio opis takiej decyzji potrafi pokazać więcej myślenia niż kolejna wizualizacja. Czytelnik widzi, jaki problem zauważyłeś i dlaczego wybrałeś określoną drogę.

Co pokazać po zakończeniu

Przekazuję odpowiedź, dowody i ograniczenia w kolejności przydatnej dla odbiorcy. Najpierw jedno zdanie o wyniku, potem tabela z liczebnościami, definicja i kontrola jakości. Kod lub szczegóły transformacji mogą być niżej. Ktoś zainteresowany decyzją nie musi zaczynać od listy wszystkich użytych funkcji.

W opisie portfolio oddzielam wykonane czynności od efektów biznesowych. Mogę napisać, że przygotowałem powtarzalne porównanie i wykryłem nierówną kompletność danych. Nie dopisuję oszczędności, których nie zmierzyłem, ani poprawy procesu, której nikt nie wdrożył. Syntetyczny projekt pozostaje syntetycznym projektem, także wtedy, gdy wygląda bardzo wiarygodnie.

Jeśli chcesz zacząć dzisiaj, wybierz jedno pytanie i napisz pięć zdań briefu. Następnie obejrzyj kilkanaście rekordów. Sprawdź, czy wybrane dane w ogóle pozwalają odpowiedzieć. Dopiero po tej próbie zdecyduj, jaki wynik zbudujesz. Taki początek daje Ci konkretny kierunek i uczciwy punkt, w którym można powiedzieć: ten projekt jest gotowy.