Pierwsza praca analityka: umiejętności techniczne i współpraca

Potrafisz połączyć tabele, zrobić wykres i znaleźć błąd w formule. Potem ktoś w pracy mówi: „Sprawdź, dlaczego ostatnio wszystko się spóźnia”. Otwierasz dane i okazuje się, że najtrudniejsza część zadania zaczyna się przed pierwszym zapytaniem. Co dokładnie się spóźnia? Względem jakiej obietnicy? Kto ma coś zrobić z wynikiem?

Ja właśnie w tym miejscu łączę warsztat techniczny ze współpracą. Potrzebuję obu, żeby dowieźć sensowną odpowiedź. Bez umiejętności obliczeniowych łatwo opowiadać historie bez pokrycia. Bez rozmowy z odbiorcą równie łatwo bardzo dokładnie policzyć coś, czego nikt nie potrzebował. Excel przyjmie oba scenariusze z podobnym spokojem.

Jeśli chcesz dostać pierwszą pracę analityka, możesz ćwiczyć ten proces już podczas nauki. Pokażę go na fikcyjnym zadaniu z zamówieniami. Wszystkie sytuacje, liczby i wypowiedzi projektowe poniżej są przykładami edukacyjnymi. Nie opisują konkretnego pracodawcy ani efektów pracy dla klientów.

Co właściwie oznacza gotowość do pierwszej pracy

Nie ustalam gotowości na podstawie liczby ukończonych kursów. Wolę sprawdzić, czy umiesz przeprowadzić małe zadanie od początku do końca, a przy problemie rozsądnie poprosić o pomoc. Samodzielność początkującego ma granice. Ważne, żebyś potrafił je zauważyć, zamiast ukrywać brak pewności pod dziesiątym wykresem.

Dobry punkt odniesienia daje brytyjski opis roli analityka danych. Na poziomie associate łączy przygotowanie danych i rozwijanie kodu z rozumieniem problemu, komunikacją oraz pracą pod opieką bardziej doświadczonych osób. To opis konkretnej administracji, a nie uniwersalny regulamin rekrutacji. Pokazuje jednak, że współpraca może być częścią warsztatu już na wejściu.

W praktyce proponuję prostą próbę. Dostajesz niewielką tabelę i pytanie. Potrafisz wyjaśnić, co oznacza jeden wiersz, wskazać brakujące informacje, policzyć wynik i pokazać, jak go sprawdziłeś. Następnie opowiadasz, jaki wniosek jest uzasadniony, a czego na tej podstawie jeszcze nie wiadomo.

Taka próbka daje też uczciwą informację o brakach. Możesz dobrze rozumieć dane, ale potrzebować pomocy z łączeniem tabel. Możesz pisać sprawne zapytania, a gubić się podczas prezentacji. Każdy z tych problemów prowadzi do innego ćwiczenia. Ogólne „muszę być bardziej techniczny” jest za szerokie, żeby ustalić, co zrobisz jutro wieczorem.

Uzgodnij pytanie, zanim wybierzesz narzędzie

W naszym przykładzie kierowniczka operacyjna chce raportu o opóźnieniach. Zaczynam od tego, jaką decyzję ma podjąć. Załóżmy, że przygotowuje przegląd procesu wysyłki i potrzebuje wiedzieć, czy problem narasta oraz które przypadki warto sprawdzić. Na początek wystarczy porównanie dwóch zakończonych tygodni. Nie buduję od razu systemu do monitorowania całej firmy.

Dopytuję, czy opóźnienie dotyczy przekazania przesyłki przewoźnikowi, czy dostarczenia jej klientowi. To różne zdarzenia. Data utworzenia etykiety też nie musi oznaczać fizycznego przekazania paczki. Ustalamy, że mierzymy przekroczenie obiecanego terminu wysyłki, a momentem wysłania jest potwierdzone przekazanie przewoźnikowi. Tę definicję zapisuję obok wyniku.

Potrzebuję również reguły przypisania zamówień do tygodnia. Wybieramy tydzień obiecanego terminu wysyłki, nie tydzień złożenia zamówienia ani wykonania raportu. Dzięki temu wiadomo, jakie zobowiązania oceniamy. W realnym projekcie doprecyzowałbym godzinę graniczną i strefę czasową. W przykładzie wszystkie terminy pochodzą z jednego lokalnego kalendarza i już minęły.

Po rozmowie wysyłam krótką notatkę: „Porównam udział zamówień wysłanych po terminie lub nadal niewysłanych po terminie. Pokażę dwa zakończone tygodnie według obiecanej daty wysyłki. Wynik ma pomóc wybrać przypadki do przeglądu”. Proszę odbiorczynię o potwierdzenie zakresu. Pięć zdań ustaleń może oszczędzić kilka wersji pięknego, nieprzydatnego dashboardu.

Jeśli robisz projekt samodzielnie do portfolio, odbiorca może być fikcyjny. Zapisz wtedy jego rolę i decyzję jako założenie ćwiczenia. Nie przedstawiaj wymyślonej rozmowy jako zebrania wymagań u klienta. Partner do nauki może spróbować odegrać odbiorcę i zakwestionować zakres. Warto jednak odróżnić taką symulację od potwierdzenia, że prawdziwa firma rzeczywiście potrzebuje danego raportu. Dzięki temu możesz przećwiczyć pytania bez dopisywania sobie doświadczenia zawodowego. Jeżeli nikt nie może pomóc, wypisz trzy możliwe interpretacje prośby i wybierz jedną z uzasadnieniem. Przy późniejszym przeglądzie pokaż ten wybór jako pierwszą rzecz do sprawdzenia. Nadal masz użyteczne ćwiczenie, a granice projektu są czytelne.

Zbuduj mały warsztat, który pozwala sprawdzić liczby

Na takim zadaniu mogę ćwiczyć Excel, SQL albo narzędzie BI. Wybieram zgodnie ze środowiskiem pracy i zakresem danych. Jeżeli uczysz się do konkretnej roli, sprawdź wymagania jej ogłoszenia i zadania zespołu. Nie zakładam, że każdy początkujący musi równocześnie znać Tableau, Power BI, Pythona i wszystkie odmiany SQL.

W tej analizie potrzebuję umieć wybrać właściwy okres, rozpoznać jedno zamówienie, połączyć potrzebne informacje i policzyć licznik oraz mianownik. Do tego dochodzi kontrola braków i powtarzających się rekordów. Przygotowanie prostej tabeli podsumowującej jest ważniejsze niż efektowny sposób wyświetlenia wyniku. Techniczne podstawy rozwijam szerzej w tekście o SQL dla analityka.

Zanim zsumuję zamówienia, zaglądam do kilku pojedynczych przypadków. Jedno zamówienie może mieć kilka pozycji albo kilka zdarzeń wysyłki. Po połączeniu takich tabel liczba wierszy może wzrosnąć. Muszę wiedzieć, czy w podsumowaniu nadal liczę zamówienia, czy przypadkiem zacząłem liczyć produkty lub skany paczek. W tym przykładzie zakładam jedną przesyłkę na zamówienie; podział na kilka paczek wymagałby dodatkowej reguły.

Sprawdzam też zamówienie wysłane na czas, wysłane po terminie i takie, którego termin minął, ale wysyłki jeszcze nie ma. Brak daty wysyłki w ostatnim przypadku nie usuwa problemu. Przy brakującej obiecanej dacie nie potrafię natomiast ocenić terminowości. Takie rekordy raportuję osobno, zamiast dowolnie dopisywać im wynik.

Policz przykład i nazwij jego granice

Przyjmijmy, że poniższe dane syntetyczne są kompletne i już sprowadzone do jednego wiersza na zamówienie. Wyłączamy zamówienia anulowane przed obiecanym terminem. Zamówienia bez terminu wykazalibyśmy osobno; w tej małej próbce ich nie ma. Opóźnione obejmują zarówno wysłane za późno, jak i nadal niewysłane po terminie.

Dzielę 20 przez 200 oraz 45 przez 300. Udział opóźnień wzrósł z 10% do 15%, czyli o 5 punktów procentowych. Wzrost względny udziału wynosi 50%, bo różnicę 5 punktów odnoszę do początkowych 10%. Liczba opóźnionych zamówień wzrosła o 25, czyli o 125% względem początkowych 20. To trzy różne sposoby opisania zmiany.

Odbiorcy pokazuję jednocześnie udział i liczebności. Samo „opóźnienia wzrosły o 125%” brzmi alarmująco, ale ukrywa, że liczba zamówień w zakresie również wzrosła: z 200 do 300. Z kolei sam procent nie pokazuje, ile przypadków trzeba przejrzeć. Dwie kolumny potrafią załatwić sprawę lepiej niż prezentacja z wielką czerwoną strzałką.

Z tego zestawienia nie wynika przyczyna pogorszenia. Mogła zmienić się struktura zamówień, dostępność towaru, sposób zapisania terminów albo proces wysyłki. Nie podpisuję tabeli „magazyn pracuje gorzej”, bo nie mam do tego podstaw. Mam sygnał do dalszego sprawdzenia i konkretną listę 45 przypadków z drugiego tygodnia. Rozdzielenie wyniku od interpretacji jest częścią mojej odpowiedzialności.

Pokaż wczesny wynik osobie, która zna proces

Nie czekam z kontaktem do ukończenia wszystkich wykresów. Pokazuję małą tabelę i definicję osobie, która rozumie wysyłkę. Pytam, czy dane obejmują właściwe zamówienia i czy istnieją wyjątki, o których nie wiem. Taka rozmowa może ujawnić choćby zmianę znaczenia pola w systemie. Działające zapytanie nie zauważy jej samo.

Załóżmy, że dostaję uwagę: w piątek zaktualizowano terminy części zamówień. Potrzebuję sprawdzić, czy w danych widzę pierwotną obietnicę, czy późniejszą zmianę. Jeśli oceniam realizację obietnicy wobec klienta, wybór wersji ma znaczenie. Zatrzymuję mocny wniosek do czasu wyjaśnienia. Nie poprawiam definicji po cichu tylko po to, żeby wynik wyglądał spokojniej.

To dobry moment, żeby oddzielić dwie role. Odbiorca pomaga ustalić, jakie pytanie ma sens i które zdarzenia opisują proces. Ja odpowiadam za spójne obliczenia oraz pokazanie ograniczeń. Kiedy dostaję sprzeczne oczekiwania od dwóch osób, zapisuję warianty i proszę właściciela zadania o wybór zakresu. Próba zadowolenia wszystkich jednym nieopisanym wskaźnikiem kończy się zwykle kilkoma wersjami prawdy.

Tak rozumiem komunikację w analizie: krótkie ustalenia, konkretna wątpliwość i widoczna korekta. Nie musisz prowadzić najgłośniejszej rozmowy na spotkaniu. Możesz przygotować pytania wcześniej, przesłać notatkę i poprosić o komentarz do jednego fragmentu. Ważne, żeby inni wiedzieli, na czym stoisz i jakiej informacji potrzebujesz do dalszej pracy.

Przed oddaniem ustalam również, co oznacza zakończenie zadania. W naszym przykładzie odbiorczyni ma dostać porównanie tygodni, definicję i listę przypadków do przeglądu. Automatyczne odświeżanie oraz znalezienie przyczyny każdego opóźnienia są osobnym zakresem. Jeśli pojawią się później, oceniam je jako kolejne zadania. Początkującemu łatwo uznać każdą dodatkową prośbę za drobną poprawkę, nawet gdy zmienia ona cały cel analizy.

Przekazanie wyniku zamknąłbym wiadomością: „Udział opóźnionych zamówień wzrósł z 10% do 15%. W załączonym zestawieniu są liczebności i definicja. Proponuję przejrzeć przypadki z drugiego tygodnia; sama tabela nie wyjaśnia przyczyny. Potrzebuję jeszcze potwierdzenia, którą wersję obiecanej daty przechowuje system”. Odbiorczyni widzi wynik, następny krok i nierozstrzygniętą kwestię. Nie musi szukać ich w historii korespondencji. Dopóki definicja daty pozostaje niepotwierdzona, oznaczam wynik jako roboczy. Po wyjaśnieniu zapisuję datę pobrania danych i wersję ustaleń, żeby następna osoba wiedziała, do czego się odnosi.

Proś o feedback, na który da się odpowiedzieć

„Oceń moje portfolio” to ogromne zadanie dla obcej osoby. „Czy w tej definicji pomijam zamówienia niewysłane po terminie?” daje znacznie węższy punkt zaczepienia. Przed wysłaniem prośby opisuję cel, pokazuję potrzebny fragment i zapisuję własną hipotezę. Dzięki temu rozmówca nie musi najpierw odgadywać całego projektu.

Przy problemie z kodem korzystam z zasady minimalnego, odtwarzalnego przykładu: ograniczam materiał do niezbędnych elementów, podaję oczekiwany wynik i sprawdzam, czy błąd nadal występuje. W naszym zadaniu mogę przygotować kilka fikcyjnych zamówień obejmujących różne przypadki. Taka próbka pozwala porozmawiać o regule bez przesyłania komuś całego firmowego eksportu.

Moja przykładowa wiadomość brzmiałaby: „Liczę opóźnienia według obiecanej daty wysyłki. Dla trzech przykładowych zamówień oczekuję dwóch opóźnień, ale wynik pokazuje jedno. Podejrzewam filtr pomijający brak daty nadania. Czy możesz spojrzeć na ten fragment?”. To wystarczająco konkretne, żeby druga osoba mogła ocenić, czy ma czas i kompetencje pomóc.

Po otrzymaniu odpowiedzi wracam z informacją, co zmieniłem i jaki jest rezultat. Jeżeli nie rozumiem rady, proszę o uzasadnienie albo mały przykład. Nie przyjmuję każdej uwagi automatycznie; sprawdzam ją na danych. Feedback ma poprawić pracę i rozumowanie. Samo zebranie dziesięciu opinii bez wykonania żadnej poprawki daje głównie nową listę rzeczy do odkładania.

Ucz się z ludźmi w konkretnym rytmie

Społeczność może dać okazję do przećwiczenia takiej wymiany, nawet gdy jeszcze nie pracujesz w zespole danych. Proponuję małą współpracę: jedna osoba przygotowuje definicję, druga próbuje znaleźć przypadek, w którym wynik będzie mylący. Potem zamieniacie się rolami. Oboje ćwiczycie coś więcej niż odtwarzanie rozwiązania z nagrania.

Ustalcie wcześniej, ile pracy obejmuje przegląd i kiedy się kończy. Przykładowo możecie poświęcić jedno krótkie spotkanie na pytanie oraz tabelę, a kolejne na poprawioną wersję. Nie trzeba zakładać wielkiego projektu z kilkoma narzędziami. Dwie osoby, jeden wynik i jedna poprawka to już materiał do sensownej rozmowy.

Dobieram też rodzaj pomocy do rozmówcy. Osoba techniczna może sprawdzić logikę obliczeń. Ktoś znający proces operacyjny zauważy niejasną definicję. Osoba spoza tematu pokaże, czy wniosek w ogóle jest zrozumiały. Żadna z tych opinii nie zastępuje wszystkich pozostałych, dlatego pytam o konkretny aspekt pracy.

Relacje zawodowe budowałbym właśnie wokół takich wymian. Możesz pokazać małą analizę, opisać napotkany problem albo wrócić z podziękowaniem i poprawką. Nie oczekuj rekomendacji do pracy od kogoś, kto widział wyłącznie Twoje zaproszenie do kontaktów. Więcej o tym piszę w artykule o szukaniu pracy na LinkedIn. Sam kontakt nie daje gwarancji zatrudnienia; pozwala rozpocząć rzeczową rozmowę.

Zostaw projekt, który ktoś potrafi zrozumieć

Portfolio powinno pozwolić prześledzić Twoje decyzje. W przykładzie z wysyłką pokazałbym pytanie odbiorcy, definicję opóźnienia, mały zbiór danych, sposób liczenia i wynik. Dodałbym opis sprawdzonych przypadków oraz jednej zmiany po feedbacku. Zrzut dashboardu zostawiłbym jako ilustrację, a obok umieścił materiał pozwalający odtworzyć obliczenia.

Przy repozytorium pomaga README. Dokumentacja GitHuba opisuje go jako miejsce wyjaśnienia celu projektu, jego przydatności i sposobu rozpoczęcia pracy. W swoim projekcie zacząłbym od kilku zdań dla odbiorcy analizy, a dalej umieścił instrukcję uruchomienia. Wymagane narzędzia i kolejność kroków powinny być jasne bez rozmowy z autorem.

Opisuję uczciwie źródło danych i pomoc innych osób. Jeśli dane są syntetyczne, piszę to wprost. Jeśli dostałem wskazówkę dotyczącą filtra, mogę pokazać, jak ją zrozumiałem i sprawdziłem. Nie nazywam projektu edukacyjnego wdrożeniem dla klienta. Nie przypisuję też raportowi oszczędności, których nikt nie zmierzył. Rekruter może dopytać o każdy z tych szczegółów.

Do prezentacji przygotowuję krótką opowieść: jaki był problem, co ustaliłem, co policzyłem, jaki błąd znalazłem i co pozostało niepewne. Przy pytaniu o trudność mam wtedy konkretny materiał. „Musiałem zdecydować, jak traktować zamówienia nadal niewysłane” mówi więcej o pracy niż „rozwinąłem umiejętności analityczne”. Możesz sprawdzić tę opowieść na osobie, która wcześniej nie widziała projektu.

Przećwicz cały przebieg na małym zadaniu

Na najbliższy tydzień wybierz jeden problem, który umiesz opisać zwykłym językiem. Może dotyczyć wysyłki z tego artykułu albo własnych danych, do których masz prawo dostępu i wykorzystania. Przygotuj pytanie oraz kilka przypadków. Zapisz, jaką decyzję ma wspierać wynik i jakie założenia przyjmujesz na potrzeby ćwiczenia.

W następnym kroku wykonaj obliczenia i sprawdź je ręcznie na małej próbce. Poproś jedną osobę o ocenę konkretnego elementu. Zanotuj uwagę, wprowadź uzasadnioną poprawkę i ponownie policz rezultat. Na koniec dopisz instrukcję oraz krótkie ograniczenie: czego nie można wywnioskować z danych. Tempo dostosuj do czasu, który rzeczywiście masz; tydzień jest propozycją organizacji ćwiczenia.

Po tej próbie oceń dwa obszary osobno. Gdzie zatrzymało Cię narzędzie? Gdzie zabrakło pytania, definicji albo wyjaśnienia? Pierwsza odpowiedź podpowie, czego uczyć się technicznie. Druga pokaże, co przećwiczyć z odbiorcą lub partnerem do nauki. Dzięki temu kolejny kurs czy projekt wynika z rozpoznanej potrzeby.

Ja szukałbym właśnie takich dowodów postępu: potrafię sprawdzić wynik, powiedzieć, skąd się wziął, i poprawić go po rzeczowej uwadze. Nadal trzeba dopasować się do wymagań stanowiska i przejść rekrutację. Masz jednak coś, co można obejrzeć, uruchomić i omówić. To rozsądny materiał do pierwszej zawodowej rozmowy o Twojej pracy.