Jak zostać analitykiem (danych, systemowym, rozwiązań)?

17 lat temu Polska weszła do UE. Dokładnie tego samego wieczoru wychodziłem z knajpy po zakończonym oblewaniu obronionej pracy magisterskiej.

Dzisiaj jestem formalnie analitykiem IT. Czego się nauczyłem w tym czasie? Czy coś bym zmienił?

Wiem z dostępnych mi danych, że stronę Dane i Analizy na Facebooku obserwują w około ¹/₅ ludzie w wieku 18-24 lata oraz w nieco ponad ¹/₂ osoby w wieku 25-34 lata. Bloga czyta podobna publiczność, w prawie identycznym rozkładzie. Tak więc sporo z Was jest na początku swojej kariery zawodowej. Zakładam też, że skoro jesteście fanami strony i czytelnikami bloga to interesuje Was ogólnie pojęte zajmowanie się danymi.

Ten post to będzie krótka (może nie tak bardzo krótka, a dłuższa) droga przez moją karierę zawodową.

Photo by Minh Pham on Unsplash

 

Doświadczenie starszego kolegi (albo może raczej: boomerzenie) może być interesujące, przydatne, może da coś do myślenia. Szczególnie jak kolega spojrzy na własne doświadczenie krytycznym okiem i powie wprost co było stratą czasu albo czego trzeba było się uczyć. Ale nie musi, wiadomo. Możecie przeczytać żeby przemyśleć, możecie przeczytać, żeby mnie poznać, możecie nie czytać.

W tekście podlinkowanych jest trochę książek – uważam je za godne uwagi, jeśli nie macie czego czytać to zerknijcie.

Wszystko zaczęło się jeszcze w podstawówce czy też na początku liceum, ale tak daleko nie będziemy sięgać, chociaż wtedy zaczynałem programować, a na studiach Excel był narzędziem codziennej pracy (laborki najlepiej jakby same się liczyły, skoro było ich kilka tygodniowo).

Zaczniemy od pierwszej pracy.

Agencja interaktywna

W dużym uproszczeniu moim zadaniem było projektowanie stron (wtedy wszystkie firmy dopiero wchodziły do internetu) typu wizytówka firmy albo prosty sklep (chociaż bardziej katalog produktów – handlu online się jeszcze nie robiło) ale głównie miałem szukać klientów i im te strony sprzedawać.

Co jak co, ale po tym krótkim czasie wiem, że urodzonym sprzedawcą nie jestem. Ale nauczyłem się dwóch rzeczy na przyszłość:

• dopytywać klientów (czy tam potencjalnych klientów) czego chcą i co pod tym co mówią rozumieją. Bo zwykle ludzie mówią jedno, a na myśli mają drugie (albo: owo jedno bardziej skonkretyzowane). Powtarzanie swoimi słowami i upewnianie się że o to chodzi, dopytywanie, drążenie – to jest kluczowa umiejętność.
• wszystkie strony internetowe można przypasować do jakiegoś szablonu pod względem UX – ludzie wolą znajome schematy zachowań, więc nie ma konieczności wymyślać innych. Wygląd, feeling robi projekt graficzny. Kruga przeczytałem wiele lat później.

 

Wiedziałem już wtedy, że chcę robić internet.

Po drodze była prawie dwuletnia przygoda w teatrze, która nauczyła mnie przede wszystkim jednego: każdy jest tylko człowiekiem i zagadać do aktora z pierwszych stron gazet można bez problemu (dostać bez powodu pęczek rzodkiewek od Wodeckiego też) i rozmawiać jak równy z równym. Od tego czasu nie boję się rozmawiać z dyrektorami, prezesami, postaciami znanymi publicznie. Bo jeśli ja wiem o czym mówię to dlaczego mam się bać? Z cudzego doświadczenia należy korzystać, a czasem (ostatnio może nawet często?) wysokie stanowisko nie oznacza dużego doświadczenia czy wiedzy.

W teatrze zajmowałem się sprzedażą biletów, robieniem w PhotoShopie ulotek i ogłoszeń, które były potem drukowane w gazetach, definiowaniem wymagań dla strony internetowej i systemu rezerwacji biletów (byłem tzw. biznesem w projekcie IT). Trochę też pisywałem o muzyce czy filmie na blogasku.

Bank korporacyjny

Podobał mi się marketing, podobał mi się PR, więc w tym kierunku chciałem iść. Trafiła się praca w dziale marketingu dużego giełdowego banku, którego klientami były wyłącznie firmy. A dział ten zajmował się całym marketingiem tego banku: od BTLi (ulotki, gadżety), ATLi (billboardy, TV) do internetu (banerki, ale przede wszystkim portal korporacyjny). W dziale była też komórka public relations i relacje inwestorskie. I jeśli kogoś interesuje komunikacja zewnętrzna spółki giełdowej to było to świetne miejsce.

Ja zajmowałem się tym co związane z internetem, głównie w ramach portalu korporacyjnego. Wrzucanie treści na stronę, koordynowanie prac podwykonawców, bycie łącznikiem między biznesem a tymi podwykonawcami w obszarze nowych funkcjonalności. Przydało się rozmawianie o potrzebach biznesu, analizowanie tego czego oczekują oraz czego oczekuje klient (to mogą być dwie różne rzeczy). Trafiłem na moment budowania nowej strategii banku, zmianę całego portalu (więc zbierałem wymagania od różnych biznesów, ale też miałem wymagania swoje – redakcyjne). Miałem okazję budować (i samodzielnie nagrywać oraz montować) pierwsze chyba w Polsce podcasty o ekonomii. Oczywiście nie sam, a razem z zespołem ekonomistów banku (bo co to jest CPI to musiałem szukać co miesiąc, przy każdym Monthly Report).

Nauczyłem się dużo o marketingu. Pierwszy raz pracowałem w dużej firmie, razem z dużym dostawcą, różnymi konsultantami z miejsc trzecich. Ale mało budowałem internetu – mało użytkowników detalicznych (bo to bank dla firm, a nie klientów indywidualnych). Chciałem więcej.

Co mogłem, a nie robiłem?

• mogłem zdobyć więcej wiedzy teoretycznej o marketingu (chociażby przeczytać Wywieranie wpływu na ludzi Caldiniego wcześniej),
• mogłem zająć się nauką BPMNa albo chociaż przeczytać jakąś książkę na ten temat. Dzisiaj procesy rysuję na czuja, głównie tego unikam.
• UMLa też się nie uczyłem i dzisiaj to boli najbardziej.

 

Portal internetowy

Na rozmowie kwalifikacyjnej powiedziałem, że jakby nie było Web 2.0 to pewnie bym go wymyślił – przecież ludzie chcą podzielić się opinią o przeczytanym tekście (wtedy już ten blog kilka lat; Marczak pisał AntyWeba na Bloxie, ja myślałem, żeby robić coś podobnego, a film Epic 2014 był przerażającą wizją).

Pracę zacząłem od budowania serwisów z gotowych klocków: tutaj jest elementy typu lista artykułów, tutaj jest strona typu artykuł, tutaj galeria, z boku damy chmurkę tagów i takie tam. Na drugą nogę była analityka i projektowanie: dlaczego na Pudelku jest więcej odsłon na użytkownika niż u nas? Co zrobić żeby to zmienić? Jak upchnąć dodatkową reklamę? Czy zdjęcie na liście artykułów powinno być klikalne? Czy pod leadem potrzebny jest napis więcej? Takie problemy się wówczas rozwiązywało.

Jeśli chcesz być na bieżąco z tym co dzieje się w analizie danych, machine learning i AI polub Dane i Analizy na Facebooku oraz @rstatspl na Twitterze.

Każdego dnia znajdziesz tam potężną dawkę wiedzy.

Jak poznałem mechanikę portalu zacząłem projektować elementy nowe albo serwisy dla reklamodawców. Robione jak najmniejszymi kosztami (czyli: z klocków, najlepiej bez developmentu) ale za każdym razem nieco inne (nie tylko graficznie; problem typu logo przypraw na liście składników w przepisie kulinarnym też się rozwiązywało), a najlepiej tak, żeby nowe elementy były re-używalne później.

To nauczyło mnie zadawania pytań dlaczego?. Mój szef dużo takich zadawał, mam to po nim. Inne pytanie to skąd user ma to wiedzieć? albo pochodne. Nauczyło też takiego projektowania nowych elementów, żeby dało się je później wykorzystać. Mogłem skupić się na sposobie dokumentowania wymagań dla programistów, ale tego nie zrobiłem (ot, pisaliśmy w wiki jakieś wymagania, bardziej biznesowe niż systemowe). Mogłem się też zakręcić koło biura analiz i mieć dostęp do większej ilości danych i bardziej o tym w co klikają użytkownicy a nie w to co jest w CMSie.

Project Management Office

Czasem dochodziło do momentów kiedy albo realizujemy projekt (na przykład nowy duży serwis internetowy – o, na przykład całą sekcję sportową o olimpiadzie) albo rzucamy cały zespół bo klient przyniósł walizkę pieniędzy i za dwa tygodnie chce mieć dużą akcję marketingową w ramach kilku serwisów portalu. Wtedy przydawał się ktoś, kto potrafi zebrać szybko liczby, oszacować ilość roboty i pomóc podjąć decyzję co robimy (olimpiada się nie przesunie na potem, klient też nie może czekać, bo kampania wsparta jest innymi mediami, które są już kupione).

Tak się składa, że takie rzeczy umiem robić i umiem je robić sprawnie. Excela w tamtym czasie znałem pewnie najlepiej w zespole (ale dopiero zacząłem rozumieć co to są tabele przestawne). Zająłem się więc bardziej pilnowaniem jak idą projekty, zbieraniem nowych pomysłów, uczeniem adeptów project managementu jak prowadzić projekty (to były raczej dobre praktyki wyniesione z doświadczeń niż jakakolwiek teoria oparta o Prince2, PMI czy zyskujący na popularności Agile).

Siedziałem więc w Excelu i cyferkach. Kombinowałem jakimi miernikami oceniać pomysły które być może wejdą do produkcji. Top 10 największych projektów dla Zarządu na slajd w prezentacji z okazji wyników finansowych? Łukasz ma, za 15 minut będzie, w podziale na piony, z tabelką i wykresami. Jaką część zespołu developerów zjada który pion? Czy UXowcy pracują dla danego pionu więcej czy dla wszystkich po równo? Takie analizy robiłem, będąc coraz lepszym kumplem Excela (w wersji 97 albo 2000 wówczas).

Później poszedłem do innej firmy, też do PMO. I robiłem podobne rzeczy przez kolejne kilka lat. Do tego dochodziła wiedza co to jest MS Project i Project Server, jak sięgnąć do jego danych SQLem. W między czasie pojawił się PowerPivot i PowerQuery (jako dodatki do Excela). Nauczyłem się też administracji (biznesowej) Sharepointem (listy zadań zanim modny stał się Kanban). Znowu trafiłem na szefa, dzięki któremu dużo się nauczyłem (przede wszystkim dbałości o szczegóły w prezentowaniu danych). To był moment kiedy Excel przestawał wystarczać.

Ale nie nauczyłem się w tym czasie VBA, nie zrobiłem żadnego certyfikatu z project managementu. Nie uczyłem się SQLa (wiedziałem co to SELECT FROM, a tabelki łączyłem przez WYSZUKAJ.PIONOWO czy VLOOKUP w Excelu), nie zgłębiałem wiedzy na temat wizualizacji danych (robiłem wykresy intuicyjnie). To są rzeczy, których żałuję.

Analityka danych

Zanim przyszedłem do kolejnej pracy w ręce wpadła mi książka Przemka Biecka Analiza danych z programem R (teraz idzie się na tę stronę i ma się co potrzeba) i R mi się spodobał. Tak więc zacząłem się go uczyć.

R a nie Pythona z dwóch banalnych powodów:

• po pierwsze nie umiałem sobie poradzić z instalacją Pythona (o Anacondzie nie słyszałem, a i do dzisiaj uważam ją za coś wydumanego – czysty Python i virtualenv wystarczy), a R się po prostu ściągało i w Windowsie działało wszystko od razu (w RGui.exe). A jak poznałem RStudio i podgląd wartości zmiennych to już idealnie!
• po drugie książkę do R miałem w rękach (i rozumiałem co jest w niej napisane), a szukanie czegoś o Pythonie po sieci nie dawało odpowiednich wyników. A nawet jeśli dawało to nie miałem jak sprawdzić czy coś co napiszę działa, bo nie umiałem uruchomić Pythona na Windowsie… A potem jeszcze stwierdziłem, że SpyDer to może się schować przy RStudio.

 

Kiedyś (przed maturą) pisałem w C, wcześniej w AMOSie, chwilę proste rzeczy próbowałem robić w PHP, więc programowanie nie było dla mnie czymś nowym. Wiedziałem co to zmienna, funkcja, pętla. Nauka kolejnego języka szła stosunkowo gładko, a jakże wspaniałe było to, że obliczenia były zdecydowanie szybsze niż w Excelu (szczególnie jak wierszy było w dziesiątkach tysięcy, a kolumn w dziesiątkach i robiony był join między takimi tabelami).

Zmiana pracy przywiodła mnie do kolejnego zespołu PMO gdzie odziedziczyłem po poprzedniku kilka maszynek napisanych w Accessie (którego wcześniej może uruchomiłem kilka razy i nie wiedziałem o co chodzi) i VBA. Miałem się nimi opiekować, rozwijać i z ich użyciem przygotowywać kolejne raporty. Takie raporty, które już istniały, których pewnie nikt nie czytał, ale robiło się je od lat. I robiło się je latami – bardzo długo się generowały. A źródłem najczęściej były 2-3 filtry z Jiry… zapisane do Excela.

Na początku więc się dokształcałem z tego co robią te maszynki – biznesowo oraz logicznie w kodzie VBA. Trochę tego VBA się chcąc nie chcąc nauczyłem, SQLa też (bo przecież w Accessie pełno jest kwerend), ale od początku wiedziałem że będę to wszystko z czasem przepisywał na R.

I powoli przepisywałem. Raporty w PDFach drukowanych z Excela napełnianego przez Access zaczęły powstawać w RMarkdown opartego o ggplot2 i kableExtra. Z czasem nauczyłem się więcej: scrappować dane, podpinać się pod API. Całą (no, takie kierunki rozwoju bardziej) wiedzę przekazywałem Wam, drodzy Czytelnicy – w postaci kolejnych postów na blogu.

W pracy doprosiłem się (co w dużej korporacji nie jest proste) własnego serwera, na którym mogłem zainstalować R, RStudio, Shiny i dać PMom co chwilę pytającym o to samo samoobsługowe narzędzia. Raporty robiły się same, w dodatku były interaktywne, mailem rozsyłane były kluczowe informacje z linkami do odpowiednich dashboardów, które zasilały się z bazy danych, do której wpadały dane skryptami odpalanymi w cronie (loader pobierał CSV z filtru w Jirze, dokonywał odpowiednich przekształceń i wrzucał do tabelki w Postgresie, a do tej samej tabelki dashboard puszczał swoje selecty, już nierzadko ubierane w joiny).

Czego się nauczyłem? Nauczyłem się szukać rozwiązań, które przy minimum wysiłku dadzą największy stopień zaspokojenia potrzeb. Wykorzystałem swoje zdolności, żeby zrobić zestaw narzędzi które pozbawiły mnie nudnej codziennej pracy. Mogłem zająć się innymi rzeczami, na przykład nauką tego co nazywa się machine learning czy też data science. Na pracowych danych wiele nie dało się wyciągnąć, więc danych szukałem w różnych miejscach. Dokumentację tych poszukiwań macie w postaci kolejnych postów.

Czego się nie nauczyłem, a powinienem? Zarządzania kodem, GITa, architektury oprogramowania. Mogłem może wcześniej zająć się Pythonem. Na pewno na studiach trzeba było lepiej przykładać się do statystyki i algebry. W pracy nie była potrzebna, a zajmując się danymi na potrzeby na przykład bloga omijałem te aspekty.

Analiza IT

Zacząłem się nudzić i proponować na przykład inne sposoby rozliczania celów kwartalnych, nowe formaty raportów. Prywatnie ćwicząc #ML, trochę #AI i zastanawiając się jak lepiej wdrażać na produkcję kolejne maszynki (Python tutaj bezapelacyjnie jest mniej wymagający niż R) czy tym bardziej modele (jeden z modeli, które napisałem w R został przepisany na Pythona tylko po to, żeby go wdrożyć gdzieś tam – pomyślałem, że mogłem od razu w Pythonie pisać) albo irytując się, że wszystkie przykłady są w scikit-learn czy keras/tensorflow. Stwierdziłem, że teraz już piszę tylko w Pythonie, nawet jeśli to ma trwać dłużej. Tak nauczyłem się R (“wszystko teraz będę robił w R, bez Excela”), więc tak też przesiądę się na Pythona. Zadziałało po raz kolejny.

Mój obecny kierownik zaczął budować zespół do spraw big data. Zaproponował mi przejście do jego zespołu. Nie mając pojęcia o Hadoopach, Kafkach, Sparkach i tym podobnych technologiach ochoczo się zgodziłem. Braki w technologiach jako tako nadrobiłem, przy okazji ćwicząc Pythona i na przykład Sparka czy Kafkę.

Stack developerski to raczej Java, więc developerem nie zostałem. Ale jak trzeba będzie grzebnąć raporcik w Sparku to spoko, da radę.

Myślę zbiorami danych, tabelkami, liczbami, tym co można z danymi zrobić, skąd dokąd przesłać i z czym połączyć. Nadaję się więc na analityka jednego systemu (takiego data lake plus te Kafki, Hive’y i inne) rozmawiającego z innymi analitykami innych systemów. Dogadujemy się: co kto komu wyśle, kto sobie coś odłoży a bo prześle dalej.

Teraz spędzam czas na spotkaniach ustalając szczegóły, a później opisując je w detalach (pole takie, z tabeli takiej trzeba wpisać w jsona pod nazwą taką, a potem wysłać jsona metodą post do api na endpoint taki i owaki) żeby reszta zespołu wiedziała co trzeba zrobić. Tego precyzyjnego notowania cały czas się uczę. Widzę też moje wcześniejsze braki w wiedzy związanej z BPMN, UML czy obsługi Enterprise Architect. Przeraża mnie ten program tak jak kiedyś przerażał mnie Access – notuję w plikach tekstowych albo OneNote (pozwala powiązać ze sobą dokumenty, ułożyć w jakąś strukturę), potem przepisuję jako wymagania do zadań w Jirze.

Nie projektuję jak kiedyś czegoś co widzi użytkownik końcowy (klient na WWW, ktoś z obsługi klienta w systemach wewnętrznych) ale staram się dopytywać biznesu o to dlaczego tak wygląda proces, czy użytkownik ma widzieć to czy tamto albo czy może zrobić coś inaczej? Czy będzie do tego potrzebny raport? Skąd biznes będzie wiedział, że projekt się udał? (to jest bardzo trudne pytanie!) Albo że produkt działa? Pytania są podobne do tych, które zadawał mi szef kiedy pracowałem w portalu internetowym jako UXowiec.

Czego się nauczyłem na obecnym stanowisku do tej pory? Trzeba wszystko notować i ciągle na notatkach pracować (szczególnie jak jest się analitykiem w kilku projektach równocześnie), trzeba wszystko upraszczać i starać się budować rozwiązania uniwersalne (mikroserwisy czy inne API). W portalu projektowałem klocki, tutaj projektuję inne klocki. Nauczyłem się też, że im szybciej będzie wszystko szczegółowo opisane tym mniej pytań zada zespół podczas developmentu (a pamięć jest ulotna). Oraz tego, że warto wszystko mierzyć i logować. Jeśli to wszystko jest dla Was oczywiste to nie musicie czytać książki o DevOps. Ale jeśli nie jest – przeczytajcie, nie zaszkodzi.

A co najlepsze – na co dzień nie programuję, a robię przeglądy kodu i mówię młodszym jak powinni pisać. Czytam mądre książki o architekturze oprogramowania czy czystym kodzie to się wymądrzam ;-)

Poza doświadczeniem zdobywanym w czasie pracy jest też to, które zdobywa się własnymi projektami poza pracą. Jeśli chcesz być analitykiem danych to samo analizowanie danych w pracy nie wystarczy żeby się rozwijać. Jeśli w pracy wszyscy siedzą w Excelach i nie chcą zmiany, to nie nauczą Cię czegoś innego. Zacznij więc samodzielnie: czytaj teksty w internecie. Jeśli nie wiesz które – zapisz się na newsletter i dostaniesz te wybrane przeze mnie. A jeśli nie chcesz newslettera to daj lajka fanpejdżowi.

Mam nadzieję, że przekazałem Ci odrobinę swojego doświadczenia. Jeśli masz pytania – śmiało, pisz w komentarzu. Lepiej rozmawia się przy piwie albo kawie, możesz je postawić tutaj ;).