Premostitev vrzeli med raziskavami in razvojem

Zgodba o biometriki Onfido

Startupi strojnega učenja pogosto trpijo med prepadom med inženiringom in raziskavami. Onfido ni izjema. V tej zgodbi vas bom popeljal skozi pot biometrične ekipe do resnično medfunkcionalnosti.

Simptomi neintegriranih skupin

Ko sem pred skoraj dvema letoma prvič začel pri Onfidu, je bila raziskovalna funkcija popolnoma ločena od inženirske funkcije. Sedel je zunaj navzkrižno funkcionalnih skupin, imel je svoje vodstvo in svoje cilje.

To vodi do različnih bolečin v podjetju:

  • Raziskovalci strojnega učenja so se počutili, kot da so porabili veliko časa za izdelavo svoje kode, ki je niso imeli pri strokovnjakih ali celo uživali. Imeli so veliko odvisnosti od DevOpsa in drugih inženirjev zunaj svojih funkcij, kar je upočasnilo njihov napredek.
  • Inženirska ekipa se je pritožila nad proizvodno pripravljenostjo izdelanih algoritmov, ki pogosto niso bili testirani in jih ni bilo mogoče meriti. Ni pomagalo, da zaledni inženirji niso resnično delali Pythona.
  • Podjetje ni bilo vidno, kaj se dogaja, in ni bilo razumevanja, kako dolgo bo trajal projekt, in je bilo na splošno frustrirano zaradi pomanjkanja vidnega napredka.

To so teme, ki sem jih videl v drugih proizvodnih podjetjih, ki temeljijo na strojnem učenju, ki delujejo brez integriranih ekip. Te napetosti lahko spodbudijo in poslabšajo zaupanje med funkcijami, spodkopavajo kakršno koli preostalo empatijo in uničijo ugled celotnih funkcij v podjetju.

Kako smo integrirali ekipe

Kot vodja izdelkov sem bil zadolžen za nadzor nad popolnoma novo biometrično linijo poslovanja. Razporedil sem procese, ki sem jih prej uporabljal za razbijanje ovir v komunikaciji in izgradnjo empatije: medsebojno funkcionalne skupine in skupne cilje.

Skupina je začela kot en vodja izdelkov, eno vodstvo ekipe, trije razvijalci Ruby / Elixir in en raziskovalec strojnega učenja. Medtem ko so bili izdelki in raziskave v Londonu, so bili inženirji v Lizboni.

Razvoj ekipe. Izginjajo obrazi = napredovanja, selitve v druge ekipe in konec pripravništva. Še sreča, da še ni nikogar odnehal

Gradnja odnosov med funkcijami

Prvi korak je bil vzpostaviti odnos z raziskovalcem strojnega učenja, ki je v tem trenutku še vedno veljal za del raziskovalne skupine in se je pravkar ukvarjal z algoritmi biometrije.

Z njim sem sodeloval, da sem razumel njegovo vizijo, problemski prostor in kaj ga je navdušilo. Pomagal mi je razumeti, kaj je zdaj mogoče, v primerjavi s čim pa bi potrebovali dolgo časa. Ocenili smo trg za podobno ponudbo in potencialne ponudnike ter pretehtali odločitve o gradnji in nakupu.

Sestavili smo seznam algoritmov, da smo jih skupaj preučili in jih prednostno razdelili, zavestno razveljavili naš portfelj stav, tako da je obstajala dobra količina določenih kratkoročnih algoritmov, uravnoteženih z večjimi in bolj tveganimi pobudami.

Vzpostavili smo partnerstvo, tako kot bi premier s svojim inženirskim vodstvom. Pomagalo je, da je ta raziskovalec strojnega učenja dokaj tržno usmerjen in usmerjen na stranke, vendar so to lastnosti, ki se jih lahko naučimo. Pomembno je graditi partnerstvo.

Uskladitev naših ciljev

Celotna skupina je skupaj zapisala četrtletne cilje in ključne rezultate (OKR), ki so bili čim bolj usmerjeni k rezultatom in ne k rezultatom. To pomeni: "premakni metriko x%", namesto "pošlji to funkcijo".

OKR usmerjeni na rezultate omogočajo raziskovalcem inženiringa in strojnega učenja, da sodelujejo pri doseganju cilja, ki ima merljiv vpliv na poslovanje, ne da bi predpisovali, kako ga doseči. To je raziskovalcem omogočilo, da so v četrtletju eksperimentirali z različnimi algoritmi, in četudi eden ne deluje, bi ga lahko še vedno opustili in poskusili z drugim načinom, kako ga rešiti.

Vsako četrtletje so moji cilji okrog odkrivanja potreb določenega trga in določitve, ali je v tem prostoru treba rešiti kakšne dragocene težave. Delitev teh spoznanj z raziskovalci strojnega učenja mi je pomagala odkriti, kaj je izvedljivo in kje lahko dosežemo prodor in inovacije pred tržiščem.

Reševanje napetosti

Medtem ko smo pisanje OKR-jev skupaj uskladili naše cilje za četrtletje, to ni popolnoma rešilo napetosti med inženiringom in raziskavami. Do tega trenutka je edini raziskovalec strojnega učenja biometrije zaposlil več ljudi, ki so se prijavili vanj in so želeli ustvariti identiteto kot raziskovalna skupina Biometrics, s čimer so se še ločili od ekipe Biometrics (Engineering).

Nekaj ​​stvari je pomagalo zbliževati ekipe in sčasoma pripeljati do oblikovanja popolnoma funkcionalne ekipe:

  • Preimenovanje našega „vodilnega tima“ v „Inženirski vodnik“: Morali smo spoznati, da če združimo ekipe, ne bi smelo voditi nihče, ampak trio potencialnih besed: trženje izdelkov, inženirsko vodenje in raziskave. Glavne vloge označujejo odgovornost vodenja linij, pa tudi arhitekturno in strateško odločanje v njihovih funkcijah.
  • Skupno druženje: obe funkciji inženiringa in raziskovanja sta bili v dveh različnih državah, zato je letenje raziskovalcev v Lizbono cel teden resnično pomagalo razbiti ovire v komunikaciji in zgraditi prijateljstvo in empatijo med obema funkcijama. To nas je združilo in ljudje so se začeli počutiti kot del enotne ekipe. Prineslo nam je tudi veliko Pasteis de Nata (portugalska kremna pogača) in okusnega portugalskega Cozida.
  • Prilagajanje slovesnosti Scruma in iteracija na proces: Narava dela inženirjev in raziskovalcev je divje drugačna in Scrum tega preprosto ne reši.
Skupinsko kosilo v Gunpowderju v Londonu.

Prilagojene slovesne slovesnosti za ekipe z raziskovalci strojnega učenja

Inženirsko delo je običajno dobro opredeljeno in gotovo. Toliko, da so bile celotne metodologije zgrajene za pomoč pri merjenju in napovedovanju rezultatov ali hitrosti programskih skupin. Najbolj priljubljena v startup svetu je agilna in različnih okusov, kot sta scrum in kanban. Medtem ko smo začeli s strogo prehrano, smo hitro naleteli na težave.

Nasprotno pa se raziskovalno delo ukvarja s številnimi neznankami. Pogosto se začne s študijo izvedljivosti, da ugotovimo, ali je kaj sploh resnično in mogoče. To se dogaja v več poskusih in lahko traja zelo dolgo, da se dosežejo predstavljivi rezultati.

Posodobitve raziskovalca so bile pogosto "moj poskus še vedno teče" ali "ja, še vedno berem prispevke". Če bi podrobneje opisali, kaj počnejo, bi inženirji zaradi pomanjkanja strokovnega znanja strogo strmeli. Njihove vozovnice so imele tudi zelo visoke ocene in so vedno prenašale več šprintov. Obe stvari sta ju frustrirali. Počutili so se, da niso mogli posodobiti posnetkov in bili ponosni na svoj napredek.

Raziskovalci pogosto ne bi razumeli, o čem govorijo inženirji. Manj so bili vključeni in jih je zanimala širša arhitektura platforme, v katero bodo sčasoma vključeni njihovi modeli.

To je bilo tako hudo, da so raziskovalci začeli preskakovati, ker se jim ni zdelo dragoceno, kar je še dodatno ustvarilo timsko disfunkcijo.

Spremembe, ki so pomagale:

  • Petek zajema: Namesto da bi se pridružili stand up (formalno Daily Scrum in scrum) bi se raziskovalci vsak dan pridružili vsak drugi dan in na koncu šele v petek, kjer bi podrobneje obveščali o tem, kaj so dosegli v tem tednu. To jim je omogočilo več časa za eksperimentiranje in jim dalo več časa, da opišejo pristop in kontekst svojega dela. Inženirji so prav tako posodobili napredek v tem tednu in kontekstualizirali svoje projekte in arhitekturne odločitve.
  • Povzetek Povzetek o Slack: Konec vsakega stojanja, napišem povzetek tega, kar se je zgodilo in na kaj se ljudje danes osredotočajo. Vsako raziskovalno raziskavo po potrebi navedem, kot je napredek pri vključevanju njihovih algoritmov ali pa je potreben njihov vložek za deblokiranje ekipe. To je pomagalo raziskovalcem, da ostanejo v zanki.
  • Algoritem klepet: V namenski seji je vsak raziskovalec razložil, kaj delajo, kako je njihov algoritem deloval ali še ni, svoj pristop, kje so bili pri njem. Vključevalo je nekaj temeljnih spretnosti za osebe, ki se ne izobražujejo na strojni ravni, in pripomoglo k izenačevanju igralnih pogojev ter vzpostavitvi skupnega jezika.
  • Dopolnjevanje skupnih zaostankov in načrtovanje šprinta: to samo po sebi ni sprememba. Pomembno je poudariti, da se je celotna ekipa pridružila med sestanki zaostanka zaostajanja in načrtovanjem šprintov, saj je pomagala uskladiti cilje za šprint, jih povezala z našimi OKR-ji in soustvarjala pot od zaključka raziskovanja algoritmov do izdelave, postopnega uvajanja in odprave v živo za vse.
  • Necenjene raziskovalne vozovnice: Ugotovili smo, da ocene raziskovalnih nalog v resnici niso pomagale napovedati, kdaj bo delo opravljeno. Odločili smo se, da bomo spuščali točke v celoti za raziskovalce, toda vstopnice naj bodo v sprintu kot način za sprožitev pogovorov med petkovim sklepom.
  • Najem mostu: Ključni najem ekipe je bil naš inženir Python, ki je premostil vrzel med raziskovalno šifro Python in našimi inženirji Ruby in Elixir. Vloga je bila ključna pri določanju, kako prehajamo od akademske kode tipa, do razširljive kode za proizvodni razred.
Praznovanje uspehov, tudi ko smo oddaljeni. Povezava do tvita.

Zaključni komentarji

Danes je ekipa za biometriko kohezivna kot kdaj koli prej. Odkar smo v naši ekipi pozdravili dve novi funkciji: Upravljanje storitev / Analiza podatkov v Londonu in testni inženir v Lizboni, sta nas začela podpirati polni delovni čas, namesto da bi ga delili z drugimi ekipami.

Skupaj praznujemo uspehe pri ohlapnih in videokonferencah, čestitamo drug drugemu za odlično delo in se učimo iz naših manj uspešnih projektov kot ekipa. Izdelek obišče Lizbono enkrat na četrtletje. Raziskave in storitve gredo v Lizbono vsakih šest mesecev. Inženirstvo in preizkusi prihajajo v London vsaj dvakrat letno. Še naprej se družimo, se učimo drug od drugega in ponavljamo svoje procese.

Zabavno potovanje do zdaj!

Vstani nad Zoom. Najbrž je nekdo rekel nekaj smešnega.

Lahko si preberete pogled razvijalca programske opreme na to zgodbo Daniela Serrana (3 min. Branja), napisano pred približno letom dni, tako da do takrat še niso bile izvedene vse zgornje spremembe.

PS: Smešno se mi zdi, kako sem na vseh teh fotografijah šel skozi štiri različne odbitke.