Analityk danych czy programista? Jak sprawdzić, która praca Ci pasuje

Gdy ktoś pyta mnie, czy zostać analitykiem danych, czy programistą, chcę najpierw wiedzieć, co kryje się za tym wyborem. Czasem chodzi o zainteresowanie technologią. Czasem o zmianę branży, pracę zdalną albo ucieczkę od obecnych obowiązków. Każdy z tych powodów prowadzi do trochę innych pytań.

Nie wybierałbym zawodu wyłącznie na podstawie tego, która lista narzędzi wygląda krócej. Excel może wydawać się znajomy, a edytor kodu obcy, ale trudność pracy szybko wychodzi poza obsługę programu. W obu rolach trzeba zrozumieć problem, sprawdzić rezultat i porozumieć się z osobą, która będzie z niego korzystała.

Patrzę na ten wybór z perspektywy analityka. Chcę jednak uczciwie pokazać obie drogi, bez obietnicy łatwego wejścia do IT. Najbardziej pomaga mi porównanie konkretnych zadań. Dlatego oprócz różnic proponuję dwa krótkie eksperymenty, które możesz wykonać przed podjęciem większej decyzji.

Film z 2025 roku i aktualizacja tekstu

Poniższy film KajoData jest materiałem towarzyszącym pierwotnemu artykułowi. Jego tytuł odnosi się do roku 2025. Tekst aktualizuję w październiku 2026 i ostrożniej formułuję wcześniejsze oceny łatwości wejścia do zawodu oraz wpływu AI. Film pozostaje zapisem wcześniejszego kontekstu, a nie aktualnym raportem rynku pracy.

Najpierw porównuję rezultat pracy

Wyobraź sobie firmę, która dostarcza zamówienia z opóźnieniem. Analityk może dostać pytanie: gdzie pojawia się problem, jak często występuje i co warto sprawdzić dalej? Efektem pracy będzie uzgodniona definicja opóźnienia, sprawdzone obliczenia oraz wnioski z określonymi ograniczeniami.

Programista może dostać zadanie zbudowania narzędzia, które oznacza opóźnione przesyłki i pokazuje je pracownikowi obsługi. Efektem będzie działająca funkcja lub aplikacja, jej testy, obsługa błędnych danych i sposób utrzymania. Obie osoby pracują nad tym samym procesem, ale dostarczają inny rodzaj rezultatu.

To celowo uproszczony przykład. Analityk może programować, a programista analizować dane. W małym zespole jedna osoba może wykonywać oba zadania. Pomaga mi więc pytanie o to, za co konkretnie odpowiadam, a nie o to, czy w ciągu dnia otwieram Pythona albo arkusz kalkulacyjny.

Jako punkt odniesienia wykorzystuję opisy analityków BI i twórców oprogramowania w O*NET. To amerykańska klasyfikacja zadań, nie opis każdej polskiej oferty ani prognoza Twoich szans na zatrudnienie. Dobrze pokazuje jednak, że obie role obejmują współpracę, dokumentowanie i sprawdzanie rozwiązań.

Co robię jako analityk, zanim powstanie wykres

W przykładzie z dostawami najpierw pytam, co oznacza opóźnienie. Czy porównujemy datę obiecaną klientowi z datą doręczenia? Czy uwzględniamy weekendy? Co z zamówieniem, którego jeszcze nie doręczono? Bez tych odpowiedzi można stworzyć kilka poprawnych technicznie raportów, które pokażą różne liczby.

Następnie sprawdzam źródła, brakujące wartości i poziom szczegółowości. Jeden rekord może oznaczać zamówienie, paczkę albo zmianę statusu. Jeżeli pomylę te poziomy, policzę jedno zamówienie kilka razy. Dopiero po takim rozpoznaniu wybieram narzędzie, piszę zapytanie i przygotowuję prezentację wyniku.

Ważna część pracy zaczyna się po pierwszym wykresie. Ktoś pyta, dlaczego wynik nie zgadza się z jego raportem. Wtedy potrzebuję cierpliwości, umiejętności odtworzenia obliczenia i gotowości do zmiany założeń. Jeżeli interesuje Cię właśnie ustalanie, skąd bierze się rozbieżność, to dobry temat do własnego eksperymentu analitycznego.

Co programista robi poza pisaniem nowego kodu

W zadaniu z oznaczaniem przesyłek najpierw trzeba ustalić oczekiwane zachowanie. Co aplikacja pokaże przy brakującej dacie? Kiedy odświeży status? Co się stanie, gdy źródło chwilowo nie odpowiada? Takie pytania wpływają na konstrukcję rozwiązania, a później na to, czy użytkownik może na nim polegać.

Pisanie kodu obejmuje również czytanie istniejącego rozwiązania, szukanie przyczyny błędu, przegląd zmian i sprawdzanie zgodności z pozostałymi częściami systemu. Mała funkcja może być łatwa do napisania od zera, a trudniejsza do bezpiecznego włączenia w działającą aplikację. Dlatego przy ocenie zawodu nie zatrzymuję się na pierwszym udanym samouczku.

Programowanie może pasować osobie, którą cieszy budowanie przewidywalnego mechanizmu i dopracowywanie jego zachowania. Nie oznacza to automatycznie mniejszej liczby rozmów. Uzgodnienie wymagań albo wyjaśnienie kompromisu technicznego potrafi zająć więcej uwagi niż sama zmiana kilku linijek. Warto sprawdzić, czy lubisz także ten fragment pracy.

Doświadczenie z poprzedniej branży pomaga w obu rolach

Nie zgadzam się z tezą, że osoba zmieniająca branżę zawsze zaczyna programowanie od zera, a w analityce od razu ma przewagę. Kompetencje trzeba rozłożyć na części. Znajomość logistyki nie zastąpi nauki języka programowania, ale pomaga zauważyć, że dostawa może składać się z kilku paczek i mieć kilka terminów.

Ta sama wiedza przydaje się analitykowi przy definiowaniu wskaźnika i programiście przy modelowaniu danych. Osoba z obsługi klienta może dobrze rozpoznawać niejasne komunikaty błędów. Ktoś z operacji może rozumieć zależności między etapami procesu. Nauczyciel może umieć wyjaśniać złożone zagadnienia oraz przygotowywać instrukcje dla użytkowników.

Zapisuję więc konkret: jaki problem rozumiem lepiej dzięki poprzedniej pracy i jak pokażę to w projekcie? Samo zdanie „mam kompetencje miękkie” niewiele mówi. Przykład uporządkowania wymagań, znalezienia źródła błędów lub wyjaśnienia decyzji daje rozmówcy materiał do oceny. Więcej o takim przełożeniu piszę w tekście o humaniście w analizie danych.

Nauka zaczyna się od małego zakresu

Dla pierwszego projektu analitycznego wybrałbym arkusz albo SQL, podstawowe operacje na danych i prosty sposób pokazania wyniku. Nie potrzebuję od razu całego zestawu narzędzi z każdej oferty. Potrzebuję umieć wyjaśnić filtr, grupowanie, brak danych i ograniczenie własnego wniosku. Dopiero następne zadanie pokaże, czego brakuje.

Dla pierwszego programu wybrałbym jeden język, podstawowe struktury danych, warunki, funkcje i testowanie kilku zachowań. Jeżeli zaczynasz od Pythona, możesz skorzystać z mojego tekstu o zmiennych, typach i operatorach. Na początek wystarczy program uruchamiany lokalnie, bez kont użytkowników, płatności i rozbudowanego wdrożenia.

W obu przypadkach ważniejsza jest pętla pracy: próbuję, obserwuję rezultat, sprawdzam go i poprawiam. Samo oglądanie kolejnych lekcji daje znajomość słów, ale nie mówi jeszcze, jak reaguję na problem bez gotowego rozwiązania. Chcę doprowadzić niewielkie zadanie do końca, zanim rozbuduję plan nauki na kilka miesięcy.

Eksperyment pierwszy: przeanalizuj sześć dostaw

Przygotowałem syntetyczne dane, które możesz przepisać do arkusza. Obiecany i rzeczywisty czas oznaczają tutaj całkowitą liczbę dni liczonych w ten sam sposób. Wszystkie dostawy są zakończone. W ćwiczeniu dostawa jest spóźniona wtedy, gdy rzeczywisty czas przekracza obiecany.

Zarezerwuj na pierwszą próbę około półtorej godziny. To moja propozycja ograniczenia zakresu, nie obietnica, że każdy początkujący skończy w tym czasie. Policz spóźnione dostawy ogółem i w każdym kanale. Napisz trzy zdania dla osoby odpowiedzialnej za proces: wynik, ograniczenie i następne pytanie.

Oczekiwany rezultat to trzy opóźnienia na sześć dostaw, czyli 50%. W sklepie są dwa na trzy, a u partnera jedno na trzy. Nie wyciągam z tego wniosku, że kanał sprzedaży powoduje opóźnienia. To mały wymyślony zbiór, a inne czynniki nie zostały opisane. Sensownym następnym krokiem byłoby sprawdzenie porównywalnych okresów, produktów i sposobów dostawy.

Na koniec dodaj wiersz bez rzeczywistego czasu. Zatrzymaj się i opisz, czy to brak danych, czy niezakończona dostawa. Nie wciskaj automatycznie zera. Właśnie rozmowa o znaczeniu takiego rekordu jest częścią analizy. Zwróć uwagę, czy ten rodzaj niejasności budzi Twoją ciekawość, czy tylko chcesz jak najszybciej go ominąć.

Eksperyment drugi: zbuduj mały klasyfikator

Na tych samych zasadach przygotuj funkcję przyjmującą obiecany i rzeczywisty czas dostawy. Ma zwracać jeden z trzech komunikatów: „na czas”, „opóźniona” albo „brak danych”. Ustal, że brak rzeczywistego czasu daje trzeci komunikat, a ujemna liczba dni jest błędnym wejściem wymagającym odrzucenia.

Możesz wybrać język, którego właśnie się uczysz. Nie potrzebujesz ekranu logowania ani bazy produkcyjnej. Wystarczy funkcja i kilka wywołań. Dla pary 2 i 3 oczekuj opóźnienia, dla 2 i 2 terminowości, dla 3 i 2 również terminowości. Dla braku rzeczywistej wartości oczekuj komunikatu o braku, a dla wartości ujemnej czytelnego błędu.

Następnie poproś inną osobę, żeby uruchomiła program według Twojej instrukcji, albo spróbuj odtworzyć uruchomienie następnego dnia bez własnych skrótów myślowych. Sprawdź, czy opis wejścia jest jasny, wyniki powtarzalne, a błąd zrozumiały. To mały fragment odpowiedzialności za rozwiązanie używane przez kogoś poza jego autorem.

Także tutaj możesz przyjąć półtorej godziny na pierwszą próbę i zapisać, co zostało niedokończone. Nie porównuj zawodów wyłącznie po szybkości. Jeśli znasz już arkusz, a pierwszy raz instalujesz środowisko programistyczne, różnica czasu mówi głównie o punkcie startu. Powtórz zadanie po oswojeniu narzędzia, zanim wydasz sobie zawodowy wyrok.

Jak porównuję wrażenia po obu próbach

Po każdym zadaniu zapisuję, który moment najbardziej mnie wciągnął. Czy chciałem rozbić wynik na kolejne grupy i ustalić, czego jeszcze nie wiem? Czy wolałem poprawić zachowanie funkcji, uporządkować kod i dodać przypadek testowy? Obie odpowiedzi są użyteczne, a zainteresowanie jednym zadaniem nie zamyka drugiej drogi.

Zapisuję też rodzaj trudności. Brak znajomości składni można odróżnić od niechęci do samego problemu. Frustracja przy instalacji programu nie dowodzi, że nie nadajesz się do programowania. Podobnie zachwyt pierwszym wykresem nie przesądza, że spodoba Ci się codzienne ustalanie definicji danych i uzgadnianie rozbieżnych raportów.

Nie stosuję punktacji, która po kilku odpowiedziach ogłasza zawód na całe życie. Traktuję te ćwiczenia jako sposób zebrania informacji o sobie. Następna próba powinna być trochę bliższa rzeczywistej pracy: cudzy zbiór z opisanymi brakami albo mała poprawka w istniejącym programie. Tam pojawia się konieczność czytania, zadawania pytań i rozumienia cudzych decyzji.

Komunikacja dotyczy obu ścieżek

Analityk wyjaśnia znaczenie wyniku, a programista zachowanie rozwiązania. Obaj potrzebują umieć przyznać, czego jeszcze nie sprawdzili. Można to zrobić na spotkaniu, w komentarzu do zadania albo w krótkiej dokumentacji. Nie utożsamiam dobrej komunikacji z byciem najgłośniejszą osobą w pokoju.

Przy analizie dostaw przydatny komunikat brzmi: „W tych sześciu rekordach połowa dostaw jest opóźniona; brakuje danych, żeby ocenić przyczynę”. Przy programie: „Funkcja rozróżnia brak czasu od zera; nie obsługuje jeszcze dat kalendarzowych”. Oba zdania pomagają odbiorcy zrozumieć granice rozwiązania i podjąć kolejną decyzję.

Jeżeli zależy Ci na spokojnej pracy, pytaj o sposób organizacji zespołu. Liczba spotkań, jakość dokumentacji, możliwość przygotowania odpowiedzi i zakres kontaktu z klientem mogą różnić się znacznie między firmami. Sama nazwa zawodu nie mówi, jak będzie wyglądał Twój wtorek ani ile czasu zostanie na skupienie.

AI zmienia zadania, ale nie daje gwarancji zatrudnienia

Nie traktuję analityki jako zawodu odpornego na AI ani programowania jako zawodu skazanego na zniknięcie. Zdolność narzędzia do wygenerowania kodu lub wykresu nie wystarcza do przewidzenia liczby stanowisk. Znaczenie mają organizacja pracy, jakość danych, odpowiedzialność, koszty oraz decyzje konkretnych firm.

W moich ćwiczeniach AI może pomóc wyjaśnić błąd, zaproponować zapytanie lub przygotować testy. Nadal sprawdzam, czy użyła właściwej definicji opóźnienia i nie zamieniła braku danych na zero. Dokumentacja GitHub Copilot również wskazuje potrzebę przeglądu i testowania sugestii. To opis ograniczeń narzędzia, nie badanie przyszłości zawodów.

Podczas nauki zapisuję, z jakiej pomocy skorzystałem i co umiem wyjaśnić samodzielnie. Jeżeli nie potrafię przewidzieć wyniku dla prostego przypadku, wracam do podstaw. Gotowe rozwiązanie może przyspieszyć pracę, ale w portfolio chcę pokazać także sposób sprawdzenia, decyzje i poprawki. Dzięki temu rozmowa dotyczy mojego rozumienia problemu.

Oferty czytam przez obowiązki i warunki

Zamiast porównywać ogólne hasła o popycie, wybieram niewielką próbkę aktualnych ofert z rynku, na którym rzeczywiście mogę pracować. Zapisuję lokalizację, poziom doświadczenia, obowiązki, wymagane narzędzia, język i sposób pracy. Oddzielam wymóg konieczny od umiejętności mile widzianej. Sprawdzam daty i unikam liczenia tej samej oferty kilka razy.

Nazwy potrafią być mylące. Stanowisko analityczne może skupiać się na raportowaniu, eksperymentach produktowych albo utrzymaniu modeli danych. Programista może budować interfejs, integracje lub narzędzia wewnętrzne. Chcę porównać konkretne rodzaje pracy, a nie wrzucić wszystkie warianty do dwóch wielkich worków.

Nie podaję tutaj rankingu wynagrodzeń ani procentowej szansy na zatrudnienie. Bez określenia kraju, poziomu, umowy i okresu takie porównanie byłoby pozornie precyzyjne. Twoją decyzję lepiej oprzeć na wymaganiach dostępnych ról, własnych ograniczeniach czasowych i dowodach umiejętności, które możesz przygotować. Plan poszukiwań rozwijam w tekście o strategii przebranżowienia.

Wybieram następny etap, nie etykietę na zawsze

Po ćwiczeniach wybieram jeden kierunek na najbliższy projekt. Określam rezultat, ograniczony zakres i sposób sprawdzenia. Dla analizy może to być krótki raport z uzgodnioną miarą oraz kontrolą jakości danych. Dla programowania małe narzędzie z instrukcją uruchomienia, obsługą błędów i testami najważniejszych zachowań.

Ustalam też moment powrotu do decyzji. Po ukończeniu projektu oceniam, czego się nauczyłem, co nadal mnie interesuje i jak rezultat pasuje do sprawdzonych ofert. Dzięki temu nie muszę co tydzień zmieniać planu pod wpływem nowego nagłówka o rynku IT. Mam własne obserwacje, do których mogę wrócić.

Jeśli oba obszary Cię ciekawią, wspólne podstawy nie będą stracone. Praca z danymi, czytanie kodu, testowanie i jasne opisywanie problemu przydają się na styku ról. Na początek wybierz jednak jedno zadanie, które da się skończyć. Ukończony mały projekt powie Ci o własnych preferencjach więcej niż kolejna lista technologii do nauczenia się kiedyś.