HIROSHI WATANABE/GETTY-BILDER
I The Wealth of Nations viser Adam Smith hvordan arbeidsdelingen blir hovedkilden til økt produktivitet. Et eksempel er samlebåndet til en pinnefabrikk: "En arbeider trekker i ledningen, en annen retter den, en tredje kutter den, en fjerde skjerper enden, en femte sliper den andre enden for å passe til hodet." Takket være spesialisering fokusert på spesifikke funksjoner, blir hver ansatt en høyt kvalifisert spesialist i sin snevre oppgave, noe som fører til økt prosesseffektivitet. Produksjonen per arbeider øker mange ganger, og fabrikken blir mer effektiv med å produsere pinner.
Denne arbeidsdelingen etter funksjonalitet er så inngrodd i våre sinn selv i dag at vi raskt organiserte teamene våre deretter. Data Science er intet unntak. Komplekse algoritmiske forretningsevner krever flere arbeidsfunksjoner, så bedrifter oppretter vanligvis team med spesialister: forskere, dataingeniører, maskinlæringsingeniører, årsak-og-virkning-forskere, og så videre. Arbeidet til spesialistene koordineres av produktsjefen med overføring av funksjoner på en måte som ligner en pinnefabrikk: "en person mottar dataene, en annen modellerer dem, en tredje utfører dem, en fjerde tiltak" og så videre,
Dessverre, vi bør ikke optimalisere datavitenskapsteamene våre for å forbedre produktiviteten. Dette er imidlertid hva du gjør når du forstår hva du produserer: pinner eller noe annet, og rett og slett streber etter å øke effektiviteten. Hensikten med samlebånd er å fullføre en oppgave. Vi vet nøyaktig hva vi vil ha - pins (som i Smiths eksempel), men ethvert produkt eller tjeneste kan nevnes der kravene fullt ut beskriver alle aspekter ved produktet og dets oppførsel. De ansattes rolle er å oppfylle disse kravene så effektivt som mulig.
Men målet med Data Science er ikke å fullføre oppgaver. Målet er heller å utforske og utvikle sterke nye forretningsmuligheter. Algoritmiske produkter og tjenester som anbefalingssystemer, kundeinteraksjoner, klassifisering av stilpreferanser, størrelse, klesdesign, logistikkoptimalisering, sesongmessig trenddeteksjon og mye mer kan ikke utvikles på forhånd. De må studeres. Det er ingen tegninger å replikere, dette er nye muligheter med iboende usikkerhet. Koeffisienter, modeller, modelltyper, hyperparametre, alle nødvendige elementer må læres gjennom eksperimentering, prøving og feiling og repetisjon. Med pins gjøres opplæring og design i forkant av produksjon. Med Data Science lærer du som du gjør, ikke før.
I en pinnefabrikk, når opplæring kommer først, hverken forventer eller ønsker vi at arbeiderne skal improvisere på noen funksjoner ved produktet annet enn å forbedre produksjonseffektiviteten. Spesialiseringsoppgaver gir mening fordi det fører til prosesseffektivitet og produksjonskonsistens (uten endringer i sluttproduktet).
Men når produktet fortsatt er i utvikling og målet er trening, forstyrrer spesialisering våre mål i følgende tilfeller:
1. Det øker koordineringskostnadene.
Det vil si de kostnadene som akkumuleres i løpet av tiden som brukes til å kommunisere, diskutere, begrunne og prioritere arbeidet som skal gjøres. Disse kostnadene skaleres superlineært med antall involverte personer. (Som J. Richard Hackman lærte oss, vokser antallet relasjoner r på samme måte som funksjonen til antall ledd n i henhold til denne ligningen: r = (n^2-n)/2. Og hvert forhold avslører en viss mengde av kostnadsforhold.) Når dataforskere er organisert etter funksjon, på hvert trinn, med hver endring, hver overlevering osv., kreves det mange spesialister, noe som øker koordineringskostnadene. For eksempel vil statistiske modellerere som ønsker å eksperimentere med nye funksjoner, måtte koordinere med dataingeniører som legger til datasettene hver gang de vil prøve noe nytt. På samme måte betyr hver ny modell som trenes opp at modellutvikleren trenger noen å koordinere med for å sette den i produksjon. Koordineringskostnader fungerer som en pris for iterasjon, noe som gjør dem vanskeligere og dyrere og mer sannsynlig at studien blir forlatt. Dette kan forstyrre læringen.
2. Det gjør ventetiden vanskelig.
Enda mer skremmende enn koordineringskostnader er tiden som går tapt mellom arbeidsskiftene. Mens koordineringskostnader vanligvis måles i timer – tiden det tar å gjennomføre møter, diskusjoner, designgjennomganger – måles ventetiden vanligvis i dager, uker eller til og med måneder! Funksjonelle spesialisters tidsplaner er vanskelige å balansere fordi hver spesialist må fordeles på flere prosjekter. Et møte på én time for å diskutere endringer kan ta uker å jevne ut arbeidsflyten. Og etter å ha blitt enige om endringene, er det nødvendig å planlegge selve arbeidet i sammenheng med mange andre prosjekter som opptar arbeidstiden til spesialister. Arbeid som involverer kodefikser eller forskning som bare tar noen få timer eller dager å fullføre, kan ta mye lengre tid før ressurser blir tilgjengelige. Inntil da er iterasjon og læring suspendert.
3. Det begrenser konteksten.
Arbeidsdelingen kan kunstig begrense læring ved å belønne folk for å forbli i spesialiteten deres. For eksempel vil en forsker som må holde seg innenfor rammen av funksjonaliteten hans fokusere energien sin på å eksperimentere med forskjellige typer algoritmer: regresjon, nevrale nettverk, tilfeldig skog, og så videre. Selvsagt kan gode algoritmevalg føre til inkrementelle forbedringer, men det er typisk mye mer å hente på andre aktiviteter, som å integrere nye datakilder. På samme måte vil det bidra til å utvikle en modell som utnytter hver eneste bit av forklaringskraft som ligger i dataene. Imidlertid kan dens styrke ligge i å endre den objektive funksjonen eller lempe på visse begrensninger. Dette er vanskelig å se eller gjøre når arbeidet hennes er begrenset. Fordi en teknisk vitenskapsmann spesialiserer seg på å optimalisere algoritmer, er det mye mindre sannsynlig at han vil gjøre noe annet, selv om det gir betydelige fordeler.
For å nevne tegnene som vises når datavitenskapsteam fungerer som pin-fabrikker (for eksempel i enkle statusoppdateringer): "venter på endringer i datapipeline" og "venter på ML Eng-ressurser" er vanlige blokkere. Jeg tror imidlertid at den mer farlige påvirkningen er det du ikke legger merke til, fordi du ikke kan angre på det du ikke allerede vet. Feilfri utførelse og selvtilfredsheten oppnådd ved å oppnå prosesseffektivitet kan maskere sannheten om at organisasjoner er uvitende om læringsfordelene de går glipp av.
Løsningen på dette problemet er selvfølgelig å kvitte seg med fabrikkpinnemetoden. For å oppmuntre til læring og iterasjon bør rollene som dataforskere være generiske, men med et bredt ansvar uavhengig av den tekniske funksjonen, det vil si organisere dataforskere slik at de er optimalisert for læring. Dette betyr å ansette «full stack-spesialister» – generelle spesialister som kan utføre en rekke funksjoner, fra konsept til modellering, implementering til måling. Det er viktig å merke seg at jeg ikke foreslår at det å ansette full-stack talenter skal redusere antall ansatte. Snarere vil jeg ganske enkelt anta at når de er organisert annerledes, er deres insentiver bedre tilpasset lærings- og ytelsesfordelene. La oss for eksempel si at du har et team på tre personer med tre forretningskunnskaper. I en pinnefabrikk vil hver tekniker bruke en tredjedel av tiden sin til hver jobboppgave, siden ingen andre kan gjøre jobben hans. I en full stack er hver generalist fullt dedikert til hele forretningsprosessen, oppskalering og opplæring.
Med færre personer som støtter produksjonssyklusen, reduseres koordineringen. Generalisten beveger seg flytende mellom funksjoner, utvider datapipeline for å legge til flere data, prøver nye funksjoner i modeller, distribuerer nye versjoner til produksjon for årsaksmålinger, og gjentar trinn så raskt som nye ideer dukker opp. Selvsagt utfører stasjonsvognen forskjellige funksjoner sekvensielt og ikke parallelt. Tross alt er det bare én person. Men å fullføre en oppgave tar vanligvis bare en brøkdel av tiden som kreves for å få tilgang til en annen spesialisert ressurs. Så iterasjonstiden reduseres.
Vår generalist er kanskje ikke så dyktig som en spesialist i en bestemt jobbfunksjon, men vi streber ikke etter funksjonell perfeksjon eller små inkrementelle forbedringer. Snarere streber vi etter å lære og oppdage flere og flere faglige utfordringer med gradvis innvirkning. Med en helhetlig kontekst for en helhetlig løsning, ser han muligheter som en spesialist ville gå glipp av. Han har flere ideer og flere muligheter. Han mislykkes også. Men kostnadene ved å mislykkes er lave og fordelene ved å lære er høye. Denne asymmetrien fremmer rask iterasjon og belønner læring.
Det er viktig å merke seg at mengden av autonomi og kompetansemangfold som tilbys fullstack-forskere i stor grad avhenger av robustheten til dataplattformen de skal jobbe på. En godt designet dataplattform abstraherer dataforskere fra kompleksiteten til containerisering, distribuert prosessering, automatisk failover og andre avanserte datakonsepter. I tillegg til abstraksjon kan en robust dataplattform gi sømløs tilkobling til eksperimentell infrastruktur, automatisere overvåking og varsling, muliggjøre automatisk skalering og visualisering av algoritmiske resultater og feilsøking. Disse komponentene er designet og bygget av dataplattformingeniørene, noe som betyr at de ikke overføres fra dataforskeren til dataplattformutviklingsteamet. Det er Data Science-spesialisten som er ansvarlig for all koden som brukes til å kjøre plattformen.
Jeg var også en gang interessert i funksjonell arbeidsdeling ved bruk av prosesseffektivitet, men gjennom prøving og feiling (det finnes ingen bedre måte å lære på), oppdaget jeg at typiske roller bedre tilrettelegger for læring og innovasjon og gir de riktige beregningene: oppdage og bygge mange flere forretningsmuligheter enn spesialisert tilnærming. (En mer effektiv måte å lære om denne tilnærmingen til organisering enn prøvingen og feilingen jeg gikk gjennom, er å lese Amy Edmondsons bok Team Collaboration: How Organizations Learn, Innovate, and Compete in the Knowledge Economy).
Det er noen viktige forutsetninger som kan gjøre denne tilnærmingen til organisering mer eller mindre pålitelig i enkelte selskaper. Iterasjonsprosessen reduserer kostnadene ved prøving og feiling. Hvis kostnadene ved feil er høye, kan det være lurt å redusere dem (men dette anbefales ikke for medisinske applikasjoner eller produksjon). I tillegg, hvis du har å gjøre med petabyte eller exabyte med data, kan spesialisering i datateknikk være nødvendig. På samme måte, hvis det er viktigere å opprettholde nettbaserte forretningsevner og deres tilgjengelighet enn å forbedre dem, kan funksjonell fortreffelighet overtrumfe læring. Til slutt er full stack-modellen avhengig av meningene til folk som vet om den. De er ikke enhjørninger; du kan finne dem eller forberede dem selv. Imidlertid er de etterspurt og tiltrekke og beholde dem vil kreve konkurransedyktig kompensasjon, sterke bedriftsverdier og utfordrende arbeid. Sørg for at bedriftskulturen din kan støtte dette.
Selv med alt det sagt, tror jeg at full stack-modellen gir de beste startforholdene. Start med dem, og gå deretter bevisst mot en funksjonell arbeidsdeling bare når det er absolutt nødvendig.
Det er andre ulemper med funksjonell spesialisering. Dette kan føre til tap av ansvar og passivitet fra arbeidernes side. Smith selv kritiserer arbeidsdelingen, og antyder at den fører til sløving av talent, dvs. arbeidere blir uvitende og tilbaketrukket ettersom rollene deres er begrenset til noen få repeterende oppgaver. Selv om spesialisering kan gi prosesseffektivitet, er det mindre sannsynlig at det inspirerer arbeidere.
I sin tur gir allsidige roller alle tingene som driver jobbtilfredshet: autonomi, mestring og hensikt. Autonomi er at de ikke er avhengige av noe for å oppnå suksess. Mestring ligger i sterke konkurransefortrinn. Og følelsen av hensikt ligger i muligheten til å ha innvirkning på virksomheten de skaper. Hvis vi kan få folk til å begeistre av arbeidet sitt og ha stor innvirkning på selskapet, så faller alt annet på plass.
Kilde: www.habr.com