Dlaczego zespołom Data Science potrzebni są uniwersaliści, a nie specjaliści

Dlaczego zespołom Data Science potrzebni są uniwersaliści, a nie specjaliści
HIROSHI WATANABE/GETTY IMAGES

W książce „Bogactwo narodów” Adam Smith pokazuje, jak podział pracy staje się głównym źródłem zwiększania wydajności. Przykładem jest linia montażowa w fabryce produkcji szpilek: „Jeden pracownik ciągnie drut, inny prostuje go, trzeci go przycina, czwarty szlifuje koniec, piąty wygładza drugi koniec do nałożenia główki”. Dzięki specjalizacji, skoncentrowanej na określonych funkcjach, każdy pracownik staje się wysoko wykwalifikowanym specjalistą w swojej wąskiej dziedzinie, co prowadzi do zwiększenia efektywności procesu. Produkcja na jednego pracownika wzrasta wielokrotnie, a fabryka staje się bardziej efektywna w produkcji szpilek.

Taki podział pracy według funkcjonalności jest tak głęboko zakorzeniony w naszych umysłach, że szybko organizujemy nasze zespoły w odpowiedni sposób. Data Science nie jest wyjątkiem. Złożone algorytmiczne możliwości biznesowe wymagają wielu funkcji pracy, dlatego firmy zazwyczaj tworzą grupy specjalistów: badaczy, inżynierów analizy danych, inżynierów uczenia maszynowego, naukowców zajmujących się przyczynowo-skutkowymi związki, i tak dalej. Pracę specjalistów koordynuje menedżer produktu, przekazując zadania w sposób przypominający fabrykę szpilek: „jedna osoba gromadzi dane, inna je modeluje, kolejna je realizuje, czwarta mierzy” i tak dalej.

Niestety, nie powinniśmy optymalizować naszych zespołów Data Science dla zwiększenia wydajności. Jednak to właśnie robicie, gdy rozumiecie, co produkcja: szpilki czy coś innego, i dążycie do zwiększenia efektywności. Celem linii montażowych jest wykonanie zadania. Dokładnie wiemy, czego chcemy — to szpilki (jak w przykładzie Smitha), ale możemy wspomnieć o każdym produkcie czy usłudze, w których wymagania w pełni opisują wszystkie aspekty produktu i jego zachowania. Rola pracowników polega na tym, aby realizować te wymagania w sposób jak najbardziej efektywny.

Jednak celem Data Science nie jest wykonywanie zadań. Raczej celem jest badanie i rozwijanie nowych silnych możliwości biznesowych. Produkty i usługi algorytmiczne, takie jak systemy rekomendacji, interakcje z klientami, klasyfikacja preferencji w stylu, dobór rozmiarów, designu odzieży, optymalizacja logistyki, wykrywanie sezonowych trendów i wiele innych, nie mogą być opracowane z góry. Muszą być badane. Nie ma żadnych szkiców do reprodukcji, to nowe możliwości z wrodzoną im niepewnością. Współczynniki, modele, typy modeli, hiperparametry, wszystkie niezbędne elementy muszą być badane poprzez eksperymenty, próby i błędy oraz iteracje. W przypadku szpilek, uczenie i projektowanie odbywa się z góry, przed ich produkcją. W Data Science uczysz się w trakcie procesu, a nie przed nim.

W fabryce szpilek, gdzie uczenie się jest na pierwszym miejscu, nie czekamy i nie chcemy, aby pracownicy improwizowali przy jakiejkolwiek cechie produktu, z wyjątkiem podnoszenia efektywności produkcji. Specjalizacja zadań ma sens, ponieważ prowadzi do efektywności procesów i spójności produkcji (bez wprowadzania zmian w finalnym produkcie).

Jednak gdy produkt wciąż się rozwija, a celem jest nauka, specjalizacja przeszkadza naszym celom w następujących przypadkach:

1. Zwiększa to koszty koordynacji.

Oznacza to koszty związane z czasem poświęconym na komunikację, dyskusje, uzasadnianie oraz określanie priorytetów zadań, które trzeba wykonać. Te koszty rosną nieliniowo wraz z liczbą zaangażowanych osób. (Jak uczył nas J. Richard Hackman, liczba relacji r rośnie w sposób analogiczny do funkcji liczby członków n zgodnie z tym równaniem: r = (n ^ 2-n) / 2. I każda relacja ujawnia pewną ilość współzależności kosztów). Kiedy specjaliści ds. analizy danych są zorganizowani według funkcji, na każdym etapie, przy każdej zmianie, każdym przekazaniu usług, itd. Wymagana jest duża liczba specjalistów, co zwiększa koszty koordynacji. Na przykład, specjaliści od modelowania statystycznego, którzy chcą eksperymentować z nowymi funkcjami, muszą koordynować swoje działania z inżynierami przetwarzania danych, którzy uzupełniają zbiory danych za każdym razem, kiedy chcą spróbować czegoś nowego. Podobnie, każdy nowy wytrenowany model oznacza, że programista modelu potrzebuje kogoś, z kim mógłby skoordynować swoje działania w celu wdrożenia go w produkcji. Koszty koordynacji działają jako opłata za iterację, co czyni je bardziej skomplikowanymi i kosztownymi, a także zwiększa prawdopodobieństwo rezygnacji z eksploracji. To może utrudnić proces uczenia się.

2. Utrudnia to czas oczekiwania.

Jeszcze bardziej niepokojące niż koszty koordynacji jest czas stracony pomiędzy zmianami roboczymi. Podczas gdy koszty koordynacji zazwyczaj mierzy się w godzinach — czyli czasie potrzebnym na przeprowadzenie spotkań, dyskusji, przeglądów projektów — czas oczekiwania zwykle mierzy się w dniach, tygodniach, a nawet miesiącach! Harmonogramy specjalistów funkcjonalnych są trudne do zgrania, ponieważ każdy specjalista musi być zaangażowany w kilka projektów. Jednogodzinne spotkanie dotyczące zmian może zająć kilka tygodni, aby dostosować przebieg pracy. A po zatwierdzeniu zmian należy zaplanować samą faktyczną pracę w kontekście wielu innych projektów zajmujących czas roboczy specjalistów. Prace związane z naprawą kodu lub badaniami, które w teorii można zakończyć w kilka godzin lub dni, mogą zająć znacznie więcej czasu, zanim zasoby będą dostępne. Do tego czasu iteracja i uczenie się są wstrzymane.

3. Ogranicza to kontekst.

Podział pracy może sztucznie ograniczyć uczenie się, nagradzając ludzi za to, że pozostają w swojej specjalizacji. Na przykład naukowiec-badacz, który musi pozostać w ramach swojej funkcjonalności, skupi swoją energię na eksperymentach z różnymi typami algorytmów: regresją, sieciami neuronowymi, random forest itd. Oczywiście dobór algorytmu może prowadzić do stopniowych ulepszeń, ale generalnie znacznie więcej można zyskać na innych rodzajach działalności, takich jak integracja nowych źródeł danych. Podobnie pomoże to opracować model, który wykorzystuje każdą bitę zdolności wyjaśniającej zawartej w danych. Niemniej jednak jej mocną stroną może być zmiana funkcji celu lub osłabienie pewnych ograniczeń. Trudno to dostrzec lub zrobić, gdy jej praca jest ograniczona. Ponieważ naukowiec-specjalista specjalizuje się w optymalizacji algorytmów, ma znacznie mniej szans na zaangażowanie się w cokolwiek innego, nawet jeśli przynosi to znaczące korzyści.

Nazwijmy cechy, które pojawiają się, gdy zespoły zajmujące się danymi działają jak fabryki szpilek (na przykład w prostych aktualizacjach statusu): „oczekiwanie na zmiany w potoku danych” i „oczekiwanie na zasoby ML Eng”, które są powszechnymi blokadami. Niemniej jednak uważam, że bardziej niebezpieczny wpływ tkwi w tym, czego nie dostrzegasz, ponieważ nie możesz żałować czegoś, o czym jeszcze nie wiesz. Nienaganna realizacja wymagań i samozadowolenie, osiągnięte w wyniku zwiększenia efektywności procesów, mogą ukrywać prawdę o tym, że organizacje nie znają korzyści płynących z nauki, które przeoczają.

Rozwiązaniem tego problemu jest oczywiście pozbycie się metody fabryki szpilek. Aby stymulować naukę i iterację, role w dziedzinie danych powinny być wspólne, ale z szerokimi obowiązkami, niezależnymi od funkcji technicznych, to znaczy należy zorganizować specjalistów w dziedzinie danych w taki sposób, aby byli zoptymalizowani pod kątem nauki. Oznacza to, że należy zatrudnić „specjalistów pełnostackowych” — uniwersalnych specjalistów, którzy mogą pełnić różne funkcje: od koncepcji po modelowanie, od realizacji po pomiar. Ważne jest, aby podkreślić, że nie zakładam, iż przy zatrudnianiu specjalistów pełnostackowych liczba pracowników powinna maleć. Raczej sugeruję, że kiedy są zorganizowani inaczej, ich motywacje lepiej pasują do korzyści płynących z nauki i efektywności. Na przykład masz zespół składający się z trzech osób, posiadających trzy cechy biznesowe. W fabryce szpilek każdy specjalista poświęcałby jedną trzecią czasu każdemu zadaniu zawodowemu, ponieważ nikt inny nie mógłby wykonać jego pracy. W pełnym stosie każdy wszechstronny pracownik jest całkowicie poświęcony całemu procesowi biznesowemu, zwiększaniu skali pracy i nauce.

Mniejsza liczba osób wspierających cykl produkcyjny prowadzi do mniejszej koordynacji. Uniwersalność płynnie przemieszcza się między funkcjami, rozszerzając łańcuch danych w celu dodania większej ilości informacji, wypróbowując nowe funkcje w modelach, wdrażając nowe wersje w produkcji dla przyczynowych pomiarów i powtarzając kroki tak szybko, jak tylko pojawiają się nowe pomysły. Oczywiście, uniwersalność wykonuje różne funkcje sekwencyjnie, a nie równolegle. W końcu to tylko jedna osoba. Jednak wykonanie zadania zazwyczaj zajmuje tylko niewielką część czasu potrzebnego do uzyskania dostępu do innego wyspecjalizowanego zasobu. W związku z tym czas iteracji się skraca.

Nasz uniwersalność może nie być tak biegła jak specjalista w określonej funkcji, ale nie dążymy do doskonałości funkcjonalnej ani do niewielkich, stopniowych ulepszeń. Raczej dążymy do odkrywania nowych zadań zawodowych z stopniowym wpływem. Mając całościowy kontekst do pełnego rozwiązania, widzi możliwości, które umknąłby wąskiemu specjaliście. Ma więcej pomysłów i więcej możliwości. On także doświadcza porażek. Mimo to koszt porażki jest niski, a korzyści z nauki są wysokie. Ta asymetria sprzyja szybkim iteracjom i nagradza uczenie się.

Warto zauważyć, że zakres autonomii i różnorodności umiejętności oferowanych przez naukowców pracujących z pełnymi stakami w dużej mierze zależy od niezawodności platformy danych, na której mogą pracować. Dobrze zaprojektowana platforma danych abstrahuje naukowców zajmujących się przetwarzaniem danych od złożoności konteneryzacji, rozproszonego przetwarzania, automatycznego przechodzenia na inny zasób i innych zaawansowanych koncepcji komputerowych. Oprócz abstrakcji, niezawodna platforma danych może zapewnić bezproblemowe połączenie z infrastrukturą eksperymentalną, zautomatyzować monitorowanie i system powiadamiania, zapewnić automatyczne skalowanie oraz wizualizację wyników algorytmicznych i debugowania. Te komponenty są projektowane i tworzone przez inżynierów platformy danych, tzn. nie są przekazywane zespołowi deweloperów platformy danych przez specjalistę ds. Data Science. To właśnie specjalista ds. Data Science odpowiada za cały kod używany do uruchomienia platformy.

Również kiedyś interesowałem się podziałem funkcjonalnym pracy przy użyciu efektywności procesów, ale metodą prób i błędów (nie ma lepszego sposobu nauki) odkryłem, że typowe role lepiej sprzyjają nauce i innowacjom oraz dostarczają właściwych wskaźników: odkrywanie i budowanie znacznie większej liczby możliwości biznesowych niż podejście specjalistyczne. (Bardziej efektywnym sposobem poznania tego podejścia do organizacji, niż metoda prób i błędów, przez którą przeszedłem, jest przeczytanie książki Amy Edmondson „Interakcje w zespole: jak organizacje uczą się, tworzą innowacje i konkurują w gospodarce wiedzy”).

Istnieją pewne ważne założenia, które mogą sprawić, że takie podejście do organizacji będzie bardziej lub mniej niezawodne w niektórych firmach. Proces iteracji obniża koszty prób i błędów. Jeśli koszt błędu jest wysoki, warto rozważyć jego redukcję (choć nie jest to zalecane w przypadku aplikacji medycznych lub produkcji). Ponadto, jeśli masz do czynienia z petabajtami lub eksabajtami danych, może być konieczna specjalizacja w zakresie projektowania danych. Podobnie, jeśli utrzymanie możliwości biznesowych w sieci i ich dostępność są ważniejsze niż ich doskonalenie, przewaga funkcjonalna może przewyższyć uczenie się. Wreszcie, model pełnego stosu opiera się na opinii osób, które się na tym znają. Nie są to jednorożce; można ich znaleźć lub wykształcić samodzielnie. Jednak ich zapotrzebowanie jest wysokie, a przyciągnięcie i zatrzymanie ich w firmie wymaga konkurencyjnego wynagrodzenia, trwałych wartości korporacyjnych oraz interesującej pracy. Upewnij się, że twoja kultura korporacyjna może zapewnić takie warunki.

Nawet biorąc pod uwagę to wszystko, uważam, że model pełnego stosu zapewnia najlepsze warunki do rozpoczęcia. Zacznij od nich, a następnie świadomie dąż do funkcjonalnego podziału pracy tylko wtedy, gdy zajdzie taka potrzeba.

Istnieją też inne wady specjalizacji funkcjonalnej. Może to prowadzić do utraty odpowiedzialności i bierności ze strony pracowników. Sam Smith krytykuje podział pracy, sugerując, że prowadzi on do stępienia talentu, to znaczy pracownicy stają się nieświadomi i zamknięci, ponieważ ich role ograniczają się do kilku powtarzających się zadań. Chociaż specjalizacja może zapewniać efektywność procesu, rzadziej inspiruje pracowników.

Uniwersalne role zapewniają wszystko, co stymuluje satysfakcję z pracy: autonomię, mistrzostwo i ukierunkowanie na cel. Autonomia polega na tym, że nie są uzależnione od niczego w osiąganiu sukcesu. Mistrzostwo to silne konkurencyjne przewagi. A ukierunkowanie na cel — możliwość wpływania na biznes, który tworzą. Jeśli uda nam się zainspirować ludzi do zaangażowania w swoją pracę i wywarcia dużego wpływu na firmę, wszystko inne znajdzie swoje miejsce.

Źródło: habr.com

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster