Loading…

READY TO DEAL WITH YOUR DATA?

Get some tips on how to do that!
Start exploring

Porad kilka dla inżyniera danych

Praca z danymi nie jest łatwa. Dane bywają wredne, brudne, irytujące. Mają nad nami przewagę liczebną i często to wykorzystują. Czy można wygrać nierówną walkę z danymi?

Celem tego wpisu jest podniesienie typowych wyzwań, jakie w ciągu ostatnich 10 lat pracy, głównie w obszarze analityki danych, zaobserwowałem u osób pracujących z danymi (wliczając samego siebie). Dodajmy, że miałem do czynienia z właściwie wszystkimi możliwymi stanowiskami pracy: od analityka biznesowego, przez inżyniera ETL, architekta hurtowni danych, programistę rozwiązań BI, aż po naukowca od danych – “data scientist” (ponoć najseksowniejszy zawód świata?). I zawsze, będąc w każdej roli, można sporo poprawić w naszych metodach pracy z danymi.

  1. Zacznij od “dlaczego” (lub “po co”). Brzmi jak tytuł znanej i, według mnie, znakomitej książki Simona Sinek’a. Ale ma naprawdę fundamentalne znaczenie w pracy z danymi, a zwłaszcza z analityką danych. Ileż to razy zetknąłem się na rozmowach kwalifikacyjnych z kandydatami pracującymi z danymi, ale nie mającymi kompletnie pojęcia, po do czego te dane wykorzystuje biznes, na jakie biznesowe pytania ma odpowiedzieć raport zbudowany w oparciu o te dane, czy jaką wartość dla biznesu mają same dane. Nawet, jeśli jesteś “zabunkrowanym i okopanym” programistą procesów ETL, zadawaj sobie pytania dotyczące biznesowego aspektu danych. Inaczej, po pierwsze, nigdy nie będziesz należycie pracować z danymi (np. jak dbać o jakość danych,  gdy się nie rozumie ich znaczenia?), po drugie, nie rozwiniesz w sobie kompetencji miękkich – rozumienia procesów biznesowych. Dane to nie węgiel, który przerzucamy z kupki na kupkę.
    Inny przykład – klient chce “przenieść” swój raport z Excela do Power BI, najlepiej z zachowaniem wyglądu. I w takim momencie często zaczyna się “rysowanie” w Power BI. Czysta “rzeźba”. A może czasem wystarczy zapytać, na jakie pytania ma odpowiadać raport i zaproponować nowy wygląd działającego w oparciu o dostępne funkcjonalności raportu? Projekt analityczny może stać się nieciekawą i trudną powtarzalną robotą przy odtwarzaniu czyjejś twórczości, tylko dlatego, że zabrakło w nim “dlaczego”.
  2. Nie wierz danym. Krytyczne podejście do danych to podstawa. Zawsze zadawaj sobie pytanie, czy dane, które wykorzystujesz, nie mają jakiegoś przekłamania. Szukaj proaktywnie problemów z danymi – od brakujących wartości, przez duplikaty, na jakości biznesowej skończywszy. Kolorowy raport pokazujący dane “od czapy” jest bezwartościową zabawką w rękach klienta. To dlatego integracja danych i zarządzanie ich jakością kosztują tyle pieniędzy w projektach analitycznych. Nie ufać danym i zawsze je kontrolować.
  3. Nie daj zamknąć się w pudełku. “Pokaż nam swoje dane, a my powiemy Ci, co z nich możemy mieć.” Tak działa wiele firm konsultingowych w obszarze analityki i data science. Oczywiście, poznanie wartości posiadanych danych może być cenną wiedzą w organizacji, ale prawda jest taka, że zakres danych, jakie powinny być wykorzystane w analityce, powinien być determinowany przez to, co chcemy tą analityką osiągnąć. Nierzadko wyjście z “pudełka” posiadanych danych i wzbogacenie obszaru analitycznego o dane zewnętrzne (rynek, pogoda, dane demograficzne, itd.) daje o niebo lepszy efekt i prowadzi do realizacji założeń. Nie zaczynaj więc od tego, jakie dane masz podane na tacy, ale od tego, co ma być efektem końcowym (znów pojawia się cel!) i jeśli zajdzie taka potrzeba, wzbogacaj zestawy danych o dane, których Twój klient być może nie rozpatrywał w założeniach.
  4. Zdefiniuj znaczenie słowa “raport”. Dzisiaj ludzie produkują “bimbaliony” raportów. Z moich obserwacji wynika jednak, że często słowo “raport” jest mocno nadużywane. Przykład to klasyczne “raporty” w dużych organizacjach. Użytkownik końcowy / odbiorca raportu zgłasza analitykowi “potrzebę raportową”. Analityk używa swoich umiejętności pisania kodu SQL (lub analogicznego języka umożliwiającego manipulacje na danych), pisze serię odpowiednich zapytań, wyciąga dane i… eksportuje je do pliku Excel! Tak, takie “raporty” to norma :-) I czy to źle? Niekoniecznie. W ten sposób w firmach jest jasny podział obowiązków – analityk odpowiada danymi na zadane pytania biznesowe, a użytkownik końcowy, szczęśliwy, że dane dostał, buduje raport. Tyle, że to jest nadal ogrom manualnej pracy do wykonania. Dlatego, w miarę możliwości, warto iść dalej z automatyzacją i zamiast produkować kolejnego Excela, który za moment stanie się żyjącą niezależnie bazą danych dla użytkownika końcowego lub – o zgrozo – całego departamentu, od razu na danych zrobić raport, idealnie wyposażony w odpowiednią parametryzację i elastyczność dla użytkownika końcowego. Niekiedy trudne, ale często wykonalne.
  5. Keep it simple, stupid. Ta, wydawałoby się, prosta zasada jest czasem zupełnie zapominana w projektach dotyczących danych. Jesteśmy tak zafascynowani świeżo poznanymi technologicznymi nowinkami, że postanawiamy natychmiast ich użyć, bez oglądania się za siebie. I tak, w projektach “dzięki nam” lądują: funkcjonalności w wersjach beta czy “preview”, nie mające pełnego wsparcia dostawcy oprogramowania, mechanizmy osadzane w dziwnych miejscach architektury, trudne w utrzymaniu i natychmiast generujące tonę długu technologicznego, błyskotki w wizualizacji danych odciągające uwagę użytkownika od meritum raportu i opowiadanej w nim historii. I nie jest to złe tylko dlatego, że odgrzebanie się z tego będzie kiedyś kogoś kosztowało sporo pracy, ale także dlatego, że takie działania od razu potrafią “zjeść” dodatkowy czas i pieniądze na projekcie. A czasu i pieniędzy zazwyczaj zawsze jest za mało…
    Przykład z projektu: klient opisał, w jakiej formie chce zobaczyć dane, konsultant stwierdził, że w Power BI (narzędzie używane przez Klienta jako korporacyjna platforma BI) nie ma takiej wizualizacji i… natychmiast przystąpił do tworzenia własnej wizualizacji Power BI, by spełnić życzenie klienta. Godna pochwały pro-kliencka postawa, ale pytanie, czy konsultant uświadomił klienta, z czym wiąże się stworzenie własnej wizualizacji? Że to tony kodu do napisania ($$$ i czas). Że potem trzeba będzie ten kod utrzymywać. Że sama wizualizacja będzie wymagała wsparcia twórcy po wdrożeniu. A może klient mógł iść na kompromis i te same dane oglądać na jednej z dostępnych w narzędziu wizualizacji? Miej takie alternatywy na uwadze. Zawsze.
  6. Nie zamykaj się na nowe narzędzia. Każdy ma swoje ulubione narzędzia, aplikacje i usługi, w których czuje się najlepiej, które poznał na projektach, których możliwości dobrze zna i rozumie. Często dlatego właśnie jesteśmy “spaczeni”. I usilnie próbujemy wszystko robić w oparciu o swój ulubiony zestaw narzędzi (tak, ja też chętnie wszystko oprogramuję w SQL-u). Efektem tego są zazwyczaj: po pierwsze, spadek produktywności (pewne rzeczy w innych narzędziach można zrobić szybciej / łatwiej, po drugie i znacznie bardziej niebezpieczne, nieoptymalne architektury rozwiązań. A zatem wpływ naszych przyzwyczajeń może być od małego (czas, budżet projektu), aż po ogromny (strategiczny – długofalowe “być albo nie być” projektu). Dlatego warto w wolnym czasie (tak, wiem, mało go!) poznawać nowe narzędzia, nowe usługi, nowe podejścia do rozwiązywania problemów, z którymi nawet sobie dawno temu poradziliśmy. Bo może ktoś rozwiązał je lepiej i szybciej, ale przy użyciu zupełnie innego zestawu śrubokrętów. Ucz się każdego dnia i rzucaj wyzwania ogranym już rozwiązaniom.

Świat pędzi do przodu z zawrotną prędkością. Za rok może nam być dane pracować z zupełnie innymi narzędziami i na projektach, w których będą całkiem nowe wyzwania. Być może to będzie kompletnie nowa era w analityce i w zarządzaniu informacją. Ale mimo to uważam, że w/w porady mają całkiem spore szanse być ponadczasowe, ponieważ 10 lat temu były na czasie i w ciągu dekady się nie zdezaktualizowały.

Idę o zakład, że każda osoba pracująca z danymi ma drugie, a nawet trzecie tyle “złotych myśli”, które bazują na doświadczeniach mozolnie zbieranych w ogniu walki na projektach. Chętnie poczytam Twoje przemyślenia, jeśli tylko podzielisz się nimi ze mną w komentarzach do tego wpisu.

Niech moc danych będzie z Tobą! :-)

4 thoughts on “Porad kilka dla inżyniera danych

  1. Eksport danych z bazy do Excela, i robienie w nim raportów/wizualizacji, to chyba typowa i normalna rzecz. Zrobienie w ten sposób kolejnego “excela” jest szybsze, łatwiejsze i tańsze niż robienie raportów w oprogramowaniu do BI. Chociażby dlatego, że oprogramowanie MS Office jest wszędzie, w każdej firmie, każdym biurze i urzędzie, a Excel jest łatwy w nauce i obsłudze. Czyli jak to się teraz mówi, ma “niski próg wejścia” dla przeciętnych użytkowników.

  2. Kontynuując moje wcześniejsze przemyślenia, “Dlatego, w miarę możliwości, warto iść dalej z automatyzacją i zamiast produkować kolejnego Excela, który za moment stanie się żyjącą niezależnie bazą danych dla użytkownika końcowego…”, “Pokaż nam swoje dane, a my powiemy Ci, co z nich możemy mieć” – oj marketing Microsoftu, marketing. Czyli jak przekonać klienta aby uwierzył że potrzebuje kolejny produkt giganta. Zero-jedynkowe podejście sugerujące że raport w Excelu jest statyczny, robiony metodą “kopiuj-wklej dane”, a produkty BI dają lepsze raporty, bo aktualizowane na bieżąco. A przecież wystarczy aby w “excelu” nie wklejać danych lecz podpiąć odpowiednie zapytanie z bazy danych albo z plików csv za pomocą Power Query. Wtedy po odświeżeniu arkusza mamy raport aktualizowany na bieżąco. “Nie zamykaj się na nowe narzędzia” – o ile klient naprawdę potrzebuje czegoś większego niż Excel. Ten program jest jednym z najlepszych które wyprodukowano w historii informatyki, z bogactwem opcji i dużymi możliwościami obróbki i wizualizacji danych. Czy naprawdę raport musi być koniecznie robiony w BI a nie w Excelu? Serio? Z tym nie zamykaniem się na nowe narzędzia, to podobnie jak jest ze smartfonami. Firmy przekonują nas że teraz potrzebujemy smartfonów składanych, z doczepianymi klawiaturami i doczepianymi ekranami, z podłączonymi smartzegarkami, i różnymi czujnikami do mierzenia aktywności fizycznej, psychicznej, itp., bo bez tego nasze życie stanie się smutne, szare i jałowe. Serio potrzebujemy smartfonów na sterydach? I czy rzeczywiście potrzebujemy raportów na sterydach?

    1. Dzięki za wartościowe komentarze. Nie, nie jestem za tym, żeby pozbyć się Excela i nigdzie o tym nie napisałem :-) Tym bardziej, że ludzie mają swoje przyzwyczajenia, mają opanowane to narzędzie w stopniu często eksperckim i umożliwiającym efektywną pracę. I Excel faktycznie jest w wielu miejscach najpopularniejszą aplikacją. Skoro tak, użyjmy go. Tylko w mądrzejszy sposób niż do powtarzanej co tydzień, miesiąc, dzień manualnej zabawy w copy, paste, link, lookup…

      Problemy, jakie widzę: a) często pliki Excel powstają w bardzo powtarzalny sposób, a znaczną część pracy niezbędnej do ich stworzenia zajmuje kopiowanie, wklejanie i powtarzalne pisanie formuł, b) słowo “raport” jest używane wobec “płachty” ogromnego arkusza Excel, z której na pierwszy rzut oka zupełnie nic nie wynika i którą trzeba poddać dodatkowej analizie, często bardzo powtarzalnej i możliwej do zautomatyzowania.

      I tak, jeśli zaprząc do tego wynalazki a la Power Query w Excelu, można się obejść bez “BI”. Choć czy Excel, przy jego dzisiejszych możliwościach, to nie BI? :-)

      Jeszcze raz podkreślam – w punkcie 4. chodzi o dążenie do automatyzacji, a nie o eliminację Excela na rzecz “fancy BI”.

  3. Tak, obecnie Excel jest na tyle rozbudowany, że faktycznie można o nim mówić że spełnia funkcję aplikacji “Bi”. Oczywiście w firmach/instytucjach, gdzie pracownikom zależy na wykorzystaniu jego możliwości. Niedawno pracowałem w urzędzie państwowym, w którym Excela używano jedynie do robienia “tabelek”, takich jakie robi się np. w Wordzie. Umiejętność osób “zaawansowanych” w obsłudze Excela ograniczała się do dodania kolumny, wiersza, czy odkrycia ukrytej kolumny (ale to ostatnie umieli już tylko “eksperci”). W tych tabelkach wpisywano np. daty planowanego zakończenia jakiś spraw, terminy do realizacji, itp. Ale ilość dni pozostałych od dzisiaj do danego terminu, to już liczono ręcznie przy użyciu kalendarza biurkowego albo ściennego. Ręce mi opadły jak to zobaczyłem, ale cóż, to był urząd państwowy, więc wiadomo jaka tam jest świadomość informatyzacji. Więc napisałem im kilka formuł i makr, aby choć trochę zautomatyzowały to co robili. Inny załamujący krok, to był wtedy, gdy stworzyli katalog tysięcy spraw w Excelu, po czym wydrukowali to wszystko, włożono do segregatorów, a plik Excela skasowano. Więc zamiast szukać danej sprawy w sekundę, dzięki Ctrl-F, to ręcznie kartkowano kilka segregatorów, kartka po kartce. I tak robiono codziennie, po kilka spraw do przeszukania na setkach stron, kartka po kartce. Ale cóż, urząd państwowy. Dobrze że już tam nie pracuję.

Leave a Reply to Pawel Cancel reply