Mapa kariery analityka danych: role, odpowiedzialność i następny krok

Patrzysz na ogłoszenia i widzisz sześć nazw stanowisk, z których każde wymaga SQL-a. Do tego Python, jakiś dashboard, komunikacja i obowiązkowa odporność na dynamiczne środowisko. W którym miejscu tej mapy właściwie jesteś? I czy następny krok musi oznaczać kolejne narzędzie?

Ja zaczynam od prostszego pytania: za jaki rezultat chcesz odpowiadać? Za poprawny raport, wyjaśnienie problemu, wspólny model danych czy projekt całego przepływu informacji? Nazwa stanowiska pomaga w wyszukiwaniu ofert. Dopiero opis pracy pokazuje, na co zapisujesz swoje poniedziałki.

Poniżej porównuję sześć obszarów: reporting, analizę, pracę seniora, analytics engineering, architekturę i data science. Senior oznacza tutaj poziom odpowiedzialności w analizie, pozostałe nazwy wskazują zakres pracy. Celowo rozdzielam te dwie rzeczy. Wszystkie scenariusze projektowe w tekście są przykładami, a nie historiami konkretnych klientów ani badaniem rynku pracy.

Jak czytam mapę kariery

Najpierw oddzielam specjalizację od samodzielności. Możesz rozwijać się w analizie, biorąc coraz trudniejsze pytania biznesowe. Możesz też przejść do budowania modeli danych i początkowo potrzebować sporo wsparcia. Dotychczasowe doświadczenie zostaje z Tobą, ale nowy rodzaj pracy ma własne pułapki. Sam napis „senior” w poprzedniej firmie ich nie usuwa.

Dobrym punktem odniesienia są publiczne opisy kompetencji. Brytyjski Government Digital and Data opisuje analityka na poziomach od associate do principal. Osobno opisuje inne zawody. Traktuję to jako przykład uporządkowania odpowiedzialności w konkretnej organizacji, bez przenoszenia jej stopni służbowych na polskie ogłoszenia.

Na własnej mapie zapisuję trzy rzeczy: jakie pytania rozstrzygam, jaki rezultat zostawiam i kto z niego korzysta. Jeśli potrafię odpowiedzieć tylko nazwami programów, mapa jest jeszcze mało użyteczna. „Znam Power BI” nie mówi, czy umiem ustalić definicję wskaźnika albo rozpoznać błędną relację między tabelami.

Tabela porządkuje rozmowę, ale nie dzieli firmy na sześć szczelnych pokoi. W małym zespole jedna osoba może wykonywać kilka z tych zadań. W dużym nawet jeden raport może potrzebować współpracy kilku specjalistów. Przy wyborze roli sprawdzam więc również otoczenie: od kogo dostanę dane, kto oceni moją pracę i komu przekażę problem przekraczający mój zakres.

Reporting: odpowiedzialność za wynik, który można odtworzyć

Reporting może być sensownym wejściem do pracy z danymi. Nie zakładam jednak, że każde stanowisko o takiej nazwie jest juniorskie. Cykl raportowy dla jednego zespołu i raportowanie obejmujące wiele systemów to zupełnie różne zakresy. W ogłoszeniu szukam opisu źródeł, częstotliwości zmian i oczekiwanego poziomu samodzielności.

Weźmy przykładowy tygodniowy raport zamówień. Ktoś musi ustalić, czy liczymy zamówienia złożone, opłacone czy wysłane. Musi zauważyć brakujący plik, opisać moment odświeżenia i sprawdzić, czy po połączeniu tabel nie powstały duplikaty. To są decyzje, od których zależy użyteczność raportu. Samo ustawienie koloru słupków zajmuje przy nich całkiem skromne miejsce.

Na początek proponuję arkusz lub zapytanie, które druga osoba potrafi uruchomić według krótkiej instrukcji. Dołącz opis kolumn, kontrolę liczby wierszy i listę wyjątków. Jeśli pojawią się dane z nowego tygodnia, pokaż, jak raport rozpoznaje nieznaną kategorię. Ręczna poprawka, o której wie tylko autor, będzie wracała przy każdym urlopie.

Za dowód rozwoju uznaję sytuację, w której umiesz wyjaśnić różnicę między dwoma wynikami i wskazać jej źródło. Pytanie juniora o niejasną definicję jest potrzebną kontrolą. Warto tylko dodać, co już sprawdziłeś i gdzie konkretnie utknąłeś. Samodzielność rośnie dzięki dobrym pytaniom oraz informacji zwrotnej; milczenie nad błędem potrafi jedynie opóźnić jego odkrycie.

Data Analyst: od pytania do uzasadnionego wniosku

W roli analityka interesuje mnie cały przebieg rozumowania. Kto ma podjąć decyzję? Jakich informacji potrzebuje? Co można powiedzieć na podstawie dostępnych danych? Ten zakres może obejmować raportowanie, przygotowanie danych i rozmowy z odbiorcami jednocześnie. Rozdział między raportem a analizą bywa płynny, dlatego patrzę na konkretne zadanie.

W przykładowym sklepie rośnie udział opóźnionych dostaw. Zanim wskażę magazyn jako winnego, sprawdzam definicję opóźnienia, kompletność dat i porównywalność okresów. Potem rozbijam wynik według sposobu dostawy, regionu i rodzaju produktu. Może zmienił się udział zamówień wymagających dłuższej obsługi. Może jeden przewoźnik przesyła daty z opóźnieniem. Wykres ogólny nie rozstrzyga tych możliwości.

Próbką pracy może być krótka notatka z trzema elementami: co widać, jakie wyjaśnienia sprawdzono i czego nadal nie wiemy. Dołącz dane pozwalające odtworzyć wynik. Jeśli rekomendujesz dodatkową kontrolę jednego procesu, wyjaśnij, dlaczego akurat tego. Odbiorca powinien rozumieć, na czym opierasz propozycję i co mogłoby zmienić Twoje zdanie.

Pilnuję też granicy między zależnością a przyczyną. To, że opóźnienia częściej występują w jednym kanale, nie dowodzi, że kanał je powoduje. Bez odpowiedniego projektu badania mogę wskazać hipotezę i następny pomiar. Uczciwie nazwana niepewność pozwala zaplanować dalszą pracę. Udawana pewność dobrze wygląda tylko do pierwszego pytania o szczegóły.

Senior: szerszy zakres i trudniejsze decyzje

Seniority oceniam przez rodzaj problemów, z którymi człowiek potrafi sobie poradzić, oraz sposób wspierania innych. Nie stosuję uniwersalnego przelicznika lat na poziom. Dwa lata regularnego przeglądu cudzych analiz mogą oznaczać inne doświadczenie niż dwa lata powtarzania jednego zestawienia. Potrzebuję przykładów decyzji, a nie samego kalendarza.

W oficjalnym opisie Senior Data Analyst pojawiają się prowadzenie pracy analitycznej, poprawa praktyk i komunikacja z odbiorcami. W moim przykładowym projekcie oznaczałoby to choćby uzgodnienie, jaki poziom pewności wystarcza do pilnej decyzji o dostawach, oraz wskazanie, które wnioski wymagają dodatkowej kontroli.

Senior może zaproponować ograniczony raport na dziś i pełniejsze wyjaśnienie po uzupełnieniu danych. Powinien opisać skutki obu opcji, uzyskać uzgodnienie zakresu i dopilnować dalszej pracy. Heroiczne poprawianie wszystkiego wieczorem nie jest jedyną dostępną metodą. Jeśli proces działa wyłącznie dzięki jednej przemęczonej osobie, warto przyjrzeć się samemu procesowi.

Dowodem gotowości będzie przegląd analizy, po którym zespół rozumie wykryty problem i umie uniknąć go następnym razem. Albo wspólna definicja wskaźnika, którą potrafią stosować dwie osoby. Nie każdy senior zarządza ludźmi, ustala wynagrodzenia czy formalnie deleguje pracę. Takie uprawnienia trzeba ustalić osobno. Rozwój ekspercki może prowadzić do szerszego wpływu bez przechodzenia na stanowisko kierownicze.

Analytics Engineer: dane przygotowane dla innych

Jeśli najbardziej wciąga Cię moment, w którym kilka analiz zaczyna korzystać ze wspólnego, przewidywalnego modelu, sprawdziłbym analytics engineering. Opis tej roli w Government Digital and Data akcentuje przekształcanie danych w struktury użyteczne dla analizy oraz współpracę z ich użytkownikami. Ten nacisk na odbiorcę jest dla mnie ważny.

W naszym przykładzie oddzielne raporty opóźnień mogą powtarzać tę samą logikę. Proponuję wtedy mały model: jedno miejsce definiujące zamówienie, osobne informacje o przesyłkach i jawna reguła liczenia terminu. Trzeba ustalić, co oznacza jeden wiersz. Zamówienie wysłane w dwóch paczkach nie może przypadkiem stać się dwoma zamówieniami w podsumowaniu.

dbt Labs opisuje analytics engineering przez transformacje, testy, dokumentację i praktyki inżynierii oprogramowania. SQL, modelowanie i kontrola zmian mogą więc stanowić rdzeń konkretnej roli. Python bywa przydatny, lecz nie wpisuję go jako obowiązkowego fundamentu każdego stanowiska. Podobnie znajomość dbt nie zastępuje rozumienia modelu. Narzędzie wybieram do zadania i środowiska zespołu.

Dobra próbka pracy powinna pokazać zmianę wymagań. Dodaj do przykładu zamówienie podzielone na przesyłki albo korektę daty i sprawdź, co się zmienia. Opisz oczekiwane wyniki oraz odbiorców zależnych raportów. Test, który wykrywa naruszenie ustalonej reguły, daje więcej informacji niż zielona kontrolka bez wyjaśnienia. Z kolei dokumentacja ma pomóc komuś użyć danych poprawnie, a nie tylko potwierdzić, że dokumentacja istnieje.

Data Architect: konsekwencje decyzji między systemami

Architekturę danych rozumiem jako pracę nad zależnościami i zasadami, które mają przetrwać więcej niż pojedynczy projekt. Oficjalny opis Data Architect obejmuje modele danych, standardy i architekturę technologii danych. Zakres konkretnej roli może dotyczyć części organizacji; nie każdy architekt sam projektuje całą firmę od zera.

Rozszerzmy przykład o drugi system zamówień. Teraz trzeba ustalić, jak rozpoznajemy to samo zamówienie w różnych miejscach, gdzie przechowujemy historię zmian i kto odpowiada za definicje. Do tego dochodzą odbiorcy, którzy potrzebują różnych częstotliwości aktualizacji. Sama lista wybranych usług chmurowych nie odpowie na te pytania. Schemat z prostokątami również może bardzo elegancko ominąć problem.

Jako próbkę pracy przygotowałbym dwa warianty rozwiązania z opisem konsekwencji. Jeden może upraszczać wdrożenie, drugi ułatwiać późniejsze dołączenie kolejnego systemu. Wskazałbym zależności, sposób przejścia i warunki ponownego rozważenia decyzji. Nie trzeba udawać budowy międzynarodowej platformy. Wąski, dobrze uzasadniony projekt pozwala sprawdzić sposób myślenia.

Oceniając gotowość, zapytałbym również o sprzeczne oczekiwania. Co zrobisz, gdy zespół raportowy chce pełnej historii, a system źródłowy jej nie przechowuje? Jak pokażesz ograniczenie i uzgodnisz właściciela dalszej decyzji? Architekt potrzebuje kontaktu z ludźmi wdrażającymi rozwiązanie. Dokument pozostawiony bez rozmowy z tymi osobami może opisywać świat, którego technicznie nie da się zbudować w ustalonym zakresie.

Data Scientist: osobna specjalizacja z własnym warsztatem

Data science ma własne poziomy doświadczenia. W brytyjskim opisie zawodu znajdziesz zarówno role początkujące, jak i bardziej samodzielne, a zakres łączy statystykę, programowanie i komunikację. Dlatego przejścia z analizy do data science nie traktuję jako automatycznego awansu. Można rozwijać się w każdej z tych specjalizacji.

W przykładzie dostaw pojawia się pytanie: czy da się wcześniej wskazać zamówienia zagrożone opóźnieniem? Zanim wybiorę model, ustalam moment prognozy i dostępne wtedy informacje. Data faktycznego doręczenia nie pomoże uczciwie przewidywać opóźnienia przed wysyłką. Trzeba też powiedzieć, kto wykorzysta wynik i jakie działanie będzie mógł podjąć. Sama prognoza nie przesuwa paczki.

W próbce pracy porównałbym model z prostą regułą odniesienia i opisał koszt pomyłek. Sprawdziłbym też przeciek informacji. Dokumentacja scikit-learn wyjaśnia, dlaczego dopasowywanie przekształceń na danych testowych zniekształca ocenę. Podział danych i sposób walidacji muszą odpowiadać zadaniu; przy prognozowaniu kolejnych okresów trzeba uwzględnić czas.

Nie każdy projekt data science kończy się autonomicznym podejmowaniem decyzji. Wynikiem może być badanie, segmentacja albo model wspierający człowieka. Wdrożenie i późniejsze utrzymanie również wymagają uzgodnienia odpowiedzialności. Na rozmowie o rolę zapytałbym o dostęp do danych, sposób oceny modeli i współpracę z inżynierami. Bez tego łatwo pomylić atrakcyjny tytuł z możliwością wykonywania sensownej pracy.

Jak odróżniam zmianę roli od zmiany etykiety

Biorę trzy ogłoszenia dotyczące interesującego mnie kierunku i zaznaczam czasowniki. „Utrzymujesz”, „wyjaśniasz”, „projektujesz”, „uzgadniasz” i „oceniasz” mówią więcej niż długa lista technologii. Następnie wypisuję rezultaty oczekiwane w pierwszych miesiącach. Jeśli ich nie podano, traktuję to jako temat do rozmowy rekrutacyjnej, bez samodzielnego dopowiadania idealnego zakresu.

Sprawdzam też warunki wykonywania pracy. Kto robi przegląd? Czy istnieje środowisko do bezpiecznej nauki? Czy będę utrzymywać gotowe rozwiązanie, czy dopiero tworzyć podstawy? Junior w zespole ze wsparciem i jedyny analityk firmy mają bardzo różne warunki, nawet jeśli oba ogłoszenia używają tego samego słowa. Zakres odpowiedzialności powinien pasować do dostępnej pomocy.

Nie ustawiam automatycznej hierarchii między analitykiem, BI developerem i analytics engineerem. Nazwy częściowo się nakładają, a znaczenie zależy od organizacji. Szerzej rozdzielam te zadania w porównaniu analityka danych, analityka biznesowego i BI developera. W mapie kariery ważniejsze jest dla mnie to, jaki rodzaj problemu chcę rozwiązywać częściej.

Jeśli rozważasz data science, zajrzyj również do porównania Data Analyst i Data Scientist. Zestaw te opisy z własnymi zadaniami. Możesz odkryć, że lubisz eksperymenty, ale utrzymanie modeli już mniej. Albo że największą satysfakcję daje Ci rozmowa, po której zespół wreszcie rozumie wynik. Taka obserwacja jest użyteczniejsza niż wybór najbardziej efektownego tytułu.

Własna mapa: mały projekt i informacja zwrotna

Proponuję ćwiczenie na cztery tygodnie, z czasem dopasowanym do Twoich możliwości. To ramy eksperymentu, bez obietnicy gotowości do nowego zawodu po miesiącu. Wybierz jeden kierunek i mały problem, do którego masz legalny dostęp do danych. Poza firmą użyj danych publicznych lub syntetycznych. Nie potrzebujesz poufnego eksportu, żeby pokazać rozumowanie.

W pierwszym tygodniu opisz rezultat oraz kryterium odbioru. Dla analizy może to być notatka wyjaśniająca dwie możliwe przyczyny zmiany wskaźnika. Dla analytics engineering model, z którego drugi raport korzysta bez kopiowania logiki. Wybierz jedną rzecz. Próba jednoczesnego zostania architektem, statystykiem i mistrzem dashboardów skutecznie utrudnia sprawdzenie postępu.

W drugim tygodniu zbuduj najprostszy wariant i zapisz decyzje. Co przyjąłeś jako założenie? Gdzie potrzebujesz wsparcia? Co odrzuciłeś ze względu na zakres? W trzecim poproś kogoś o próbę użycia rezultatu bez Twojego tłumaczenia przy każdym kroku. Zapisz pytania tej osoby. Jeśli nie rozumie definicji, popraw opis lub model, zamiast dopisywać kolejne dekoracyjne wykresy.

W czwartym tygodniu podsumuj konkrety: co już robisz samodzielnie, co wymaga przeglądu i czego jeszcze nie sprawdzono. Oddziel przyjemność z poznania nowego narzędzia od chęci wykonywania podobnej pracy regularnie. Warto zapytać siebie, czy interesowała Cię również trudna, mniej widowiskowa część zadania. Każda z tych ról ma własny zestaw monotonnych obowiązków.

Z takim materiałem można rozmawiać z przełożonym o małym rozszerzeniu zakresu albo szukać roli, w której dostępne będzie potrzebne wsparcie. Próbka pracy nie gwarantuje awansu ani zatrudnienia. Pozwala za to pokazać coś dokładniejszego niż deklarację „chcę się rozwijać”. Ja od tego zacząłbym rysowanie następnego odcinka swojej mapy.