Comment nous surmontons l'incertitude au Delivery Club

Amis, bonjour tout le monde! Je m'appelle Kolya Arkhipov, je suis responsable de la recherche et du développement au Delivery Club.



Notre équipe résout des tâches à forte intensité scientifique au sein de la plate-forme FoodTech: nous développons des composants basés sur des algorithmes et des données, dont il existe de nombreux dans la plate-forme DC. Dans le processus de résolution, nous sommes confrontés à de nombreuses incertitudes tant du côté commercial que du côté du développement.



Le matériel s'est avéré volumineux et, je l'espère, utile pour vous. Par conséquent, je recommande de mettre une théière et de préparer un délicieux café, je l'ai fait moi-même en travaillant sur cet article.



Aujourd'hui, je vais vous parler de la course que notre équipe a passée au cours de l'année écoulée. L'analogie est née d'elle-même: nous travaillons dans une entreprise très dynamique, le leader du marché FoodTech en Russie. Nous développons rapidement différents domaines d'activité, et cela motive vraiment! Nous sommes non seulement arrivés à la ligne d'arrivée avec succès, mais nous avons également obtenu de nombreuses informations pendant la course. C'est ce que je veux partager avec vous.

L'article est paru après le rapport lors de la conférence RIT ++ 2020 . Pour ceux qui aiment la vidéo, cherchez-la à la fin de l'article.

La bouilloire est-elle déjà en ébullition? Super! Alors, ce qui sera discuté aujourd'hui:

1. R&D et incertitude. Ce que nous avons affronté.
2. Expériences. Comment et pourquoi les menons-nous au combat.
3. Mesurabilité. Discutons du choix des métriques et travaillons avec les risques.
4. Autonomie. Comment nous, chez DC Tech, avons adapté le cadre GIST et l'approche Inner Source.

Feu vert, embrayage, d'abord - allons-y.

R&D et incertitude

Dans certaines entreprises, l'équipe R&D est engagée dans la recherche fondamentale de nouvelles technologies. Le but d'une telle recherche peut être à la fois le développement de processus actuels et de tout nouveaux secteurs verticaux dans les affaires. Par exemple, la blockchain était une telle technologie il y a quelques années.



Immédiatement, nous parlons d'autre chose. La R&D chez Delivery Club consiste à résoudre des problèmes appliqués. Notre activité se développe rapidement, le nombre de commandes augmente et la plupart de nos processus internes sont basés sur des données et des algorithmes. Avec une augmentation de la quantité de données d'entrée, certains algorithmes cessent d'être efficaces, et ces composants qui nous convenaient parfaitement hier, nous les trouvons aujourd'hui souvent inopérants.



Comme vous l'avez peut-être deviné, ces problèmes sont souvent faiblement déterministes et, par conséquent, s'accompagnent de nombreuses incertitudes de toutes parts. Soulignons les principaux:





Examinons de plus près ce à quoi nous sommes confrontés et si ce sont vraiment des difficultés.



Comment atteindre l'objectif



Nous comprenons toujours clairement l'objectif commercial - dans quelle direction nous prévoyons d'aller, où nous devons aller. Mais il est loin d'être toujours immédiatement clair comment aborder cet objectif lorsqu'il s'agit de tâches de recherche. Quelle stratégie adopter: à travers des expérimentations ou un grand déploiement de la fonctionnalité tout de suite? Construire des environnements avec simulation ou expérimenter au combat? Le choix est grand - les yeux se lèvent.



Que vaut la peine de faire exactement



D'accord, nous comprenons l'objectif commercial et nous nous sommes mis d'accord sur la stratégie à suivre. Il est temps de décider d'un ensemble spécifique de fonctionnalités que nous utiliserons pour fonctionner. Comment les choisir, ce qu'il faut inclure dans l'arriéré, dans quel ordre: vous devez déterminer non seulement «ce qui vaut la peine d'être fait», mais aussi qui aura l'expertise maximale dans notre domaine.



Quand nous pouvons atteindre notre objectif Le



timing est vraiment très important pour les entreprises. La recherche est cool et divertissante, vous pouvez rechercher de nouvelles fonctionnalités dans les données, rechercher des algorithmes, lire des notes intéressantes de nos collègues d'autres pays. Mais il est important pour les entreprises de comprendre quand l'objectif sera atteint, car une fonctionnalité lancée au mauvais moment n'est souvent tout simplement pas nécessaire - le marché de la FoodTech est si dynamique maintenant.



Pourquoi quelqu'un a-t-il besoin de mon code?



L'incertitude finale, mais loin d'être significative, est une question de motivation des développeurs. La R&D est en grande partie du développement expérimental, par conséquent, notre code ne prend pas toujours racine dans la production. Au début, nous étions très contrariés parce que nous ne comprenions pas pourquoi nous avons fait la fonctionnalité, et de tout cœur, et l'entreprise décide que cela ne fonctionne pas et doit être scié. Questions - pourquoi est-ce que je fais cela? Pourquoi quelqu'un aurait-il besoin de mon code? - est apparu assez souvent avec nous. Dans le processus, nous avons réalisé comment nous pouvons et devons travailler avec cela, et maintenant nous sommes sûrs que c'est l'une des incertitudes les plus critiques qui doit être surmontée en premier.



Et ainsi, après avoir rempli un tas de bosses aussi décentes, nous avons rassemblé tous nos problèmes en un seul endroit et avons réalisé que pour le bonheur, nous manquons de trois processus à l'intersection de ces incertitudes.

1. , , .
2. . , , . , - , , .
3. , , - . . IT- ( ), , , , 2-3 . — , .

Schématiquement dans l'image ci-dessous.



Les expériences répondront aux questions de savoir comment atteindre les objectifs et que faire exactement. Les métriques permettront de répondre de manière très claire et transparente à la question de savoir si ce code doit vraiment rester en production. La pleine autonomie aidera à évaluer et à respecter les délais.



Nous n'arrêtons pas. Embrayage, deuxième vitesse, nous prenons rapidement de l'élan.

Expériences

Envisagez une plate-forme d'affectation automatique de messagerie personnalisée. Elle a une tâche assez simple: réunir trois acteurs du marché: nos partenaires, les logisticiens (c'est-à-dire leurs coursiers) et les clients, afin que tous les participants soient satisfaits. C'est-à-dire qu'à la réception d'une commande, il faut choisir un coursier qui viendra au restaurant exactement au moment où le restaurant finira de préparer le plat, le récupérera rapidement et le livrera au client chaud et savoureux au moment promis.



Cela semble assez simple, et ici vous pourriez dire - assez de théorie! Il est temps de passer à de vrais lancements.



Je suis d'accord avec vous, mais revenons encore un peu sur le processus des expériences. Regardons l'image dans son ensemble.

1. - — . — , , .
2. — . . — , .
3. — Just In Time. , : , , . , , , . , FoodTech- : , . , .

Examinons de plus près quel processus est sous le capot de l'incrément de produit.







3.1 Hypothèse. Il peut être formulé en mots ou schématisé. L'essentiel est de justifier clairement pourquoi cela devrait fonctionner. Autrement dit, l'expérience doit avoir une formation théorique.



3.14 Développement. Je ne m'attarderai pas ici, plus de détails sur notre développement sont décrits dans cet article . Nous utilisons Scrum, des itérations de deux semaines avec toutes les activités requises.



3.2 Préparation. Ensuite, vous devez préparer une expérience. Autrement dit, nous devons décider du geosegment ou du public avec lequel nous voulons communiquer pendant cette expérience. Et sélectionnez également le segment avec lequel nous comparerons les résultats.



3.3 Expérience. Ensuite, nous commençons l'expérience elle-même. Un point important: avant même le démarrage, nous nous entendons sur les métriques métier que nous allons suivre. Laissons aujourd'hui la discussion sur les métriques techniques, qui nous disent que l'expérimentation est lancée et techniquement stable, nous parlerons davantage d'indicateurs métier. Nous corrigerons définitivement les drapeaux rouges - ce sont des valeurs seuils que nous ne devons pas franchir au cours de notre expérience.



3.4 Analyse. Nous avons accumulé beaucoup de données intéressantes et uniques que nous sommes les seuls à posséder. Il serait étrange de ne pas en extraire des informations utiles, c'est-à-dire de tirer des conclusions raisonnables sur la validité de l'hypothèse testée, ainsi que de souligner de nouvelles choses sur l'audience de notre service.



3.5 Conclusion.Probablement le point le plus important de ce processus. Dans notre cas, la sortie est toujours en appuyant sur trois boutons:

• déployer l'expérience plus loin, à la géographie suivante ou au segment suivant du public;
• restauration si quelque chose ne va pas;
• continuer. Il y a des cas où nous constatons l'influence de facteurs tiers que nous n'avons pas pris en compte et, par conséquent, nous ne pouvons pas tirer de conclusion sans ambiguïté. Dans ces cas, nous décidons de continuer.

Vraie expérience

Il est enfin temps de voir comment cela fonctionne avec un exemple réel. Êtes-vous encore fatigué? Le plaisir commence.



Revenir à la plateforme d'attribution automatique. Avant cela, nous avons suggéré que l'approche Just In Time serait très cool pour nous de réduire les délais de livraison. Nous la comparerons à la stratégie d'affectation actuelle, que nous désignons comme un algorithme glouton.



Pour commencer, nous justifierons l'hypothèse.

Algorithme gourmand

Sa principale caractéristique est de prescrire immédiatement. Dès que la commande arrive sur la plate-forme, nous recherchons le transporteur le plus approprié de notre partenaire pour cette commande, nommons sans délai et informons le transporteur de cette commande. En conséquence, nous optimiserons le temps passé à chercher un coursier. Mais cette approche n'est pas toujours efficace, car en une minute la situation peut changer: une nouvelle commande arrive ou un autre courrier est libéré. L'algorithme ne réagit plus à cela. Ci-dessous une illustration.





Dans cet exemple, nous avons un total de 45 minutes pour prélever deux commandes. Il semble que nous pouvons faire mieux.

Juste à temps

La tâche de cet algorithme est de choisir exactement le courrier qui arrivera au restaurant exactement au moment où la commande est prête. Que va-t-il nous apporter? Cela réduira à terme le délai de livraison en raison du fait que:

• le courrier passera moins de temps au restaurant;
• nous choisirons le courrier de manière plus optimale.

Techniquement, c'est assez simple à mettre en œuvre. Lorsque la commande arrive, nous choisissons tout de suite le transporteur, mais ne lui communiquons pas la commande, prenant ainsi un «rendez-vous virtuel» et nous donnant le temps de changer notre choix. Et nous ne déciderons finalement (s'il faut transférer la commande au coursier) que lorsque le chemin vers le restaurant est égal au temps restant pour préparer la commande. Schématiquement - dans l'illustration ci-dessous.







En conséquence, nous sélectionnons les commandes en seulement 30 minutes, soit un tiers de moins que dans le cas précédent.



A mon avis, l'hypothèse est justifiée, nous la prenons en développement. Comme convenu, nous ne considérerons pas le processus de développement en détail.

Passons à la préparation de l'expérience

Que faut-il préparer dans notre cas? Pas tellement: la période du test A / B, la géographie de l'expérience et celle avec laquelle nous allons comparer. Nous avons choisi une ville spécifique, sélectionné les conditions afin de minimiser l'impact d'une stratégie de nomination sur la seconde.



Nous allons certainement négocier avec l'entreprise au sujet des drapeaux rouges et des réactions à ceux-ci. Les drapeaux rouges sont des seuils de métrique d'entreprise que nous ne voulons pas franchir au cours de l'expérience. S'il est franchi, dans le nombre écrasant d'expériences, il s'agit d'un retour en arrière. Mais il y a des exceptions lorsque nous savons avec certitude que l'intersection ne s'est pas produite à cause de nous, mais était le résultat d'autres facteurs. Dans ce cas, nous pouvons parfois décider de poursuivre l'expérience.



Que faut-il encore préparer? D'accord avec nos confrères de la salle de contrôle, qui observent en temps réel que tout va bien avec les commandes. Pour eux, notre changement sera visible, car avant de passer immédiatement une commande pour le courrier, mais maintenant nous ne le faisons pas, nous nous donnons le temps de changer d'avis. C'est pourquoi les collègues doivent être avertis des expériences prévues.



Ok, passons à autre chose. Préparé une expérience, l'a menée et obtenu les résultats. Et voici la partie amusante - l'analyse.

Analyse d'expériences

Nous avons convenu d'améliorer le délai de livraison total, et soudain il y a eu quatre horaires. Cela vaut la peine de l'expliquer ici. Lors du lancement d'une expérience, il est important de ne pas regarder une mesure clé, mais plusieurs indicateurs commerciaux qui sont essentiels pour l'entreprise - dans ce cas, nous pouvons réduire considérablement les risques d'une hypothèse infructueuse affectant les processus réels de la plate-forme. Soyons honnêtes, nous avons commis de telles erreurs au début de nos expériences, et parfois elles ont conduit à des conséquences vraiment désagréables. Mais les erreurs sont bonnes, nous en tirons des leçons.



Jetons un coup d'œil aux résultats. Nous montrerons les graphiques sans valeurs spécifiques, car le but de l'article n'est pas une analyse détaillée de l'efficacité de l'algorithme Just In Time. Nous voulons nous concentrer davantage sur notre approche lors de la réalisation d'expériences. Pour la même raison, nous ne nous attarderons pas sur la théorie de la conduite des tests A / B et de la détermination de la signification statistique des résultats, c'est un sujet énorme pour la prochaine publication, et peut-être même pour tout le cycle.

• « ». , , . , . , — , . , . , , . , . , , (/), — , , . -, .
• « ». . , , , . , . , .
• « » « ». : . .

En conséquence, nous avons une diminution de la métrique clé (1), une diminution d'une métrique très importante (2), des valeurs stables de deux autres métriques clés (3, 4), les drapeaux rouges ne sont pas allumés. Cela nous permet de conclure sur le succès de l'expérience et la validité de l'hypothèse testée.



Classe! Êtes-vous passé à l'hypothèse suivante? C'est incroyablement divertissant et conçu pour améliorer la vie de chacun! Mais non, ce n'est pas tout. Il reste peut-être l'une des étapes les plus importantes, qu'il ne faut pas oublier. Ceci consiste à appuyer sur l'un des trois boutons:

1. Sortir
2. Retour en arriere
3. Continuer

Dans le processus d'expérimentation, l'équipe doit avoir un collègue dont le rôle est d'être entièrement responsable de la fonctionnalité, qui appuiera sur l'un de ces trois boutons. Au début, nous avons eu des cas où nous avons oublié cette étape, du coup, nous avons reçu plusieurs dizaines d'expériences lancées simultanément sans statut compréhensible pour chacune d'elles. Ils ont donné des résultats positifs, mais n'ont pas été entièrement déployés, ce qui est inefficace pour les entreprises. De plus, nous avons dû dépenser des ressources importantes juste pour nous souvenir des détails et mettre les choses en ordre. Mais, encore une fois, nous apprenons des erreurs.

Expériences du monde réel

Arrêtons-nous brièvement sur les raisons pour lesquelles nous expérimentons immédiatement au combat. Cette approche est généralement opposée par les environnements de simulation analytique qui, sur la base de données historiques, peuvent, avec une certaine précision, répondre à ce que «ce serait» si nous implémentions une telle fonctionnalité.



Pourquoi avons-nous choisi la première approche pour nous-mêmes? Deux raisons.

• -, .
  
  , , . , - , , . — .
  
  
  
  . .
  
  
  
  ? , , , — . , , , , , . , .
  
  
  
  Cela vaut la peine d'être honnête ici, c'est une approche plutôt risquée. Le risque de décevoir le public, les clients, les entreprises. Cet article est en grande partie consacré à la manière de réduire ces risques: sélectionnez avec soin et précision les métriques (plusieurs) et surveillez-les en temps réel. En cas de problème, nous désactivons immédiatement l'expérience.

• Le second est, bien sûr, la vitesse. Les expériences en conditions de combat donneront des résultats beaucoup plus précis et plus rapides.

Avant d'aller plus loin, corrigeons quelques petites victoires.





Un processus d'expérimentation transparent nous donne la réponse à la question de savoir comment atteindre un objectif. Et en effectuant des tests immédiatement en conditions réelles, nous commençons à mieux comprendre notre audience. En conséquence, l'équipe de développement dispose d'une expertise suffisante pour proposer des fonctionnalités spécifiques permettant de résoudre un problème métier.



Pas mal, mais ce n'est pas tout. Il est temps de parler davantage de mesurabilité. Et pendant ce temps, nous allumons le troisième, le gaz au sol, le vent siffle.

Mesurabilité

Pourquoi avons-nous besoin de mesures? Principalement pour confirmer une hypothèse ou réduire l'impact d'une hypothèse ratée. Les hypothèses, même fondées en théorie, ne tournent pas toujours. Et quand ils tirent, parfois dans le genou.

• -, FoodTech, : , , , .
• -, , , . , , , . ! , , , . , , -.

Notre expérience montre qu'une bonne recette est quand il y a plusieurs métriques. Une mesure cible - l'améliorer; et quelques autres clés - nous ne devons pas les abandonner.



Introduisez un espace de surveillance unifié dans lequel les affaires et le développement se penchent. Il n'est pas nécessaire que ce soit un seul outil, nous en utilisons deux: Metabase et Grafana, mais à l'avenir, nous prévoyons d'en choisir un. Plus important encore, il devrait y avoir un espace unique où les collègues des affaires et du développement regarderont. Et assurez-vous d'identifier les drapeaux rouges.

drapeaux rouges

Oui, ce sont des valeurs seuils de métriques que nous ne devons pas franchir pendant le test. Cela vaut la peine de s'entendre avec l'entreprise sur les réactions, si elles se sont croisées, et de suspendre des alertes sur elles.



Et encore une petite victoire: nous avons répondu à la question «Pourquoi quelqu'un a-t-il besoin de mon code». Ne l'oublions pas!





Permettez-moi de vous rappeler que cette incertitude de la part du développement est que nous n'avons pas toujours compris pourquoi notre code n'est pas resté en production et, franchement, nous en étions tristes. En adoptant une approche d'immersion peer-to-peer, du développement aux mesures commerciales, nous avons non seulement amélioré notre compréhension des solutions clients, mais nous nous sommes également donné une dose de motivation pour résoudre les problèmes commerciaux en nous concentrant sur le résultat final.



D'accord, nous avons compris des expériences et des processus transparents, des mesures et des mesures de mesurabilité. Devant la ligne d'arrivée, nous tournons sur le quatrième, et à vitesse maximale jusqu'à la victoire.

Autonomie

Tout ce qui précède ne fonctionne aussi bien que possible que lorsque nous devenons autonomes du côté des affaires et du développement.

ESSENTIEL

Ici, par autonomie, nous entendons la dépendance minimale lors de la prise de décision. Qu'avons-nous fait du côté commercial pour prendre des décisions rapidement et ne pas nous noyer dans les processus d'approbation? Nous avons implémenté le framework GIST.





Cette approche comprend les objectifs, les idées, les projets d'étape, les tâches. L'entreprise a des objectifs commerciaux clairs que la direction communique de manière transparente à tous les employés. Pour atteindre ces objectifs, les employés lancent des idées. Il peut y avoir une douzaine ou une idée. Il est important qu'une idée ne soit pas encore un projet. Ce sont quelques-unes des approches que je voudrais mettre en œuvre. Step-project - ce sont déjà des projets: des fonctionnalités assez volumineuses qui mettent en œuvre ces idées. Dans notre exemple Just In Time, la destination est exactement le projet Step. Au dernier niveau se trouvent les tâches auxquelles nous sommes habitués - il s'agit d'un projet Step décomposé, estimé en coûts de main-d'œuvre.



Alors, comment l'approche vous aide-t-elle à atteindre l'autonomie? Lorsque nous proposons de créer cette fonctionnalité (Just In Time), l'entreprise voit de manière transparente:

1. La taille et le coût de mise en œuvre de la fonctionnalité.
2. Quelle idée met-il en œuvre.
3. Quel est l'objectif spécifique de l'entreprise (impact).

Ensuite, il suffit de le comparer avec le projet Step voisin selon les mêmes critères: coût, impact. Nous tenons une réunion (ils sont réguliers avec nous), discutons, priorisons et prenons une décision.



Cela semble très simple et direct. Dans notre cas, ça l'est, et ça marche: l'entreprise prend des décisions rapidement, on est content. Mais ce n'est que le premier pas vers l'autonomie, car du côté du développement, nous ne devons pas non plus être bloqués.

Source intérieure

C'est comme l'open source, uniquement au sein de l'entreprise. L'architecture du Delivery Club est constituée de microservices, il en existe désormais plus d'une centaine. Souvent, pour réaliser une fonctionnalité, il est nécessaire de modifier non seulement les composants dont notre équipe est responsable, mais également les services voisins. Et ici, nous avons deux façons:

1. Mettez des améliorations dans l'arriéré des autres équipes, convenez que les gars vont les faire.
2. Fais le toi-même.

Dans notre adaptation, le processus fonctionne comme suit. Il existe une grande fonctionnalité Just In Time, elle affecte trois groupes de services:

• une plateforme d'auto-affectation dont la R&D est responsable,
• plateforme logistique,
• composantes d'interaction avec les partenaires (restaurants et magasins).

Nous faisons ceci:

1. rassembler toutes les tâches dans l'arriéré de l'équipe R&D;
2. nous priorisons et distribuons au sein de l'équipe lequel des gars affinera lequel des composants;
3. nous sommes d'accord avec les responsables techniques des équipes de logistique et des zones partenaires sur les nuances de mise en œuvre;
4. nous nous développons, nos collègues effectuent un examen;
5. puis nous nous testons;
6. Nous donnons déjà les services aux propriétaires pour la mise en production.

Une fois mises en production, ces améliorations restent du ressort des équipes propriétaires de ces services.



Pour être absolument honnête, l'approche n'est pas parfaite et comporte des risques. Le principal est le timing. Le plus souvent, nous modifions les composants 2 à 2,5 fois plus longtemps que ne l'auraient fait les propriétaires de services.



Mais l'avantage est également évident, il l'emporte de loin sur le petit retard de mise en œuvre - c'est la prévisibilité. Il est important de noter ici que les autres équipes ont leur propre arriéré, leurs propres priorités, et qu'elles ne peuvent le plus souvent prendre nos tâches «d'urgence». Par conséquent, notre échéance pour les affaires est réaliste; elle ne sera pas affectée par d'éventuels changements de priorités dans d'autres équipes.



Alors, félicitations - finition, victoire!





Nous avons implémenté le framework GIST pour une prise de décision rapide et transparente, et l'approche Inner Source pour l'autonomie dans le développement, et maintenant toutes les pièces du puzzle sont assemblées. Il est temps de conclure, c'était une course intéressante, merci pour votre participation! Résumons.

conclusions

• Une expérience est un outil transparent et efficace pour atteindre un objectif.
• En le réalisant dans un environnement réel, nous étudions notre audience, ce qui nous permet d'apporter des changements de plus en plus utiles à chaque fois, et aussi de comprendre pourquoi toutes les fonctionnalités ne doivent pas rester en production.
• Mais pour éviter le chaos, vous avez besoin d'un processus clair, de la répartition des rôles et de la nomination d'une personne responsable.
• Dans la phase active de l'expérience et pendant l'analyse, il vaut la peine de surveiller plusieurs métriques clés à la fois et de ne pas oublier de tirer une conclusion (dans notre cas, appuyez sur l'un des trois boutons).
• Prendre des décisions rapides et l'autonomie dans le développement aide à obtenir des résultats et à garder l'équipe motivée.

Enregistrement vidéo du rapport de la conférence RIT ++ 2020 .





C'est tout, merci d'être avec moi sur cette course. Je suis sûr que nous en sommes au tout début et que de grands défis nous attendent. Je les partagerai avec plaisir, à bientôt!