Zarząd firmy dystrybucyjnej chce prognozować popyt, bo magazyn jednocześnie trzyma za dużo jednych towarów i za mało innych. Dyrektor operacyjny czytał o uczeniu maszynowym, prezes słyszał na konferencji, że konkurencja „ma już AI”, a dział HR dostaje zadanie: znaleźć data scientista. Ogłoszenie wymienia Pythona, modele szeregów czasowych, mile widziany doktorat. Po czterech miesiącach rekrutacji do firmy przychodzi świetny kandydat.
Pierwszy tydzień spędza na zdobywaniu dostępu do systemu ERP. Drugi i trzeci na odkrywaniu, że sprzedaż z dwóch kanałów jest zapisywana w dwóch systemach z różnymi kodami produktów. W drugim miesiącu pisze skrypty, które co noc eksportują dane do arkusza, bo nie ma innego miejsca, gdzie mogłyby się spotkać. W piątym miesiącu ma pierwszy model, ale dział zakupów mu nie ufa, bo liczby sprzedaży w modelu nie zgadzają się z raportem, który dział widzi co poniedziałek. Po roku kandydat odchodzi, a w CV wpisuje „budowa potoków danych”.
To scenariusz ilustracyjny, nie opis konkretnej firmy, ale jego mechanizm jest łatwy do rozpoznania. Ten artykuł jest dla CTO, szefów IT i partnerów HR, którzy mają obsadzić pierwszy albo kolejny etat w obszarze danych. Teza: kolejność zatrudnień w zespole danych wyznacza dojrzałość danych w firmie, a nie ambicja zarządu ani modny tytuł stanowiska. W większości organizacji, które dopiero zaczynają, pierwszy etat danych nie powinien nosić tytułu data scientist. Ale ta zasada działa w obie strony: w firmie, która ma już zaufane dane i dobrze postawione pytanie, zatrudnienie kolejnego data engineera zamiast data scientista jest takim samym błędem.
Czym właściwie zajmuje się data scientist i dlaczego ta nazwa myli?
Najkrótsza definicja pochodzi od amerykańskiego Bureau of Labor Statistics, który w podręczniku zawodów opisuje data scientistów jako osoby używające narzędzi i technik analitycznych, by wydobyć z danych znaczące wnioski. Ta sama publikacja podaje, że w maju 2025 roku mediana rocznego wynagrodzenia w tym zawodzie w Stanach Zjednoczonych wynosiła 120 230 dolarów, zawód liczył 275 600 miejsc pracy, a prognozowany wzrost zatrudnienia w latach 2025–2035 to 35%, znacznie szybciej niż średnia dla wszystkich zawodów. Te liczby tłumaczą, dlaczego tytuł jest atrakcyjny i dla kandydatów, i dla firm, które chcą pokazać, że „robią coś z danymi”.
Definicja zawiera jednak ukryte założenie: że dane, z których wydobywa się wnioski, już istnieją, są dostępne i można im ufać. Data scientist w ścisłym sensie pracuje na danych, nie nad danymi. Formułuje hipotezę, dobiera metodę statystyczną albo model, projektuje eksperyment, ocenia, czy model działa lepiej niż prosta reguła, i tłumaczy wynik ludziom, którzy podejmują decyzje. Jego produktem jest odpowiedź na pytanie albo prototyp modelu z uczciwą oceną jego jakości.
Nazwa myli, bo na rynku obejmuje co najmniej trzy różne prace. Pierwsza to analityka: raporty, wskaźniki, odpowiedzi na pytania „ile, gdzie, kiedy”. Druga to właściwa nauka o danych: modele predykcyjne, eksperymenty, wnioskowanie przyczynowe. Trzecia to inżynieria: budowa potoków danych i wdrażanie modeli. Ogłoszenie „data scientist” w firmie, która nie ma jeszcze wspólnej warstwy danych, w praktyce szuka osoby do pracy pierwszej i trzeciej, opisując ją słowami z drugiej. Stąd rozczarowania po obu stronach.
Dla partnera HR praktyczny wniosek jest taki: zanim napiszesz ogłoszenie, zapytaj zleceniodawcę, jaki konkretny produkt pracy chce dostać po trzech miesiącach. Jeśli odpowiedź brzmi „raport sprzedaży, któremu wszyscy wierzą”, to nie jest etat data scientista. Jeśli brzmi „model, który przewiduje odejście klienta lepiej niż obecna reguła”, to jest, pod warunkiem że dane do tego modelu już istnieją. Już samo hasło „analiza danych” pokazuje, jak szeroki jest obszar, który kryje się pod jednym słowem „dane”.
Czym różnią się data engineer, data scientist i ML engineer w codziennej pracy?
Najprościej odróżnić te role po tym, co dostarczają i za co odpowiadają, gdy coś się zepsuje. Tytuły stanowisk różnią się między firmami, ale odpowiedzialność już mniej.
Data engineer buduje i utrzymuje drogę danych od systemów źródłowych do miejsca, w którym można z nich korzystać. Pobiera dane z ERP, CRM, sklepu internetowego i systemów partnerów, ładuje je do hurtowni albo jeziora danych, pilnuje, żeby potoki działały codziennie, i reaguje, gdy system źródłowy zmieni strukturę tabeli. Odpowiada za to, że dane są kompletne, aktualne i spójne. Gdy w poniedziałkowym raporcie brakuje danych z weekendu, telefon dzwoni u niego. Szerzej opisujemy tę dziedzinę w haśle inżynieria danych.
Data scientist pracuje na danych przygotowanych przez inżyniera. Odpowiada za poprawność wniosku: czy wynik jest istotny statystycznie, czy model nie uczy się na danych, których w chwili predykcji nie będzie, czy eksperyment był dobrze zaprojektowany. Gdy model przewiduje źle, pytanie „dlaczego” trafia do niego.
ML engineer odpowiada za to, żeby model działał w produkcji tak samo dobrze jak w notatniku. Buduje sposób udostępniania wyników (interfejs API, przetwarzanie wsadowe, integrację z aplikacją), monitoruje jakość predykcji i dryf danych wejściowych, wersjonuje modele i pozwala bezpiecznie wycofać zmianę. Gdy model działał w zeszłym tygodniu, a dziś zwraca bzdury, to jest jego dyżur. Całość tej praktyki nazywa się MLOps i obejmuje cały cykl życia modelu, od trenowania po wycofanie.
Między tymi rolami są jeszcze dwie, które często rozwiązują problem taniej, niż się wydaje. Analityk danych odpowiada na pytania biznesowe przy pomocy raportów i zapytań. Analytics engineer to rola, którą spopularyzowała firma dbt Labs: osoba, która przekształca, testuje i dokumentuje dane tak, żeby dostarczyć użytkownikom czyste zbiory, i w ten sposób wypełnia lukę między inżynierią danych a analizą. W wielu firmach, które dopiero zaczynają, to właśnie analytics engineer albo data engineer z silnym SQL jest najbardziej brakującym ogniwem.
Różnica ma znaczenie przy zatrudnianiu z prostego powodu: każda z tych osób będzie nieszczęśliwa i nieskuteczna, gdy dostanie pracę innej. Data scientist zmuszony do pisania potoków robi to gorzej niż inżynier i szybciej odchodzi. Data engineer poproszony o model predykcyjny zbuduje coś, co działa technicznie, ale bez metodycznej oceny, czy w ogóle pomaga. ML engineer bez modelu do wdrożenia buduje platformę, której nikt nie używa.
Dlaczego kolejność zatrudnień wynika z dojrzałości danych, a nie z ambicji?
Bo każda z tych ról potrzebuje do pracy czegoś, co dostarcza rola poprzednia. Monica Rogati opisała to w 2017 roku w tekście „The AI Hierarchy of Needs” jako piramidę potrzeb. Na dole jest zbieranie danych: wiedza, jakie dane są potrzebne, czy istnieją i czy interakcje w ogóle są rejestrowane. Wyżej przepływ danych: niezawodne potoki, miejsce przechowywania, łatwy dostęp. Dalej eksploracja i czyszczenie, potem analityka, czyli definicje wskaźników i przygotowanie danych uczących, następnie eksperymenty i proste modele bazowe, a dopiero na samej górze zaawansowane metody uczenia maszynowego. Rogati pisze wprost, że firmy częściej niż rzadziej nie są gotowe na AI, a niektóre zatrudniły pierwszego data scientista z mizernym skutkiem.
Ten sam wniosek, sformułowany z perspektywy inżynierskiej, znajdziesz w opracowaniu „Rules of Machine Learning” Martina Zinkevicha z Google. Pierwsza reguła brzmi: nie bój się uruchomić produktu bez uczenia maszynowego, bo uczenie maszynowe wymaga danych. Druga: najpierw zaprojektuj i wdroż metryki, śledź jak najwięcej w obecnym systemie, zanim sformalizujesz, co ma robić system uczący się. Czwarta: pierwszy model ma być prosty, a infrastruktura poprawna. Kolejność tych reguł jest kolejnością zatrudnień w miniaturze: najpierw ktoś, kto zbuduje rejestrowanie i metryki, potem ktoś, kto zbuduje prosty model, a na końcu ktoś, kto zadba, żeby infrastruktura wokół modelu była solidna.
Trzecie źródło pokazuje, dlaczego ostatni krok też nie jest drobiazgiem. Zespół Google pod kierunkiem D. Sculleya opisał w pracy „Hidden Technical Debt in Machine Learning Systems” na konferencji NIPS 2015, że w realnych systemach uczenia maszynowego łatwo zaciągnąć ogromne, stałe koszty utrzymania. Wymienia zależności od danych, ukryte pętle sprzężenia zwrotnego, nieujawnionych odbiorców wyników, problemy z konfiguracją i zmiany w świecie zewnętrznym. Żadne z tych ryzyk nie dotyczy wyboru algorytmu. Wszystkie dotyczą danych i produkcji, czyli pracy inżyniera danych i ML engineera.
Ambicja zarządu jest ważna, bo wyznacza cel. Ale cel nie zmienia kolejności kroków. Firma, która chce prognozować popyt, a nie ma jednego źródła danych o sprzedaży, musi najpierw to źródło zbudować, niezależnie od tego, jak bardzo chce prognozy. Pytanie nie brzmi więc „czy zatrudnić data scientista”, tylko „na którym piętrze piramidy dziś stoimy”.
Jak w godzinę ocenić dojrzałość danych w firmie?
Nie potrzebujesz do tego konsultanta ani audytu. Wystarczy spotkanie z osobą z IT, która zna systemy, i z jednym właścicielem procesu biznesowego, który ma problem do rozwiązania. Zadaj im siedem pytań i zapisz odpowiedzi bez upiększania.
- Czy potrafimy w ciągu jednego dnia odpowiedzieć na proste pytanie liczbowe, na przykład ilu aktywnych klientów mieliśmy w zeszłym kwartale? Jeśli odpowiedź wymaga kilku osób, kilku eksportów i dyskusji, co znaczy „aktywny”, jesteś nisko.
- Czy dane z różnych systemów spotykają się w jednym miejscu automatycznie? Hurtownia, jezioro danych, nawet jedna baza raportowa. Jeśli spotykają się w arkuszu ręcznie, to nie jest jeszcze warstwa danych.
- Czy kluczowe wskaźniki mają jedną, zapisaną definicję? Gdy sprzedaż i finanse podają różne przychody za ten sam miesiąc, problem nie leży w modelu.
- Czy ktoś odpowiada za jakość danych i wie o tym? Konkretna osoba, do której trafia zgłoszenie „w tej tabeli od marca brakuje co dziesiątego rekordu”.
- Czy dane, które byłyby potrzebne do pytania predykcyjnego, w ogóle są rejestrowane? Prognoza odejść klientów wymaga historii kontaktów, reklamacji i zmian w zamówieniach. Jeśli tych zdarzeń nikt nie zapisuje, nie ma czego modelować.
- Czy istnieje konkretne pytanie, na które raport nie odpowie, i czy ma właściciela, który zmieni decyzję na podstawie odpowiedzi? „Chcemy wykorzystać AI” nie jest takim pytaniem. „Chcemy wiedzieć, do których klientów zadzwonić w przyszłym tygodniu, żeby nie odeszli” jest.
- Czy jakikolwiek model albo reguła oparta na danych działa dziś w procesie i ktoś go utrzymuje? Prosta reguła scoringowa w CRM też się liczy.
Odpowiedzi układają się zwykle w jeden z czterech poziomów. Poziom 0: dane rozproszone w systemach i arkuszach, brak wspólnej warstwy, brak wspólnych definicji (przeczenie w pytaniach 1–3). Poziom 1: jest wspólna warstwa danych i raporty, ale zaufanie do nich jest ograniczone, a nikt nie odpowiada za jakość (tak w pytaniu 2, nie w 3 lub 4). Poziom 2: dane są zaufane, istnieją definicje i właściciel jakości, pojawiło się konkretne pytanie predykcyjne z właścicielem (tak w 1–6). Poziom 3: model albo reguła działa w procesie i trzeba go utrzymywać, rozwijać i mnożyć (tak w 7).
Jedna uwaga: odpowiedzi należy oceniać pesymistycznie. Firmy mają tendencję do zawyżania własnej dojrzałości o jeden poziom, bo hurtownia „jest”, choć nikt z niej nie korzysta, a definicje „są”, choć każdy dział ma swoje. Jeśli wahasz się między dwoma poziomami, wybierz niższy. Błąd w dół kosztuje kilka tygodni pracy inżyniera, którą i tak trzeba będzie wykonać. Błąd w górę kosztuje rok pracy osoby zatrudnionej do zadań, których nie da się jeszcze wykonać.
Kogo zatrudnić najpierw na poziomie zero, gdy dane leżą w systemach źródłowych?
Na poziomie zero pierwszym etatem powinien być data engineer, a w mniejszej firmie, której dane mieszczą się w jednej hurtowni i kilku źródłach, analytics engineer z mocnym SQL i umiejętnością rozmowy z biznesem. Jego zadanie na pierwsze miesiące jest skromne w opisie i trudne w wykonaniu: połączyć dane z dwóch–trzech najważniejszych systemów w jednym miejscu, ustalić z właścicielami procesów definicje kilku kluczowych wskaźników i dostarczyć kilka raportów, którym zarząd uwierzy.
Ten wybór bywa kwestionowany argumentem, że data engineer „nie przyniesie wartości biznesowej”, bo dostarcza infrastrukturę, a nie odpowiedzi. To nieporozumienie. Pierwsza wspólna, zaufana liczba przychodu, marży albo rotacji zapasu jest dla wielu zarządów większą zmianą niż jakikolwiek model, bo kończy comiesięczne spory o to, czyje dane są prawdziwe. Zinkevich ujmuje to w drugiej regule: zanim zbudujesz system uczący się, mierz to, co dzieje się w obecnym systemie. Bez tego nie wiesz nawet, czy model coś poprawi.
W artykule o strukturze zespołu AI Bartosz Ciepierski dodaje do tej rekomendacji warunek, który warto potraktować poważnie: pierwszy inżynier danych potrzebuje pisemnego mandatu do zmian w systemach źródłowych, bo inaczej utknie w kolejce priorytetów cudzych zespołów. Ten artykuł nie powtarza tego argumentu, tylko go uogólnia: mandat jest warunkiem skuteczności pierwszego etatu, a poziom dojrzałości decyduje, jaki to ma być etat.
Na poziomie zero nie zatrudniaj jeszcze data scientista ani ML engineera. Jeśli zarząd naciska na „coś z AI”, uczciwszą odpowiedzią jest krótki projekt sprawdzający na danych, które już istnieją, zlecony na kilka tygodni specjaliście z zewnątrz, niż etat, który przez pół roku będzie budował dane. Jak rozdzielić pracę nad danymi między zespół własny i zewnętrzny, opisujemy w tekście o zarządzaniu danymi jako usłudze.
Na poziomie jeden, gdy wspólna warstwa danych istnieje, ale zaufanie jest ograniczone, drugim etatem jest zwykle analityk danych albo kolejny inżynier, a nie data scientist. Brakuje tu nie modeli, tylko ludzi, którzy będą z danych korzystać na co dzień, zgłaszać błędy i budować nawyk pracy z liczbami. Data scientist na tym poziomie spędzi większość czasu na weryfikacji danych, a każdy jego wynik zostanie zakwestionowany argumentem „te dane są złe”. Dobrze zaprojektowany model danych bardzo tu pomaga; dlaczego jego błędy kosztują więcej niż zły wybór technologii, wyjaśniamy w artykule o modelowaniu danych dla biznesu.
Kiedy data scientist jest właściwym pierwszym etatem?
Tu teza artykułu działa w drugą stronę i to jest jej część najczęściej pomijana. Popularna dziś rada „zawsze zaczynaj od data engineera” jest tak samo mechaniczna jak dawna moda „zatrudnij data scientista”. Są sytuacje, w których data scientist jest pierwszym brakującym etatem, a kolejny inżynier byłby stratą pieniędzy.
Pierwsza sytuacja: firma jest na poziomie dwa. Ma hurtownię, z której korzystają działy, definicje są spisane, ktoś odpowiada za jakość, a raporty od dawna odpowiadają na pytania „ile i gdzie”. Pojawia się pytanie innego rodzaju: „co się stanie, jeśli” albo „kto prawdopodobnie”. Na przykład: którzy klienci prawdopodobnie odejdą, jaki będzie popyt na nowy produkt, czy zmiana ceny podniosła sprzedaż, czy tylko zbiegła się w czasie z sezonem. Na takie pytania raport nie odpowie i kolejny inżynier też nie. Potrzebna jest osoba, która zaprojektuje eksperyment albo model i uczciwie oceni jego wynik.
Druga sytuacja: produkt firmy jest oparty na danych od pierwszego dnia. Firma oferująca na przykład scoring, rekomendacje albo prognozy jako usługę ma inny problem niż firma, która chce lepiej zarządzać magazynem. Tu pytanie metodyczne, czyli czy w ogóle da się przewidzieć zjawisko z wymaganą dokładnością, jest pytaniem o sens całego biznesu. Odpowiedź na nie musi przyjść wcześnie, zanim powstanie infrastruktura. Data scientist może wtedy pracować na próbce danych, nawet zebranej ręcznie, i rozstrzygnąć, czy budowa infrastruktury ma sens.
Trzecia sytuacja: firma potrzebuje odpowiedzi, a nie systemu. Jednorazowa analiza, na przykład czy program lojalnościowy zwiększa wartość klienta, czy tylko nagradza tych, którzy i tak kupowaliby więcej, wymaga metod wnioskowania przyczynowego, a nie potoku danych. Tu data scientist, często na kontrakt, jest właściwym i jedynym etatem.
We wszystkich trzech sytuacjach warto sprawdzić jeden warunek: czy pytanie ma właściciela, który zmieni decyzję na podstawie odpowiedzi. Data scientist bez takiego właściciela produkuje ciekawe analizy, które nic nie zmieniają, i po roku zespół danych ma opinię kosztu, a nie inwestycji. Zinkevich w pierwszych regułach nie pisze o algorytmach, tylko o celu i metrykach. To nie przypadek.
Kiedy ML engineer powinien wyprzedzić data scientista?
Klasyczna kolejność zakłada, że model trzeba najpierw wymyślić, a dopiero potem wdrożyć, więc data scientist idzie przed ML engineerem. Ta kolejność przestała być oczywista, odkąd wiele zastosowań opiera się na gotowych modelach, kupowanych jako usługa albo pobieranych jako otwarte modele, i dostosowywanych do własnych danych.
Jeśli firma chce wykorzystać duży model językowy do klasyfikacji zgłoszeń, wyszukiwania w dokumentacji albo wstępnej obsługi klienta, nie musi wynaleźć modelu. Musi go wdrożyć: połączyć z własnymi danymi, zbudować warstwę udostępniania, monitorować jakość odpowiedzi i koszt, zadbać o bezpieczeństwo i możliwość wycofania zmiany. To jest praca ML engineera, a nie data scientista. W tej sytuacji kolejność wygląda tak: data engineer (dane muszą istnieć i być dostępne również tu), potem ML engineer, a data scientist dopiero wtedy, gdy pojawi się potrzeba rzetelnej oceny jakości na większą skalę albo dostrajania modelu na własnych danych.
Druga sytuacja, w której ML engineer idzie wcześniej, to poziom trzy z testu dojrzałości: firma ma już działający model, zbudowany przez data scientista albo przez dostawcę, i ten model zaczyna się psuć. Zmieniły się dane wejściowe, zmienił się proces, nikt nie wie, która wersja działa na produkcji. Praca Sculleya i współautorów pokazuje, że to nie jest wyjątek, tylko naturalny los systemów uczenia maszynowego bez inżynierii wokół nich. Kolejny data scientist w takiej firmie zbuduje kolejny model, który za rok będzie miał ten sam problem. ML engineer zbuduje sposób, w jaki wszystkie modele są wdrażane, monitorowane i wymieniane.
Jest też sytuacja odwrotna, w której ML engineer jest zatrudniany za wcześnie. Firma na poziomie zero albo jeden, zachęcona prezentacją platformy MLOps, zatrudnia inżyniera, który buduje rejestr modeli, potoki trenowania i monitoring, zanim powstał pierwszy model wart wdrożenia. Platforma jest technicznie poprawna i pusta. Zinkevich w czwartej regule pisze, żeby pierwszy model był prosty, a infrastruktura poprawna, ale infrastruktura ta ma służyć konkretnemu modelowi, nie hipotetycznym przyszłym.
Jak wygląda kolejność zatrudnień dla każdego poziomu dojrzałości?
Poniższa tabela zbiera wnioski z poprzednich sekcji. Traktuj ją jako punkt wyjścia do rozmowy z zarządem, a nie jako przepis, bo każdą z rekomendacji może zmienić konkretne pytanie biznesowe.
| Poziom dojrzałości | Jak go rozpoznać | Pierwszy etat | Drugi etat | Czego jeszcze nie zatrudniać | Produkt pracy po 90 dniach |
|---|---|---|---|---|---|
| 0: dane rozproszone | Odpowiedź na proste pytanie liczbowe wymaga kilku osób i eksportów; brak wspólnych definicji | Data engineer albo analytics engineer z mandatem do systemów źródłowych | Analityk danych | Data scientist, ML engineer | Dane z 2–3 kluczowych systemów w jednym miejscu, spisane definicje kilku wskaźników, pierwsze zaufane raporty |
| 1: wspólna warstwa, ograniczone zaufanie | Hurtownia istnieje, ale działy podają różne liczby; nikt nie odpowiada za jakość | Kolejny data engineer albo analytics engineer odpowiedzialny za jakość i definicje | Analityk danych w dziale biznesowym | ML engineer | Testy jakości danych, właściciel jakości, raporty używane co tydzień przez co najmniej jeden dział |
| 2: zaufane dane, pytanie predykcyjne | Definicje spisane, dane zaufane, konkretne pytanie „kto prawdopodobnie” z właścicielem | Data scientist | ML engineer, gdy model ma trafić do procesu | Kolejna rola platformowa bez modelu | Model albo eksperyment z oceną względem prostej reguły i decyzja, czy wdrażać |
| 3: model w procesie | Co najmniej jeden model lub reguła działa w procesie i wymaga utrzymania | ML engineer | Kolejny data scientist do nowego pytania | Kolejny model bez inżynierii wokół istniejących | Monitoring jakości i dryfu, wersjonowanie, procedura wycofania zmiany |
| Wyjątek: gotowy model jako usługa | Zastosowanie oparte na dużym modelu językowym lub gotowym modelu, bez potrzeby budowy własnego | Data engineer, jeśli dane nie są dostępne; ML engineer, jeśli są | Data scientist do oceny jakości na skalę | Data scientist jako pierwszy etat | Działające wdrożenie na danych produkcyjnych z monitorowaniem jakości i kosztu |
Dwie obserwacje dotyczące tabeli. Po pierwsze, przejście między poziomami nie następuje samo z siebie przez zatrudnienie. Firma na poziomie zero, która zatrudni data scientista, nie przeskoczy na poziom dwa; będzie miała data scientista na poziomie zero. Po drugie, ostatnia kolumna jest najważniejsza przy rozmowie z zarządem. Zamiast zatwierdzać etat, zarząd zatwierdza produkt pracy po 90 dniach i kryterium, po którym oceni, czy warto zatrudniać dalej.
Ile kosztuje każda z tych ról i co z tego wynika dla budżetu?
Dane o stawkach warto brać z jednego, sprawdzalnego źródła. W cenniku ARDURA senior data engineer kosztuje 1600–2240 zł netto za dzień (8 godzin), czyli 200–280 zł za godzinę, a lead 2240–3040 zł netto za dzień. Przy 21 dniach roboczych w miesiącu daje to dla seniora około 33 600–47 040 zł netto miesięcznie. Strona usług programistów Python podaje dla seniorskich inżynierów ML w Pythonie 1920–2800 zł netto za dzień, co przy tych samych 21 dniach daje około 40 320–58 800 zł miesięcznie. Stawki data scientista cennik ARDURA nie podaje i dlatego nie podajemy jej tutaj; wycena zależy od specjalizacji i zakresu. Szczegóły stawek inżynierów danych i czynniki, które je różnicują, omawiamy w artykule o stawkach data engineering developera w 2026 roku.
Same stawki mówią jednak mniej niż koszt błędnej kolejności. Policzmy ilustracyjnie scenariusz z początku artykułu. Data scientist zatrudniony na poziomie zero przez pierwsze sześć miesięcy wykonuje głównie pracę inżynierską. Nie znamy jego dokładnej stawki, ale nawet jeśli założyć, że kosztuje tyle samo co senior data engineer, firma płaci za pół roku pracy, którą inżynier wykonałby szybciej i trwalej, bo zbudowałby potoki z monitoringiem, a nie skrypty eksportujące do arkusza. Do tego dochodzi koszt rekrutacji i wdrożenia następcy, jeśli osoba odejdzie, oraz koszt utraconego zaufania zarządu do całego obszaru danych. Ten ostatni bywa najwyższy, bo kolejny wniosek o budżet na dane trafia na argument „już próbowaliśmy”.
Z tego wynika praktyczna zasada budżetowa: na poziomie zero i jeden budżet na dane to w większości budżet na inżynierię, a pozycja „data scientist” powinna pojawić się dopiero w planie na kolejny rok, warunkowo, po osiągnięciu kryteriów poziomu dwa. Na poziomie dwa i trzy proporcje się odwracają i to tam warto zainwestować w data scientista i ML engineera.
Warto też policzyć koszty, których nie ma w stawkach. Czas właściciela procesu biznesowego, który musi uzgodnić definicje i odpowiadać na pytania, jest realny i często większy, niż zakłada plan. Licencje hurtowni danych, narzędzi do orkiestracji i usług modelowych rosną z wolumenem. Przy zastosowaniach opartych na gotowych modelach koszt zużycia usługi bywa niedoszacowany, bo pilotaż liczy się na małej próbce. Te pozycje warto wpisać do planu obok etatów, a nie odkrywać po pierwszym kwartale.
Jak napisać ogłoszenie, żeby przyciągnąć właściwą rolę?
Ogłoszenie jest pierwszym filtrem i najczęstszym miejscem, w którym kolejność zatrudnień się psuje. Tytuł „data scientist” przyciąga kandydatów o profilu badawczym, którzy chcą pracować nad modelami. Jeśli rzeczywista praca to budowa potoków, ogłoszenie przyciąga złych kandydatów, a dobrych do właściwej pracy odstrasza, bo inżynier danych nie ma powodu otwierać oferty z takim tytułem.
Partner HR może zastosować prostą metodę: zacznij ogłoszenie od produktu pracy, a nie od listy technologii. Zamiast „szukamy data scientista ze znajomością Pythona, SQL i uczenia maszynowego” napisz: „w pierwszym kwartale połączysz dane sprzedaży z ERP i sklepu internetowego w jednej hurtowni, uzgodnisz z działem handlowym definicję aktywnego klienta i zbudujesz raport, który zastąpi trzy obecne arkusze”. Kandydat od razu wie, czy to praca dla niego, a zleceniodawca musi doprecyzować, czego naprawdę chce.
Kilka konkretnych wskazówek dla każdej z ról:
- Data engineer: opisz systemy źródłowe (ERP, CRM, sklep, systemy partnerów), skalę danych i to, czy kandydat będzie miał dostęp do zmian w tych systemach. Doświadczenie z systemami, których kandydat nie kontroluje, jest w tej roli cenniejsze niż znajomość najnowszego narzędzia.
- Analytics engineer: podkreśl pracę z definicjami wskaźników, testami jakości i dokumentacją oraz kontakt z działami biznesowymi. To rola dla osoby, która lubi, gdy liczby się zgadzają.
- Data scientist: podaj konkretne pytanie biznesowe, opisz dostępne dane (z historią, wolumenem i znanymi lukami) i nazwij właściciela decyzji. Dobry kandydat zapyta o dane, zanim zapyta o technologię.
- ML engineer: opisz, jaki model ma trafić do produkcji, w jakim systemie i z jakimi wymaganiami czasowymi i kosztowymi. Jeśli modelu jeszcze nie ma, to sygnał, że etat może być przedwczesny.
Wymaganie doktoratu warto zostawić dla pracy rzeczywiście badawczej. W większości zastosowań biznesowych zawęża pulę kandydatów i podnosi koszt bez proporcjonalnej korzyści. Lepszym sygnałem jest opis, jak kandydat ocenił w przeszłości, czy jego model był lepszy od prostej reguły, i co zrobił, gdy nie był. Więcej o tym, jak przygotować proces rekrutacji inżyniera danych od strony wymagań i etapów, piszemy w poradniku o weryfikacji umiejętności data engineering developera.
Jak w rozmowie odróżnić data engineera od data scientista i ML engineera?
Tytuły w CV są zawodne, bo te same nazwy oznaczają w różnych firmach różne prace. Bardziej wiarygodne są historie, które kandydat opowiada, i to, o co pyta. Kilka pytań pomaga szybko ustalić, z kim rozmawiasz.
Pytanie o ostatni problem, który kandydat rozwiązał. Data engineer opowie o potoku, który przestał działać, bo system źródłowy zmienił format, o duplikatach klientów albo o tym, jak skrócił czas ładowania danych. Data scientist opowie o pytaniu, hipotezie, metodzie i o tym, czy wynik był istotny. ML engineer opowie o modelu, który działał w testach, a w produkcji zwracał złe wyniki, i o tym, jak to wykrył.
Pytanie o to, co kandydat zrobi w pierwszym tygodniu. Data engineer zapyta o systemy źródłowe, dostęp i właścicieli danych. Data scientist zapyta o pytanie biznesowe i o to, jakie dane istnieją. ML engineer zapyta o to, gdzie model ma działać i jak dziś wygląda wdrażanie oprogramowania. Kandydat na data scientista, który w pierwszym tygodniu chce wybierać algorytm, zanim zobaczy dane, to sygnał ostrzegawczy.
Pytanie o porażkę. Dobry data scientist potrafi opowiedzieć o modelu, który nie pobił prostej reguły i który zarekomendował porzucić. Dobry data engineer o potoku, który zaprojektował źle i musiał przebudować. Dobry ML engineer o wdrożeniu, które musiał wycofać. Brak takich historii przy kilku latach doświadczenia oznacza zwykle, że kandydat nie miał kontaktu z produkcją.
Zadanie praktyczne dopasowane do roli. Dla data engineera: zaprojektuj przepływ danych z dwóch systemów o różnych identyfikatorach klienta. Dla data scientista: oto zbiór danych i pytanie; jak sprawdzisz, czy da się na nie odpowiedzieć, i jaki jest prosty punkt odniesienia? Dla ML engineera: model działa w notatniku, opisz, co musi się stać, żeby działał w produkcji przez rok. Zadanie nie musi być długie. Ważniejsze jest, o co kandydat zapyta, zanim zacznie je rozwiązywać.
Partner HR nie musi oceniać merytorycznej poprawności odpowiedzi; to rola technicznego członka komisji. Może natomiast sprawdzić, czy historie kandydata dotyczą tego produktu pracy, który opisano w ogłoszeniu. To najprostszy filtr przeciwko zatrudnieniu właściwej osoby do niewłaściwej pracy.
Kiedy zatrudnić na etat, a kiedy wziąć specjalistę na kontrakt?
Decyzja o kolejności ról i decyzja o formie zatrudnienia są ze sobą powiązane. Pierwszy etat na danym poziomie dojrzałości często ma charakter budowy: trzeba coś postawić, a potem utrzymywać mniejszym wysiłkiem. Takie zadania dobrze nadają się do współpracy z zewnętrznym specjalistą, a stały zespół warto budować na role, których praca nie kończy się nigdy. Gdy pytanie dotyczy jednorazowej oceny wykonalności, a nie stałej roli, pomocny jest tekst o tym, kiedy zatrudnić konsulting machine learning.
Kilka sytuacji, w których kontrakt ma przewagę nad etatem. Sprawdzenie, czy pytanie predykcyjne ma sens, zanim firma zatrudni data scientista na stałe: kilka tygodni pracy specjalisty na istniejących danych daje odpowiedź, czy warto budować zespół. Budowa pierwszej warstwy danych, gdy firma nie wie jeszcze, jakiej skali zespołu inżynierskiego będzie potrzebować w utrzymaniu. Wdrożenie pierwszego modelu do produkcji, gdy firma ma data scientista, ale nie ma jeszcze pracy na pełny etat ML engineera. Luka w czasie rekrutacji: rekrutacja seniora w obszarze danych bywa długa, a praca nie czeka.
W modelu body leasingu ARDURA zapewnia specjalistę w ciągu około dwóch tygodni, z dwutygodniową gwarancją bezpłatnej wymiany, wymianą w ciągu 5 dni roboczych, jeśli specjalista odejdzie w trakcie współpracy, i 30-dniowym okresem wypowiedzenia bez kar umownych. Dla firmy, która nie jest pewna swojego poziomu dojrzałości, ta elastyczność ma znaczenie praktyczne: jeśli po trzech miesiącach okaże się, że potrzebny jest inny profil, zmiana nie wymaga rozwiązywania umowy o pracę. Koszty i ryzyka obu ścieżek warto rozpisać przed decyzją, licząc także czas rekrutacji i koszt ewentualnej pomyłki.
Etat ma przewagę tam, gdzie wiedza o danych firmy jest kapitałem, który nie powinien odchodzić: przy właścicielu jakości danych, przy osobie, która zna definicje i historię wskaźników, przy liderze zespołu danych. Dobrym układem bywa połączenie obu form: stała osoba odpowiedzialna za dane i ich znaczenie oraz zewnętrzni specjaliści do zadań budowy i do ról, które na danym poziomie dojrzałości są potrzebne czasowo.
Jedna przestroga: zewnętrzny specjalista nie zastąpi mandatu. Jeśli pierwszy inżynier danych, etatowy czy kontraktowy, nie ma prawa uzyskać dostępu do systemów źródłowych i zmian w nich, utknie tak samo. Mandat trzeba załatwić po stronie firmy, zanim specjalista zacznie pracę.
Jakie są kluczowe wnioski przed obsadzeniem pierwszego etatu danych?
Pytanie „data scientist, data engineer czy ML engineer” nie ma jednej odpowiedzi, ale ma jedną metodę: najpierw ustal, na którym poziomie dojrzałości danych stoi firma, potem zatrudnij rolę, która przeniesie ją na kolejny. Kolejność wynika z tego, że każda rola potrzebuje do pracy produktu poprzedniej: data scientist potrzebuje zaufanych danych, a ML engineer modelu wartego wdrożenia.
Zapamiętaj sześć rzeczy. Po pierwsze, rozróżniaj role po produkcie pracy i odpowiedzialności, a nie po tytule: data engineer odpowiada za dane, data scientist za poprawność wniosku, ML engineer za działanie modelu w produkcji. Po drugie, oceń dojrzałość danych siedmioma pytaniami i wybierz niższy poziom, jeśli się wahasz. Po trzecie, na poziomie zero i jeden zatrudniaj inżynierię i analitykę, a nie data scientista. Po czwarte, na poziomie dwa zatrudnij data scientista, ale tylko do konkretnego pytania z właścicielem decyzji; kolejny inżynier byłby wtedy błędem. Po piąte, przy gotowych modelach i na poziomie trzy ML engineer wyprzedza data scientista. Po szóste, pisz ogłoszenia od produktu pracy po 90 dniach i każ zarządowi zatwierdzać ten produkt, a nie sam etat.
Jeśli chcesz sprawdzić, czy pytanie predykcyjne ma sens, zanim zatrudnisz kogoś na stałe, albo potrzebujesz inżyniera danych na czas budowy pierwszej warstwy, zobacz, jak pracujemy w modelu body leasingu specjalistów danych i ML, lub umów rozmowę. Zaczynamy od ustalenia, na którym poziomie jesteście i jakiego produktu pracy potrzebujecie po pierwszym kwartale.