Combler le fossé entre la recherche et le développement

Une histoire d'équipe biométrique Onfido

Les startups de Machine Learning souffrent souvent d'un gouffre entre ingénierie et recherche. Onfido ne fait pas exception. Dans cette histoire, je vais vous guider à travers le parcours de l’équipe de biométrie pour devenir véritablement interfonctionnelle.

Symptômes des équipes non intégrées

Lorsque j'ai commencé à travailler à Onfido, il y a presque deux ans, la fonction de recherche était complètement séparée de la fonction d'ingénierie. Il siégeait en dehors des équipes transversales, avait son propre leadership et ses propres objectifs.

Cela a conduit à différents points douloureux dans l’ensemble de l’entreprise:

  • Les chercheurs en apprentissage automatique ont eu l’impression de consacrer beaucoup de temps à la production de leur code, qu’ils n’étaient ni spécialistes ni même appréciés. Ils avaient de nombreuses dépendances avec DevOps et d’autres ingénieurs extérieurs à leur fonction, ce qui ralentissait leur progression.
  • L'équipe d'ingénierie s'est plainte de la disponibilité des algorithmes produits, qui étaient souvent sans tests et incapables de s'adapter. Cela n’a pas aidé les ingénieurs backend à ne pas vraiment utiliser Python.
  • L'entreprise n'avait aucune visibilité sur ce qui allait arriver, ne comprenait pas la durée d'un projet et était généralement frustrée par le manque de progrès visibles.

Ce sont des thèmes que j'ai déjà vus dans d'autres sociétés de produits basées sur l'apprentissage automatique, qui fonctionnent sans équipes intégrées. Ces tensions peuvent falsifier et dégrader la confiance entre les fonctions, éroder l’empathie restante et détruire la réputation de fonctions entières au sein de l’entreprise.

Comment nous avons intégré les équipes

En tant que chef de produit, je devais superviser un tout nouveau secteur d'activité de la biométrie. J’ai déployé les processus que j’avais utilisés auparavant pour éliminer les barrières de la communication et développer l’empathie: équipes interfonctionnelles et objectifs partagés.

L'équipe a débuté en tant que chef de produit, un chef d'équipe, trois développeurs Ruby / Elixir et un chercheur en apprentissage automatique. Alors que Product and Research étaient à Londres, les ingénieurs étaient à Lisbonne.

L'évolution de l'équipe. Visages disparus = promotions, déplacements dans d'autres équipes et fin des stages. Heureux de ne pas avoir encore arrêté de fumer

Renforcement des relations entre les fonctions

La première étape consistait à établir une relation avec le chercheur en apprentissage automatique, qui, à ce stade, se considérait toujours comme faisant partie de l'équipe de recherche et venait juste de travailler sur des algorithmes de biométrie.

J'ai travaillé avec lui pour comprendre sa vision, l'espace du problème et ce qui l'excitait. Il m'a aidé à comprendre ce qui était possible maintenant, par rapport à ce qu'il faudrait beaucoup de temps pour expérimenter. Nous avons évalué le marché pour des offres similaires et des fournisseurs potentiels, et pesé les décisions relatives à la construction par rapport à l'achat.

Nous avons compilé une liste d’algorithmes à explorer et hiérarchisés ensemble, en diversifiant consciemment notre portefeuille de paris, de sorte qu’il existe une bonne quantité de certains algorithmes à court terme, équilibrés avec des initiatives plus grandes et plus risquées.

Nous avons formé un partenariat, tout comme un PM avec son responsable technique. Cela a aidé que ce chercheur en apprentissage automatique soit plutôt commercial et centré sur le client, mais ce sont des traits qui peuvent être enseignés. L'important est de construire le partenariat.

Aligner nos objectifs

Toute l'équipe a rédigé ensemble des objectifs et résultats clés trimestriels, qui, dans la mesure du possible, étaient axés sur les résultats plutôt que sur les résultats. C'est-à-dire: "déplacer métrique x%", plutôt que "expédier cette fonctionnalité".

Les OKR axés sur les résultats permettent aux chercheurs en ingénierie et en apprentissage automatique de travailler ensemble pour atteindre un objectif qui a un impact commercial mesurable, sans être contraignant quant à la manière de le réaliser. Cela a permis aux chercheurs d’expérimenter divers algorithmes au cours du trimestre et, même s’ils ne fonctionnaient pas, ils pouvaient toujours abandonner celui-ci et expérimenter un autre moyen de le résoudre.

Chaque trimestre, mes objectifs sont de découvrir les besoins d’un marché particulier et de déterminer s’il existe des problèmes importants à résoudre dans cet espace. En partageant ces connaissances directement avec les chercheurs en apprentissage automatique, les chercheurs m'ont permis de découvrir ce qui était réalisable et les domaines dans lesquels nous pourrions réaliser des percées et des innovations avant le marché.

Résoudre la tension

Bien que l’écriture des OKR ensemble ait aligné nos objectifs pour le trimestre, cela n’a pas complètement résolu les tensions entre l’ingénierie et la recherche. À ce stade, le seul chercheur en biométrie en apprentissage automatique a embauché plusieurs personnes qui lui ont rendu compte et qui souhaitaient créer une identité en tant qu’équipe de recherche en biométrie, se séparant davantage de l’équipe de biométrie (ingénierie).

Quelques éléments ont permis de rapprocher les équipes et d’aboutir à la création d’une équipe pleinement fonctionnelle:

  • Renommer notre «chef d’équipe» en «responsable technique»: nous devions reconnaître que, si nous devions fusionner les équipes, il ne pourrait y avoir aucun chef d'équipe unique, mais un trio de responsables proprement dits: gestion de produit, responsable technique et directeur de recherche. Les rôles principaux désignent la responsabilité de la gestion hiérarchique ainsi que le pouvoir de décision architectural et stratégique de ses fonctions.
  • Socialiser ensemble: les deux fonctions d'ingénierie et de recherche se situant dans deux pays différents, le fait d'envoyer les chercheurs à Lisbonne pendant une semaine entière a vraiment aidé à éliminer les obstacles à la communication et à créer une amitié et une empathie entre les deux fonctions. Cela nous a rapprochés et les gens ont commencé à se sentir membres d'une seule équipe. Il nous a également apporté de nombreux Pasteis de Nata (tartes à la crème portugaises) et de savoureux portugais Cozido.
  • Adaptation des cérémonies Scrum et réitération du processus: la nature du travail des ingénieurs et des chercheurs est extrêmement différente, et Scrum ne le coupe tout simplement pas.
Déjeuner d'équipe à Gunpowder, Londres.

Cérémonies Scrum adaptées aux équipes de chercheurs en apprentissage automatique

Le travail d'ingénierie est généralement bien défini et certain. À tel point que des méthodologies complètes ont été construites pour aider à mesurer et à prévoir le rendement ou la vitesse des équipes logicielles. Le plus populaire dans le monde des startups est l'agile et ses différentes saveurs telles que scrum et kanban. Alors que nous avons commencé une diète scrum stricte, nous avons rapidement rencontré des problèmes.

En revanche, les travaux de recherche traitent de nombreuses inconnues. Cela commence souvent par une étude de faisabilité pour déterminer si quelque chose est réaliste et possible. Cela se produit dans plusieurs expériences et cela peut prendre très longtemps pour produire des résultats présentables.

Les mises à jour du chercheur étaient souvent «mon expérience est toujours en cours» ou «ouais, toujours en train de lire des articles». S'ils décrivaient plus en détail ce qu'ils faisaient, les ingénieurs se montreraient aveuglément faute d'expertise en apprentissage automatique. Leurs billets avaient également des estimations très élevées et continuaient à courir sur plusieurs sprints. Ces deux choses les ont frustrés. Ils ont estimé qu’ils n’étaient pas en mesure de fournir des mises à jour détaillées et d’être fiers de leurs progrès.

Souvent, les chercheurs ne comprenaient pas de quoi les ingénieurs parlaient. Ils étaient moins impliqués et intéressés par l'architecture de plate-forme plus large dans laquelle leurs modèles seraient finalement intégrés.

C’est devenu si grave que les chercheurs ont commencé à ne pas se lever parce qu’ils ne trouvaient pas cela utile, ce qui a créé un dysfonctionnement de l’équipe.

Les changements qui ont aidé:

  • Récapitulatif du vendredi: au lieu de vous joindre à la tribune (anciennement Daily Scrum in scrum), les chercheurs se joignaient tous les jours aux chercheurs, et finalement seulement le vendredi, pour donner une mise à jour plus longue des résultats obtenus cette semaine-là. Cela leur donnait plus de temps pour expérimenter et leur donnait plus de temps d'antenne pour décrire l'approche et le contexte de leur travail. Les ingénieurs ont également fait le point sur les progrès de cette semaine et ont contextualisé leurs projets et leurs décisions d’architecture.
  • Résumé Debout sur Slack: À la fin de chaque débat, j’écris un résumé de ce qui s’est passé et de ce sur quoi les gens se concentrent aujourd’hui. J'éclaire n'importe quel sujet de la recherche, le cas échéant, comme l'avancement de l'intégration de leurs algorithmes ou la nécessité de leur contribution pour débloquer l'équipe. Cela a aidé les chercheurs à rester dans la boucle.
  • Discussion sur l’algorithme: lors d’une session dédiée, chaque chercheur a expliqué sur quoi il travaillait, comment son algorithme fonctionnait ou non, son approche, où il en était. Il comprenait des compétences de base pour les personnes n’apprenant pas en machine et permettait d’égaliser les chances et d’établir un langage commun.
  • Amélioration de l'arriéré partagé et planification des sprints: il ne s'agit pas d'un changement en soi. Il est important de souligner que toute l'équipe s'est jointe aux sessions de raffinement de l'arriéré et à la planification du sprint, car cela a permis d'aligner les objectifs du sprint, de les relier à nos OKR et de créer un chemin allant de l'achèvement de la recherche algorithmique à la production, de la mise en place et du suivi. vivre pour tout le monde.
  • Tickets de recherche non estimés: nous avons constaté que les estimations relatives aux tâches de recherche ne nous aidaient pas vraiment à prédire quand le travail serait effectué. Nous avons décidé de laisser des points entièrement aux chercheurs, mais de garder les billets dans le sprint pour susciter des conversations lors de la récapitulation du vendredi.
  • Embauchez le pont: Notre ingénieur Python a été un élément clé de l’équipe, qui a permis de combler le fossé entre le code Python des chercheurs et nos ingénieurs dorsaux Ruby et Elixir. Ce rôle a joué un rôle déterminant dans la définition du passage d’un code de type académique à un code évolutif destiné à la production.
Célébrer les succès, même lorsque nous sommes à distance. Lien vers tweet.

Commentaires de clôture

Aujourd'hui, l'équipe de biométrie est aussi cohésive que jamais. Depuis, nous avons depuis ajouté deux nouvelles fonctions à notre équipe: la gestion des services / l'analyse des données à Londres et notre ingénieur de test à Lisbonne a commencé à nous soutenir à plein temps, plutôt que d'être partagés avec d'autres équipes.

Nous célébrons ensemble les succès obtenus grâce aux vidéoconférences et aux vidéoconférences, en nous félicitant mutuellement pour leur excellent travail et en tirant les leçons de nos projets moins fructueux en équipe. Le produit visite Lisbonne une fois par trimestre. La recherche et le service vont à Lisbonne tous les six mois. Engineering and Test vient à Londres au moins deux fois par an. Nous continuons à traîner, à apprendre les uns des autres et à réitérer nos processus.

Quel voyage amusant jusqu’à présent!

Debout devant Zoom. Quelqu'un a dû dire quelque chose de drôle.

Vous pouvez lire une vue de développeur de logiciel de cette histoire de Daniel Serrano (3 min de lecture), écrite il y a environ un an. Par conséquent, toutes les modifications ci-dessus n'avaient pas encore été mises en œuvre.

PS: Je trouve ça hilarant de voir quatre différentes coupes de cheveux sur toutes ces photos.