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ą! :-)

One thought on “Porad kilka dla inżyniera danych

  1. We offer you the opportunity to advertise your products and services.
    Dear Sir / Madam That is a fine offering for you. I can send your commercial offers or messages through feedback forms. The advantage of this method is that the messages sent through the feedback forms are included in the white list. This method increases the chance that your message will be read. The same way you received this message.

    Sending via Feedback Forms to any domain zones of the world. (more than 1000 domain zones.). The cost of sending 1 million messages for any domain zone of the world is $ 49 instead of $ 99.
    Domain zone .com – (12 million messages sent) – $399 instead of $699
    All domain zones in Europe- (8 million messages sent) – $ 299 instead of $599
    All sites in the world (25 million messages sent) – $499 instead of $999
    Domain zone .de – (2 million messages sent) – $99 instead of $199
    Domain zone .uk – (1.5 million messages sent) – $69 instead of $139
    Domain zone .nl – (700 000 sent messages) – $39 instead of $79

    Discounts are valid until March 25.

    Contact us.
    Telegram – @FeedbackFormEU
    Skype – FeedbackForm2019
    Email – FeedbackForm2019@gmail.com

    Hope to hear from you soon.

Leave a Reply