5 błędów junior data analyst i nawyki, które pomagają w pracy

Dostajesz pierwszą pracę jako junior data analyst. Potrafisz napisać zapytanie, zrobić tabelę i przygotować wykres. A potem przychodzi zadanie: „sprawdź, co się dzieje ze zwrotami”. Bez definicji, bez terminu decyzji, za to z dużym oczekiwaniem, że przecież jako analityk będziesz wiedzieć. I tutaj zaczyna się praca, której sam kurs składni nie załatwi.

Ja patrzę na pięć obszarów: sens zadania, inicjatywę, komunikację, rozwój i widoczność pracy. W każdym można wyrobić sobie nawyk, który ułatwia współpracę. W każdym można też zaliczyć solidną wtopę, nawet mając bardzo dobry SQL. Poniżej pokażę, jak rozpoznać problem i co konkretnie zrobić przy następnym zadaniu.

Najpierw granica: dobra praca nie daje gwarancji zatrudnienia. Firma może ograniczyć budżet, zamknąć produkt albo zmienić strukturę. Nie wyciągam z czyjegoś zwolnienia wniosku, że za mało się starał. Interesuje mnie to, na co masz wpływ w codziennej pracy i o czym możesz rozsądnie porozmawiać z przełożonym.

Przez tekst przejdziemy z fikcyjnym raportem zwrotów w sklepie internetowym. Wszystkie sytuacje, wypowiedzi i liczby są przykładami edukacyjnymi. Nie opisują konkretnego pracodawcy ani moich wyników u klienta. Możesz przećwiczyć ten sam sposób pracy na syntetycznym zbiorze, nawet jeśli dopiero budujesz portfolio.

Błąd 1: robisz raport, zanim ustalisz, do czego posłuży

Prośba „sprawdź zwroty” może oznaczać kilka zupełnie różnych rzeczy. Kierowniczka sklepu chce ustalić, czy zmienić opis produktu. Logistyka potrzebuje zaplanować obsługę paczek. Finanse próbują uzgodnić korekty sprzedaży. Każdy z tych odbiorców może oczekiwać innej daty, innej jednostki i innego momentu uznania zwrotu. Jeden efektowny wykres nie rozstrzygnie wszystkich potrzeb.

Zanim otworzę narzędzie, pytam o decyzję: co ma się wydarzyć po przeczytaniu raportu? Potem ustalam odbiorcę, zakres i termin. Jeżeli odpowiedź brzmi „chcemy po prostu wiedzieć”, proponuję pierwszą wersję pytania. Na przykład: czy udział zamówień z co najmniej jednym przyjętym zwrotem wzrósł w porównywalnych grupach zamówień? Taka propozycja daje coś konkretnego do poprawienia.

W naszym ćwiczeniu jednostką jest zamówienie, a nie zwracana sztuka produktu. Zamówienie z trzema zwróconymi sztukami liczy się raz. Warto to zapisać, zanim połączysz tabelę zamówień z pozycjami zwrotów. Inaczej bardzo łatwo uzyskasz wynik, który świetnie wygląda, ale odpowiada na inne pytanie. Definicja wskaźnika jest częścią zadania analityka, choć na ekranie nie wygląda szczególnie widowiskowo.

Nie przypisuję każdemu raportowi natychmiastowego przychodu. Czasem wartością jest wykrycie niezgodności, uspójnienie definicji albo umożliwienie powtarzalnej kontroli. To nadal trzeba opisać: komu pomaga wynik i w jaki sposób będzie używany. Zdanie „zrobiłem dashboard” mówi, co powstało. Do oceny przydatności potrzebuję jeszcze wiedzieć, co odbiorca może dzięki niemu sprawdzić.

Zapisz brief, który da się sprawdzić

Mój krótki brief dla tego zadania brzmiałby tak: przygotowuję porównanie udziału zamówień ze zwrotem dla dwóch zamkniętych grup zamówień. Odbiorczynią jest kierowniczka sklepu. Raport ma pomóc wybrać produkty do dalszego sprawdzenia, bez przypisywania przyczyny samemu wykresowi. Pierwszy przegląd robimy w środę, a definicję przyjętego zwrotu potwierdza osoba znająca proces obsługi.

Dopisuję warunek porównywalności. Zwroty pojawiają się po zakupie, więc grupa zamówień sprzed dwóch dni miała mniej czasu na zwrot niż grupa sprzed miesiąca. Ustalamy taki sam okres obserwacji albo wyraźnie zaznaczamy niepełność. W przeciwnym razie rzekoma poprawa może wynikać z kalendarza. Junior nie musi sam wybierać firmowej reguły, ale powinien umieć zauważyć, że jej brakuje.

Przydatnym punktem odniesienia jest Project Poster z Atlassian Team Playbook, który porządkuje problem, założenia i sposób sprawdzenia pomysłu. Ja do małej analizy wykorzystuję krótką notatkę zamiast rozbudowanej dokumentacji. Ważne, żeby odbiorca mógł poprawić moje rozumienie zadania, zanim spędzę dwa dni na czymś niepotrzebnym.

Uzgadniam także warunki odbioru. Wynik ma zawierać definicję, okres, liczbę zamówień, liczbę zamówień ze zwrotem i informację o wykluczeniach. Ktoś powinien móc odtworzyć obliczenie. Prognoza kosztów i automatyczne rekomendacje zakupowe pozostają poza pierwszym zakresem. Jeżeli pojawią się później, wracamy do priorytetów i terminu. Dopisanie nowego pomysłu do rozmowy nie wydłuża magicznie tygodnia.

Błąd 2: czekasz na instrukcję albo przejmujesz wszystko

Brak inicjatywy bywa prosty do zauważenia: kończysz przydzielony fragment, widzisz problem i milczysz, bo nikt nie dopisał go do zadania. Druga skrajność wygląda bardziej bohatersko. Samodzielnie przebudowujesz raport, zmieniasz definicję i obiecujesz trzem działom dodatkowe zestawienia. Na koniec Twoje pierwotne zadanie stoi, a zespół dowiaduje się o nowym zakresie przy terminie oddania.

Ja proponuję inicjatywę z określoną granicą. W przykładzie znajdujesz dwa różne znaczenia statusu „przyjęty”. Zapisujesz po jednym przypadku, pokazujesz wpływ na wynik i proponujesz rozmowę z właścicielem procesu. Możesz przygotować oba warianty obliczenia, jeśli to niewielki wysiłek. Nie wybierasz jednak potajemnie reguły tylko dlatego, że jedna wersja ładniej pasuje do wykresu.

Propozycja usprawnienia powinna zawierać koszt i następny krok. „Mogę dodać kontrolę powielonych identyfikatorów przed odświeżeniem raportu. Potrzebuję na próbę około godziny; najpierw sprawdzę ją na kopii danych”. To przykład komunikatu, nie uniwersalna wycena. Odbiorca może porównać tę pracę z pozostałą kolejką. Samo „trzeba wszystko zautomatyzować” zostawia innym sporo roboty do odgadnięcia.

Jeżeli nie masz dostępu albo uprawnienia do zmiany, inicjatywą może być dobrze opisane zgłoszenie. Nie obchodź ograniczeń, żeby udowodnić samodzielność. Podobnie przy dodatkowym zadaniu zapytaj, co przesuwamy. Umiejętność wskazania konfliktu terminów jest użyteczna. Zbieranie zobowiązań bez końca szybko robi z kalendarza zbiór fantastycznych opowieści.

Błąd 3: milczysz do momentu oddania wyniku

Dwa dni bez wiadomości mogą oznaczać spokojną pracę, walkę z błędem albo oczekiwanie na dostęp. Z zewnątrz te sytuacje wyglądają podobnie. Dlatego na początku ustalam, kiedy i gdzie pokażę postęp. Przy małym zadaniu wystarczy aktualizacja po sprawdzeniu danych oraz informacja o problemie, który zagraża terminowi. Nie potrzebuję relacji z każdego kliknięcia.

Wyobraź sobie, że w raporcie część zwrotów nie ma identyfikatora zamówienia. Komunikat „dane są popsute” jest zbyt szeroki. Napisałbym: „Sprawdziłem kompletność kluczy. W części rekordów brakuje połączenia z zamówieniem, więc nie mogę jeszcze policzyć uzgodnionego udziału. Przykłady są w zadaniu. Potrzebuję potwierdzenia źródła identyfikatora od właściciela eksportu do jutra rano”. Widać problem, jego znaczenie i potrzebną pomoc.

Nie musisz czekać, aż wykorzystasz wszystkie możliwe sposoby diagnozy. Jeśli nieznana reguła biznesowa zmienia sens wyniku, dalsze zgadywanie raczej nie przybliży Cię do rozwiązania. Przy błędzie technicznym pokaż najmniejszy przykład, oczekiwany wynik i to, co już sprawdziłeś. Dzięki temu osoba pomagająca zacznie od właściwego miejsca, zamiast odtwarzać całą Twoją ścieżkę.

Do aktualizacji dodaję wpływ na plan. Mogę przygotować strukturę raportu i sprawdzić kompletne rekordy, ale finalna liczba poczeka na decyzję. Jeżeli potrzebuję zmienić termin, mówię o tym, gdy ryzyko staje się widoczne. Nie wpisuję optymistycznego procentu ukończenia tylko po to, żeby dobrze wyglądał status. Ostatnia nierozstrzygnięta definicja potrafi zmienić całe obliczenie.

Oddaj raport razem z instrukcją użycia

Przekazanie wyniku zaczynam od odpowiedzi na uzgodnione pytanie. W danych syntetycznych mamy 1000 zamówień i 80 zamówień z przyjętym zwrotem w jednej grupie oraz 1200 i 120 w drugiej. Udziały wynoszą 8% i 10%. Różnica to 2 punkty procentowe; względny wzrost udziału wynosi 25%. Te dwa ostatnie zapisy opisują różne rzeczy, więc nie zamieniam ich miejscami.

Obok wyniku podaję porównywalny okres obserwacji i regułę liczenia. Nie piszę, że gorszy opis produktu spowodował wzrost. Taki wniosek wymaga dodatkowych danych i sprawdzenia innych wyjaśnień. Zmienić się mogły produkty, klienci albo sposób rejestrowania zwrotów. Raport wskazuje obszar do zbadania. Przyczyny pozostają pytaniem, a nie nagrodą za efektowną prezentację.

Dobra wiadomość przy oddaniu może mieć kilka zdań: „W uzgodnionych grupach udział wzrósł z 8% do 10%. W pliku są mianowniki, definicja i kontrola duplikatów. Wynik obejmuje zamówienia z pełnym okresem obserwacji. Proponuję sprawdzić strukturę produktów przed zmianą opisów. Potrzebuję potwierdzenia, czy ten podział wystarcza do wyboru kolejnego kroku”. To nadal komunikat edukacyjny z naszego przykładu.

Zostawiam również źródło, datę odświeżenia, sposób odtworzenia i ograniczenia. Wersja robocza powinna być oznaczona w samym pliku, żeby zastrzeżenie przetrwało przeklejenie tabeli. Po poprawce zapisuję, co zmieniło wynik. Jeżeli raport będzie używany regularnie, ustalam właściciela i kontrolę odświeżenia. Przekazanie linku nie oznacza automatycznie, że ktoś przejął utrzymanie.

Błąd 4: rozwój sprowadzasz do listy narzędzi

Można przez miesiąc oglądać kursy i nadal nie umieć wyjaśnić, dlaczego połączenie tabel podwoiło liczbę zamówień. Dlatego ja zaczynam plan nauki od konkretnej luki w pracy. W naszym przykładzie będzie to rozumienie poziomu szczegółowości danych i kontrolowanie relacji między zamówieniem a zwrotem. Nowa biblioteka może chwilę poczekać. Ten problem już leży na biurku.

Wybieram małe ćwiczenie: syntetyczne zamówienia, kilka zwrotów do jednego zamówienia, zamówienie bez zwrotu i rekord bez klucza. Przed uruchomieniem zapisuję oczekiwane liczby. Potem wykonuję obliczenie i tłumaczę komuś, skąd bierze się różnica między liczbą wierszy a liczbą zamówień. Jeśli nie potrafię jej wyjaśnić, wracam do modelu danych. Poprawny wynik otrzymany przypadkiem słabo nadaje się na fundament dalszej pracy.

Uzgadniam z przełożonym, kiedy mogę ćwiczyć i jaki rezultat pokażę. Nie zakładam, że każdy ma siłę na drugi etat po godzinach. Rozwój może polegać na spokojnym przeglądzie jednego zapytania z bardziej doświadczoną osobą. Ważne, żeby po spotkaniu została umiejętność samodzielnego sprawdzenia podobnego przypadku, a nie tylko poprawiony plik.

Po tygodniu wracam do tego samego problemu na innych danych. Sprawdzam, czy potrafię rozpoznać błąd bez podpowiedzi i uzasadnić rozwiązanie. Taki dowód postępu jest dla mnie bardziej użyteczny niż liczba obejrzanych lekcji. Szerszy kontekst pierwszej pracy znajdziesz w tekście o błędach początkujących analityków. Tutaj interesuje nas zmiana jednego konkretnego nawyku.

Błąd 5: liczysz, że wkład sam stanie się widoczny

Twoja przełożona nie widzi każdej kontroli, którą dopisałeś do raportu. Odbiorca może nawet nie wiedzieć, że wcześniej wynik zawierał duplikaty. Nie oznacza to, że masz ogłaszać sukces po każdej poprawce. Potrzebujesz jednak miejsca, w którym da się sprawdzić, co zmieniłeś i dlaczego. Ja zapisuję krótko problem, własny zakres, rezultat i dowód.

W naszym przykładzie notatka brzmiałaby: „Uzgodniłem z właścicielką procesu definicję przyjętego zwrotu, przygotowałem zestawienie na poziomie zamówienia i dodałem kontrolę powielonych kluczy. Kolega sprawdził zapytanie, a odbiorczyni potwierdziła układ raportu. Link prowadzi do wersji z datą odświeżenia i ograniczeniami”. Własny wkład jest widoczny, a praca innych osób nie znika z historii.

Nie dopisuję oszczędności, których nie zmierzyłem. Jeżeli usunąłem ręczne łączenie plików, mogę to powiedzieć. Jeżeli chcę podać czas, potrzebuję porównywalnych obserwacji i uwzględnienia obsługi błędów. Szacunek opisuję jako szacunek. Zaufanie łatwo nadwyrężyć zdaniem o ogromnym efekcie biznesowym, którego po dwóch pytaniach nie da się odtworzyć.

Widoczność obejmuje też zrozumienie, kto korzysta z analizy i kto rozstrzyga sporne definicje. Wolę znać te zależności niż próbować zgadywać nieformalne układy w firmie. W rozmowie o rozwoju pytam o oczekiwania na obecnym poziomie, przykłady braków i kryteria większej samodzielności. Więcej o dokumentowaniu wkładu i pomaganiu innym znajdziesz w artykule o rozwoju w zespole.

Gdy oczekiwania zmieniają się w trakcie pracy

Możesz dobrze przygotować brief i nadal usłyszeć przy odbiorze, że potrzebna była zupełnie inna analiza. Wtedy wracam do zapisanych ustaleń i proszę o wskazanie różnicy. Czy zmieniła się decyzja biznesowa, czy od początku inaczej rozumieliśmy pytanie? To pomaga rozdzielić zmianę potrzeb od błędu wykonania. Obie sytuacje wymagają reakcji, ale każda prowadzi do innej poprawki w sposobie pracy.

Jeżeli pomyliłem definicję, opisuję błąd i poprawiam wynik. Jeżeli doszedł nowy zakres, ustalamy jego termin oraz wpływ na pozostałe zadania. Nie obiecuję automatycznie pracy wieczorem, żeby ukryć problem z planem. Przy powtarzających się rozbieżnościach proponuję wcześniejszy przegląd małej próbki. Kilka wierszy z opisem potrafi ujawnić nieporozumienie przed budowaniem całego raportu.

Odpowiedzialność za dobrą współpracę jest wspólna. Junior potrzebuje dostępnej osoby do konsultacji i informacji, według jakich kryteriów jego praca będzie oceniana. Jeśli stale dostaje sprzeczne polecenia, warto zebrać konkretne przykłady i poprosić przełożonego o ustalenie kolejności. Same kolejne kursy techniczne nie rozwiążą konfliktu oczekiwań. Rozmowa o organizacji pracy również należy do zawodowego rozwoju i nie wymaga udawania, że wszystko da się naprawić większym osobistym wysiłkiem.

Przećwicz jeden pełny cykl zadania

Na początek wybierz małą analizę, którą możesz ukończyć w uzgodnionym czasie. W poniedziałek spisz pytanie, odbiorcę, definicję i warunek odbioru. We wtorek sprawdź dane i opisz jedną niepewność. W środę pokaż roboczy wynik, razem z tym, czego jeszcze nie wolno z niego wnioskować. Dni są przykładowe; dopasuj rytm do realnego zadania i dostępności osób.

Następnie przekaż wynik tak, żeby druga osoba mogła go odtworzyć. Poproś o konkretny feedback: czego brakowało do użycia raportu, która informacja pojawiła się za późno, co trzeba było zgadywać? Wybierz jedną poprawkę na następne zadanie. Próba naprawienia wszystkiego jednocześnie utrudnia zauważenie, czy cokolwiek faktycznie się zmieniło.

Jeśli nie pracujesz jeszcze w zespole, odegraj rolę odbiorcy po dniu przerwy. Otwórz własny plik bez zaglądania do historii pracy. Sprawdź, czy rozumiesz definicję, okres i ograniczenie. Możesz też poprosić znajomą osobę o odtworzenie wyniku na syntetycznych danych. Nie przedstawiaj takiego ćwiczenia jako doświadczenia komercyjnego. Jego wartością jest sprawdzenie warsztatu w uczciwie opisanych warunkach.

Na koniec rozmowy z przełożonym ustal, co będziesz robić inaczej i kiedy wrócicie do oceny. Samo „muszę być bardziej proaktywny” jest mało użyteczne. „Przed kolejną analizą potwierdzę decyzję i odbiorcę, a blokady zgłoszę wraz z wpływem na termin” daje zachowanie, które można zobaczyć. Od takiego konkretu zacząłbym poprawę swojej pracy.