Co musi umieć analityk danych? 10 kompetencji sprawdzonych na zadaniu

Umiesz Excela, trochę SQL-a, oglądasz kurs Pythona. Do tego co tydzień wpada nowe narzędzie AI. Łatwo dojść do wniosku, że analityk powinien znać wszystko, najlepiej od wczoraj. Ja wolę zadać prostsze pytanie: jaki problem potrafisz już samodzielnie przeprowadzić od niejasnego zlecenia do sprawdzonej odpowiedzi?

Moje zestawienie obejmuje pięć kompetencji technicznych i pięć związanych ze sposobem pracy. Zachowuję perspektywę artykułu z 2026 roku, ale nie przedstawiam tej listy jako badania wszystkich ogłoszeń. Wymagania zależą od roli, firmy i poziomu odpowiedzialności. Fundamenty można ćwiczyć długo po tym, jak ucichnie szum wokół kolejnej premiery modelu.

Zaczynałem w customer service, później pracowałem z analizą i architekturą danych. Dlatego interesuje mnie połączenie narzędzi z realnym procesem. Kurs pomaga poznać przyciski i składnię. Dopiero zadanie pokazuje, czy rozumiesz wynik, zauważasz błąd i umiesz powiedzieć komuś, co dalej. Poniżej proponuję takie zadanie. Wszystkie dane i sytuacje w ćwiczeniu są syntetyczne.

Jeden projekt, na którym widać warsztat

Wyobraź sobie, że osoba koordynująca obsługę zgłoszeń chce sprawdzić zaległości. Dostajesz migawkę sześciu spraw przyjętych w jednym tygodniu, ze stanem na poniedziałek o 9:00 w strefie Europe/Warsaw. Jedna sprawa należy do jednego zespołu. W tym uproszczeniu dozwolone są dwa statusy: open i closed. Nie ma brakujących ani powtórzonych identyfikatorów.

Dodatkowy słownik przypisuje identyfikatorom A i B nazwy Alpha i Beta. Zespół Alpha ma dwie zamknięte sprawy na trzy, czyli około 66,7%. Beta ma jedną na trzy, czyli około 33,3%. Łącznie zamknięto trzy z sześciu spraw, a więc 50%. To udziały w wybranej grupie zgłoszeń według stanu z migawki. Nie są oceną produktywności ani dotrzymania terminu.

Nie znamy jeszcze wieku spraw, trudności, obsady zespołów i uzgodnionych terminów. Trzy otwarte zgłoszenia mogą być świeże. Mogą też czekać od dawna na odpowiedź klienta. Wynik ma pomóc zadać następne pytanie. Z sześciu wierszy nie wyprodukujesz uczciwego rankingu pracowników, nawet jeśli dashboard ma bardzo poważny granatowy nagłówek.

Efektem projektu ma być mały pakiet: opis pytania, dane wejściowe, sposób obliczenia, sprawdzenie wyniku, wykres i krótka rekomendacja. Możesz zacząć w arkuszu i dopiero później odtworzyć obliczenia w SQL-u lub Pythonie. Kolejne kompetencje oceniam przez to, co wnoszą do tego samego pakietu.

1. Excel: szybko sprawdzić, co właściwie liczę

Excel jest dla mnie dobrym miejscem na pierwszy szkic. W tym zadaniu zacząłbym od tabeli z jednym wierszem na zgłoszenie, jednoznacznymi nagłówkami i filtrem. Obok umieściłbym prosty słownik statusów. Oddzieliłbym surową próbkę od wyniku, żeby poprawianie prezentacji nie zmieniało przypadkiem danych wejściowych.

W tabeli przestawnej ustaw zespoły jako wiersze, status jako kolumny i licznik identyfikatorów jako wartości. Sprawdź sposób agregacji: suma numerów zgłoszeń jest tutaj bezużyteczna. Po dopisaniu wierszy odśwież wynik i upewnij się, że źródło je obejmuje. Mechanizm opisuje dokumentacja tabel przestawnych Microsoftu.

Na poziomie junior chciałbym zobaczyć, że umiesz odtworzyć wynik ręcznie i wyjaśnić każdą kolumnę. Dodaj testowe siódme zgłoszenie jako otwarte dla Alpha. Licznik zamkniętych pozostanie równy dwa, a mianownik wzrośnie do czterech. Jeżeli raport nadal pokazuje 66,7%, szukaj problemu w zakresie danych albo odświeżeniu.

To także ćwiczenie przekazywania pliku. Nazwa arkusza „ostateczne_final2” nie zastępuje opisu. Dopisz moment migawki, zastosowany filtr i instrukcję aktualizacji. Osoba otwierająca plik za tydzień powinna rozumieć, gdzie wkleić dane i które komórki zawierają wynik. Więcej o takim podejściu opisuję w tekście o Excelu w pracy analityka.

2. Zadawanie pytań: ustalić decyzję przed raportem

Zlecenie „pokaż zaległości” zostawia sporo miejsca na interpretację. Zapytałbym najpierw, jaka decyzja ma zapaść po analizie. Czy koordynator chce przydzielić wsparcie na dzisiaj, znaleźć problem procesu, czy przygotować podsumowanie tygodnia? Każda z tych potrzeb wymaga trochę innych danych i innego horyzontu.

Następnie uzgodniłbym znaczenie otwartej sprawy. Czy czekanie na klienta liczy się do zaległości? Czy ponowne otwarcie zmienia poprzedni wynik? Czy patrzymy na zgłoszenia przyjęte w tygodniu, czy wszystkie otwarte w danym momencie? W naszym przykładzie wybraliśmy pierwszą grupę. Starsze zgłoszenia pozostają poza nią, więc wynik nie opisuje całego obciążenia działu.

Nie musisz prowadzić godzinnego przesłuchania. Przygotuj trzy najważniejsze pytania i zapisz uzgodnienia w kilku zdaniach. Jeżeli rozmówca nie zna odpowiedzi, pokaż dwie możliwe definicje wraz z ich konsekwencjami. To pomaga podjąć decyzję bez przerzucania na niego całego problemu analitycznego.

Dowodem umiejętności będzie krótki brief, na podstawie którego druga osoba potrafi wskazać potrzebne rekordy. W portfolio możesz opisać założenia sam, jasno zaznaczając, że są częścią ćwiczenia. Nie dopisuj fikcyjnego spotkania z zarządem, żeby projekt brzmiał bardziej zawodowo.

3. SQL: pilnować znaczenia jednego wiersza

W SQL-u zacząłbym od filtrowania, grupowania i złączeń. Dopiero kiedy ten fundament działa, dokładałbym funkcje okna czy bardziej złożone konstrukcje. Liczba użytych CTE nie jest miarą jakości analizy. Najpierw chcę wiedzieć, czy jeden wiersz po złączeniu nadal oznacza jedno zgłoszenie.

Załóżmy, że do sześciu spraw dołączasz tabelę zdarzeń. Pierwsza sprawa ma dwa zdarzenia, a każda z pozostałych po jednym. Proste złączenie da siedem wierszy. Jeśli policzysz zamknięte sprawy przez sumowanie znacznika po tym złączeniu, dostaniesz cztery zamiast trzech. Pierwsza, zamknięta sprawa została policzona dwukrotnie. Taką semantykę dopasowań opisuje dokumentacja złączeń PostgreSQL.

Wybór naprawy zależy od pytania. Możesz wcześniej sprowadzić zdarzenia do jednego wiersza na sprawę albo sprawdzać tylko istnienie odpowiedniego zdarzenia. Samo dodanie DISTINCT do całego wyniku nie wyjaśnia, które dane chciałeś zachować. Dwa zdarzenia z różnymi datami nadal będą różnymi wierszami.

W ćwiczeniu zapisałbym liczbę zgłoszeń przed i po każdym kroku. Porównałbym również identyfikatory, które zniknęły. Junior nie musi znać każdej optymalizacji, ale powinien umieć wykryć, że wynik przypadkiem urósł. Następny krok to ćwiczenia ze złączeniami SQL.

4. Rozumienie biznesu: odróżnić wskaźnik od oceny

Wynik Alpha wygląda lepiej, dopóki nie zapytasz o rodzaje spraw. Być może ten zespół obsługuje proste zmiany danych, a Beta trudne reklamacje. To hipoteza do sprawdzenia. Na podstawie samej tabeli nie wiemy, czy różnica pochodzi z organizacji pracy, trudności zgłoszeń, czasu ich przyjęcia czy zwykłego przypadku.

Dla decyzji o wsparciu potrzebowałbym przynajmniej wieku otwartych spraw, priorytetu i informacji o oczekiwaniu na inne osoby. Dla oceny terminowości potrzebny byłby termin dla każdej sprawy. Odsetek zamkniętych zgłoszeń oraz odsetek zgłoszeń zamkniętych w terminie odpowiadają na inne pytania. Nie zmieniałbym etykiety wskaźnika tylko dlatego, że brakuje danych do właściwego obliczenia.

Rozumienie procesu sprawdzisz, zapisując drogę jednej sprawy od przyjęcia do zakończenia. Wskaż, kto może zmienić status i co ta zmiana oznacza. Zastanów się też, czy sam wskaźnik nie zachęca do zamykania prostych spraw kosztem trudniejszych. Takie pytanie można postawić bez twierdzenia, że ktoś rzeczywiście tak robi.

Moja rekomendacja dla ćwiczenia byłaby skromna: przejrzeć trzy otwarte sprawy i uzupełnić informacje potrzebne do decyzji o wsparciu. Rankingu zespołów na tej podstawie bym nie publikował. To ograniczenie jest częścią wyniku, a nie przyznaniem się do porażki.

5. Wizualizacja: pokazać wynik razem z kontekstem

Do tej próbki wystarczy tabela albo dwa słupki liczby otwartych spraw: jeden dla Alpha, dwa dla Beta. Tytuł powinien mówić o zgłoszeniach z wybranego tygodnia i stanie na konkretny moment. Obok pokaż liczebność grup. Sam procent łatwo wygląda imponująco, kiedy odbiorca nie widzi, że stoi za nim kilka obserwacji.

Narzędzie dobierz do środowiska, w którym ma działać raport. Power BI, Tableau czy arkusz mogą wystarczyć do tego projektu. Nie wyciągałbym z własnej preferencji wniosku o dominacji rynkowej jednego produktu. Przy nauce lepiej rozumieć relację między danymi, filtrem i wynikiem, niż kolekcjonować zrzuty ekranów z kolejnych aplikacji.

Jeżeli budujesz model Power BI, oddziel zgłoszenia od słownika zespołów i ustal relację po identyfikatorze. Microsoft w przewodniku modelowania podkreśla znaczenie spójnego poziomu szczegółowości tabel faktów. W tym zadaniu jest nim pojedyncze zgłoszenie. Każdy dodatkowy zbiór trzeba ocenić pod kątem tego poziomu.

Sprawdzenie wizualizacji zrobiłbym z drugą osobą. Daj jej minutę i poproś o powiedzenie, co wynika z wykresu oraz czego z niego nie wiadomo. Jeśli odczyta „Beta pracuje dwa razy gorzej”, popraw tytuł, kontekst lub sam wybór prezentacji. Efektowny raport, który prowadzi do błędnej decyzji, wymaga poprawki.

6. Prosty język: zostawić odbiorcy użyteczną wiadomość

Spróbuj opisać wynik w trzech zdaniach. „W grupie sześciu zgłoszeń przyjętych w badanym tygodniu trzy pozostają otwarte w poniedziałkowej migawce. Jedno należy do Alpha, dwa do Beta. Przed przydzieleniem wsparcia sprawdźmy ich wiek, trudność i termin, bo obecny wyciąg tych informacji nie zawiera”.

W tej wiadomości masz obserwację, ograniczenie i następny krok. Nie trzeba do niej dopisywać słów takich jak „synergia” czy „optymalizacja ekosystemu”. Potrzebny jest za to kontakt do osoby, która może uzupełnić dane, oraz termin, jeśli decyzja ma zapaść dzisiaj. W projekcie syntetycznym zaznacz, że role są umowne.

Prosty język wymaga zachowania precyzji. Zdanie „połowa zgłoszeń jest zaległa” byłoby krótsze, ale w naszym przykładzie nie znamy terminów. Otwarte nie musi znaczyć spóźnione. To drobna zmiana słowa, która może całkowicie zmienić odbiór pracy zespołu.

Ćwicz również odpowiedź na pytanie „skąd ta liczba?”. Powinieneś umieć przejść od zdania do tabeli, a z tabeli do trzech konkretnych rekordów. Jeżeli cały wywód opiera się na pamięci autora, dołóż ślad obliczeń. Taka sprawdzalność przydaje się bardziej niż bardzo pewny ton prezentacji.

7. Python: odtworzyć obliczenie i zatrzymać błędne dane

Pythona rozwijałbym tam, gdzie pojawia się powtarzalne przetwarzanie. W tym małym zadaniu nie daje przewagi skali, ale pozwala pokazać czytelny przebieg obliczenia i kontrolę wejścia. Poniższy przykład wymaga pandas. Uruchom go jako całość; sam tworzy syntetyczne dane, więc nie potrzebujesz pliku z firmy.

import pandas as pd

tickets = pd.DataFrame(
    [(1, "A", "closed"), (2, "A", "closed"), (3, "A", "open"),
     (4, "B", "closed"), (5, "B", "open"), (6, "B", "open")],
    columns=["ticket_id", "team_id", "status"],
)
teams = pd.DataFrame(
    [("A", "Alpha"), ("B", "Beta")],
    columns=["team_id", "team"],
)

def summarize(tickets, teams):
    if tickets.empty:
        raise ValueError("No tickets in the selected snapshot")
    if tickets.isna().any().any() or teams.isna().any().any():
        raise ValueError("Missing input value")
    if tickets["ticket_id"].duplicated().any():
        raise ValueError("Duplicate ticket_id")
    if not tickets["status"].isin(["open", "closed"]).all():
        raise ValueError("Unknown status")
    joined = tickets.merge(
        teams, on="team_id", how="left",
        validate="many_to_one", indicator=True,
    )
    if not joined["_merge"].eq("both").all():
        raise ValueError("Unknown team_id")
    result = (
        joined.assign(closed=joined["status"].eq("closed"))
        .groupby(["team_id", "team"], as_index=False)
        .agg(tickets=("ticket_id", "size"), closed=("closed", "sum"))
    )
    result["closed_pct"] = (100 * result["closed"] / result["tickets"]).round(1)
    return result

print(summarize(tickets, teams).to_string(index=False))

Wynik dla Alpha to trzy zgłoszenia, dwa zamknięte i 66,7%; dla Beta trzy, jedno i 33,3%. W wydruku Python użyje kropki dziesiętnej. Parametr validate="many_to_one" sprawdza unikalność klucza w słowniku po prawej stronie, a indicator pozwala wykryć brak dopasowania. Szczegóły opisuje dokumentacja pandas.

Pusty zbiór celowo kończy się komunikatem. Nie chcę udawać, że brak zgłoszeń oznacza zerową skuteczność. Kod odrzuca też nieznane statusy zamiast traktować je automatycznie jako otwarte. To decyzje dla tego ćwiczenia; w produkcji wymagają uzgodnienia oraz obsługi błędu przez proces uruchamiający raport.

Teraz popsuj wejście. Powiel identyfikator, dodaj nieznany zespół i usuń status. Sprawdź także wszystkie sprawy otwarte oraz wszystkie zamknięte. Dobry wynik pojedynczego uruchomienia jest początkiem. Chcę wiedzieć, czy rozumiesz, na jakich założeniach działa program i co się dzieje po ich naruszeniu.

8. Samodzielność: wiedzieć, kiedy poprosić o pomoc

Samodzielność mierzyłbym jakością następnego kroku po napotkaniu problemu. Jeśli zgłoszenie ma nieznany zespół, możesz sprawdzić źródło słownika, datę eksportu i inne rekordy z tym samym identyfikatorem. Zapisz, co ustaliłeś. Nie dopisuj wymyślonej nazwy, żeby kontrola przestała zgłaszać błąd.

Dobra prośba o pomoc może brzmieć: „Dwa rekordy mają zespół C, którego nie ma w przekazanym słowniku. Sprawdziłem oba pliki i ich daty. Potrzebuję aktualnego mapowania albo potwierdzenia, że te rekordy mają zostać osobno oznaczone”. Odbiorca widzi problem i decyzję, którą może podjąć. Nie musi zgadywać, co kryje się za komunikatem „raport nie działa”.

Ustal sobie rozsądny czas na samodzielne poszukiwania, zależny od pilności. Godzina śledztwa w sprawie przecinka może być gorszym wyborem niż krótkie pytanie. Z kolei ciągłe proszenie o kolejne kliknięcie blokuje naukę. W ćwiczeniu zapisz, gdzie utknąłeś, czego spróbowałeś i co ostatecznie rozwiązało problem.

Granica kompetencji też jest informacją. Junior powinien zgłaszać niejasną definicję oraz ryzyko błędnej decyzji. Udawanie pewności przesuwa problem na odbiorcę raportu. Samodzielny wynik ma być możliwy do sprawdzenia przez kogoś innego.

9. AI: sprawdzać podpowiedź na znanym wyniku

AI wykorzystałbym w tym projekcie do zaproponowania przypadków brzegowych, wyjaśnienia błędu albo porównania dwóch wersji opisu. Przekazałbym syntetyczną próbkę, definicję wskaźnika i oczekiwany rezultat. Taki kontekst daje mi również punkt odniesienia do oceny odpowiedzi. Łatwiej zauważyć błąd, kiedy znam wynik małego przykładu.

Poproś model o kontrolę kodu, a potem sprawdź każdą istotną sugestię. Może zaproponować usuwanie duplikatów bez wyjaśnienia ich przyczyny albo zastąpienie braku zerem. W obu sytuacjach trzeba wrócić do znaczenia danych. Elegancko wyglądająca poprawka nie zwalnia z decyzji, czy jest właściwa dla danego procesu.

Na poziomie junior bardziej interesuje mnie umiejętność zweryfikowania odpowiedzi niż deklaracja znajomości wielu modeli. Zaawansowane systemy wyszukiwania wiedzy czy automatyczni agenci mogą być dalszym kierunkiem, jeśli wymaga ich rola. Nie robiłbym z nich warunku rozpoczęcia każdego pierwszego projektu analitycznego.

Do portfolio dołącz krótką notatkę: w czym pomogło AI, co sprawdziłeś sam i którą sugestię odrzuciłeś wraz z powodem. W pracy korzystaj z narzędzi i zakresu danych dopuszczonych przez firmę. W naszym ćwiczeniu nie ma potrzeby sięgania po prawdziwe zgłoszenia ani dane klientów.

10. Uczenie się: wybrać lukę, którą widać w projekcie

Po wykonaniu zadania wybierz jeden problem do dalszego ćwiczenia. Jeśli pomyliłeś mianownik, następny kurs o wizualizacji raczej tego nie naprawi. Jeżeli obliczenie jest poprawne, ale nie umiesz wyjaśnić ograniczeń, warto popracować nad opisem wyniku i rozmową z odbiorcą. Plan nauki powinien wynikać z obserwacji własnej pracy.

Proponuję trzy krótkie sesje. W pierwszej odtwórz przykład bez podglądania rozwiązania. W drugiej zmień warunek, na przykład dodaj nowy zespół albo pustą próbkę. W trzeciej pokaż projekt komuś i zapisz pytania, na które nie potrafiłeś odpowiedzieć. Potem popraw dokładnie tę część. To propozycja organizacji ćwiczeń, bez obietnicy konkretnego tempa kariery.

Zostaw miejsce na odpoczynek i zwykłe obowiązki. Plan, który wymaga codziennie kilku godzin pełnej koncentracji po pracy, może po prostu nie pasować do Twojego życia. Wolałbym mniejszy projekt z zakończonym sprawdzeniem niż ambitny harmonogram z dziesięcioma rozpoczętymi kursami i żadnym wynikiem do pokazania.

W moim arkuszu samooceny byłyby trzy oznaczenia: „robię sam”, „robię z pomocą”, „jeszcze nie umiem”. Przy każdym dopisałbym dowód z projektu. Bez średniej punktowej sugerującej, że dobry wykres rekompensuje błędne liczenie. Jeżeli kluczowy wynik jest niepoprawny, najpierw wracam do obliczenia.

Co pokazać na koniec

Gotowy projekt powinien pozwalać drugiej osobie odtworzyć liczby bez Twojego udziału. Dołącz instrukcję uruchomienia, wersję użytej biblioteki, definicję grupy zgłoszeń i moment migawki. Zachowaj dane syntetyczne oraz listę kontroli. Osobno zapisz, czego nie da się ustalić na podstawie próbki i jakich informacji potrzebowałbyś dalej.

Poproś kogoś, żeby zmienił jedno zgłoszenie z otwartego na zamknięte i sprawdził, czy wynik reaguje zgodnie z oczekiwaniem. Następnie niech wskaże zdanie, które uważa za najważniejszy wniosek. W ten sposób oceniasz zarówno techniczną część, jak i komunikację. Nie potrzebujesz do tego fikcyjnej historii o wdrożeniu w wielkiej firmie.

Taki pakiet daje konkretny materiał do rozmowy o rozwoju. Możesz pokazać błąd, sposób jego znalezienia i poprawkę. Ja właśnie od tego zaczynałbym ocenę kompetencji: czy umiesz wyjaśnić, co zrobiłeś, sprawdzić wynik i świadomie wyznaczyć granicę odpowiedzi. Następne narzędzie dobierzesz do problemu, który rzeczywiście pojawi się na tej drodze.