Wypełnianie luki między badaniami a rozwojem

Historia zespołu Onfido Biometrics

Startupy Machine Learning często cierpią z powodu przepaści między inżynierią a badaniami. Onfido nie jest wyjątkiem. W tej historii poprowadzę Cię przez podróż zespołu Biometrics w kierunku prawdziwie cross-funkcjonalnego.

Objawy niezintegrowanych zespołów

Kiedy zaczynałem w Onfido, prawie dwa lata temu, funkcja badawcza była całkowicie oddzielona od funkcji inżynierskiej. Siedział poza zespołami funkcjonalnymi, miał własne przywództwo i własne cele.

Doprowadziło to do różnych problemów odczuwanych w całej firmie:

  • Badacze uczący się maszynowo mieli wrażenie, że spędzają mnóstwo czasu na tworzeniu kodu, w którym nie byli specjalistami, a nawet się podobali. Mieli wiele zależności z DevOps i innymi inżynierami spoza ich funkcji, co spowolniło ich postęp.
  • Zespół inżynierów narzekał na gotowość produkowanych algorytmów, które często nie były testowane i nie były w stanie skalować. Nie pomogło to, że inżynierowie backendów tak naprawdę nie robili Pythona.
  • Firma nie widziała, co nadchodzi, nie rozumiała, jak długo potrwa projekt, i ogólnie była sfrustrowana brakiem widocznych postępów.

Są to tematy, które widziałem w innych firmach opartych na uczeniu maszynowym na wczesnym etapie, które działają bez zintegrowanych zespołów. Napięcia te mogą potęgować i osłabiać zaufanie między funkcjami, podważać wszelką pozostałą empatię i niszczyć reputację całych funkcji w firmie.

Jak zintegrowaliśmy zespoły

Dołączając do menedżera produktu, miałem za zadanie nadzorować zupełnie nową linię biznesową Biometrics. Wdrożyłem procesy, których wcześniej użyłem, do przełamywania barier w komunikacji i budowania empatii: zespoły funkcjonalne i wspólne cele.

Zespół rozpoczął jako jeden menedżer produktu, jeden lider zespołu, trzech programistów Ruby / Elixir i jeden badacz uczenia maszynowego. Podczas gdy produkt i badania były w Londynie, inżynierowie byli w Lizbonie.

Ewolucja zespołu. Znikające twarze = promocje, przeniesienia do innych zespołów i koniec staży. Na szczęście nikt jeszcze nie zrezygnował

Budowanie relacji między funkcjami

Pierwszym krokiem było zbudowanie relacji z badaczem uczącym się maszynowo, który w tym momencie nadal uważał się za część zespołu badawczego i właśnie akurat pracował nad algorytmami biometrycznymi.

Pracowałem z nim, aby zrozumieć jego wizję, problematykę i to, co go podnieciło. Pomógł mi zrozumieć, co jest teraz możliwe, a co zajęłoby dużo czasu na eksperymentowanie. Oceniliśmy rynek podobnych ofert i potencjalnych dostawców i porównaliśmy decyzje dotyczące budowania z zakupami.

Zebraliśmy listę algorytmów do zbadania i uszeregowaliśmy je według priorytetów, świadomie dywersyfikując nasze portfolio zakładów, tak aby istniała spora liczba pewnych algorytmów krótkoterminowych, zrównoważonych większymi, bardziej ryzykownymi inicjatywami.

Stworzyliśmy partnerstwo, tak jak premier zrobiłby z ich inżynierem. Pomogło to temu, że ten badacz uczenia maszynowego jest nastawiony komercyjnie i zorientowany na klienta, ale są to cechy, których można się nauczyć. Ważne jest zbudowanie partnerstwa.

Dostosowanie naszych celów

Cały zespół napisał razem kwartalne cele i kluczowe wyniki (OKR), które w jak największym stopniu były skoncentrowane na wynikach, a nie na wynikach. To znaczy: „przenieś metrykę x%” zamiast „wyślij tę funkcję”.

OKR skoncentrowane na wynikach pozwalają badaczom inżynierii i uczenia maszynowego współpracować w celu osiągnięcia celu, który ma mierzalny wpływ na biznes, bez nakazu jak go osiągnąć. Umożliwiło to naukowcom eksperymentowanie z różnymi algorytmami w ciągu kwartału, a nawet jeśli jeden z nich nie działał, nadal mogli go porzucić i eksperymentować z innym sposobem jego rozwiązania.

Co kwartał moje cele polegają na odkrywaniu potrzeb konkretnego rynku i określaniu, czy istnieją jakieś cenne problemy do rozwiązania w tej przestrzeni. Dzielenie się tymi wnioskami bezpośrednio z badaczami uczenia maszynowego pomogło mi odkryć, co było wykonalne i gdzie możemy osiągnąć przełomowe i innowacyjne rozwiązania na rynku.

Rozwiązywanie napięcia

Pisząc OKR wspólnie zrównaliśmy nasze cele na kwartał, nie rozwiązało to jednak całkowicie napięć między inżynierią a badaniami. W tym momencie jedyny badacz uczący się w dziedzinie biometrii zatrudnił wielu ludzi, którzy zgłosili się do niego i chcieli stworzyć tożsamość jako zespół ds. Badań biometrycznych, dodatkowo oddzielając się od zespołu ds. Biometrii (inżynierii).

Kilka rzeczy pomogło zbliżyć zespoły i ostatecznie doprowadziło do stworzenia w pełni funkcjonalnego zespołu:

  • Zmieniając nazwę „Lead Team” na „Lead Engineer”: Musieliśmy zdać sobie sprawę, że gdybyśmy połączyli zespoły, nie byłoby nikogo, kto prowadziłby jeden zespół, ale trzy triady leadów na słowo: zarządzanie produktem, inżynieria i lead badań. Wiodące role oznaczają odpowiedzialność kierownictwa linii, a także architektoniczną i strategiczną siłę decyzyjną w ich funkcjach.
  • Wspólne relacje towarzyskie: dwie funkcje inżynierii i badań odbywały się w dwóch różnych krajach, więc przelot naukowców do Lizbony na cały tydzień naprawdę pomógł przełamać bariery w komunikacji oraz zbudować przyjaźń i empatię między tymi dwiema funkcjami. Połączyło nas to i ludzie zaczęli czuć się częścią jednego zespołu. Przyniosło nam również wiele Pasteis de Nata (portugalskie tarty z kremem) i smaczne portugalskie Cozido.
  • Dostosowywanie ceremonii Scruma i iteracja procesu: natura pracy inżynierów i badaczy jest zupełnie inna, a Scrum po prostu tego nie ogranicza.
Drużynowy lunch w Gunpowder, Londyn.

Dostosowane ceremonie Scruma dla zespołów z badaczami uczenia maszynowego

Prace inżynierskie są zazwyczaj dobrze określone i pewne. Do tego stopnia, że ​​opracowano całe metodologie, aby pomóc zmierzyć i przewidzieć wydajność lub prędkość zespołów oprogramowania. Najbardziej popularnym w świecie startupów jest zwinny i jego różne smaki, takie jak scrum i kanban. Kiedy zaczęliśmy stosować ściśle scrumową dietę, szybko napotkaliśmy problemy.

Natomiast prace badawcze dotyczą wielu niewiadomych. Często zaczyna się od studium wykonalności, aby dowiedzieć się, czy coś jest w ogóle realistyczne i możliwe. Odbywa się to w wielu eksperymentach i może zająć bardzo dużo czasu, aby zapewnić reprezentatywne wyniki.

Aktualizacje badacza często brzmiały „mój eksperyment wciąż trwa” lub „tak, wciąż czytam artykuły”. Gdyby opisali bardziej szczegółowo, co robią, inżynierowie patrzyliby tępo z powodu braku wiedzy na temat uczenia maszynowego. Ich bilety miały również bardzo wysokie szacunki i nadal prowadziły wiele sprintów. Obie te rzeczy ich sfrustrowały. Uważali, że nie byli w stanie przekazywać mięsistych aktualizacji i byli dumni ze swoich postępów.

Badacze często nie rozumieli, o czym rozmawiali inżynierowie. Byli mniej zaangażowani i zainteresowani szerszą architekturą platform, w której ich modele zostaną ostatecznie zintegrowane.

Stało się tak źle, że badacze zaczęli pomijać wstawanie, ponieważ nie uważali tego za wartościowe, co dodatkowo powodowało dysfunkcję zespołu.

Zmiany, które pomogły:

  • Podsumowanie z piątku: Zamiast dołączać do trybuny (formalnie Daily Scrum in scrum) każdego dnia naukowcy dołączali do niego co drugi dzień, a ostatecznie dopiero w piątek, gdzie dawali dłuższą aktualizację tego, co osiągnęli w tym tygodniu. To pozwoliło im na więcej czasu na eksperymenty i dało więcej czasu na opisanie podejścia i kontekstu ich pracy. Inżynierowie przedstawili również informacje o postępach w tym tygodniu i kontekstualizowali swoje projekty i decyzje dotyczące architektury.
  • Podsumowanie wstań na temat Slacka: Pod koniec każdego wstania piszę podsumowanie tego, co się wydarzyło i na czym ludzie się dzisiaj skupiają. Zwracam się w razie potrzeby do każdego z badań, takich jak postępy w integracji ich algorytmów lub potrzeba wkładu, aby odblokować zespół. Pomogło to naukowcom pozostać w pętli.
  • Czat z algorytmem: w dedykowanej sesji każdy badacz wyjaśnił, nad czym pracował, w jaki sposób algorytm działał lub jeszcze nie działał, jakie było jego podejście, gdzie się z tym zajmowali. Obejmował on podstawowe umiejętności podnoszenia umiejętności osób nie uczących się maszynowo oraz pomógł wyrównać szanse i ustalić wspólny język.
  • Udostępnianie zaległych zaległości i planowanie sprintu: nie jest to zmiana sama w sobie. Ważne jest, aby podkreślić, że cały zespół dołączył podczas sesji doskonalenia zaległości i planowania sprintu, ponieważ pomógł wyrównać cele sprintu, powiązał je z naszymi OKR i współtworzył ścieżkę od zakończenia badań nad algorytmem do produkcji, wdrażania etapowego i uruchamiania żyj dla wszystkich.
  • Nieprzewidziane bilety na badania: Odkryliśmy, że szacunki dotyczące zadań badawczych w rzeczywistości nie pomogły nam przewidzieć, kiedy praca zostanie wykonana. Postanowiliśmy zrzucić punkty całkowicie dla badaczy, ale trzymaj bilety w sprincie, aby rozpalić rozmowy podczas piątkowego podsumowania.
  • Zatrudnij most: kluczowym zatrudnieniem dla zespołu był nasz inżynier Python, który wypełnił lukę między kodem naukowym Pythona a naszymi inżynierami zaplecza Ruby i Elixir. Rola odegrała kluczową rolę w określeniu, jak przechodzimy od akademickiego kodu typu do skalowalnego kodu klasy produkcyjnej.
Świętujemy sukcesy, nawet gdy jesteśmy oddaleni. Link do tweeta.

Komentarze końcowe

Dzisiaj Zespół Biometrii jest tak spójny jak zawsze. Od tego czasu powitaliśmy w zespole dwie nowe funkcje: zarządzanie usługami / analizę danych w Londynie, a nasz inżynier ds. Testów w Lizbonie zaczął wspierać nas w pełnym wymiarze godzin, zamiast dzielić się nimi z innymi zespołami.

Wspólnie świętujemy sukcesy związane ze zwolnieniami i wideokonferencjami, gratulując sobie nawzajem wspaniałej pracy i ucząc się z naszych mniej udanych projektów jako zespołu. Produkt odwiedza Lizbonę raz na kwartał. Badania i obsługa odbywają się w Lizbonie co sześć miesięcy. Inżynieria i testy przyjeżdżają do Londynu co najmniej dwa razy w roku. Ciągle spędzamy wolny czas, ucząc się od siebie i powtarzając nasze procesy.

Co za fajna podróż do tej pory!

Wstań nad Zoomem. Ktoś musiał powiedzieć coś śmiesznego.

Możesz przeczytać pogląd autora oprogramowania na tę historię autorstwa Daniela Serrano (przeczytany 3 minuty), napisany około rok temu, więc nie wszystkie powyższe zmiany zostały do ​​tej pory wprowadzone.

PS: To zabawne, jak przeszedłem przez cztery różne fryzury na wszystkich tych zdjęciach.