To jest 199. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o biznes intelligence deweloperze. Sponsorem tego odcinka jest firma Tpay. Przypominam, że w poprzednim odcinku rozmawiałem o marce osobistej na rynku pracy IT. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/199.

Ocena lub recenzja podcastów w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Oceny podcastom można wystawiać również w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję. 

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest m.in. ten podcast. Wspierając mnie przez Patronite, dzieląc się tym odcinkiem w swoim kręgu lub feedbackiem na jego temat ze mną, pomagasz w realizacji tej misji.

A teraz życzę Ci już miłego słuchania. Odpalamy!

Cześć!

Mój dzisiejszy gość od ponad 15 lat pracuje z danymi. Na początku jako analityk danych. Dzisiaj przewodzi zespołom Business Intelligence i Data Warehousing w firmie Tpay. Ojciec rocznej Tosi. Moim i Waszym gościem jest Michał Chrzanowski.

Cześć, Michał, bardzo mi miło gościć Cię w podcaście.

Cześć, Krzysztofie, dziękuję Ci za zaproszenie.

Dzisiaj skorzystamy z Twojego bardzo szerokiego doświadczenia związanego z danymi, bo będziemy mówić o tematach związanych z Business Intelligence, a skupimy się najbardziej na roli Business Intelligence Developera. Powiemy, czym ta rola jest, czym się zajmuje taka osoba, jakie kompetencje, jakie umiejętności musi posiadać, czym zajmuje się w firmie, z kim współpracuje, i też jak może taka przykładowa ścieżka kariery takiej osoby wyglądać.

Ale zanim do tego przejdziemy, to chciałbym Cię, Michał, zapytać, jak każdego mojego gościa, czy słuchasz podcastów. Być może będziesz w stanie jakieś zarekomendować.

Jak widziałem tę sugestię pytania, to się złapałem za głowę, że nie oglądam podcastów IT, chyba nie robię czegoś dobrze, ale potem sobie przypomniałem, że oglądam Leksa Friedmana.

Liczy się jak najbardziej.

Liczy się jak najbardziej. Jest tam tematyka IT, jak jest jak najbardziej dla mnie interesująca, w szczególnie te wczesne historie, na przykład programowania, tworzenia gier, różnych przełomów w tej dziedzinie. Bardzo mnie to fascynuje, łącznie z pozostałymi zagadnieniami, które on tam porusza.

A tak poza IT, to chyba dzisiaj duża część ludzi stała się geopolitykami ze względu na wojnę w Ukrainie. Więc bardzo dużo teraz tego oglądam, żeby się trochę więcej dowiedzieć o tym, co się dzieje dokoła mnie.

Dla przyjemności różnych standuperów amerykańskich, ich podcasty, ich historie. I jako ojciec rocznej Tosi, dużo o dzieciach.

Bardzo przekrojowo, różne wątki. Świetnie.

Jakiś czas temu nagrywałem podcast dotyczący analizy danych, dotyczący osób, które zajmują się zawodowo analizą danych. I tam bardzo delikatnie dotknęliśmy tematu różnicy pomiędzy analizą danych a business intelligence. Myślę, że dobrze byłoby dzisiaj rozpocząć od tego pytania, czym BI różni się od analityki danych.

No więc czy w ogóle business intelligence jest? Może od tego też możemy zacząć. Trochę buzzword, taki, który jest teraz bardzo popularny, ale jak w wielu przypadkach też bardzo różnie definiowany i różnie wykorzystywany. Jakoś tak się utarło, że w takim wąskim ujęciu BI to są narzędzia. Czyli jest zespół narzędzi, które wręcz ma w nazwie BI, jak np. Microsoft Power BI czy różne inne dodatki do dużych pakietów czy usług chmurowych. Ale myślę, że o tym trzeba znacznie szerzej myśleć. Trzeba myśleć trochę o tym, jak o procesie przekształcania, udostępniania danych w organizacji po to, żeby zwiększać jej konkurencyjność, poprawiać jej działanie, optymalizować koszty.

Chyba takim sekretnym elementem tego jest to, że to jest duży proces obejmujący wiele osób w firmach, który uwzględnia wykorzystanie narzędzi IT, gotowych pewnych pakietów, pewnych rozwiązań, pewnych metodyk, gdzie ta analiza danych jest częścią tego procesu, a całość koronuje to oprogramowanie, które pokazuje i wizualizuje pewne rzeczy.

Powiedziałeś, że BI to proces. Dlaczego wobec tego firma miałaby się decydować, żeby inwestować takie osoby czy w taki dział, czy w ogóle rozwijać procesy związane z BI? Po co firmie potrzebne jest BI?

Dzisiaj wszyscy przekształcają, przetwarzają i wykorzystują dane w firmach, tylko robią to na bardzo różne sposoby. Ostatnio byłem na takiej konferencji dotyczącej właśnie wykorzystywania danych w organizacjach i rozmawialiśmy o sztucznej inteligencji, rozmawialiśmy o różnych nowinkach, aż ktoś podniósł rękę i powiedział: ale widzę, że u nas jeszcze Excel jest dominującym narzędziem analizy danych i nie pozbędziemy się go bardzo, bardzo długo. Ja bym trochę obrócił to pytanie i powiedział, że każda firma, która przetwarza dane i z jakiegoś powodu może wypracować na niej jakąś korzyść, na jakimś etapie powinna sobie to zorganizować. Czy to z wykorzystaniem tych większych i też czasem droższych rozwiązań BI-owych, czy też po prostu ułożyć sobie pracę ludzi, analityków, którzy nawet pracują z Excelem czy z innymi narzędziami.

Ja tak sobie myślę, że są takie dwa scenariusze. Pierwszy jest taki scenariusz, że każda firma w Polsce, która ma bardzo różne procesy biznesowe, coś sprzedaje, coś montuje, z kimś się kontaktuje – tam zawsze jest potrzeba podsumowania tego procesu w jakichś metrykach, w jakichś informacjach. Do tego BI może służyć, ale nie jest to kluczowe rozwiązanie, szczególnie jeżeli się zdecydujemy na specjalistów, tych trochę droższych, na oprogramowanie, ale jeżeli już zaczynamy się profesjonalizować, jeżeli skala firmy się zwiększa, to bardzo się często okazuje, że takie procesy BI-owe są w stanie przynieść oszczędności, wyłapać jakieś nadużycia i się sfinansować, bo to jest chyba w tym najważniejsze.

Ale jest też drugi scenariusz, taki w którym model biznesowy firmy zależy od przetwarzania danych. To znaczy w sytuacji, w której jesteśmy, czy to na przykład serwisem internetowym, który żyje dzięki swoim systemom rekomendacyjnym, albo żyje dzięki temu, jak sprawnie pewne rzeczy przetwarza i oddaje z powrotem, wtedy BI jest kluczowy. Czy to jako proces taki automatyczny, udostępniany dla naszych klientów, odbiorców, czy też jako coś wewnętrznego, co używamy, żeby robić to jeszcze lepiej.

I w takich przypadkach nie ma wyjścia. To jest to, co sprawi, że będziemy lepiej działać niż nasza konkurencja. Szczególnie się widzi w obszarze internetu, gdzie tych danych jest bardzo dużo, ale też w wielu innych dziedzinach, tak jak retailu, czy sprzedaży detalicznej, jak telekomów, tych dziedzin jest całkiem sporo i sposoby na monetyzację, czyli wypracowanie zysku na danych pojawiają się właściwie w każdym obszarze.

BI nie jest tani i to nie chodzi o programowanie, chodzi o ludzi. Sfinansowanie takiego procesu w firmie to są duże koszty, tego nie da się zrobić tak zupełnie po kosztach, czy w sposób zupełnie tani. Więc na pewno jest jakiś próg dla firm, które będą musiały się zastanowić, czy im się to opłaca, zanim wejdą w te bardziej całościowe rozwiązania, czy pozostaną, przy prostszej analityce, która też będzie wartościowa, ale może wystarczająco na tym etapie rozwoju, czy firmy, czy działalności.

BI nie jest tani i to nie chodzi o programowanie, chodzi o ludzi. Sfinansowanie takiego procesu w firmie to są duże koszty, tego nie da się zrobić tak zupełnie po kosztach, czy w sposób zupełnie tani. Więc na pewno jest jakiś próg dla firm, które będą musiały się zastanowić, czy im się to opłaca, zanim wejdą w te bardziej całościowe rozwiązania, czy pozostaną, przy prostszej analityce, która też będzie wartościowa, ale może wystarczająco na tym etapie rozwoju, czy firmy, czy działalności.

Rozumiem. Słuchałem, gdy mówiłeś o tym, że BI to jest proces składający się z wielu elementów, angażujący wiele osób, więc domyślam się, że takie zmiany w firmie polegające na tym, że teraz chcemy stosować tego typu rozwiązania i przewagi wynikające z tych rozwiązań wymagają też zaangażowania, czy takiego szerszego podejścia.

To zazwyczaj rodzi jakieś opory. Każda zmiana rodzi opory. Myślę, że tak jak mówiło się o zmianie cyfrowej, o takiej adaptacji tych różnych cyfrowych rozwiązań, tak samo wprowadzenie takiego podejścia opartego o dane, opartego o BI, wymaga właśnie zmian.

Jak takie zmiany w firmie mogą wyglądać, albo czego wymagają od firmy, aby wdrożenie oparte o BI mogło się zakończyć sukcesem?

Może warto powiedzieć, że ten proces składa się z kilku podstawowych elementów i dookoła nich trzeba coś zrobić. Z jednej strony są dane i sposób ich wytwarzania, sposób nadawania im znaczeń, sposób ich organizowania. To jest cały zasób, którym trzeba się zająć i zaopiekować. Tu jest taki obszar, który się nazywa Data Governance, czyli zarządzania danymi w firmie, czyli ich jakością, ich sposobem wytwarzania, definiowania, uspójniania, tak, żeby wszyscy funkcjonowali, używając tej samej definicji.

W ogóle w BIA, a tak naprawdę szerzej w modelowaniu danych, mówi się o jednym źródle prawdy. To jest taki ideał, do których chcemy dojść, czyli doprowadzić do tego, że wszyscy posługujemy się tymi samymi definicjami.

Ja w jednej z firm pracując, naliczyłem chyba dziewięć sposobów na zdefiniowanie klienta business to business. I każdy odzwierciedlał zupełnie inną cechę tego klienta. To czy się z nim rozliczamy jak business to business, czy ma NIP, czy pomimo tego, że ma NIP, to jest naprawdę firmą, czy jest taką jednoosobową działalnością jakiegoś profesjonalisty, czy oferta, którą otrzymał, to jest oferta B2B. Naprawdę wiele różnych logiki. Wystarczy sobie wyobrazić, że każdy z działów będzie się posługiwał inną, a potem wszyscy się spotkamy na jakimś spotkaniu zarządu, czy w jakiejś wspólnej rozmowie i każdy wyciągnie z kapelusza zupełnie inne wartości.

I to jest chleb powszedni. To się dzieje w każdej firmie i w każdy sposób i tym trzeba zarządzać. Dane czasem są używane do tego, żeby coś udowodnić, żeby coś uzasadnić, żeby coś obronić. Więc zapewnienie takiej, powiedzmy, żelaznej spójności i też wiarygodności jest jednym z kluczowych elementów tego, co musimy osiągnąć. No i teraz zależy od tego, czy taki dział BI ma siłę przebicia w organizacji, bo działy BI to też jest ciekawy wątek. Są umieszczane pod bardzo różnymi działami i IT nie jest najczęstszym. IT jest takim naturalnym miejscem, bo jest blisko technologii, jest jakieś oprogramowanie, jakaś infrastruktura jest do tego potrzebna, ale są też takie, które są przy zarządach, są takie, które są przy kontrolingu. Mnie się zdarzyło pracować w firmie, który był przy marketingu, więc teraz pytanie, czy z tego miejsca w tej strukturze jesteśmy w stanie doprowadzić do tego w organizacji i doprowadzić do tego, żebyśmy wszyscy rozmawiali w ten sam sposób.

Trudne zadanie i bardzo zależy od wsparcia zarządu. Czy ktoś tam na samej górze uważa, że to jest ważne, że warto temu poświęcić czas, zmienić jakieś decyzje czasem, czy raczej to jest… jakiś dodatek.

Oprócz tych danych mamy narzędzia IT, więc potrzebujemy infrastruktury, musimy te dane gdzieś przechowywać, musimy utrzymywać ich świeżość, zdolność do ich wyciągania, wyciągania ich szybko, możliwie bez błędów albo takich błędów, które jesteśmy w stanie wyłapać i to też jest taki obszar, który można nazwać data opsami, tak jak tych opsów mamy, devopsy i tym podobne rzeczy, no to można sobie też wyobrazić całą organizację data opsów, czyli dbania jakby o cały ten proces od strony infrastrukturalnej, ale też jakby do dotarcia do tych użytkowników końcowych.

Mamy narzędzia BI, to o tym pewnie trochę więcej, i mamy ludzi, bo te rozwiązania są tak dobre, jak uda się to wykorzystać w pracy codziennej wszystkich osób w organizacji i takich na samej górze i tych, którzy podejmują po prostu codzienne jakieś działania operacyjne, do których potrzebują informacji i wytworzenie cudownych narzędzi BI-owych, świetnej infrastruktury nie jest gwarantem tego, że w ten krwiobieg firmy dane wejdą, to jest inne zagadnienie, które też wymaga zaadresowania, jak ludzi przekonać do tego, jak zmienić ich przyzwyczajenia, znałem prezesów, znałem dyrektorów, którzy woleli dostać dane SMS-em albo wiadomością, albo byli przyzwyczajeni do bardzo konkretnej wyglądającej tabelki w Excelu, o konkretnych kolorach i nie było negocjacji, to musi tak wyglądać.

I to wszystko nas prowadzi trochę do takiej idei, która się nazywa self-service, czyli że my w procesie BI-owym udostępniamy narzędzia i pozwalamy organizacji i ludziom korzystać z nich i wyciągać z nich wnioski. Bo tu jest taki zawsze dylemat, czy my jako organizatorzy tego procesu będziemy dobrze wiedzieć, co te dane znaczą, czy jesteśmy w stanie je zinterpretować, jesteśmy w stanie wyciągnąć z nich jakieś wnioski, wiadomo i będziemy dalej od tego procesu, bo nie będziemy sprzedawać, nie będziemy pakować towaru, nie będziemy rozmawiać z klientem, to nie wszystko jesteśmy w stanie tak sprawnie zinterpretować jak ci, którzy na co dzień pracują z tym, z czym pracują.

I wtedy jeżeli jesteśmy w stanie doprowadzić do takiej sytuacji, że oni są w stanie samodzielnie pracować z danymi, wyciągać swoje wnioski od razu, szybko, mając je pod palcem, to tak się definiuje bardzo często sukces BI-owy w organizacji. Zaznaczę, że zgodnie z kilkoma statystykami, bardzo często projekty BI-owe się nie udają w organizacjach. I to są kilkudziesięcioprocentowe wartości badania, które pokazują, że te przedsięwzięcia pomimo tych inwestycji nie doprowadzają do tego efektu.

I to wszystko nas prowadzi trochę do takiej idei, która się nazywa self-service, czyli że my w procesie BI-owym udostępniamy narzędzia i pozwalamy organizacji i ludziom korzystać z nich i wyciągać z nich wnioski. Bo tu jest taki zawsze dylemat, czy my jako organizatorzy tego procesu będziemy dobrze wiedzieć, co te dane znaczą, czy jesteśmy w stanie je zinterpretować, jesteśmy w stanie wyciągnąć z nich jakieś wnioski, wiadomo i będziemy dalej od tego procesu, bo nie będziemy sprzedawać, nie będziemy pakować towaru, nie będziemy rozmawiać z klientem, to nie wszystko jesteśmy w stanie tak sprawnie zinterpretować jak ci, którzy na co dzień pracują z tym, z czym pracują.

Powiedziałeś tutaj, mam wrażenie, o kilku takich krokach, można powiedzieć, w cyklu życia danych w firmie, od ich zebrania, układania, wyciągnięcia jakichś wniosków, zaprezentowania, no i całej infrastruktury, która jest do tego potrzebna.

Domyślam się, że to się przekłada na różne role w zespole BI-owym. Gdybyś mógł chwilkę powiedzieć, jakie role spotykamy, skąd wynika taki właśnie ich podział.

Tak się przyjęło, że chyba takimi dwoma najważniejszymi rolami w tym zespole to jest inżynier danych, ten, który jest odpowiedzialny za ich dostarczenie, i BI developer, czy też analityk danych, bo ten rynek jest cały czas zmieniający się, więc te nazwy się też dosyć zmieniają, który te dane w jakiś sposób konsumuje, to znaczy tworzy z nich raporty, tworzy z nich narzędzia, często też wyciąga wnioski.

I teraz w bardzo różnych firmach różnie się organizuje ten proces, więc czasem się wymaga od tego, żeby ten developer był też trochę inżynierem, czasem się wręcz inżyniera dzieli na pomniejsze role, na przykład takiego, który zapewnia przepływy danych, pipelines, które dostarczają danych, ale też osobno takiego, który modeluje dane, czyli umieszcza je w określonych strukturach, w hurtowniach danych, decyduje o tym, jak je zinterpretować w sensie biznesowym, jak kontrolować ich jakość.

Z kolei BI developera też można czasem rozdzielić na kilka pomniejszych ról, czyli na przykład na takiego analityka biznesowego, który próbuje zrozumieć, jaki biznes ma problem. Biznes, czyli jakby ci nasi klienci wewnętrzni, o których obsługujemy jakby tymi rozwiązaniami, jaki on ma problem i w jaki sposób dane mogą rozwiązać ten problem biznesowy. Może to jeszcze powtórzę kilka razy, ale według mnie to jest najtrudniejsze i najważniejsze zadanie jakby w tym procesie, to znaczy umieć zrozumieć, jak problem biznesowy taki prosty, chcę więcej sprzedawać, coś mi nie idzie, nasi klienci są niezadowoleni, jak my możemy w nim pomóc, dostarczając jakieś informacje.

I powiązanie ze sobą tych dwóch światów bardzo często jest rolą analityka biznesowego, który na przykład na tej podstawie, czego się dowie, i swojego doświadczenia definiuje potem zadanie do wykonania, na przykład dla takiego BI-developera, który już tylko i wyłącznie w pewnych określonych warunkach przygotowuje narzędzie, ale on już dostaje pewne wytyczne, dostaje często wręcz gotową makietę rozwiązania i jest takim wykonawcą i wtedy jakby jego kompetencje są też znacznie węższe.

Gdzieś tam dookoła tego też się pojawiają bardziej wyspecjalizowane role związane na przykład z dbaniem o jakość danych, bo to sobie można wyobrazić, szczególnie w dużych firmach, jak zupełnie osobny obszar, jakość, ale też bezpieczeństwo, bo ono też jest ważne. I coraz też silniej obszar BI wiąże się z data science, więc też czasem te role są ze sobą wiązane, a czasem po prostu to jest element współpracy.

Czy wobec tego jesteśmy w stanie powiedzieć, kim jest BI Developer? Czy to jest bardziej inżynier, czy to jest bardziej analityk, czy to jest bardziej twórca jakichś rozwiązań, albo czy jest jakiś wspólny background zawodowy, który charakteryzuje te osoby?

Tak, i będziemy się poruszać pomiędzy tym wąskim i szerokim ujęciem. Tym najwęższym ujęciem to BI Developer, jak ma w nazwie, bo jest jakimś deweloperem, to jest ta osoba, która tworzy zautomatyzowane raporty z analityką danych, która najczęściej umożliwia jakąś interakcję dla użytkowników, czyli można by nawet powiedzieć, że jest wytwórcą pewnego rozwiązania, może nie programuje tak bardzo, używa pewnych gotowych elementów, ale wytwarza pewne narzędzie. Można sobie wyobrazić, że po jego wytworzeniu już nie ma z nim żadnego kontaktu, ktoś je przejmuje, z niego korzysta. I pewnie dużą rolę BI Developerów na tym polega, po prostu twórczy raporty.

Szerzej, to o czym też wcześniej mówiłem, to jest po prostu uczestniczenie w całym tym procesie biznesowym, czyli zrozumienie potrzeb, zebranie ich, podsumowanie, stworzenie narzędzia, wdrożenie tego narzędzia, przeszkolenie pewnych ludzi. I w zależności od tego, w jakiej organizacji i trybie pracy realizujemy tę rolę, to będziemy albo szerzej, albo węziej to realizować.

To jest cały dosyć szeroki wachlarz różnych możliwości, różnych kombinacji. To teraz może chciałbym Cię zapytać, jakie kompetencje, jakie umiejętności musi taka osoba posiadać? Czy to zależy właśnie od tego, jaka jest ta węższa rola w organizacji, czy też może jest jakiś taki ogólny, wspólny zestaw kompetencji, umiejętności, które trzeba po prostu posiadać, chcąc występować w tej roli?

Idąc od tych najprostszych, to będąc Developerem BI, trzeba się znać na narzędziach BI-owych. I to już bardzo zależy od tego technologicznego stacka, który dana firma wybierze. Tego oprogramowania jest trochę. To najbardziej znane to jest np. Microsoft BI czy Tableau. Teraz też przebojem i mocą Google wbija się Looker, czyli dawne Google Data Studio. I też masa innych rozwiązań, których trochę narosło w tych latach. Więc trzeba go umieć używać.

Używanie go nie jest do końca programowaniem, bo to jest takie trochę rozwiązanie click and play. Możemy sobie w bardzo prosty sposób pewne rzeczy składać, w zależności od którego rozwiązania to jest mniej lub bardziej intuicyjne. Więcej tam jest chyba o tym, że trzeba umieć wizualizować dane. Jest cała taka dziedzina data storytellingu, czyli umiejętności opowiadania pewnych historii danymi, narracji. Żeby raport nie był zwyczajnym zlepkiem jakiejś wizualizacji, tylko był czymś, co odpowiada ponownie na tę potrzebę biznesową, żeby rozwiązywał jakiś problem, żeby dał nam jakieś odpowiedzi.

Więc tak uzupełniając, te narzędzia BI oraz umiejętność wizualizacji danych, która wydaje się być prosta, bo przecież każdy z nas umie w Excelu sobie zrobić wykres kołowy, ale za tym są i dobre praktyki, i pewna sztuka, i też pewne umiejętności i predyspozycje, żeby umieć opowiadać historię danymi w sposób klarowny, czytelny, komunikowalny dla naszych odbiorców. I też nie trudno wyłapać tego elementu, że trzeba też rozumieć biznes czy model biznesowy, który analizujemy, żeby móc też robić rzeczy sensowne, a nie jakieś takie artefakty danych.

Więc to jest taki core, który wszyscy muszą znać. I jak spojrzymy sobie na oferty pracy, to się zawsze od tego zaczyna. Potem jakiś język bazodanowy, najbardziej uniwersalny SQL, który jest też w takiej czy innej formie językiem różnych rozwiązań chmurowych, w stylu tych googlowskich czy Amazona. I ten SQL zawsze się przyda. Nawet jeżeli będziemy mieli inżyniera danych, który nam te dane w jakiś sposób bardzo już bezużytkowy dostarcza, to na jakimś etapie musimy się zastanowić, jakie dane pobieramy, w jaki sposób, czasem musimy połączyć ze sobą jakieś tabele, musimy rozumieć, na czym polegają te połączenia, czym są klucze, czym są połączenia jeden do wielu, wiele do wielu.

Więc też taką minimum wiedzy na temat modelowania danych jako ich użytkownik musimy rozumieć. Czyli jeżeli używamy jakichś zbiorów danych opartych na przykład na strukturze gwiazdy, to musimy wiedzieć, co to jest i w jaki sposób z tego korzystać.

Nie musimy być bardzo zaawansowani w SQL-u, rzadko się tego wymaga, chyba że w tych takich naprawdę full stackowych rolach, gdzie ktoś chce, żeby ktoś to zrobił od początku do końca, ale musimy rozumieć, na jakich danych korzystamy.

Dla mnie zawsze najważniejszym pytaniem jest, co reprezentuje pojedynczy wiersz zbioru. To jest taki poziom też myślenia o tym, czy to jest jeden klient, jedna transakcja, jedna wykonana instalacja, czy czym to jest. Więc to jest mniej więcej taki poziom, który trzeba znać. Przydałaby się jakaś wiedza z dziedziny analizy danych i statystyki. To znaczy, żeby znać podstawowe koncepty, analityki, eksploracji danych, czym są miary opisowe, takie jak jakaś częstość, średnia, mediana, bo to są takie wskaźniki, których używamy i też tego od nas użytkownicy potrzebują, ale też tych takich złożonych bardziej konceptów, czyli takich, jak można pokazać, albo odkryć współzależność pomiędzy pewnymi zagadnieniami. Czy nasza sprzedaż jest jakoś związana z tym, jak zachowuje się nasza obsługa klienta, czy takie problemy się mogą pojawiać, więc też musimy mieć takie narzędzia analityczne, żeby to pokazać, chociażby w postaci wykresu rozrzutu, tabeli krzyżowej, tym podobnych rzeczy.

Więc ponownie nie trzeba się tutaj specjalizować w jakichś modelach regresyjnych czy bardziej zaawansowanych konceptach statystycznych, ale trzeba rozumieć podstawową statystykę, bo się jej używa.

Powiedziałbym też, że warsztat pracy z danymi, bo wydaje mi się, że bardzo dużą wartością ja i dewelopera, ale też każdego analityka jest to, żeby umieć w sposób przewidywalny, monitorowalny pracować z danymi w ten sposób, że jesteśmy w stanie wyłapać błędy, jesteśmy w stanie uczyć się na swoich błędach, nie popełniamy systematycznych błędów, takich, których np. tworzymy zmienne, nie sprawdzamy rezultatu, bo to wszystko sprawia, że po pierwsze nie generujemy problemów z danymi, które podważają wiarygodność nas jako osób w zespole, ale też po prostu całej naszej operacji, bo jeśli te raporty pokazują rzeczy, które łatwo podważyć, powiedzieć, że są źle wyliczone, to po co to robiliśmy, po co wydawaliśmy na to dużo pieniędzy.

A z drugiej strony wyłapywać błędy, bo będziemy zawsze popełniać błędy i coś nam się omsknie, jakiś warunek nam się nie pojawi, komórka nam się przeklei z jednego miejsca w drugie i to się wszystkim zdarza, niezależnie ile lat z tym pracują, natomiast umiejętność do szybkiego wyłapywania tego i też taki wieloetapowy sposób pracy z danymi, w których swoje wyniki potwierdzamy, weryfikujemy, to różni tego dojrzałego analityka od tego początkującego czy średnio zaawansowanego.

Zastanawiam się, jak oceniasz znaczenie albo wielkość tego komponentu, powiedzmy techniczno-inżynieryjnego i tego z kolei biznesowego, czy któregoś jest więcej pracy BI-dewelopera, czy masz jakieś wskazówki albo jak gdyby tutaj taki przekaz, w którą stronę osoba w tej roli powinna bardziej się rozwijać, to jak byś mógł to ująć?

Wydaje mi się, że z dostępnością narzędzi, które są gotowymi rozwiązaniami, tymi dużymi pakietami BI-owymi, to jest coraz mniej technologiczny proces. Dlatego że kiedyś BI też funkcjonowało, odkąd się pojawiły komputery, tylko sposób wytworzenia jakichś takich dashboardów, jakichś raportów był procesem na przykład programowania, procesem wystawiania pewnych usług webowych, to było po prostu technicznie zaawansowane zagadnienie.

Natomiast w tym momencie te narzędzia są proste, to znaczy nie wymagają ogromnych kompetencji, żeby z nich skorzystać. Wiadomo, że te kompetencje się bardzo przydadzą i pomagają rozwiązać bardziej złożone problemy. Natomiast zrozumienie procesu biznesowego i wiedzieć, jak dane wykorzystywać w biznesie, to jest to, co jest unikalne.

Jest dużo takiej koncepcji, że to jest pół na pół. Mówi się też właśnie o takim bardzo specyficznym połączeniu, bo możemy z jednej strony mieć programistę albo matematyka, który zaczął robić wizualizację, ale gdzieś mu trudno jest zrozumieć potrzeby biznesu, czym jest sprzedaż, logistyka, kontroling, takie może być abstrakcyjne dla niego elementy. A z drugiej strony można sobie wyobrazić kogoś, kto pracuje już operacyjnie, czyli sprzedaje, wysyła, sprawdza jakość i tak dalej, który nagle zapragnął dostarczyć sobie narzędzi, ale też technicznie nie jest biegły.

Więc cudownie byłoby mieć kogoś, kto posiada obie te strony. I pewnie w każdym zespole jest jeden, który jest trochę mocniejszy w tej stronie biznesowej i jeden, który jest mocniejszy w stronie technologicznej i jeżeli będziemy współpracować ze sobą, to coś wypracujemy. Ale ci, którzy są doskonali w obu stronach, to są tacy jednorożce, których się szuka. I jakbym miał oceniać, co będzie tworzyć wartość na rynku pracy w przyszłych latach, to właśnie takie kompetencje. Łączenie dziedzin, mniej wąski obszar technologiczny.

Tak, tak, zgadzam się absolutnie i powiem Ci szczerze, że jesteś kolejną osobą, która z kolei z tego trochę innego obszaru, bo ja najczęściej poruszam się w programowaniu aplikacji webowych, kolejną osobą, która potwierdza, że znaczenie umiejętności miękkich, nazwa może niekoniecznie super, ale wiemy, o co chodzi, ma znaczenie, jest istotne, jest wręcz niezbędne w nowoczesnym IT i po prostu nie możemy uciekać, nie możemy zamykać oczu przed tym właśnie obszarem. Rozwój, nasz rozwój w tym obszarze może być też doskonałą taką, czymś, co nas doskonale wyróżnia na rynku pracy, tak jak Ty powiedziałaś. Może oznaczać coś tak przyziemnego, jak chociażby lepsze zarobki, zwyczajnie.

Okej, wiesz co, Michał, teraz bardzo fajnie namalowałeś taki krajobraz tego, jak praca BI developera wygląda, albo jakie problemy ona opowiada, jakie kompetencje musi posiadać, ale myślę sobie, że nieuchronnie zbliżamy się do pytania o narzędzia. Czyli to pytanie, które pewnie tutaj zaciekawi wszystkich inżynierów. Co ty wykorzystujesz w swojej pracy? Jakie są takie standardy rynkowe obecnie, jeśli chodzi o narzędzia w pracy BI-developera?

Tych narzędzi jest coraz więcej. Są liderzy rynkowi, tacy, którzy dominują na rynku. I to jest trochę związane z usługami chmurowymi, bo jeżeli w usłudze chmurowej mamy też od razu pakiet BI-owy, to wszystko posiadamy w jednej infrastrukturze, w jednym sposobie wyceny, nie ma problemu z transferem danych pomiędzy jakąś hurtownią danych a narzędziem BI-owym. Więc na przykład najbardziej popularne teraz rozwiązanie to jest Microsoft Power BI, głównie dlatego, że jest on elementem wszystkich usług Microsoftu, które on udostępnia i dostęp do infrastruktury jest uproszczony.

Lustrzanie na przykład Google w tym momencie promuje produkt, który się nazywa Looker. To się kiedyś nazywało Google Data Studio, potem Google wykupił firmę Looker i połączył te dwa rozwiązania. Jego główną wartością też jest, według mnie, integracja z pozostałymi usługami chmurowymi. Z łatwością się dostaniemy do BigQuery czy wręcz do usług, które chcemy analizować w stylu Google Analytics czy AdWords czy tym podobne rzeczy.

To są takie dwa rozwiązania, które są najbardziej znane z tego, że są związane i powiązane z usługami chmurowymi. Osobiście pracuję na oprogramowaniu, które się nazywa Tableau, które też jest, wydaje mi się, drugim najbardziej popularnym rozwiązaniem w tym obszarze. One wszystkie mają swoje plusy i minusy, i niuanse. 

Trochę się tak utarło, że BI deweloperzy się specjalizują w jednym z nich, bo jednak ta wiedza zgromadzona w toku wielu projektów, co działa, co nie działa, każdy z tych oprogramowań ma jakieś swoje smaczki, że w niektórych przypadkach musisz używać rozwiązań magicznych, obrócić trzy razy na pięcie i dopiero to zacznie działać. I skumulowanie tej wiedzy jest przydatne, bo w zasadzie one są bardzo podobne do siebie, więc teoretycznie tu i tu można zrobić to samo.

To jest też znajomość jakiegoś narzędzia i biegłość w jego posługiwaniu się po prostu.

A luszczanie z drugiej strony to hurtownie danych, czy też teraz tych zagadnień związanych z udostępnianiem danych jest bardzo dużo. Data Lake’i, hurtownie danych, ta dziedzina już jest bardzo szeroka. Ja sobie patrzyłem ostatnio na taki poster, taki plakat ze wszystkimi rozwiązaniami w każdym tym obszarze przechowywania, przetwarzania, pipelines. Myślę, że tam jest kilkaset różnych rozwiązań, które w różnej kombinacji można ze sobą połączyć.

Natomiast akurat BI Developer nie jest inżynierem danych zazwyczaj, więc on jest raczej użytkownikiem tych usług. Więc właśnie, na przykład GCP, AWS, usługi chmurowe, gdzie po prostu pobieramy dane. Dla BI Developera może to oznaczać tylko kliknięcie „pobierz mi z tego projektu tą tabelę, a ja już się dalej tym zajmę” i tam się mojego kontaktu może skończyć. Czasem niektóre firmy mogą zdefiniować szerzej te obowiązki związane z korzystaniem z tego. 

Ja akurat korzystam z usług google’owych i też tutaj poszerzamy swoje kompetencje. No i też dookoła tego są różne usługi, które pomagają, ale też zdarzało mi się ze Snowflakiem pracować, który też ma swoje rozwiązania, też ma swoje umiejętności, jakieś można tam wykorzystać. I chyba tyle, bo cała reszta to są jakieś rozwiązania komplementarne. Rozwiązanie BI-owe i to, skąd biorę dane, to są chyba te takie dwa najważniejsze.

Dobrze, zastanawiam się, kto jest klientem BI Developera, kto jest odbiorcą jego pracy i co właściwie ta osoba dostarcza.

My ich nazywamy biznes. Nie wiem, czy to się utarło wszędzie, my jesteśmy coś, a oni są biznes. Czyli nasi różni klienci wewnętrzni w naszej organizacji, a czasem też zewnętrzni, bo czasem też usługi BI-owe są też usługami, szczególnie w tych takich dzielonych centrach usług, są usługami pełnionymi dla zewnętrznych klientów, czyli jakichś tam obsługiwanych firm.

Więc po pierwsze mamy ten rozdział, ten biznes i my i ten biznes oczywiście jest bardzo różny, bo zdarzało mi się pracować z zarządami i jednocześnie z szeregowymi pracownikami poszczególnych działów. To są czasem osobne wszechświaty, na przykład w naszych zespołach byśmy się specjalizowali w danych obszarach. Był ktoś, kto dobrze orientował się w obszarze marketingu, więc robił raport i proces analityczny marketingowy, uczestniczył w spotkaniach biznesowych. Próbował być trochę takim oficerem danych, czyli osobą, która mówi, co mamy, co możemy poszukać albo wyłapuje jakiś problem, który możemy rozwiązać. A ktoś inny na przykład świetnie się orientował w procesach finansowych, ekonomicznych, kontrolingowych, rozumiał w ogóle te zagadnienia, wiedział, co wsadza do tych tabelek, co to są te etykiety, które tam umieszczam, do czego one służą.

Więc tutaj nie ma jednej odpowiedzi. Potencjalnie odbiorcą BI są wszyscy w organizacji na każdym szczeblu. Zazwyczaj jednak to jest zarząd, bo oni najczęściej mają siłę przebicia, żeby sobie takie usługi zapewnić, czy jacyś dyrektorzy, a potem już te dziedziny, które, powiedzmy, bardziej z danymi pracują. Takim naturalnym klientem są dziedziny, które pracują z finansami, czyli kontroling, księgowość, finanse, też po prostu szerzej, bo oni muszą na bieżąco robić pewne zestawienia, pewne analizy finansowe, też bardzo często muszą sprawozdawać te rzeczy na zewnątrz. Więc to są te naturalni klienci.

Z kolei marketing by zawsze chciał wiedzieć, jakim idzie i czy działania, które prowadzą, przynoszą sukces. I to jest też taki klient, który bardzo często chce coś wyciągnąć. Ale na przykład zdarzało nam się robić projekty dla HR-ów, czyli na przykład śledzić kompetencje, w tym sensie, że jakoś tam je monitorować, analizować, stawki wynagrodzeń, porównywać je z rynkiem.

Więc w każdym obszarze można sobie wyobrazić taką dziedzinę analityczną, w której ktoś będzie chciał z nami rozmawiać i współpracować. Dla nas ten biznes jest przede wszystkim odbiorcą naszych produktów, ale też jakby dostawcą danych i też takiej wiedzy, co one oznaczają, która nam pomaga w pracy. A to, co my im oddajemy, to najczęściej narzędzia. Jeżeli myślimy o tym self-service, analytics, czyli takiej sytuacji, w której oni sobie z nich korzystają, to są zazwyczaj narzędzia, ale są też takie potrzeby, żeby czasem coś przeanalizować samemu i dostarczyć nie narzędzia, ale insajtu. I wtedy już przechodzimy bardziej w kierunku analityka danych, który w niektórych modelach biznesowych i sposobach organizacji firmy jest osobną, komplementarną rolą.

Rozumiem. W tej chwili przed nagraniem rozmawialiśmy o tym, żartowaliśmy sobie, że jako branża dawno już wyszliśmy z piwnicy i domyślam się, że w przypadku BI deweloperów to też nie jest tak, że działają oni jako samotne wyspy, ale muszą współpracować z wieloma rolami w firmie, aby dostarczać tą swoją pracę. Więc no właśnie z kim na co dzień taka osoba w organizacji może współpracować?

Inżynier danych to jest ta pierwsza osoba, z którą będzie współpracować, bo od niego dużo zależy, chyba że w tej organizacji on jest też inżynierem danych. Albo ona. Czasem tak się specjalizujemy, że mamy też wręcz projektantów rozwiązań UX-owych dla raportów, bo ten raport trzeba też jakoś skonstruować wizualnie, żeby on był zgodny z jakąś tam identyfikacją wizualną firmy, żeby był atrakcyjny, bo też tak ludzie trochę oceniają wiarygodność tych narzędzi. Czy to jest spójne, czy to wygląda po prostu jak jakiś brudnopis, jakiś szkic. Czasem patrzymy na różne nawet Excel’e i od razu myślimy sobie, że to zostało przygotowane w sposób profesjonalny, a to wygląda jakby ktoś dużo rzeczy poprzeklejał, każdy w innej wielkości.

Więc wydaje się to być zagadnieniem błahym, że jakaś estetyka, jakieś fonty, jakiejś wielkości czcionek, ale przy komunikowaniu wyników ta estetyka jest bardzo ważna, bo ona buduje wiarygodność tych danych. Zdarzają się też na przykład współpraca z UX-owcami, czy po prostu projektantami graficznymi, i właśnie z tymi wszystkimi biznesowymi naszymi partnerami, którzy nam mówią, czego chcą, przy współpracy z analitykiem biznesowym, który potrafi czasem to przygotować i jakoś nam ułatwić, albo wręcz bezpośrednio.

Mnie się też zdarzali CBA deweloperzy, którzy mówili, że oni nie chcą rozmawiać z ludźmi, bo biznes ciągle coś chce, też czasem mówi nieprecyzyjnie, wraca z tymi samymi zadaniami. Niektórzy chcieli tego unikać i zdarzało nam się ten proces projektować, żeby na przykład tych, którzy sobie lepiej z tym razem wystawiać jakby frontem do biznesu, żeby rozmawiali, zbierali pewne zagadnienia, a niektórych się wręcz zostawiało w naszej takiej bańce, której mogli już sobie wykonywać swoją pracę, nie mierząc się z tymi wyzwaniami.

Mnie się też zdarzali CBA deweloperzy, którzy mówili, że oni nie chcą rozmawiać z ludźmi, bo biznes ciągle coś chce, też czasem mówi nieprecyzyjnie, wraca z tymi samymi zadaniami. Niektórzy chcieli tego unikać i zdarzało nam się ten proces projektować, żeby na przykład tych, którzy sobie lepiej z tym razem wystawiać jakby frontem do biznesu, żeby rozmawiali, zbierali pewne zagadnienia, a niektórych się wręcz zostawiało w naszej takiej bańce, której mogli już sobie wykonywać swoją pracę, nie mierząc się z tymi wyzwaniami.

 

Mam wrażenie, że z tego jak rozmawiamy o tym temacie może wynikać, że biodeveloper to jest zawsze pracownik firmy, który bardzo dobrze zna tą domenę, potrafi zrozumieć, gdzie mogą jakieś takie przewagi się pojawić, w jaki sposób zaprezentować te dane. Czy to jest jedyny model pracy biodevelopera w branży?

Absolutnie nie. Wydaje mi się, że to pandemia nam to zrobiła, że ten rynek pracy się tak mocno uwolnił, umiędzynarodowił, więcej korzystamy z freelancerów, w związku z tym jakby też jest więcej takich okazji, żeby pracować jako biodeveloper w bardzo różnych ustawieniach.

To, o czym ja mówię, to jesteśmy w firmie, w organizacji i pracujemy na przykład ze swoim zarządem dla swojej firmy i to jest taki powiedzmy, nazwijmy in-house taki, który dobrze rozumie, gdzie pracuje i jakie realizuje potrzeby, ale też bardzo częstym modelem jest bycie usługodawcą, czy to w ramach po prostu firmy doradczej, bo jest dużo firm doradczych, które realizują usługi BI, czyli przychodzą do firmy i ten BI robią. Rozumieją ich potrzeby, dostarczają narzędzi, czasami z tym zostawiają, czasem robią jakiś buddy leasing, czyli udostępniają swoich pracowników jako wsparcie, i wtedy taki biodeveloper nie siedzi w tych firmach, tych poszczególnych, tylko siedzi przez jakiś czas na jakimś projekcie i to może być usługodawca na rynku polskim, albo tak jak w wielu tych usługach dzielonych, może być to po prostu usługodawca, który jest dzielony, czy to w obrębie jednej firmy i jej grupy kapitałowej, czy też po prostu we wszystkich firmach. To już tych modeli korporacyjnych jest bardzo dużo.

To, co wyróżnia tą rolę, to to, że wtedy ma się możliwość oglądania bardzo różnych firm, różnych kontekstów biznesowych. Raz się jest w takiej organizacji, raz się jest w takiej organizacji, to oczywiście są zazwyczaj projekty wielomiesięczne, czy czasem wieloletnie, ale też zdarza się praca na kilku projektach, naraz.

I taka najmniej chyba przeze mnie zbadana, ale też widziana przeze mnie na różnych serwisach z ofertami pracy, praca jako freelancer, czyli ja się śmieję, że szukam trzeciego do trójki murarskiej, nie? Czyli taka bardzo lotna organizacja zbiera trzech, czterech specjalistów, na przykład inżyniera, dwóch BI-owców, jakiegoś UX designera i angażują się w pojedynczy projekt. Ten projekt może trwać pół roku, może trwać rok, może mieć zagwarantowaną liczbę godzin pracy, ale nie musi, bo to też bardzo różnie wygląda, ale za to może być robiony na przykład dla klientów zachodnich, gdzie oczywiście stawki są może już nie tak znacznie wyższe, ale można już sobie je wynegocjować.

I to już jest zupełnie inny typ pracy, bo o ile ten in-house, to bardzo często siedzi w firmie i to jest bardzo korzystne, bo też słucha, wie, co tam się dzieje, chociaż ja na przykład w tym momencie jestem takim in-housem, ale pracuję 100% zdalnie, mam taki model współpracy. Ja jestem w Krakowie, firma jest w Poznaniu, więc też już tam się zmienił ten rynek, ale jaki freelancer, to może tu pracować dla Australii, tu pracować dla Wielkiej Brytanii, a zaraz się organizować na jakiś proces dla, nie wiem, Arabii Saudyjskiej.

Więc to też jest model. Ja nie pracowałem tak nigdy, ostatnio jak zmieniałem pracę, to dostałem różne takie oferty. Ja akurat się na nie nie zdecydowałem, bo zależało mi na stabilności, zależało mi na dłuższej relacji z firmą, bo chciałem się więcej nauczyć o danym biznesie, ale wyobrażam sobie, że dla wielu to może być bardzo atrakcyjny model pracy, bo mniej limitowane godziny pracy, większa swoboda, czasem też wyższe wynagrodzenie.

Myślę, że tutaj możemy płynnie przejść do tematu ścieżek kariery. Mam wrażenie, że mówiliśmy o BI Developerze jako takiej osobie, która pojawia się w organizacji, robi swoją robotę i po prostu w tym miejscu zostaje. Natomiast domyślam się, że tak to nie wygląda, więc w jaki sposób BI Developer może się rozwijać, kierować swoją karierą?

Chyba najważniejsza to jest ta kwestia, żeby rozwijać swoje umiejętności zrozumienia biznesu. Tak jak wcześniej sugerowałeś mi niektóre pytania, mówiliśmy o ścieżkach karier, to się zastanawiałem, jak się zostaje BI Developerem, bo to może też jest ciekawe. Z ciekawostek, ja jestem na przykład socjologiem i jestem co prawda po takiej socjologii analitycznej z elementami programowania, więc nie takie oderwane jakby od tej rzeczywistości, ale tych ścieżek naprawdę może być wiele.

Z tego powodu, o którym wcześniej mówiłem, że możemy być tym takim inżynierem, który bardzo dobrze rozumie zagadnienia technologiczne i nagle chce się nauczyć, jak wykorzystać to w kontekście biznesowym. I taka ścieżka będzie inna. Na przykład w moim aktualnym zespole jest matematyczka. Zdarzają się informatyka stosowana, to jest taki naturalny też kierunek. Zdarzają się różne też już takie specjalistyczne jakby kursy związane z BI-em czy po prostu z analityką danych. I tacy ludzie mają inną ścieżkę kariery, bo oni bardzo często mają bardzo dobry background technologiczny. Oczywiście muszą go cały czas rozwijać i zmieniać, ale muszą się nauczyć realiów biznesowych tej materii.

Tutaj trudno zaplanować tę ścieżkę. Wydaje mi się, że doświadczenie zawodowe to daje. Czyli trzeba w tej firmie być po prostu ciekawym. Trzeba pytać, a po co to, a na co to. To chyba jest taka moja zawsze porada dla każdej osoby, z którą współpracuję, czy której jakby rozwój prowadzę, to, że nigdy nie realizuj zlecenia w firmie bez zapytania się, po co masz to zrobić. Bo nagle się okazuje, że może jest inne rozwiązanie, ty się czegoś dowiadujesz o danych, więc ten obszar sobie trzeba tak kształtować.

Natomiast jest jeszcze ta druga ścieżka, to znaczy ludzie, którzy zostają BI-developerami z tych dziedzin takich kierunkowych, na przykład byli finansistami, zajmowali się księgowością, kontrolingiem, zajmowali się innymi takimi dziedzinami, gdzie używali analityki i teraz by chcieli się sprofesjonalizować. I tutaj oni muszą bardziej nadrobić te zagadnienia technologiczne i tutaj tych rozwiązań jest bardzo dużo. Kursów online, przemiłych panów i pań z Indii, którzy tłumaczą, jak pewne rzeczy zrobić w internecie, jest bardzo, bardzo dużo.

Są też oczywiście systemy certyfikacji. Microsoft ma bardzo swoje rozbudowane, Tableau ma swoje, które tak naprawdę trochę porządkują tę ścieżkę i udostępniają pewne sposoby potwierdzenia tych kompetencji. Ale jesteśmy w stanie to nadrobić za pomocą różnych internetowych zasobów.

I można oczywiście pójść dalej, bo teraz umiejętność połączenia tego jeszcze z programowaniem, bo w każdy system BI-owy można wpleść zewnętrzne rozwiązania oparte na Pythonie czy na Azure, czyli tych takich wiodących rozwiązaniach analityki i data science, no to wtedy zaczynamy być coraz mocniejszym pracownikiem w tych obszarach i też powoli migrować w kierunku np. data science.

Bo to znaczy, że do naszego procesu BI-owego, tej wizualizacji, możemy nagle np. wrzucić jakiś model predykcyjny, bo przetworzyć w jakiś sposób niestandardowy dany, więc jakby umiejętność programowania, ale przede wszystkim w tym programowaniu pracy ze strukturami danych, bo w tym Pythonie, data science to nie Python jest najważniejszy.

Czasem cały kod składa się z pięciu linijek, jakaś tam umiejętność pisania obiektowego czy funkcjonalnego nie jest aż tak szalenie ważna, wręcz można mieć od kogoś innego, ale umiejętność pracy ze strukturami danych, z konkretnymi bibliotekami, które je przetwarzają, też rozumieć modele statystyczne, które za nich stoją, no to jest najważniejsze.

Ale też można zostać i być po prostu BI-developerem. Tutaj jakby tych ścieżek rozwoju jest dużo. Ja myślę np. o swojej ścieżce w takim obszarze łączenia BI z data science, bo też moje wykształcenie mnie do tego jakby predystynuje, ale można też sobie myśleć o tym, żeby być osobą, która zarządza, czy też jakby podejmuje decyzje na podstawie tych danych. To też jest taka ścieżka, z którą można wskoczyć. To znaczy pracować, być analitykiem, wyciągać wnioski, dostarczać insightów, a potem zacząć coś z tym robić.

Czyli trzeba w tej firmie być po prostu ciekawym. Trzeba pytać, a po co to, a na co to. To chyba jest taka moja zawsze porada dla każdej osoby, z którą współpracuję, czy której jakby rozwój prowadzę, to, że nigdy nie realizuj zlecenia w firmie bez zapytania się, po co masz to zrobić. Bo nagle się okazuje, że może jest inne rozwiązanie, ty się czegoś dowiadujesz o danych, więc ten obszar sobie trzeba tak kształtować.

Czyli znowu mamy mnogość różnych możliwości. To jest pewnie bardzo fajne właśnie w tej roli, ale zanim będziemy stali przed taką możliwością dokonania tego wyboru, no to wypadałoby może powiedzieć chwilkę o tym, jak wygląda obecnie rynek pracy, może proces rekrutacji na tę rolę, czego takie osoby mogą się podczas tego procesu spodziewać.

Na pewno rynek pracy dla tej roli się zmienia i będzie się zmieniał. Jak wejdziemy sobie na różne serwisy pracy i poszukamy sobie BI dewelopera, to się okaże, że pod tymi samymi nazwami są bardzo różne stanowiska. I dopiero w tekście tych ogłoszeń rekrutacyjnych jesteśmy w stanie zorientować się właśnie, w jakim trybie będziemy pracować, czy raczej takim usługodawczym, czy takim in-house’owym, z jakim oprogramowaniem będziemy pracować, czego się od nas oczekuje, na przykład w dziedzinie inżynierii danych. Bardzo też często to są role po prostu nazywane analityk danych, tylko ma gdzieś w wymaganiach wpisane, że musi umieć pracować z narzędziami BI-owymi.

Więc tutaj trzeba być bardzo uważnym, patrząc na te ogłoszenia, żeby spróbować zrozumieć, jaki model pracy, jaki model kompetencyjny na firma wymaga. A co za tym idzie, też te stawki wynagrodzeń są szalenie różne. To znaczy, jeden analityk danych z dopiskiem BI gdzieś tam w dopisku może mieć zaproponowaną stawkę z rzędu kilku tysięcy nawet złotych. To ja szczególnie obserwuję takie oferty w przypadku jakichś takich dużych banków, dużych instytucji finansowych, że tam tych analityków się bardzo dużo zatrudnia i niestety o takich stawkach dosyć niskich, które wręcz nie są traktowane jako IT. Bo to jest ta wielka różnica, czy ja jestem rozumiany jako IT, czy nie.

Ale mamy też właśnie szum nienazwanych BI-developerów, senior BI-developerów, jeszcze nawet bardziej złożonych stanowisk, gdzie potrafią być stawki rzędu kilkudziesięciu tysięcy złotych, które tak patrząc sobie na same ogłoszenia, na ich formy, bardzo często one wyglądają bardzo podobnie. Ta różnica jest prawdopodobnie przede wszystkim w tej dojrzałości, osoby, która to używa też biegłości w tej technologii i też tej szerokości, czy jesteśmy takim full stackiem, który robi wszystko od początku do końca, czy jesteśmy tylko takim małym trybikiem, który musi uruchomić tablo czy lookera, porzucać kilka wykresów i oddać, nie zastanawiając się nad resztą procesu.

Więc przy szukaniu pracy i wejściu na ten rynek bym przede wszystkim zalecał taką uważną analizę tych ogłoszeń, bo same nazwy stanowisk na tym etapie niewiele mówią. Ja myślę, że za może kilka lat, chociaż teraz AI pewnie nam to wszystko zupełnie znowuż poprzestawia, te nazwy stanowisk się trochę bardziej unormują, już będzie wiadomo, kto jest kim.

Wydaje mi się, że jest duże zapotrzebowanie. Ta profesjonalizacja analityków, BI developerów, bo można tak o tym myśleć, że bierzemy tych takich mistrzów Excela i robimy z nich programistów i traktujemy to jako proces tworzenia oprogramowania, taki developerski, przyśpiesza. Dzisiaj sobie wszedłem i widziałem kilkaset ogłoszeń. I też zagranicznych, i polskich i to się też będzie po prostu zmieniać korzystnie.

Zdecydowanie. Myślę, że liczba rośnie i rośnie też jakość tych ogłoszeń, ale tutaj tak jak powiedziałeś, rada numer jeden, czytajmy wnikliwie te ogłoszenia i spróbujmy zrozumieć jakie będą przyszłe nasze obowiązki, co będziemy musieli robić. To na pewno można poradzić. Co jeszcze polecałbyś osobom, które myślą właśnie o zostaniu BI developerem?

Jeżeli chodzi o pozostanie, no to tak, opanować narzędzia. Narzędzia trzeba umieć wykorzystywać i to nie jest wcale trudne. To jest proces nawet kilku miesięcy pracy z nimi. Zresztą one w większości występują w formach też darmowych, które można sobie przetestować. Tableau ma na przykład Tableau Public, który jest całkowicie publiczny. Jedyne ograniczenie jest takie, że to co wytworzysz, muszą wszyscy móc zobaczyć, ale do uczenia się jak najbardziej jest to zasadne. Looker też ma takie opcje, Power BI też ma takie opcje, więc trzeba być dobrym w tych narzędziach. Trzeba wiedzieć jak się z nich korzystać, orientować się w zmianach, bo one się też rozwijają.

Myśleć o swoim warsztacie pracy – to jest trudno do ujęcia, bo ja nawet chyba nie widziałem jakichś kursów z warsztatów pracy z danymi. Zdarzały mi się takie na jakichś konferencjach, pojedyncze wystąpienia, gdzie ktoś trochę opowiadał jak on to robił. Mam wrażenie, że nie ma tu takiej spójnej metodyki, która mówi jak to dokładnie zrobić, że jednak wszyscy sobie trochę wypracowujemy samodzielnie, ale grunt jest myśleć o tym. Nie zakładać, że wystarczy, że coś tam poklikam i wynik będzie doskonały. Trzeba myśleć o tym jak sprawiać, żeby nasza praca była powtarzalna, to znaczy, że dało się ją odtworzyć, żeby można było reprodukować wynik, który wytworzyliśmy, żeby była dokumentowalna, żeby można było analizować jej jakość, czy można było wyłapywać błędy. O tym trzeba wszystkim jakoś tam sobie pomyśleć i zdobywać doświadczenie w danym biznesie. To jest ważne.

Więc praca w jakiejś firmie, w dodatkowym obszarze, jak na przykład zaczniemy w finansach, czy na przykład w energetyce, czy gdziekolwiek indziej, to w kolejnej pracy będzie nam znacznie łatwiej, bo będziemy wiedzieć, o czym rozmawiamy, będziemy znać te różne sformułowania, dziwne trójliterowe skróty, instytucje, z którymi pracujemy. Ja na przykład teraz wszedłem do nowej branży finansowej i to jest wyzwanie duże, żeby zrozumieć, na czym to wszystko tu polega. Ja się na nie bardzo cieszę, bo ja chcę rozumieć różne konteksty biznesowe, bo tak upatruję swoją przyszłość też biznesową, żeby mieć bardzo szerokie spojrzenie, ale te węższe też się przyda. Dobrze gdzieś tam na boku sobie Pytona przećwiczyć, zrozumieć. Jest dużo tych kursów online, które można zrobić.

Czy się testuje te umiejętności na spotkaniach? Tak. To jest takie odwieczne pytanie o tym, czy robić testy, czy robić zadania domowe na procesach rekrutacyjnych. Ze względu na to, że kilka z tych obszarów jest dosyć ulotnych, tak jak na przykład umiejętność opowiadania o danych. Każdy sobie w CV wpisze, że jest świetnym storytelerem. To ja zachęcam i też samodzielnie często realizuję jakiś rodzaj testów. Takie, które przynajmniej coś mi są w stanie pokazać. Na przykład, czy umiesz opowiedzieć historię danymi, umiesz zwizualizować, czy jesteś dokładny, czy zwracasz uwagę na detale, czy jesteś w stanie wyłapać pewne rzeczy intuicyjnie, nawet nic nie wiedząc o tym zbiorze. Jak to jest, że tutaj rośnie, a tu spada? To dziwnie wygląda. Zadajmy sobie pytanie, dlaczego tak jest.

Taką uważność w detalu można wyłapać na rozmowach i na jakichś takich krótkich, nawet prostych ćwiczeniach. Masz zbiór, masz 30 minut, powiedz mi coś o nim i zwizualizuj mi to. To jest dla mnie na przykład bardzo takie wręcz decydujące doświadczenie, którym jestem w stanie zdecydować, czy ktoś się nadaje do tego, czy nie nadaje.

Dzięki za te cenne porady. Naszą rozmowę nagrywamy w połowie 2023 roku, gdzie sztuczna inteligencja, zwłaszcza w tej odmianie generatywnej, podbija świat. Nie mogę Cię, Michał, nie zapytać o to, czy AI zastąpi w ogóle BI, czy będzie w stanie samo jakieś wnioski wysuwać, w związku z tym eliminując potrzebę zatrudnienia BI deweloperów. Jak Ty patrzysz na ten nowy trend?

Wszyscy trochę zgadujemy, bo jednak rozwój jest dosyć gwałtowny i nieoczekiwany. Tak jak wcześniej opowiadałem, o tym byłem na konferencji, na której przedstawiciel Google’a sugerował, że tu się dużo zmieni. Nie chciał powiedzieć co, ale sugerował, że się bardzo dużo zmieni i tak trochę insynuując, że raczej będziemy prompterami, że raczej będziemy pytać modele o dane, niż samemu konstruować takie rozwiązanie.

To jest możliwe. Już teraz wiele z tych rozwiązań, łącznie z tym, że Tableau ma swoje ask data, czyli że możesz zadać pytanie i on coś tam odpowie, spróbuje przesiać te wszystkie obszary. Więc to jest na pewno obszar rozwoju technologicznego, który się pojawi. Ale według mnie, dalej ktoś będzie musiał to zorganizować, dalej ktoś będzie musiał to zweryfikować, będzie musiał umieścić to w kontekście biznesowym. Czyli tak jak mnie wcześniej pytałeś o to, czy technologia, czy biznes, która ta strona będzie ważniejsza, to właśnie być może ten AI sprawi, że te akcenty się tam przesuną, że narzędzia przestaną być aż tak bardzo ważne, ta umiejętność korzystania z nich, a sposób ich wykorzystania zrobi się o wiele ważniejszy. Czyli to, w jaki sposób w praktyce biznesowej wykorzystać te narzędzia do tego, żeby osiągać określone wyniki.

Ale jak myślimy o tym rozwoju, to cały czas mam z tyłu głowy tego pana, co wstaje na konferencji i mówi „ale u nas jeszcze Excela mają”. Więc niezależnie od rozwoju tych technologii, też pytanie, na ile my jako organizacje, jako pojedynczy ludzie będziemy skłonni do tego, żeby z nich korzystać, żeby im zaufać, żeby je wykorzystywać. Na konferencji, na której ostatnio byłem przedstawiciel bardzo dużej firmy technologicznej międzynarodowej, lidera, powiedział, że oni zakazują używania chat GPT w swojej organizacji.

Więc też będą takie procesy administracyjne, które będą w dbałości o bezpieczeństwo danych, o może przewidywalność ich wykorzystywania, ale też trochę w braku zaufania o danych. Też będą oporować przed tym procesem zmiany, albo szukać jakichś rozwiązań hybrydowych, że ty się tym zajmij, a tutaj masz obok jakieś na rzędzie jakiegoś takiego helpera, który ci pewne rzeczy usprawni i pomoże. Więc myślę o tym.

Fascynujący trend, na pewno przynajmniej warto spoglądać w tym kierunku. Nigdy nie wiadomo kiedy znaczenie być może tego obszaru po prostu się zwiększy i będziemy musieli go uwzględniać w naszej pracy znacznie bardziej niż teraz.

Świetnie. Dzisiaj moim gościem był Michał Chrzanowski z firmy Tpay. Rozmawialiśmy o tym, jak wygląda praca business intelligence dewelopera. Michał, bardzo Ci dziękuję za poświęcony czas.

Ja też dziękuję.

Powiedz, proszę, jeszcze na koniec, gdzie Cię można znaleźć w internecie, gdzie możemy słuchaczy odesłać.

Przechadzając się spacerem po ulicach Krakowa.

Zapraszamy.

Oraz na LinedInie, gdzie mam jakiś tam swój profil i tu chyba moja publiczna obecność się kończy.

Oczywiście będzie to podlinkowane w opisie do odcinka. Michał, jeszcze raz bardzo ci dziękuję. Do usłyszenia. Cześć!

Dzięki.

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz lub w social mediach.

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiamyoit.pl lub przez media społecznościowe. Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o BI Developers. Zapraszam do kolejnego odcinka już wkrótce.

Cześć!