Mokslinių tyrimų ir plėtros atotrūkio sumažinimas

„Onfido Biometrics“ komandos pasakojimas

Praktinius kompiuterių mokymus dažnai patiria inžinerijos ir tyrimų atotrūkis. Onfido nėra išimtis. Šioje istorijoje apžvelgsiu „Biometrijos“ komandos kelionę, kad ji būtų tikrai daugiafunkcinė.

Neintegruotų komandų simptomai

Kai aš pirmą kartą pradėjau Onfido, beveik prieš dvejus metus, tyrimų funkcija buvo visiškai atskirta nuo inžinerinės funkcijos. Jis sėdėjo ne vienoje funkcinėje komandoje, turėjo savo lyderystę ir savo tikslus.

Tai sukėlė įvairius skausmo taškus, jaučiamus visame versle:

  • Mašinų mokymosi tyrėjai jautė, kad praleido daug laiko kurdami savo kodą, kuris jiems nebuvo specialistas ar net nepatiko. Jie turėjo daug priklausomybių nuo „DevOps“ ir kitų inžinierių, nepriklausančių jų funkcijai, o tai sulėtino jų progresą.
  • Inžinierių komanda skundėsi dėl parengtų algoritmų, kurie dažnai buvo be bandymų ir negalėjo įvertinti masto, parengties gamybai. Nepadėjo tai, kad programinės įrangos inžinieriai iš tikrųjų neatliko „Python“.
  • Verslas neturėjo jokio supratimo, kas atsitiks, ir suprato, kiek laiko užtruks projektas, ir apskritai buvo nusivylęs matomos pažangos trūkumu.

Tai temos, kurias mačiau kitose ankstyvojo etapo mašininio mokymosi pagrindu veikiančiose produktų įmonėse, kurios veikia be integruotų komandų. Ši įtampa gali sužlugdyti ir sumažinti pasitikėjimą tarp funkcijų, išnaikinti bet kokią empatiją ir sunaikinti visų funkcijų reputaciją versle.

Kaip mes integravome komandas

Įstojus į produktų vadybininką, man buvo pavesta prižiūrėti visiškai naują „Biometrikos“ verslo liniją. Aš diegiau procesus, kuriuos anksčiau buvau panaudojęs komunikacijos kliūčių pašalinimui ir empatijos ugdymui: funkcinėms komandoms ir bendriems tikslams.

Komanda pradėjo veikti kaip vienas produkto vadovas, vienas komandos vadovas, trys „Ruby / Elixir“ kūrėjai ir vienas mašinų mokymosi tyrėjas. Kol produktai ir tyrimai vyko Londone, inžinieriai - Lisabonoje.

Komandos raida. Dingę veidai = paaukštinimai, persikėlimas į kitas komandas ir stažuočių pabaiga. Laimei, kad dar niekas neturėjo mesti

Ryšio tarp funkcijų kūrimas

Pirmasis žingsnis buvo užmegzti ryšius su mašinų mokymosi tyrėju, kuris šiuo metu vis dar laikė save tyrėjų komandos dalimi ir ką tik nutiko dirbti su biometrijos algoritmais.

Aš dirbau su juo norėdamas suprasti jo viziją, probleminę erdvę ir tai, kas jį jaudino. Jis padėjo man suprasti, kas dabar įmanoma, palyginti su tuo, su kuo reikės ilgai eksperimentuoti. Įvertinome panašių pasiūlymų ir potencialių tiekėjų rinką ir pasvėrėme sprendimus, susijusius su statyba ir pirkimu.

Mes sudarėme algoritmų sąrašą, norėdami juos ištirti ir suskirstyti į prioritetus, sąmoningai diversifikuodami savo lažybų portfelį taip, kad būtų nemažai tam tikrų trumpalaikių algoritmų, suderintų su didesnėmis, rizikingesnėmis iniciatyvomis.

Mes užmezgėme partnerystę, lygiai taip pat, kaip ir pirmininkas. Tai padėjo tai, kad šis mašininio mokymosi tyrinėtojas yra gana komerciškai nusiteikęs ir orientuojantis į klientą, tačiau tai yra bruožai, kurių galima išmokyti. Svarbu sukurti partnerystę.

Deriname savo tikslus

Visa komanda kartu rašė ketvirčio tikslus ir pagrindinius rezultatus (OKR), kurie kiek įmanoma labiau buvo orientuoti į rezultatus, o ne į rezultatus. T. y., „Perkelti metriką x%“, o ne „išsiųsti šią funkciją“.

Į rezultatus orientuoti OKR leidžia inžinerijos ir mašinų mokymosi tyrėjams dirbti kartu siekiant tikslo, kuris turi išmatuojamą poveikį verslui, nenurodant nurodymų, kaip jį pasiekti. Tai leido tyrėjams per ketvirtį eksperimentuoti su įvairiais algoritmais ir net jei vienas jų neveikė, jie vis tiek galėjo to atsisakyti ir eksperimentuoti kitu būdu.

Kiekvieną ketvirtį mano tikslas yra sužinoti tam tikros rinkos poreikius ir apibrėžti, ar toje erdvėje nėra kokių nors vertingų problemų, kurias reikia išspręsti. Dalijimasis šiais įgūdžiais tiesiogiai su mašinų mokymosi tyrėjais padėjo man sužinoti, kas yra įmanoma ir kur galime pasiekti proveržį ir inovacijas rinkoje.

Spręsdamas įtampą

Rašydami OKR kartu suderinome mūsų ketvirčio tikslus, tačiau tai visiškai neišsprendė įtampos tarp inžinerijos ir tyrimų. Iki to laiko vienintelis mašininio mokymosi biometrijos tyrėjas buvo pasamdęs kelis žmones, kurie jam pranešė ir norėjo sukurti tapatybę kaip Biometrijos tyrimų komanda, toliau atsiribodami nuo Biometrijos (inžinerijos) komandos.

Keletas dalykų padėjo suartinti komandas ir galiausiai paskatino sukurti visiškai funkcinę komandą:

  • „Team Lead“ pervadinimas į „Engineering Lead“: Turėjome pripažinti, kad jei sujungsime komandas, komandoms gali vadovauti ne vienas, o tik vienas trejetukas: produktų valdymas, inžinerijos ir tyrimų lyderiai. Pagrindiniai vaidmenys žymi linijinio valdymo atsakomybę, taip pat architektūrinę ir strateginę galią priimti savo funkcijas.
  • Bendravimas socialiniame gyvenime: Abi inžinerijos ir tyrimų funkcijos buvo skirtingose ​​šalyse, todėl tyrėjų skraidymas į Lisaboną visai savaitei tikrai padėjo panaikinti bendravimo kliūtis ir užmegzti draugystę bei empatiją tarp šių dviejų funkcijų. Tai mus suartino ir žmonės pradėjo jaustis kaip viena komanda. Tai taip pat atnešė mums daug „Pasteis de Nata“ (portugališko varškės pyrago) ir skanaus portugališko „Cozido“.
  • „Scrum“ ceremonijų pritaikymas ir proceso iteravimas: Inžinierių ir tyrėjų darbo pobūdis yra be galo skirtingas, o Scrum to paprasčiausiai nesumažina.
Komandos pietūs „Gunpowder“, Londone.

Pritaikytos Scrum ceremonijos komandoms su mašinų mokymosi tyrėjais

Inžinerinis darbas paprastai yra tiksliai apibrėžtas ir tikras. Tiek, kad sukurta visa metodika, padedanti įvertinti ir numatyti programinės įrangos komandų išėjimą ar greitį. Populiariausias startuolių pasaulyje yra judrus ir skirtingų skonių, tokių kaip „scrum“ ir „kanban“. Kol pradėjome laikytis griežtos kreivės dietos, greitai susidūrėme su problemomis.

Priešingai, tiriamajame darbe nagrinėjama daug nežinomųjų. Dažnai pradedama galimybių studija, norint išsiaiškinti, ar kažkas yra realu ir įmanoma. Tai atliekama keliais eksperimentais ir pristatomų rezultatų pateikimas gali užtrukti labai ilgai.

Tyrėjo atnaujinimai dažnai būdavo „mano eksperimentas vis dar vykdomas“ arba „taip, vis dar skaitau dokumentus“. Jei jie išsamiau aprašytų, ką jie daro, inžinieriai nustebtų tuščiai, nes trūktų žinių apie mašinas. Jų bilietai taip pat buvo labai aukšti ir nuolat keliaudavo po kelis sprintus. Abu šie dalykai juos nuvylė. Jie jautė, kad nesugeba pateikti skanių atnaujinimų ir didžiuojasi savo progresu.

Tyrėjai dažnai nesuprato, apie ką kalbėjo ir inžinieriai. Jie buvo mažiau įtraukti ir domėjosi platesne platformos architektūra, į kurią galų gale bus integruoti jų modeliai.

Tai pasidarė taip blogai, kad tyrėjai pradėjo praleisti atsistoti, nes nerado to vertingo, dar labiau sukurdami komandos disfunkciją.

Pokyčiai, kurie padėjo:

  • Penktadienio paaiškinimas: Užuot prisijungę prie „stand up“ (oficialiai „Daily Scrum in scrum“), kiekvieną dieną tyrėjai prisijungtų kas antrą dieną, o galiausiai tik penktadienį, kur jiems būtų suteikta ilgesnė informacija apie tai, ką jie pasiekė tą savaitę. Tai leido jiems daugiau laiko eksperimentuoti ir suteikė jiems daugiau laiko apibūdinti požiūrį ir darbo kontekstą. Inžinieriai taip pat informavo apie šios savaitės pažangą ir aptarė savo projektus bei architektūros sprendimus.
  • Atsistokite santūriai apie vangumą: Kiekvieno atsistojimo pabaigoje rašau santrauką apie tai, kas nutiko ir į ką žmonės kreipia daugiausiai dėmesio šiandien. Jei reikia, pamenu bet kurį iš tyrimų, pvz., Jų algoritmų integravimo pažangą ar jų indėlį, norint atblokuoti komandą. Tai padėjo tyrėjams išlikti sąžiningais.
  • Algoritmo pokalbis: tam skirtoje sesijoje kiekvienas tyrėjas paaiškino, ką jie dirbo, kaip jų algoritmas veikė ar dar neveikė, koks buvo jų požiūris. Tai apėmė pagrindinį ne mašinomis besimokančių žmonių kvalifikacijos kėlimą ir padėjo išlyginti konkurencijos sąlygas bei sukurti bendrą kalbą.
  • Bendras atsilikimo patikslinimas ir „Sprint“ planavimas: tai nėra permaina. Svarbu pabrėžti, kad visa komanda prisijungė prie atsilikimo tobulinimo sesijų ir sprinto planavimo, nes tai padėjo suderinti sprinto tikslus, susiejo juos su mūsų OKR ir kartu sukūrė kelią nuo algoritmo tyrimų pabaigos iki jo pagaminimo, inscenizuotą plėtrą ir ėjimą. gyventi visiems.
  • Neįvertinti tyrimų bilietai: nustatėme, kad tyrimų užduočių įvertinimai iš tikrųjų nepadėjo mums numatyti, kada darbas bus atliktas. Mes nusprendėme visiškai atsisakyti taškų tyrinėtojams, tačiau laikydami bilietus į sprinto bilietą, mes galime paskatinti pokalbius per „Penktąją atkaklą“.
  • Pasamdykite tiltą: Pagrindinė komandos nuoma buvo mūsų „Python“ inžinierius, kuris užpildė atotrūkį tarp tyrėjų Python kodo ir mūsų „Ruby“ ir „Elixir“ inžinierių. Šis vaidmuo buvo labai svarbus nustatant, kaip pereiname nuo akademinio tipo kodo prie gamybos laipsnio keičiamo kodo.
Švenčiame sėkmes, net kai esame nutolę. Nuoroda į tviterį.

Uždarymo komentarai

Šiandien „Biometrijos“ komanda yra darni kaip niekad. Nuo to laiko savo komandai palankiai įvertinome dvi naujas funkcijas: paslaugų valdymą / duomenų analizę Londone, o bandymų inžinierius Lisabonoje pradėjo mus palaikyti visą darbo dieną, o ne dalintis su kitomis komandomis.

Kartu švenčiame sėkmę, naudodamiesi nesąžiningais ir vaizdo konferencijomis, sveikiname vieni kitus už puikų darbą ir mokomės iš mūsų, kaip mažiau sėkmingų, projektų. Produktas apsilanko Lisabonoje kartą per ketvirtį. Moksliniai tyrimai ir paslaugos į Lisaboną vyksta kas šešis mėnesius. „Engineering and Test“ į Londoną atvyksta bent du kartus per metus. Mes nuolat plepame, mokomės vieni iš kitų ir kartojame savo procesus.

Kokia smagi kelionė ji buvo iki šiol!

Atsistokite per mastelį. Kažkas turėjo pasakyti ką nors juokingo.

Galite perskaityti Danielio Serrano (3 min. Skaitymas), parašytą maždaug prieš metus, programinės įrangos kūrėjo apžvalgą apie šią istoriją, parašytą maždaug prieš metus, taigi iki tol visi minėti pakeitimai nebuvo įgyvendinti.

PS: Man smagu, kaip aš išgyvenu keturis skirtingus kirpimus visose šiose nuotraukose.