Kluczowe role w projekcie Machine Learning

Dlaczego większość projektów Machine Learning nie odnosi sukcesu lub wręcz upada?

Jakie są kluczowe role, aby projekt miał szansę przeżyć i przynieść wymierne korzyści?

Posłuchaj tego odcinka podcastu lub przeczytaj artykuł, aby odpowiedzieć na te i wiele innych pytań, które zwiększają szansę na powodzenie projektów klasy R&D w branży Data Science i Machine Learning.

Dlaczego tak wiele projektów ML rozpoczyna się, ale większość z nich kończy się bez sukcesu? Czy da się tym efektywniej zarządzać?

Wszystkie szczęśliwe rodziny są do siebie podobne, każda nieszczęśliwa rodzina jest nieszczęśliwa na swój sposób

Lew Tołstoj, Anna Karenina.

Podobnie jest z ML, istnieje wiele przyczyn, co może pójść nie tak, więc próba wymienić je wszystkie może być dużym wyzwaniem. Analizując sytuacje, których byłem świadkiem lub takie, w których mogłem dostrzec pewne szczegóły, aby wyciągać wnioski, zadałem sobie trudu zapytać, czy da się wyłonić z tego kilka punktów, które są ważne, aby projekt ML (niemal każdy) mógł się udać. 

Podchodziłem do tego zadania na kilka sposobów. Natomiast zostałem przy dość oczywistej interpretacji i skupiłem się na ludziach. Mówiąc dokładniej – ludzi w pewnych rolach, które są kluczowe dla projektów Machine Learning moim zdaniem.  

W zespole powinny się znaleźć pewne role, aby projekt się udał. Teraz nie chcę wymieniać ich wszystkich i rozdrabniać się, ponieważ przy pracy z danymi istnieje wiele ról, takich jak np.:

• Machine Learning Engineer
• Data Engineer
• Machine Learning Researcher

I każdy z nich robi coś swojego, ale w tym dzisiejszym rozważaniu te role połączę w jedno i nazwę ją jako rola techniczna.

Na początek podam Ci prosty wzór, który wręcz jest dość oczywisty. Natomiast następnie przerobimy konkretne przykłady i zobaczysz, że stosując ten prosty schemat naprawdę można szybko wychwycić potencjalne problemy.

Kluczowe role w zespole Machine Learning

Warstwa pierwsza (role):

• Marzyciel/Wizjoner
  • ma pomysł (marzenie) zrobić “coś”.
• Kierownik/Manager/PM
  • Potrafi przenieść marzenie na poziom planu (ustawić priorytety, deadline, przypisać zadania do właściwych wykonawców itd).
• Wykonawca
  • Potrafi wykonać plan (dobrze).

Dodatkowo można powiedzieć, że ta struktura zagnieżdża się, czyli możemy wziąć sobie rolę wykonawcy i tam wyróżnić: 

• Wykonawca Wizjoner (umie łączyć świat “wykonawcy” ze światem wizjonera)
• Wykonawca-Kierownik  (umie dobrze zdefiniować np. techniczne zadanie)
• Wykonawca-Wykonawca (zrobi dobrze zdefiniowane zadanie)
  
  

Pewnie ciekawy jesteś, na czym polega rola: Wizjoner x 2. Simon Sinek powiedział:

„Vision” is the ability to talk about the future with such clarity it is as if we are talking about the past.

„Wizja” to umiejętność mówienia o przyszłości z taką klarownością, jakbyśmy mówili o przeszłości.

Pomyśl, jak dużo znasz wizjonerów (lub mówiąc precyzyjniej osób, które zajmują się wizją) i potrafią ją bardzo precyzyjnie określić?   Wizjoner-Wizjoner, to jest człowiek, który więcej czasu spędza w teraźniejszości, aby lepiej wyczuć przyszłość. Natomiast prawda jest taka, że takich ludzi jest mało. Dlatego występowanie wszystkich 9 ról jest przypadkiem idealnym.

Mając przynajmniej takie 3 role (albo nawet 3 x 3), zwiększasz swoje szanse, że Twój projekt ML się uda. Swoją drogą, czy te wszystkie role może pełnić jedna osoba?

W teorii pewnie tak, w praktyce dość rzadkie zjawisko (o ile możliwe). Natomiast te 9 ról wcale nie oznacza zawsze 9 osób. Jedna osoba, może łączyć w sobie kilka ról. Natomiast ważne jest, aby być świadomym tego, czy w Twoim zespole są spełnione istotne role (przynajmniej 3 role).

Opowiem Ci 3 historie, podczas których pojawiły się pewne kłopoty przy projektach. Z jednej strony te kłopoty są dość szczególne i po swojemu “nieszczęśliwe”, ale jeśli przyjrzeć się im dokładniej, to można zobaczyć, że te kłopoty są skutkiem tego, jak rozłożyły się pewne role w projekcie i zespole.

Pochopne budowanie infrastruktury

Spróbujmy lepiej zrozumieć kontekst.  Z jednej strony wiemy i także ja to ciągle powtarzam, jak ważne są dane dla ML. To jest prawda. Nie mając danych, nie można wytrenować modelu, bo to jak w tym słynnym powiedzeniu – dane są paliwem dla modelu. Z drugiej strony zdrowy rozsądek jest ważniejszy! Miałem okazję zobaczyć na własne oczy skrajność, która z dużym prawdopodobieństwem  może powielać się w wielu przypadkach. O co chodzi?

Pewna spółka wpadła na pomysł, że skoro dane są konieczne ML, to najpierw budujemy infrastrukturę i zbieramy dane.  Początek brzmi sensownie, ale co to oznacza w praktyce (słynne pytanie, które często zadajemy w DataWorkshop)? Ta spółka zaprosiła do tego ludzi, którzy znają się na budowaniu infrastruktury IT.  Powstał plan, jak fajne pewne procesy można skalować, nawet petabajty danych można obsłużyć. Płacimy tylko wtedy jak używamy te zasoby i dzięki temu mamy duże oszczędności. To wszystko brzmi atrakcyjnie i nawet może sprawić, że jesteśmy na wygranej pozycji już na starcie. 

Teraz nie próbuję podważać kwestii technicznych (czy to naprawdę skaluje się i czy płacimy tylko wtedy jak używamy) oraz czy taka infrastruktura jest naprawdę potrzebna, bo docelowo tak,  ale …

Zwracam uwagę na coś innego. W tej dyskusji (której byłem świadkiem) zabrakło jednego ważnego pytania, które powinno być zadawane zawsze, a w przypadku początkowego etapu rozwoju projektu ML i firmy szczególnie często.
 

Po co? Po co nam infrastruktura, która  fajnie skaluje się, skoro nawet nie wiemy, jakie dane chcemy zbierać i w jakiej postaci.

Podam Ci analogię, jak to brzmi dla mnie. Zamiast tego, aby zaprojektować dobry biznes model i uruchomić go w rzeczywistości  i zweryfikować czy to faktycznie działa, zamiast tego spędzasz swoją całą uwagę, który bank wybrać aby przechowywać tam właśnie zarobione pieniędzy. Tylko jeszcze nie masz tych pieniędzy i nawet nie wiesz, czy będą, bo dopiero testujesz pomysł.

Owszem przydałoby się zarządzać również pieniędzmi we właściwy sposób, ale kolejność działań jest istotna. Myślę, że zgodzisz się z tym, że problem gdzie przechowywać pieniądze jest dość “przyjemniejszy” i na to jest sporo “gotowców”. Ciężej jest pieniądze  pozyskać.

Zobacz, jak łatwo jest zgubić koncentrację i zacząć robić niewłaściwe rzeczy. Skupienie się na niewłaściwych rzeczach, nawet kiedy je zrobisz we właściwy sposób – powoduje, że i tak przegrasz (czas, pieniędzy, rynek lub wszystko na raz)!

Jak byłem w Stanach, wtedy pracowałem jako architekt systemu wyszukiwarki w General Electric, to na jednym ze spotkań w pracy zauważyłem napis na tablicy:

The manager does things right; the leader does the right thing.

Menedżer robi rzeczy we właściwy sposób, lider robi właściwe rzeczy. Przykuła moją uwagę ta gra słów: “do things right “ oraz “do right thing”. Robić rzeczy we właściwy sposób vs robić właściwe rzeczy. Taka zwykła odmiana słów i totalnie zmienia sens tego, co robimy.

Zwrócę Twoją uwagę, że pytałem “po co?” nie pytam “po co chmura?” To są różne pytania. Bo chociażby  w poprzednim odcinku mówiłem, że chmura daje duże możliwości. Mało tego jako DataWorkshop używamy jej na co dzień i to faktycznie nam pomaga, ale robimy to świadomie. Zobacz, w naszym przypadku to było tak, że najpierw zrozumieliśmy na mniejszą skalę, jakie dokładnie mamy problemy, gdzie faktycznie jest wąskie gardło i potem zaczęliśmy je rozwiązywać.

Przykład: aby skalować środowisko jupyter, czyli naszą platformę (opartą na open-source rozwiązanie), gdzie ludzi trenują modele uczenia maszynowego i robić to największą skalę (1000 lub więcej osób jednocześnie) w dużym stopniu automatyzacji potrzebowaliśmy użyć właściwego narzędzia i go użyliśmy. Mieliśmy problem, znaleźliśmy optymalne rozwiązanie. W tym przypadku najpierw zrozumieliśmy, który problem jest właściwy i następnie go rozwiązaliśmy we optymalny  sposób.

W zależności od tego, gdzie jest Twoja firma, również może wybrzmieć zadanie, że model potrzebuje danych do trenowania. Jeśli dopiero zaczynasz lub masz duże zaległości z infrastrukturą – to należy o to zadbać, ale zrób to z głową. Najpierw trzeba znaleźć właściwe rzeczy, np. właściwy problem do rozwiązania. 
Podpowiem Ci, jakie pytania stosujemy, aby upewnić się, czy to jest właściwa rzecz. Pytanie jest bardzo proste.

Co się stanie, jeśli tego nie zrobimy? Tylko znów na to pytanie, należy odpowiedzieć w kontekście “co to oznacza w praktyce”. Np. abstrakcyjna rozmowa, jeśli nie mamy infrastruktury IT to nie ma danych, więc nie będziemy trenować modeli ML jest dość abstrakcyjna. Bo równie dobrze można mieć dużo serwerów, które przez przypadek można nazwać jako infrastruktura IT, ale co z tego? Skoro tam gromadzą się losowe rzeczy, które wcale nie są danymi, na które model oczekuje, to nadal mamy ten sam problem.




To w takim razie zadam inne pytanie. Co powinno się stać, aby model wytrenować? Można na to pytanie odpowiedzieć abstrakcyjnie: potrzebne są dane, ale znów używając naszego słynnego pytania “co to oznacza w praktyce?” lub ewentualnie pomocnicze pytanie “jak możemy rozpoznać i zmierzyć ten moment, że mamy dane”. To pytanie powoduje, że zaczynamy bardziej dokładniej rozpisywać ten proces.

Na przykład:

• Mamy tabelę w bazie danych. 
• Która ma 10k rekordów i 150 kolumn.
• Każda kolumna to…. oraz mamy nasza odpowiedź (czyli tak zwana zmienna docelowa).
  

Dobra, to skoro na początek potrzebujemy bazę z 10k (czy nawet 100k) rekordów, to wystarczy najzwyklejsza baza MySQL/PostregSQL, która np. w chmurze da się wyklikać za 5-10 min i automatycznie mieć backup i w razie potrzebny nawet ustawić replikę. To po co na początek spróbować więcej losowych rzeczy? Zamiast tego, aby sprawdzić, czy te dane, które mamy są właściwe?

Oczywiście, mówiąc te słowa, rozumiem, że to może doprowadzić do innej skrajności, kiedy robi się duży dług techniczny. Natomiast to, co próbuję przekazać to idea, że bycie efektywnym wymaga myślenia i ciągłego zadawania sobie pytań, czy to, co robię jest naprawdę właściwym krokiem? 

To co sami robimy w ramach DataWorkshop i polecam, to robić, to dużo małych kroków, aby móc szybko i jasno odpowiadać na pytania “co to oznacza w praktyce”. Owszem w małych krokach też można się mylić, ale to mniej boli. 

Jeśli dopiero zaczynasz wdrażać ML i nie wiesz, co to oznacza dane, to warto coś zrobić, aby w Twojej głowie było lepsze rozumienie, jakie dane są potrzebne, aby to mogło wytworzyć wartość dodaną. Nie musisz rozumieć wszystkiego, od tego są specjaliści, ale spróbuj zrozumieć podstawy. Obserwuj różne inicjatywy, które robimy w DataWorkshop, część z nich jest też bezpłatna i zbadaj ze zrozumieniem ten temat. Dzięki temu ciężej będzie Ci błądzić i może unikniesz całkowitego zagubienia. Po prostu od razu będziesz wiedzieć, czego chcesz!

Wróćmy do tego, o czym mówiliśmy na początku.Jakich ról zabrakło w tym przypadku?

Był wizjoner. Pojawili się  wykonawcy-wykonawcy (czyli osoby, które potrafią np. świetnie skalować storage itd). Natomiast zabrakło spójnika. To znaczy powiem, że w zespole było dużo różnych osób, ale zabrakło wśród nich takiej osoby, która była w stanie wyczuć, na czym polega “marzenie” skonsultować go z wykonawcami, zadając sporo pytań “po co?” i przygotować solidny plan. Wbrew pozorom ta rola jest trudna, tu chodzi o coś więcej niż zwykły project-manager, który pogania  i pilnuję deadline. 

Czasem tę rolę spełnia  pewnie CTO, czasem Data Officier czasem ktoś C-level, nie ważne, ale ważne, aby był człowiek, który z jednej strony potrafił wczuć się w “wizje/marzenie”, z drugiej strony potrafił to przepisać jako plan działań i znaleźć właściwe osoby, które to zrealizują. Nawet powiem więcej, ta osoba powinna sama móc to wszystko napisać (bo wcześniej już to robiła), tylko ze względu na stanowisko brakuje na to czasu. Myślę, że to zdanie jest w stanie dość mocno pomóc, aby sprawdzić, czy w Twoim zespole jest taka osoba.

Kierownik w zespole a biurokratyzacja

Kiedyś Elon Musk w jednym z wywiadów powiedział, na czym ma koncentrować się CEO:

„Spend less time on finance, spend less time in conference rooms, less time on PowerPoint and more time just trying to make your product as amazing as possible„

Spędzaj mniej czasu finansami, spotkaniami, power point i więcej czasu robiąc Twój produkt lepszym jak to tylko jest możliwe.

Ta wypowiedź jest ciekawa, ale nasuwa się inne pytanie. Kiedyś usłyszałem, takie pytanie, który CEO jest lepszy:

• Innowator (powiedzmy właśnie taki Musk);
• Manager (który stabilizuje procesy);
• Prawnik (który walczy o patenty, prawa autorskie itd.);
• Urzędnik (który procesuje w nieskończoność).

Jak myślisz, który CEO jest lepszy?

Na początek, nasuwa się (przynajmniej u mnie), że innowator. To jest oczywiste, bo najbardziej mi rezonuję, ale właściwa odpowiedź, brzmi klasycznie  – to zależy. To zależy, gdzie jest Twoja firma i o co walczysz. Słuchając (lub czytając wywiadów) z osobami, które zbudowały firmy od zera do potęg, to słyszę dość często, że np. biurokracja jest konieczna, na pewnym etapie rozwoju firmy. Po prostu (w ich doświadczeniu), jak ludzi staje się więcej, powiedzmy więcej niż tysiąc czy kilka tysięcy to musi pojawić się sporo biurokratycznych procesów. 

To w tym przypadku, stawiania innowatora jako CEO do takiej firmy, raczej nie zawsze jest dobrym pomysłem. Dla mnie zrozumienie dojrzałości firmy i że ona ma różne potrzeby (różnych liderów) i różnego sposobu myślenia stało się odkrywcze. Z jednej strony to jest oczywiste, ale z drugiej strony stąd płynie wiele ciekawych wniosków.

Nie próbuję powiedzieć, że innowacyjny CEO/ lider jest tylko jedną możliwą opcję, bo fakty jak na razie mówią coś innego. Chociaż może to kwestia zmian, które dojrzewają, po prostu musi przyjść nowe pokolenie i to zmienić, co myślisz? 

Warto też zrozumieć, że projekty R&D bardzo potrzebują innowatorów. Bo to jest ich natura. Dlatego przy większych organizacjach opłaca się robić mniejsze niezależne jednostki. Myślę, że dobrym przykładem jest PZU-lab. Więcej możesz posłuchać na ten temat w  rozmowie z Marcinem Kurczabem w 69 odcinku podcastu.

Wymieniłem, że w zespole mają się znaleźć co najmniej 3 role, najlepiej 9 ról, aby dowieść projekt ML. Natomiast może się znaleźć znacznie więcej, ale część z tych ról niestety może bardziej zaszkodzić, bo z jednej strony wydaje się, że to jest rola środkowa (czyli kierownik), ale jak to jest w praktyce? 

Na ile kierownika w tych moich rolach można nazwać urzędnikiem lub nawet biurokratom? Świadomie używam tych słów, aby podkreślić co próbuję powiedzieć. Jeśli człowiek pełniąc rolę kierownika w projektach ML zachowuje się bardziej jako urzędnik, czyli bardziej dba o papierki i o to,  aby wszystko zgadzało się na papierku, to można uznać, że mamy w zespole urzędnika (który “przejmuje” władzę) może przynieść dużo negatywnych konsekwencji i nadal brakuje kierownika. 

Kierownik w moim rozumieniu to osoba, który z jednej strony jest bardzo poukładana, ale z drugiej strony ma otwarty umysł, potrafi zrozumieć zmienną i płynność projektów R&D i uwaga znaleźć narzędzie, aby tym ryzykiem zarządzać. Natomiast to narzędzie nie jest banalnym spisywaniem na papierku (czy wersji cyfrowej), tylko coś więcej.

Jako ciekawostka i pewien paradoks. Spotkałem już różnych ludzi, którzy są jeszcze jedną nogą na uczelni (lub już może porzucili) i narzekają, że uczelnie są skostniałymi  organizacjami – dużo biurokracji i po prostu nie da się tam rozwijać (z czym ciężko jest nie zgodzić się czasem), więc ten człowiek mówi – rzucam to i idę do biznesu.

Tylko paradoks polega na tym, że ten człowiek (o ile już spędził trochę lat na uczelni) nie potrafi ot tak myśleć inaczej. Psycholodzy na to mają swoją terminologię, natomiast jako programista powiem dość prosto – każdy z nas działa wg programu, który nadpisało mu otoczenie (zaczynając najpierw od rodziców, przyjaciół, kolegi i koleżanek). To może brzmieć dziwnie, przecież sam zarządzam swoim życiem.

Natomiast to jest łatwo sprawdzić, jeśli zaczniesz mierzyć swoje opinię, poglądu do wartości średniej swojego otoczenia. Wiem, że czasem lepiej o tym nie wiedzieć, ale już wiesz dlaczego spędzając więcej czasu w środowisku, w którym wszystko było mocno biurokratyczne, ciężko jest pozbyć się tego myślenia. To jest możliwe, ale to wymaga dużej pracy i otwartości na nowe doświadczenie, zwykle z tym już różnie bywa.

Podsumować ten punkt mogę powiedzieć tak.  Kiedy urzędnik trafia na stanowisko kierownika projektów R&D, możesz być prawie pewien – że będzie wszystko zgadzało się na papierkach (np. tak jak to jest lub powinno być  NCBR), ale czy wydarzy się coś więcej?  To pytanie zostawię dla Ciebie.

Poprawa sprzedaży …

Opowiem Ci trzecią historię. 

Chcemy poprawić sprzedaż do istniejących klientów w bazie danych.

Takie zdanie do nas napisała jedna z osób jako pomysł do zastosowania ML.

Spróbujmy przyjrzeć się temu. Sam cel jest zrozumiały, no bo ciężko jest znaleźć biznes, który nie chce poprawić sprzedaży. 

Teraz pytanie co powinno się stać, aby to udało się?

W dużym uproszczeniu mamy marzenie, chcemy usprawnić sprzedaż. Kolejnym krokiem jest znaleźć dobrego kierownika i wykonawców. Natomiast należy zrobić to rozsądnie i we właściwej kolejności. Jeśli znajdziesz tylko dobrych fachowych technicznych, to jest duża szansa, że coś dostaniesz, ale nie wiadomo po co.  Dlatego najpierw, w ten czy inny sposób, należy zrozumieć, co dokładnie może pomóc, aby sprzedaż wzrosła.

Czy tutaj na pewno ML jest potrzebny? Być może trzeba zostawić telefon lub e-mial na stronie internetowej, aby klienci mogli kontaktować się, być może lepiej opisać swój produkt lub usługi, jakie dokładnie problemy rozwiązuje. Natomiast jeśli to wszystko już jest zrobione i trzeba coś więcej, to może faktycznie warto sięgnąć po ML. Tylko znów, pomyśl dokładniej przed wykonaniem, co chcemy usprawnić.

Istnieje wiele przykładów, kiedy ludzie wprowadzając małe zmiany potrafili osiągnąć duży sukces. Polegało to na tym, aby myśleć wprost, jak zwiększyć x2 sprzedaż, pomyśl, jak możesz usprawnić każdy poszczególny krok (np. w lejku sprzedaży o 2%), to już brzmi zdecydowanie mniej rewolucyjnie, ale jak masz takich kroków 5 sztuk i każdy poprawisz o 2% to masz ostatecznie 2.5 razy lepiej. Zobacz na przykładzie. Mamy 5 kroków. Stan przed był, na każdym kroku przechodzi 10%, stan każdy krok poprawiamy o 2%, czyli konwersja na każdy kroku 12%

Przykład:

1. 100000 => 10000 => 1000 => 100 => 10 => 1 
2. 100000 => 12000 => 1440 => 172.8 => 20.7 => 2.5 

Mając taką wizję (co nadal nie jest klarowne), ale przynajmniej można próbować zrobić przymiarki i zobaczyć co może pomóc zwiększyć konwersję na każdym kroku o 2%. Być może właśnie ML, ale też nie zawsze. Czasem chodzi o jakieś proste działania.

Natomiast jeśli jednak chodzi o ML, to przynajmniej w tym przypadku właściwy kierownik projektu będzie w stanie przekuć to na właściwie zadania, rozpisać na osi czasu i wyjaśnić wykonawcom, co należy zrobić.

Podsumowanie

Opowiedziałem Ci dzisiaj moje przemyślenia o rolach, które powinny się znaleźć, są co najmniej trzy lub nawet 9, to wizjoner/marzyciel, kierownik oraz wykonawca. Natomiast każdą z tych ról można jeszcze dodatkowo podzielić na kolejne podobne trzy.

Podałem też przykład, że mogą się pojawiać inne role w zespole lub wiele innych osób, ale to często zwykle powoduje więcej kłopotów niż pożytku. Biurokracja w projektach R&D zwykle wprowadza dużo zamieszania. Jeśli Twoja organizacja jest duża i jej natura jest taka, że inaczej nie da się – buduj laby, niezależne komórki, które rządzą się prawami startupów (innowacyjności i mają na czele  lidera innowatora).

Bardzo jestem ciekaw Twojej informacji zwrotnej. Właściwe nazwy ról, które nadałem są mało istotne, ale ciekawy jestem, czy masz przykłady z życia wzięte, kiedy któraś inna rola koniecznie jest potrzebna (dla projektów ML) i w moim zestawieniu zostało pominięta? Zapraszam do merytorycznej dyskusji.

Tak się składa, że kolejny odcinek będzie setny. Pewnie to ma być coś ciekawego? Też tak myślę dlatego do usłyszenia za 2 tygodni, już szykuję materiał.