RDF – o Big Data dla biznesu i ekspertów

Idea jest prosta. Rekrutujesz osoby z podstawową wiedzą. Nie, nie Big Datową. Podstawową wiedzą z IT. Na przykład studentów. Następnie poddajesz ich odpowiedniemu szkoleniu. Po 1.5-2 mies. kursanci zaczynają przygodę w projekcie. Niemożliwe? Możliwe, o ile kilka kroków będzie solidnie zrealizowanych. Takie podejście to prawdziwe wybawienie w obliczu trudnodostępnych fachowców.

Jak pozyskać inżynierów Big Data? Nie pozyskuj – ukształtuj!

Wiele firm inwestuje obecnie w Big Data. I tyleż samo firm doświadcza problemów z pozyskaniem pracownika. Z jednej strony stawki które kandydaci sobie życzą potrafią być zawrotne. Z drugiej strony, po odpowiednim sprawdzeniu często wychodzi, że kandydat mimo pewnego doświadczenia (wyrażonego w stażu pracy), nie dysponuje szczególnie imponującą wiedzą. Mówiąc delikatnie;-). Pytanie stare jak polska polityka: “Jak żyć?”.

Odpowiedź, którą chcę dzisiaj przytoczyć, nie będzie absolutnie pełna. I nie zastąpi to poszukiwania specjalistów na wakat seniora czy mocnego mida. Przykro mi. Chcę jednak zwrócić uwagę na coś, co często umyka wielu firmom, a co może być uzupełnieniem tego trudnego procesu, jakim jest budowa kompetentnego zespołu.

Może zamiast pozyskiwać ludzi, postawić na ich wykształcenie?

W skrócie wygląda to tak, jak napisałem we wstępie. Pierwszy plus: znaleźć kogoś z niezłymi umiejętnościami (o tym jakimi, napiszę jeszcze potem) nie jest ciężko. Kolejny plus: przed projektem naprawdę wiemy, jakie przygotowanie ma pracownik (gdy zatrudniamy, zawsze to pewna niewiadoma). Wreszcie największy plus: nie szukamy idealnego kandydata pod projekt. Możemy go wykształcić w konkretną stronę. Oczywiście szkolenie powinno być przekrojowe i dawać ogólne pojęcie. To jednak jakie technologie będą wykładane, zależy głównie od firmy. To jakby zamiast kupować buty z półki – zamówić uszyte pod konkretny bieg.

Przygotowanie i przeprowadzenie takiego szkolenia ma kilka etapów. Jako, że niedawno zakończyłem jedno z nich, zanurzmy się w kolejne etapy, sprawdzając “jak to się robi” na konkretnym przykładzie.

Faza wstępna – określenie celu i rekrutacja

Zanim cokolwiek się zacznie, trzeba się przygotować. To dość logiczne – bez kursantów szkolenie może przynieść niesatysfakcjonujące efekty. W związku z tym należy zrobić dwie rzeczy:

1. Określić po co chcemy kursantów
2. Zrekrutować przyszłych wojowników.

W punkcie pierwszym, mamy do czynienia przede wszystkim z wybraniem projektu, lub paru projektów, w których potrzebujemy solidnych juniorów. Dzięki temu będziemy znali zakres technologiczny. Warto zadać sobie takie pytania jak:

1. Jakie technologie są wykorzystywane w projekcie? (wypisujemy wszystkie)
2. Które technologie są używane w jakim stopniu? (z jednych korzysta się czysto użytkowo i doraźnie, inne są rdzeniem projektu)
3. Jakie języki programowania są w użyciu?
4. Które z wyżej wymienionych chcemy, aby znali kursanci? Przy tym pytaniu warto się zatrzymać, bowiem korci żeby “napchać ile wlezie”. Lepiej jednak dość dużo obciąć, co przełoży się na lepsze opanowanie materiału.
5. Czy są inne aspekty technologiczne, które chcemy dodać? Na wszelki wypadek, lub dla uniknięcia zbyt wąskiego wyszkolenia (można dodać tutaj ogólną wiedzę np. z technologii cloudowych).

W punkcie drugim wybieramy konkretne osoby. Co na pewno muszą aplikujący?

1. Znać podstawy języka – najlepiej ogólnie rzecz biorąc, znać podstawy javy, jako fundamentu Big Data (choć są od tego wyjątki oczywiście).
2. Mieć opanowane podstawy relacyjnych baz danych
3. Znać podstawy linuxa oraz sieci. Tu chodzi o naprawdę proste rzeczy, jak połączeni po SSH, posługiwanie się bashem.
4. Rozumieć o co chodzi w GIT.
5. Wiedzieć, na co się piszą;-).

W przypadku ostatniego szkolenia, języki to była java i scala (przy czym scalę poznali już na szkoleniu). Dodatkowo kursanci dostali bardzo mocny przekrój technologiczny. Nie chcę wymieniać wszystkiego, natomiast m.in. pojawiły się:

1. Hadoop + Hive
2. Spark
3. Airflow
4. Ogólne warsztaty ze streamingu
5. HBase
6. Jenkins

Tyle wystarczy na dobry początek. Aha! Warto wspomnieć, że tego typu szkolenie raczej nie powinno być masówką. Tutaj były to zaledwie 2 osoby, może to być 3,4, maksymalnie 5 osób (chociaż 5 to już dość dużo). Dodatkowo były to osoby z różnych miejsc w Polsce – całość szkolenia była przeprowadzona on-line.

Czas ruszyć na samo szkolenie!

Warsztaty

Zasadniczo samo szkolenie składa się z dwóch części. Pierwsza z nich to właśnie warsztaty. Podstawowy cel: poznać technologie. Każdy dzień to fundamenty jednej technologii. No dobrze – niekiedy dwa dni. Wszystko zależy od ilości całego materiału:-).

Warsztaty mają następującą strukturę: rano zaczynamy dzień od wykładu, który wprowadza w temat konkretnej technologii. Następnie kursanci mają cały dzień na wykonywanie ćwiczeń, które zlecił im instruktor. W tym czasie instruktor jest dostępny, ale nie bierze aktywnego udziału w ćwiczeniach. Wieczorem (albo popołudniem – zależy od pory roku;-)) wszyscy spotykają się, żeby przegadać wątpliwości które się pojawiły, omówić ćwiczenia itd. Takie podsumowanie dnia.

Omawiane szkolenie zaczęliśmy od krótkiego wstępu do Big Data. Osobiście jestem fanem przechodzenia od ogółu do szczegółu. No i spoglądania na szerszy kontekst. O ile potem jest czas na zanurzenie się w technikaliach, o tyle warto ciągle mieć świadomość częścią jak wielkiego świata jesteśmy. Znacznie więcej opisywałem tego w ebooku – zachęcam do zajrzenia. Kursanci odsłuchali prezentacji, następnie ustaliliśmy wspólnie kształt całego szkolenia, które przejdą. Przestrzegłem przed kluczowymi rzeczami i… ruszyliśmy do akcji!

Jeszcze pierwszego dnia zrobiliśmy krótki warsztat z gita. Chociaż oboje znali już podstawy, pokazałem jak to się robi w projektach komercyjnych. Po co stosujemy system kontroli wersji i w jaki sposób go używać.

Kolejne 2.5 tygodnia upłynęły na poznawaniu technologii w przyspieszonym tempie. Szczerze przyznam, że poradzili sobie wyśmienicie. To był pierwszy raz, gdy dostawałem od kursantów zrobione prawie wszystkie zadania dzień w dzień. Fakt jest jednak taki, że taki sprint wyczerpuje i nie zawsze wszystko uda się skończyć. Dlatego pod koniec zostawiłem jeden “dzień wolny”. Tym bardziej, że warsztaty z Elastic Searcha postanowiłem połączyć z HDFSem i Sparkiem;-). Naprawdę przekrojowo, ale dali radę wyśmienicie!

Zacny zespół. Nawet bardzo;-).

Projekt

Gdy dokończyliśmy poznawanie fundamentów technologicznych, przyszedł czas na najciekawszy kąsek. W czwartek spotkaliśmy się i zaczęliśmy… projekt. Tak – prawdziwy projekt. Właściwie to taka miniaturka projektu komercyjnego. Z githubem, na klastrze szkoleniowym RDF, z metodyką pracy i – co ważniejsze – konkretnym celem biznesowym.

Infrastruktura szkoleniowa

Sam klaster odgrywał pewną rolę już wcześniej, na etapie warsztatów. Przygotowałem go specjalnie na potrzeby szkoleń. Każdy z kursantów ćwiczy dzięki temu w warunkach ekstremalnie zbliżonych do rzeczywistych. To klaster złożony z dwóch nodów (serwerów), które pracują w chmurze. Jest na nich Hadoop, Spark, Elasticsearch i czego tylko dusza zapragnie (nawet Hue!).

Poniżej możesz obejrzeć wideo, w którym dość szczegółowo opowiadam o tym na czym pracują kursanci RDF i dlaczego akurat tak;-).

Organizacja projektu

Co ważne, kursanci dostają konkretne wymagania biznesowe projektu. To w założeniu ma być system, który mógłby mieć zastosowanie w biznesie czy R&D. Oczywiście niekoniecznie pełny, bardziej PoC, ale grunt że wiemy dokąd dokładnie zmierzamy i dlaczego.

Dodatkowo kursanci pracują w ramach uproszczonego scruma. Mamy swojego boarda z taskami, mamy codzienne spotkania, całość następuje przyrostowo. W ten sposób pierwsze zderzenie z uporządkowanym systemem pracy jest jeszcze przed wejściem do prawdziwego, komercyjnego projektu.

Oczywiście wdrożony jest także cały system pracy z kontrolą wersji. Jest praca z branchami na Git, Są Pull Requesty, code review. Co więcej – zanim code review pójdzie do instruktora (tutaj do mnie), najpierw to kursanci sami sobie sprawdzają swoją pracę.

Duża skala

Mimo, że projekt jest miniaturą – wcale nie jest “niepoważny”. Prawda jest taka, że kursanci mają od pierwszego dnia ogrom pracy do wykonania. W tym przypadku zbudowali 4 moduły pobierające, odpowiednio dużo modułów przetwarzających, do tego indeksacja i kilka komponentów pomocniczych. Dołóżmy jeszcze orkiestrację (przy pomocy airflow) oraz CI/CD (Jenkins) i mamy… naprawdę solidny kawał roboty do przerobienia. Dla dwójki osób. Które dodatkowo nie miały nigdy do czynienia z Big Data.

Na szczęście naszym kursantom całość poszła śpiewająco;-). Nie obyło się bez trudów i wątpliwości, ale o tym już za chwilę.

Chcę jednak podkreślić, że projekt podczas tego typu szkolenia przekrojowego, to naprawdę ogrom pracy i wytężone obroty mózgu. W ten sposób kursanci w praktyce gruntują sobie wyłożoną wcześniej w metodyczny sposób, wiedzę.

Jako że projekt był systemem wspierającym analizę inwestorów, zespół połączył dane finansowe, gieldowe oraz aktywność około-spółkową na Twitterze. Pisząc “okołospółkową” mam na myśli, że często liczy się nie tylko oficjalny profil firmy. Przykładowo – w przypadku PKN Orlen głupotą byłoby zignorowanie profilu Prezesa Daniela Obajtka, który jest bardzo aktywny i zaangażowany. Podobnie należy starać się wyłapywać także to, co mówią inni.

Dane, po szeregu operacji, trafiają do Elasticsearcha, skąd zaciągane są i wizualizowane przy pomocy Kibany. Poniżej można zaobserwować finalny efekt prac – czyli jeden z dashboardów, który wizualizuje część danych.

Nie tylko umiejętności techniczne

Prezentacja

Całość kończyła się prezentacją przed innymi członkami firmy. Pamiętasz jak to wyglądało na studiach? Praca do samego rana, potem szybko klejona prezentacja w tramwaju, wpadanie spoconym na zajęcia i… prezentujemy!

Na szczęście, tutaj ustawiamy sobie deadline wykonania projektu na ok. 2-3 dni przed prezentacją. Raz, że wiadomo, że będą obsuwy. Po drugie – na długo przed punktem kończącym szkolenie, spotykamy się i daję kilka wskazówek. Z doświadczenia wiem, że nie jesteśmy nauczeni prezentacji. Raczej przygotowując takowe zaczynamy od otwarcia Power Pointa, co jest raczej niepokojące. Spotykamy się więc i staram się w kilku zdaniach przedstawić odrobinę inny obraz prezentacji. Nakierowany na słuchacza, a nie na “byle zrobić”. Nie żebym sam świetnie prezentował. Coś tam jednak wiem i to “coś” staram się podpowiedzieć, zawsze odrobina do przodu;-).

Potem kursanci samodzielnie przygotowują i ćwiczą prezentację, aż do punktu dzień przed – gdy prezentują ją mnie. Tak próba generalna. Albo, jak się okazuje, niekoniecznie generalna. Bo po moich poprawkach tym razem kursanci poprosili o jeszcze jedną taką próbę.

Efekt? Sama prezentacja wypadła bardzo dobrze, a kursanci… nawet się nie stresowali. Wiedzieli co mają zrobić, poszli po swoje i wzięli co do nich należało.

Dzięki temu szkolenie przekrojowe nauczyło nie tylko Hadoopa, Sparka i Elasticsearcha. Nauczyło również skutecznie przedstawiać efekt prac. A to czasami – niestety – ważniejsze w kontakcie z klientem.

Współpraca

O ile warsztaty są w miarę indywidualne, o tyle projekt to wspólne dziecko kursantów. I to, że sukces zależeć będzie od ich współpracy, mają wbijane od pierwszego dnia, gdy się zobaczyliśmy. Tu naprawdę jest dużo miejsc, w których coś może pójść “nie tak”. I w związku z tym bardzo dużo punktów zapalnych. Jednym z zadań szkolenia jest zetrzeć ze sobą kursantów w tych momentach w taki sposób, żeby wiedzieli, że stoją w jednym szeregu i że od tego czy pomogę koledze/koleżance, zależy to czy dobrniemy do celu.

Jeśli chodzi o naszych kursantów, nie widziałem żadnych spięć, żadnego obrzucania się winą. I fantastycznie było na to patrzeć. Gdy jedno rozwiązało jakiś szerszy problem, dzieliło się z drugim. Razem wypracowywali koncepcję, struktury, pomysły. Razem sprawdzali sobie kod i dzielili się wątpliwościami. To zżywa. Co ważniejsze natomiast – to pokazuje, że nikt nie jest idealny, uczy pokory i tego, że warto pracować wspólnie, razem, a nie tylko w jednym zespole.

 

Odbiór krytyki

Takie szkolenie uczy poprawnego odbioru krytyki. Oczywiście nie jest to szkolenie z przyjmowania krytyki, ale jakiejś części tego tematu owszem, uczy. I poruszam to, co ciekawe, jeszcze na początku, przy okazji szkolenia z Gita, a potem wielokrotnie w trakcie projektu. Żeby zrozumieć o co chodzi, powiem tylko, że nasz kod to często nasze dziecko. Traktujemy swoją pracę wielokrotnie jak przedłużenie nas samych.

W trakcie pracy następuje natomiast taki moment jak “code review”. Pokazujemy nasze zmiany innym, a inni je komentują. I nie pokazujemy po to, żeby usłyszeć jacy jesteśmy wspaniali, tylko gdzie mamy błędy, gdzie postąpiliśmy definitywnie niezgodnie ze standardami, a gdzie całość można znacząco uprościć.

To nigdy nie jest łatwe, czytać na swój temat szereg uwag. I to wielokrotnie. Dlatego od początku tłumaczę, że kod to nie my. Krytyka kodu, to nie krytyka nas. A uwagi służą temu, żeby zbudować lepszy produkt finalny. I przy okazji, żebyśmy my stali się lepszymi programistami, inżynierami. Ta teoria + wielokrotna praktyka później, ustawia kursantów w odpowiednim punkcie. Nie chodzi o to, żeby krytyką się biczować. Nie chodzi też o to, żeby spływała jak po kaczce. Ona ma być konstruktywna.

Ma to też drugą stronę medalu – sami mamy dawać możliwie konstruktywny feedback. Liczę, że zostanie to potem z kursantami w życiu;-)

Wytrwałość

Ostatnie co należy wspomnieć, to kwestia wytrwałości. Kursanci nie rozwiązują jedynie przykładowych ćwiczeń. Oni mają całe dnie, żeby poradzić sobie z – często – trudnym, złożonym problemem. Takim, który sprawia kłopoty na poziomie pomysłu, konfiguracji, implementacji.

Wiem dobrze, że czasami kursanci wyrywają sobie włosy z głowy. To są normalne problemy, które przyjdą potem w projekcie. Dlatego zderzamy się z nimi już tutaj, w kontrolowanych warunkach.

No właśnie. Tego typu przekrojowe szkolenie z Big Data to dużo potu, wysiłku, presji. Natomiast nie jest to nigdy presja niezdrowa. I to jeden z moich obowiązków, żeby w odpowiednim momencie pomóc, podpowiedzieć, pokrzepić dobrym słowem. Żeby ciągle utrzymywać dobrą atmosferę, bo presja ma wynikać z wewnętrznego poczucia obowiązku, a nie z napięcia między członkami takiego projektu. To bardzo ważne, bo z jednej strony pomaga podejść do komercyjnego projektu. Z drugiej – nie jest wyniszczające i wypalające.

Nasi kursanci byli niezwykle wytrwali. Pracowali ciężko, w sposób zdyscyplinowany. Czy był jakiś brak? Owszem – brak wymówek i migania się od roboty. Oboje ciężko zasuwali, żeby nauczyć się i dopiąć całą robotę. Jestem szczerze przekonany, że świetnie poradzą sobie w najbliższym projekcie i w życiu. Wróżę dużo sukcesu, bo dysponują fantastycznym zestawem cech. A teraz – mam nadzieję – także solidną wiedzą technologiczną;-).

Podsumowanie

Szkolenie przekrojowe może być realizowane w rozmaity sposób. Staram się podczas niego:

1. Nauczyć podstaw technologii w metodyczny sposób
2. Ugruntować wiedzę poprzez łączenie elementów w praktycznych zadaniach (jak projekt)
3. Dorzucić elementy miękkie – komunikację, organizację projektu, umiejetność odpowiedniego podejścia do krytyki.

Jeśli tylko jesteś przedstawicielem firmy, która chciałaby wyszkolić nowych pracowników w podobny sposób, napisz na

kontakt@riotechatafactory.com

Odpowiem tak szybko jak to możliwe. Dogadamy razem szczegóły i ułożymy plan w taki sposób, żeby za jakiś czas Twoje szeregi zasilili wspaniali Inżynierowie Big Data. Moją misją jest pomoc w takich właśnie momentach. Instruktorom z którymi współpracuję, także;-).

Jeśli chcesz mnie lepiej poznać, mam dla Ciebie kilka propozycji:

1. Zapisz się na newsletter i odbierz darmowego ebooka o Big Data. Prawie 140 stron opisu branży z wielu różnych stron.
2. Przejrzyj YouTube – znajdziesz tam nie tylko materiały techniczne!
3. Przesłuchaj podcast “Big Data Po Polsku”. Mówię tam o Big Data ludzkim językiem.