Elodie Mermet Chris Dupin - Faciliter l'adoption de processus innovants par le partage d'information

[00:00:00] Bonjour à tous, euh, désolé, on a dû faire une petite adaptation technique parce que la salle n'aime pas les Mac, mais euh c'est pas grave, on va y arriver. Euh donc on est passé sur Linux, chose qui est un peu euh nouvelle euh pour moi, vous allez comprendre après pourquoi. Euh donc on va commencer déjà par euh faire un rapide état des lieux tous ensemble. Donc euh on va vous demander euh d'être euh d'être actif pendant les trois prochaines minutes. On va vous donner quelques affirmations euh avec Chris et euh vous allez devoir lever la main si vous vous sentez concerné et attention euh ne mentez pas, s'il vous plaît. Première affirmation, j'ai déjà rencontré des retards euh dans le le enfin le déploiement de mes projets. On est d'accord.
[00:00:57] Euh, deuxième affirmation, j'ai déjà rencontré des problèmes de communication au sein de mon équipe, voire même avec les autres équipes. Ouais, c'est pas grave.
[00:01:08] Dernière affirmation, j'ai fait partie d'un projet où le design initial ou les spécifications fonctionnelles ont dû être modifiées un peu en dernière minute pour mettre en production plus rapidement.
[00:01:22] Je vois qu'il ment au premier rang, mais pas de problème. Euh du coup en effet c'est plutôt notre challenge et c'est un challenge qui est plutôt commun. Euh parce qu'on on a tous en tête le fonctionnement du d'une équipe agile optimale ou d'une organisation optimale. On essaie de créer une espèce de bulle pluridisciplinaire euh où la communication est accrue dans l'objectif euh pour la réussite d'un objectif qui est précis. Le problème, c'est que les besoins de croissance de l'organisation peuvent venir vraiment mettre à mal ces différents canaux de communication et euh vraiment réduire l'efficacité de ces différentes équipes. Parce que euh les équipes grossissent et et s'étend de plus en plus, leur scope est de plus en plus précis et leurs besoins de communiquer avec d'autres équipes augmentent. Parce que le problème, c'est que les organisations, euh les humains, les logiciels et euh les processus n'évoluent pas du tout au même rythme. Du coup, se pose une question et un challenge qui est comment est-ce qu'on fait pour que les attentes et les besoins et les contraintes de chacun euh soient remplies, comment est-ce qu'on arrive à niveler tout le monde par le haut euh pour prendre le le meilleur en fait de chaque discipline, spécialité. Et comment est-ce qu'on fait pour utiliser des processus et des outils sans pour autant les imposer. En tout cas, c'est un challenge qui nous intéresse particulièrement chez Back Market. Et c'est pour ça qu'aujourd'hui, on voulait vous parler de comment est-ce qu'on a fait pour croiser les flux, en fait, entre les différentes équipes et expertise euh pour en fait euh faire en sorte que les différentes attentes et besoins de chacun euh soient remplis au mieux.
[00:02:54] Et donc avant de vous dire comment on a enfin comment on résout notre challenge, on va déjà se présenter. Donc pour ceux qui connaissent pas Back Market, c'est euh une marketplace qui vend des appareils reconditionnés. Et notre objectif, c'est que vous n'ayez plus euh de raison d'acheter des appareils électroniques neufs. Donc voici quelques chiffres qui nous représentent. Euh, je vais pas tous les décrire. Ce qui va nous intéresser aujourd'hui, ça va être les plus de 700 employés. Donc vous voyez qu'on est déjà une une une belle équipe. Et au sein de l'équipe, ce qui est important euh pour nous, c'est de suivre l'émission de CO2 qu'on réussi à éviter euh en permettant bah d'acheter des produits reconditionnés à la place des produits neufs. Et donc on est assez fier parce que là on peut voir que euh chaque employé, donc ce qu'on appelle les backmakers, euh en 2021 ont contribué à éviter l'émission euh de 628 tonnes euh de CO2, ce qui est pas négligeable.
[00:03:47] Et donc parmi les 700 et plus Backmarketer, euh vous en avez deux devant vous aujourd'hui. Euh donc moi c'est Elodie, euh je suis Principal Designer chez Back Market depuis un peu plus de 3 ans. Euh je travaille sur la partie euh expérience client euh avant-vente et fidélisation. Et j'ai commencé dans l'équipe après-vente avec Chris.
[00:04:10] Et moi c'est Chris, je suis euh back end, back end developer euh depuis Back Market depuis un peu plus de 3 ans aussi et pour le coup, moi je suis toujours resté euh côté après-vente. Et euh ce qui m'a amené en fait à à m'intéresser à ces ces ces problématiques, c'est que euh moi j'y suis rentré par la porte de domain driven design et comment mieux communiquer euh avec les différents membres de de mes équipes.
[00:04:33] Euh, rappelons un petit peu de contexte. Euh du coup, nous on est dans une société qui est été vraiment en hypercroissance. Donc c'est ça va, on a essayé de répondre à nos enjeux, ça veut pas pour autant dire que vous avez exactement les mêmes ni les mêmes problématiques et cetera.
[00:04:47] Euh, comme je disais, euh, du coup à Back Market, les humains, les processus et l'organisation n'évoluent vraiment pas du tout au même rythme. Euh ce qui fait que au fur et à mesure que les équipes ont grandi, euh on a commencé à à devoir vraiment parler à de plus en plus de monde et intégrer de plus en plus de compétences dans les différentes équipes. Par exemple, dans la partie après-vente, euh quand je suis arrivé à Back Market, on était une équipe euh je crois de 5 ingénieurs et 10 au total et 2 ans après, on était quatre équipes avec à peu près 40 personnes. Ce qui pose beaucoup de problèmes de définition de d'ownership entre les les différentes équipes et au fur et à mesure qu'on vient rajouter des nouvelles expertises, en fait, euh en fait, les règles du jeu changent complètement. On n'a pas du tout les mêmes contraintes pour parler avec les autres, on ne connaît même pas les contraintes finalement des autres. Et il faut aussi prendre en compte que chaque équipe est complètement immutable, c'est-à-dire que ajouter une personne ou en enlever modifie complètement la dynamique de l'équipe. Donc c'est essayer de prendre tout ça en compte, c'est assez assez difficile et compliqué. Aussi toutes les équipes n'ont pas forcément le même niveau de maturité parce que comme j'ai dit, à chaque fois qu'on ajoute ou qu'on enlève une personne, en fait, on vient diluer ou perdre des fois une partie de la connaissance du produit et des différents processus et de notre façon de de travailler.
[00:06:03] Euh aussi toutes les l'un des symptômes que ça a créé, c'est que on voit, nous on a observé en fait, des délais non respectés et surtout beaucoup de frustration. Alors la frustration ça ça comment ça s'appelle ça émane de plein de façons différentes. Mais on a de la frustration côté métier parce qu'ils ont pas leur leur objectifs ni les les besoins des fonctionnels qui sont remplis dans les temps. La frustration ingénierie parce qu'on a l'impression de pas construire la bonne chose, ni au bon moment, ni comme on voudrait. La frustration côté design parce que ils essaient toujours de proposer une expérience idéale pour l'utilisateur, ils se retrouvent toujours en fait à la fin avec une expérience complètement dégradée. Donc ça me coûte ciseaux que vous devez connaître. En tout cas, c'est pas mal de, donc ça c'est quelques problèmes qu'on rencontre, euh, c'est que souvent, en fait, les attendus sont pas clairs. chacun de ces personnes, donc que ce soit métier, ingénierie, design et cetera, ont des attendus et des contraintes qui leur sont propres. Par exemple, des fois, Elodie vient me demander, euh, est-ce que tu peux me demander, est-ce que tu peux me dire combien de temps il faudrait pour implémenter ça ? Le problème c'est que moi je suis sur un autre projet, donc j'ai pas le temps de faire une analyse approfondie du tout et donc je lui dis, ah ben oui, en une semaine c'est fait, il y a pas de problème. Sauf que quand on se met à le faire, et ben tout d'un coup, c'est pas une semaine, en fait, c'était un mois. Donc c'est, voilà, on n'a pas forcément les mêmes attentes au même moment. Et aussi les itérations grossissent parce que au fur et à mesure, on ajoute des compétences et on a de plus en plus de de contraintes. Euh, on les prend pas forcément en compte au début, en fait, dans la gestion de nos projets et des produits qu'on veut sortir. Un exemple que j'ai en tête ici, c'est on est présent sur 17 ou 18 pays, euh, ça veut dire que à chaque fois qu'on sort une nouvelle feature, on est obligé euh de d'essayer de traduire pour toutes les langues dans lesquelles on est ouverte. Sauf que d'un point de vue euh complètement ingénieur backend, c'est juste une clé de traduction avec trois informations. On se rend pas forcément compte derrière que il y a 3 semaines de boulot pour valider, écrire toutes ces translations pour qu'elles soient validées et cetera, ça doit prendre beaucoup de temps. De même, si un moindre changement de design, en fait, dans un des écrans, peut euh déclencher des communications avec la la l'équipe de brand, donc ce qui gère la marque visuelle, l'identité visuelle du site, mais aussi euh l'équipe en charge de tous les composants communs, front end et cetera et un moindre changement peut déclencher d'énormes conversations. Et aussi, et moi c'est le truc qui me me plaît le plus, c'est qu'on a un langage qui est complètement différent, c'est-à-dire que un même concept peut avoir des définitions entièrement différentes en fonction euh du personna, voire même du contexte, voire même du bounding context, si si j'ose dire, en fonction de la personne à qui on parle.
[00:08:39] Un des symptômes de ça, c'est que j'ai moi-même horreur, c'est de demander au produit, comment est-ce que ça c'est censé fonctionner et qu'il me répond en utilisant toujours plus d'acronymes que je ne comprends pas ou de synonyme et j'ai je comprends pas de quoi on parle.
[00:08:52] Euh, et on s'est même rendu compte que finalement, même un mot et un concept aussi standard que MVP pour most valuable product, avait une signification complètement différente en fonction des différents personnels et expertise.
[00:09:06] Pourtant, parce que tout n'est tout n'est pas noir quand même. Euh, on a des équipes d'un back market euh qui ont réussi à délivrer des projets, euh qui se sont bien passés, on a des processus qui marchent plutôt bien et cetera. Le truc c'est qu'en en grossissant, euh la la la connaissance et les savoir-faire en général sont déjà présentes, mais en grossissant, c'est la façon d'y accéder qui va complètement changer. Parce que ponctuellement, on a des processus utilisés par des équipes euh qui ont amené à des succès. Et aussi, il faut voir que certaines de ces équipes-là ont réussi à faire ces transitions de de communication avec d'autres équipes en donnant l'ownership et cetera. Du coup, si on sait que le savoir-faire et les différentes compétences en fait sont là, la question c'est comment est-ce qu'on fait pour récupérer euh ces connaissances, processus et comment est-ce qu'on fait pour les transmettre au plus grand nombre ? C'est un truc qu'on aimerait faire, c'est par exemple récupérer la façon de faire de l'AB testing de l'équipe de paiement, parce qu'ils sont vraiment très bons là-dedans, on aimerait bien pouvoir savoir comment ils font. Savoir comment euh l'équipe après-vente arrive à faire des spécifications fonctionnelles.
[00:10:09] qu'on y arrive très très bien.
[00:10:11] Et euh aussi comment est-ce que dans d'autres équipes, par exemple, pour la gestion du catalogue, comment est-ce qu'ils font euh pour faire des co-design entre les différents ingénieurs front end. Et euh et produit et produit product design, comment est-ce qu'on comment est-ce qu'on pourrait faire ?
[00:10:26] Eh bien, euh, pour résoudre notre challenge, on a décidé de créer un playbook qu'on a appelé le Solution Discovery Playbook. Donc c'est un ensemble de processus qui sont euh clé en main et qui vont aider les équipes à mettre en place des bonnes pratiques pour la bonne conduite de leurs projets. Donc ça s'appelle Solution Discovery Playbook euh car il commence à partir du moment où on a déjà défini euh le problème à résoudre, l'opportunité business, donc on a priorisé ça euh dans dans notre roadmap et il s'arrête pour le moment jusqu'à la mise en place du MVP. Plus tard, il évoluera euh certainement. Donc voici un aperçu de ce que pouvait vous pouvez avoir euh dans notre boîte à outils et donc en vert, vous avez dans les rectangles verts, vous avez euh les différentes étapes euh macro d'un projet et sous chacune d'entre elles, vous avez les processus qu'on a listé euh pour le moment dans notre playbook. Et donc on va s'attarder sur un des processus, donc celui qui est en bas, qui est de définir euh les spécifications et priorités dans un product requirement document, donc PRD. Euh donc ce que vous voyez sur ce processus, c'est qu'il est pas unique enfin il appartient pas à une étape d'un projet, mais il va suivre euh vraiment euh toute la vie euh du projet. Donc le PRD chez nous, c'est un document euh sur confluence euh qui a les différentes sections, donc les objectifs du projet, euh ces critères euh de succès, euh les besoins fonctionnels qui au début vont être très très macro. Donc quand on va concevoir le flow design, ça va être vraiment euh quelques entrées sur un tableau euh à peine sous forme de de user stories. Et au fur et à mesure du projet, euh du coup ces ces user stories en fait vont être détaillé. Donc ce qui fait aussi on on étale un peu la charge de spécification fonctionnelle et tout n'est pas à pondre d'un coup. Euh on a aussi ce qui est hors scope, très important pour euh arrêter les débats euh dès que bah quelqu'un d'autre va intégrer le projet, un nouveau business stakeholder qui va vouloir bah ajouter peut-être quelque chose en plus. On log sur ce document bah pourquoi c'est hors scope et que ça fera partie certainement d'une prochaine itération. Aussi, ce qui est clé, c'est de euh d'avoir l'historique des questions et décisions qui ont été prises lors du projet. Parce que sur des projets euh très court terme, cette section va peut-être être un peu moins utile, mais sur des projets qui sont un peu plus long terme ou auquel on va devoir enfin on itère toujours, mais quand on va faire l'itération, on va revenir à ce PRD et on va comprendre bah pourquoi à tel moment on a pris cette décision et ça permet aussi de trancher euh certains débats qui pourraient arriver plus tard dans le projet. Donc on a déjà des bons retours euh sur l'adoption euh de du PRD. Donc ce qui est bien, c'est que bah c'est génère des débats en amont du projet et au lieu que ces débats arrivent trop tard et qu'on réalise qu'il y a des complexités fonctionnelles qu'on aurait pas identifié qui créerait bah du redesign ou de l'adaptation des spécifications. Et donc ça permet vraiment d'aligner toutes les personnes euh impliquées dans le projet, donc même les stakeholders business, donc marketing, ops et cetera, euh pour que ils puissent aussi euh voir comment on avance, les décisions qu'on ont été prises et euh et être enfin ambassadeur de ce projet.
[00:13:44] Donc comment on s'y est pris pour créer ce playbook ? Donc là, on va vous partager notre recette, euh, elle peut bien sûr être adaptée aussi à votre organisation. Donc pour l'instant, ça ça plutôt marché pour nous. Euh, donc déjà, ce qui est très important, c'est de considérer le playbook comme un comme un projet à part entière. Euh, comme sinon, ça sera toujours ce qui va être dépriorisé et donc au final, il n'existera pas. Euh, donc comme tout projet, définissez son objectif. Donc nous, c'est euh de diminuer le retravail et donc euh de diminuer euh les délais.
[00:14:16] Comme tout projet, vous créez une équipe euh projet et du coup nous, on a un casting euh de quatre sous-groupes. Euh, le premier groupe, c'est l'Obsteem euh qui va être responsable de faciliter la mise en place du playbook et de suivre son adoption. Euh le Working Group est composé de plusieurs expertises, donc là vous voyez qu'il y a une dizaine de personnes, donc comme expertise, on a des content designer,
[00:14:40] des backend engineer,
[00:14:42] des product designer,
[00:14:43] des mobile engineer,
[00:14:45] product manager,
[00:14:46] des front end engineer.
[00:14:47] Et on avait même des quality engineer.
[00:14:48] Ah oui, tu me l'as volé.
[00:14:49] Voilà. Euh, et donc ce working group en fait va être responsable de prioriser et de rédiger les processus du playbook. Ensuite, en troisième, on a le feedback group qui a à peu près la même composition que le working group, qui va relire les processus rédigés et euh faire une première passe euh pour les améliorer. Et après, on a les sponsors à ne pas négliger aussi, qui vont vraiment être là pour aider à l'adoption du playbook. Donc les sponsors, c'est plus des C-level CPO et aussi CTO.
[00:15:21] Comme tout projet, il y a un planning, donc le playbook n'a pas de date de fin parce que on ne veut pas que notre documentation devienne obsolète, elle va s'améliorer en continu en fonction aussi bah de la du changement de la structure d'équipe de Back Market. Mais par contre, n'hésitez pas à mettre des jalons à chaque, enfin n'hésitez pas à mettre des jalons et donc des dates sur ces jalons. Donc là, voici le planning qu'on a eu, donc l'année dernière, on a commencé par l'état des lieux, ensuite la rédaction des processus, avoir une première phase de retour sur ces processus et après présentation du playbook et amélioration et adoption du playbook. Donc là, on est toujours en phase d'amélioration et adoption, on sera certainement très longtemps dans cette phase, même si on va incorporer d'autres jalons avec euh enfin en itérant, en ajoutant d'autres process. Ça peut paraître long, euh mais dites-vous que c'est pas notre tâche principale au sein de Back Market, c'est une initiative transvers.
[00:16:18] Et donc Chris, est-ce que tu peux me dire comment on a fait l'état des lieux ?
[00:16:21] Bah, avec plaisir. Euh, déjà, on a pris pour point de départ de faire une une grande frise chronologique avec toutes les étapes euh qu'on avait en tête pour la réalisation d'un projet. Euh, quand est-ce qu'on priorise les différentes fonctionnalités qu'on va ajouter ? Quelles sont ces fonctionnalités ? Quand est-ce qu'on s'aligne sur le MVP ? Qu'est-ce que ça, qu'est-ce que ça veut dire ? Euh, quand est-ce qu'on veut écrire des user story et sur quoi est-ce qu'on les base ? Quand est-ce qu'on veut déployer, comment est-ce qu'on veut déployer ? Est-ce qu'on veut déployer d'abord en France, puis dans d'autres pays et cetera et cetera. Donc on a vraiment mis tout ça sur une une grande frise chronologique et une fois qu'on avait toutes ces étapes à peu près dans l'ordre, euh on a essayé de lister en fait tous les petits problèmes qu'on rencontre, les pistes d'amélioration qu'on avait et cetera. Alors essayez pas de lire, c'est plus pour vous donner une idée en fait de à quoi ça peut ça peut ressembler. Et en fait en ici en violet, on a en fait une étape, donc là par exemple vous avez prioritization workshop et mapping dependency. En rouge, vous avez un problème ou une frustration, euh donc tout ça va être remonté par le working group. En disant ben par exemple, je suis content de designer et moi je trouve qu'on a ce problème-là, moi je suis ingénieur mobile et on a ce problème-là ici et cetera et cetera. En vert, on a des processus ou des outils qui fonctionnent plutôt bien, où en fait les gens sont contents de les utiliser et tout, c'est aussi intéressant. Donc ce qu'on cherche à faire, c'est de aussi de récupérer toutes les les bonnes façons de faire et tout, donc c'est assez important de aussi récupérer ça.
[00:17:46] Euh après en bleu, on a aussi toutes les toutes les idées en fait d'amélioration, d'outils qu'on pourrait utiliser, trucs qu'on aimerait changer. Ou juste tout bêtement, chacun vient exprimer en fait les les attendus et les différents besoins qu'ils ont. Genre, je suis quelqu'un qui travaille au côté content design, j'ai besoin de faire des traductions, j'ai besoin de savoir par exemple, quelles sont toutes les clés de traduction pour que je puisse faire les trucs correctement avec quelles sont les différentes variables et cetera.
[00:18:13] Prendre un exemple ici, euh c'est que on a remonté que, enfin les ingénieurs en fait ont remonté que les MVP étaient souvent beaucoup trop gros euh de leur point de vue. Parce que du coup, à chaque fois, les ingénieurs proposaient de découper ce MVP en encore plus de parties, donc c'était le MVP dans le MVP. Leur le but, côté ingénieur, c'était de pouvoir délivrer beaucoup plus souvent et du coup de diminuer le risque sur le projet, valider des assumption beaucoup plus vite et cetera. Ça part forcément d'une bonne intention. Le problème, c'est que ça vient générer beaucoup de frustration et du retravail côté design. Parce que il y a des informations euh en fait, qui ont été enlevées, donc il faut réordonnancer les différentes pages, peut-être qu'il y a même des pages entières qui s'en vont, il faut réadapter un petit peu leur contenu pour que pour que ça fasse sens au fur et à mesure, en fait, de de la livraison de ces petits incréments. Et ce travail-là peut même avoir un impact côté content design, donc ceux qui se servent vraiment, en fait, de des différents mots utilisés parce que c'est pareil, il faut retra si l'élu il a à changer, eux aussi ils doivent changer. Donc ça génère beaucoup beaucoup de de de frustration ici. Alors pourquoi dans ce cas précis, c'est comme je vous l'ai dit, on n'était pas d'accord sur ce que veut dire finalement un MVP et on n'était vraiment pas aligné sur comment est-ce qu'on prioriser les différents requirements fonctionnels. Et l'un des plus grosses sources en fait de cette problématique, c'était que la partie tech était engagée beaucoup trop tard en fait dans la définition de ce MVP, voire même à la fin. Du coup, toute euh toute modification après venait changer en fait tout le travail qui était fait en amont, ce qui était franchement pas idéal et génère beaucoup de frustration. Du coup, une des suggestions qu'on a fait pour essayer de corriger ça, euh c'était d'utiliser des product requirement documents pour qu'on aligne tout le monde, tech inclu et les différents stakeholders sur le scope du projet, qu'est-ce qui va dedans, qu'est-ce qui ne va pas dedans et cetera et cetera. Et aussi de valider le fait que c'est OK de partir avec de l'incertitude euh des des open questions qui sont vraiment pas encore répondues et cetera, mais au moins, on le fait volontairement.
[00:19:36] tech était engagé beaucoup trop tard en fait dans la définition de ce MVP, voire même à la fin. Du coup, toute euh toute modification après, venait changer en fait tout le travail qui était fait en amont, ce qui était franchement pas idéal et génère beaucoup de frustration. Du coup, une des suggestions qu'on a fait pour essayer de corriger ça, c'était d'utiliser des product requirement documents, pour qu'on aligne tout le monde, tech inclus, et les différents stakeholders sur le scope du projet, qu'est-ce qu'il va dedans? Qu'est-ce qui ne va pas dedans, et cetera, et cetera. Et aussi de valider le fait que c'est OK de partir avec de l'incertitude, euh des des open questions qui sont vraiment pas encore répondues et cetera, mais euh au moins, on le fait volontairement.
[00:20:21] Un autre exemple, euh, c'est que les différentes dépendances, en fait, entre les différentes équipes et produits, sont découvertes trop tard, voire pire, euh, sur le tas, quand on est en train de de faire le truc. Ce qui nous force à re-communiquer le but du projet aux différentes équipes, à essayer de les convaincre, de modifier leur roadmap. C'est toujours une partie de de plaisir, elles le font jamais vraiment avec plaisir, parce que elles ont leurs propres priorités et ce qui est important pour nous, ne l'est pas forcément pour elles du tout. Du coup, ici, avoir la tech discovery en même temps euh que la product discovery, euh nous permet de montrer et de directement euh highlight les les différentes dépendances entre les équipes euh sur ce qu'on veut implémenter. Et c'est intéressant parce que ça nous permet de négocier et voire même d'abandonner ou de changer des requirements, si ça nous permet par exemple d'enlever une dépendance avec une autre équipe. Donc ça nous permet d'itérer plus vite et de de pouvoir itérer plus vite et et enchaîner.
[00:21:18] Bon, je vous ai cité deux exemples, mais je voulais quand même vous montrer à peu près à quoi ça ressemble en vrai. Et bon, je pense qu'il en manque et on s'est concentré sur, on va dire, certaines grandes étapes et pas absolument tout. Il y a eu beaucoup, beaucoup de de propositions, beaucoup de points de frustration remonté, mais aussi beaucoup d'idées et aussi beaucoup de processus en fait qui me sont déjà là dans certaines équipes et qui marchent bien. Mais bon, il y en a beaucoup, ce qui nous amène à la question de la priorisation.
[00:21:47] Comment est-ce qu'on fait pour euh pour avancer euh à partir de maintenant?
[00:21:52] Et bien, déjà, euh ça paraît évident, mais on va garder ce qui fonctionne. Donc certaines équipes euh remontaient que euh bah ça fonctionnait bien quand les spécifications fonctionnelles étaient établies plutôt dans la dans la Discovery. D'autres disaient que l'investigation technique aussi euh avait lieu plutôt dans leurs équipes, donc c'était anticipé et planifié en amont, euh et ça arrivait presque en parallèle de la phase de design. D'autres équipes ont encore remonté qu'il y avait des sessions rapides en fait de de design review avec toute la squad, mais de façon plus fréquente et ce qui permettait bah d'éviter de de créer des petits monstres en fait. Et de réaliser trop tard bah qu'il fallait passer ces fameux coups de ciseaux. Euh.
[00:22:34] Ensuite, ben on regarde ce qui fonctionne moins et euh et ce qui génère le plus de délai. Donc voici les le top 3, on va dire, de ce qui fonctionnait moins. Ça peut paraître évident quand on le présente. Euh, c'est juste que des fois, bah quand on est dans le run, quand une équipe grossit vite, et bah malheureusement, on se retrouve à avoir euh des des choses qui nous semblent basiques, mais qui euh qui se vivent malheureusement dans la vraie vie. Donc bah les MVP qu'on pensait avoir créé n'était peut-être pas si simple que ça. Donc même si les ingénieurs étaient impliqués, ils n'étaient pas assez impliqués pour regarder vraiment en détail ce qui était complexe. Euh, de euh ce qui ne fonctionnait pas, c'est quand on ne travaillait pas entre product, enfin avec le product et l'ingénierie en même temps sur le projet. Et ce qui ne marchait pas non plus, c'est quand il y avait un manque de synchronisation de toutes les parties prenantes, donc la partie aussi business qui était plus là en amont du projet et à la fin et donc créer certains débats aussi en fin de projet et donc bah du des fois, il fallait changer un peu ce qu'il y avait été designé. Et donc après cet état des lieux, on voit qu'on a quand même pas mal de choses à améliorer, bon, ce qui est bien, il faut le voir en opportunité. Euh, mais euh bah il faut bien commencer quelque part, donc on a fait un MVP en fait euh du playbook. Donc la Working Group a sélectionné les étapes principales euh à améliorer en priorité. Et donc euh ce qui en ressort, c'est que euh on doit améliorer d'abord la priorisation des fonctionnalités même avant de commencer le projet. Et donc ça, c'est quelque chose qu'on va faire grâce au PRD. Ensuite, euh il faut que la création du flow utilisateur soit plus collaborative, parce que dès cette phase-là, on peut identifier si on commence à créer des monstres. Pareil pour la phase de co-design avec des rituels un peu plus fréquents avec les ingénieurs. Et euh voir comment on peut changer euh le séquencement de cette investigation technique qui arrivait trop tard. Et donc après, le Working Group s'est divisé en différents sous-groupes, chacun a pris une des étapes à améliorer et a rédigé les processus. Donc, avant la rédaction des processus, on s'est mis d'accord sur certains principes. Donc là, il y en a enfin, on a quatre principes. Donc le premier, c'est l'accessibilité. Il est très, très important que euh chaque process soit compris par tous les membres euh d'une équipe projet. Donc on évite les acronymes, les mots farfelus ou à minima, on les définit euh dans le process.
[00:25:03] Deuxième principe, chaque processus doit être indépendant. Donc l'idée c'est que chaque équipe pioche un des processus du playbook qui les aidera à mieux performer. Notre objectif, c'était vraiment pas et c'est ça l'est toujours pas de créer une méthode qui soit vraiment appliquée de façon stricte de A à Z. Déjà, ça va être très compliqué pour l'adoption, parce que on sait qu'on est humain et que l'adoption enfin l'adaptation au changement est compliquée. Et en plus euh les équipes ne faisaient pas tout euh mal. Donc il y a des choses qui fonctionnaient chez elles, le but c'est qu'elle garde ce qui fonctionne et qu'elle pioche dans cette boîte à outils ce qui leur permettent de s'améliorer. Et donc c'est aussi plus simple à mettre en place pour chacune des équipes. Troisième principe, c'est que chaque processus doit être actionnable. Donc on a fait en sorte que la rédaction des processus puisse se scanner très rapidement. Et y associer des templates, donc que ça soit des templates Confluence pour l'adopter plus rapidement, on a même fait des templates sur Figjam de workshop, euh, des templates je crois de design review récemment aussi.
[00:26:05] Et dernier principe, c'est que les processus doivent être uniformes, donc ils respectent le même format. Si dans une documentation vous devez changer votre grille de lecture à chacun des processus, vous avez pas du tout envie de les lire. Euh donc, on a mis en place un format commun pour chaque process. Euh donc là, vous avez le processus du PRD dont je parlais euh au début. Et donc, sur ce processus, on a une définition rapide. Quand l'appliquer, euh, quand ne pas l'appliquer, hein, parce que c'est pas euh forcément pertinent pour tous les projets. Comment le faire et donc là, pareil, on rédige pas 3000 paragraphes, on y va vraiment en mode bullet point avec des astuces, euh des liens vers des templates, des exemples de gens qui l'ont déjà appliqué. On met aussi les critères de succès du process. Et euh on finit par garder un historique de l'amélioration du process. Ça peut paraître banal, mais en vrai, c'est très important parce que ça va inciter les gens qui vont euh utiliser les process à être force de proposition et euh à participer à l'amélioration en continue de ces process.
[00:27:09] Et donc Chris, comment se passe euh l'adoption?
[00:27:13] Alors, une fois que le working group a écrit tous ces différents processus, euh, on veut essayer qu'il soit euh adopté par le plus grand nombre et en plus c'est assez important, c'est que on cherche pas à les imposer. Donc, on veut vraiment que ces processus euh soient de qualité. Donc, une des premières étapes euh qu'on a fait pour ça, c'est qu'on a utilisé le feedback group pour venir relire en fait tous ces processus, poser des questions, euh aligner la terminologie, dire par exemple, ah, vous parlez de de product product owner dans cette page-là, mais de product manager dans l'autre, il y a un truc bizarre, essayer d'enlever le jargon euh dans d'un peu près partout, et euh vraiment s'assurer que en fait ça qu'il rencontre les différents critères d'accessibilité, d'indépendance, euh d'actionnabilité et qu'il soit uniforme.
[00:27:51] Et euh vraiment s'assurer que en fait ça qu'il rencontre les différents critères d'accessibilité, d'indépendance, euh d'actionnabilité et qu'il soit uniforme. Le but d'avoir ses relectures en plus par quelqu'un qui est qui ne les a pas écrites, c'est qu'ils ont pas la tête dans le guidon, ils ont un point de vue vraiment extérieur et en plus vu que le working group, il est composé de gens qui viennent d'expertise complètement différentes, des fois on peut avoir des points de vue et des points de vue et des façons d'améliorer ces processus de façon assez efficace. Comment est-ce qu'on a fait? Nous, alors nous, ça a été vraiment organique, c'est-à-dire que on ça a été fait par les des différents commentaires dans confluence, on a eu des relectures communes de temps en temps, des fois ça a été fait de façon synchrone, des fois asynchrone, et cetera, et cetera. En fait, tout le monde a fait un peu comme il voulait, et ça a pas mal marché. Seul point vraiment important, c'est qu'il faut vraiment donner des des étriers et des dates de de complétion de ces de la relecture de ces processus, pour s'assurer que enfin comme comme on le disait, c'est un truc qu'on a fait à un projet à part entière, mais on n'a pas que ça à faire non plus, donc essayer de donner des dates pour qu'on puisse continuer à avancer, c'est vraiment important.
[00:28:55] Et n'hésitez pas à relancer les gens parce que ça sera certainement dans le bas de leur priorité, donc le gentil harcèlement ça ça fonctionne bien quoi.
[00:29:06] Et et après il y a une étape qui est qui est vraiment bah du coup cruciale, c'est une fois que ça a été revu par par ce feedback group, c'est ben c'est qu'il faut essayer de promouvoir le Solution Discovery playbook pour essayer de gagner un peu plus de traction. Alors, le fait d'avoir récupéré une grande partie des processus des équipes qui les utilisaient déjà et de beaucoup en ça. Euh parce qu'on a moins de gens entre guillemets à convaincre. Et mais il faut quand même qu'on essaie de trouver des équipes qui sont volontaire pour tester et faire des retours d'expérience sur les différents processus. Et là, en fait, c'est le rôle de de l'operational team, en fait, d'aller pousser et communiquer autour du Solution Discovery Playbook. Alors, dans les faits, comment est-ce qu'on a fait? Ben on a des des grandes réunions, par exemple, où il y a toutes les tous les product managers et tous les gens routés aux produits, en fait, on va devoir dedans et on leur présente ça, on leur fait on fait pareil côté ingénieur, et cetera, et cetera.
[00:29:56] On va aussi créer des des des réunions dédiées des fois avec des product managers et des engineering manager pour leur présenter le solution Discovery Playbook, les différentes process et outils qu'on a en place, qu'ils peuvent piocher s'ils en ont besoin et cetera. On vient aussi chercher des projets qui pourraient être des des bons candidats et cetera, et aussi par-dessus tout, on essaie de en fait, on propose notre aide via des process helper en disant, ben,
[00:30:21] vous voulez utiliser le le PRD, bah je suis là, vous pouvez me contacter n'importe quand euh pour vous faire un bref aperçu de comment ça marche. Vous montrer deux trois autres exemples dans d'autres équipes, vous débloquez si vous semblez être être coincé et surtout juste simplement rassurer et rassurer les gens euh du celle. Et une fois qu'on a plein d'équipes prêtes à tester, on leur laisse la liberté, comme je l'ai dit, de prendre les processus euh qui les intéressent, qui veulent qui qui veulent le prendre. L'un des seuls euh trucs qu'on demande en fait, c'est qu'ils mesurent le nombre de retravails euh de petits changements qu'ils ont dû faire en fait au fur et à mesure du projet. Euh c'est la capi qu'on utilise pour essayer de voir si un projet se passe bien ou pas. Euh et donc là, on a plusieurs équipes qui se mettent à tester ces différents processus et cetera, et cetera.
[00:31:11] Et une fois que c'est bon et qu'ils ont bien pu fournir euh leur leur feedback qui ont été pris en compte et donc dans la section que que mentionnait Elodie, ce qui est important, c'est de me voir que ben effectivement tout le monde peut participer, proposer ses améliorations ou même dire ah, attention, si vous êtes dans ce cas-là, ce c'est peut-être pas très bien d'utiliser ce processus là et cetera et cetera. Et donc là, on les différentes équipes, au fur et à mesure, là, de plus largement en fait, vient d'utiliser ces ces processus, les processus qui les intéressent, et on commence vraiment du coup à avoir beaucoup plus de feedback et de voir en fait des retours de plus en plus nombreux et on essaie d'améliorer ces différents processus au fur et à mesure de l'eau. Donc là, c'est la partie qui théoriquement ne finit jamais, euh et tant mieux. Mais il faut voir aussi un point un peu un peu difficile, c'est que les projets souvent s'inscrivent plus ou moins long terme, donc on il faut toujours trouver un peu les bonnes occasions de dire ah oui mais toi dans 3 mois tu commences ce projet-là, peut-être que tu peux commencer ça et cetera. Donc pouvoir avoir vraiment euh du feedback, on va dire et des métriques chiffrées au fur et à mesure, pour le moment, nous c'est un peu compliqué d'avoir ça. Par contre, on commence à vraiment avoir de de bons retours et entendre de bons retours positifs, des gens qui sont contents d'avoir travaillé sur ce projet-là parce qu'il était très clair, content d'avoir fait des sessions de co-design avec euh avec plusieurs membres parce que ça a été très clair, ça les a beaucoup amélioré, et cetera. Donc les gens globalement sont vraiment content quand ils utilisent ces processus et en fait et le disent, ça c'est cool, même si c'est moins plus difficilement chiffrable.
[00:32:36] Et aujourd'hui, euh, bon, on a quand même plusieurs mois d'implémentation de ça. Euh, donc Elodie, est-ce que tu peux me parler un peu plus des bénéfices?
[00:32:45] du projet? Oui, oui. Et bien, le playbook, euh garder en tête que c'est un outil, euh enfin, en tout cas pour nous, qui est très puissant. Déjà parce qu'il a permis de créer un sentiment d'appartenance dès sa création. C'est pas euh des une méthode qui est arrivée de manager un peu trop éloigné euh enfin qui ça a vraiment été créé par les gens qui ont les mains dans le cambouis au jour le jour et qui réalisent les projets. Et le sentiment d'appartenance, on le prolonge aussi par les gens qui vont tester les process, en leur disant, bah n'hésitez pas à ajouter vos propres process si vous avez une idée, ou n'hésitez pas à améliorer les processus existants. Ensuite, cette boîte à outils, elle est puissante parce que on n'impose pas une méthode rigoureuse. Donc ça, c'est peut-être propre à notre organisation parce que chaque équipe a sa façon de de fonctionner, mais quand c'est le cas, c'est c'est très important de pas arriver avec quelque chose, une boîte toute faite et et de l'imposer. Et donc ça permet aussi à chaque équipe bah de de s'améliorer au lieu d'avoir une phase d'adaptation d'adaptation au changement qui qui puisse être très longue.
[00:33:52] On ne réinvente pas la roue. La plupart des processus du playbook euh sont connus euh dans le métier, hein, c'est c'est des processus qui ont été fait euh parfois dans certaines équipes en interne, parfois lors de d'expériences précédentes et donc ça permet aussi de faciliter l'adaptation euh des équipes à ces nouveaux processus. Donc c'est vraiment un partage euh de bonnes pratiques. Ça peut paraître bateau, mais quand on est une grosse équipe hein, de plus de enfin de plusieurs centaines d'employés, c'est quand même important d'avoir un euh une petite boîte à outils euh commune qu'on puisse bah accéder à à tout moment. Et euh ça marche bien aussi parce que ça se fait progressivement.
[00:34:33] Comme on vous l'a dit, c'est pas notre tâche principale au sein de Back Market. Donc il faut aussi pouvoir dire à nos managers, bah je vais devoir dédier tant de temps euh à ce projet. Et donc si vous voulez sortir une encyclopédie euh d'un coup, euh le temps va être très important et il y a de fortes chances que votre manager vous dit bah, euh Elodie, tu es bien sympa euh mais euh tel projet est quand même plus important, donc euh on fera ça plus tard. Et plus tard égale jamais. Donc, allez-y petit à petit, faites un petit playbook. Des fois nous on en a eu 10 parce que on a eu quand même pas mal de volontaires dans le working group. Ça peut être trois processus, les tester, voir si montrer que ça ça a aidé ces équipes qui les ont testé et après ajouter d'autres processus.
[00:35:19] Et bon, honnêtement, Chris, est-ce qu'on peut dire euh si ça fonctionne?
[00:35:27] Alors oui. Mais c'est pas si simple, euh on l'a mentionné plusieurs fois, mais l'adaptation au changement, c'est quelque chose de difficile. Pour tout le monde.
[00:35:38] Euh je veux on veut vraiment aussi mettre le point sur l'importance des sponsors à ce moment-là. Avoir des sponsors à à C level qui viennent pousser côté produit en mode, tu devrais t'intéresser à ça et cetera, c'est vraiment très très important et ça aide beaucoup à la diffusion en fait de ce playbook. Un des autres avantages en fait d'avoir des en fait des volontaires dans les working group feedback group et cetera, c'est qu'ils deviennent aussi des émissaires dans leurs différentes équipes et en fonction des différents points de contact qu'ils ont. Euh un des cas qu'on a eu par exemple dans Car, c'est que donc nous on utilise pas mal les PRD et on s'est mis du coup, on a eu un projet avec l'équipe qui était en responsabilité des d'envoyer en fait les les téléphones de d'un point à un point B et en fait, on a créé le PRD, ils se sont greffé dessus pour essayer de comprendre ce qu'on faisait et à la fin ils étaient ah oui, effectivement, c'est c'est très très clair. Donc ça permet en fait comme ça, essayer de gagner un peu plus de de traction.
[00:36:30] Après aussi, euh il y a certains process qui s'appliquent vraiment pas toutes les semaines, euh du coup avoir du feedback dessus et cetera, c'est compliqué. Donc du coup avoir vraiment du buy-in de euh toutes les parties prenantes, que ce soit genre ingénierie et cetera, ça peut être un peu difficile. Parce qu'il faut aussi arriver au bon moment au moment où ils pourront en avoir besoin. Euh et il faut communiquer, communiquer, communiquer, communiquer, l'existence de ce playbook, le fait que c'est là et cetera, le aider les gens, dire, vous avez pas de problème, on est là pour aider et cetera. Comme je l'ai dit, la feedback loop, elle est vraiment elle peut être vraiment longue en fonction des processus et cetera. Aussi, comme je le disais au début, il y a certaines équipes n'ont pas forcément la même maturité. Donc euh voir en fait le résultat fini d'un de l'application d'un processus euh par une équipe qui le fait depuis des années, et nous on veut s'y mettre, ça peut paraître extrêmement intimidant. Euh et donc du coup, bah on a peur de vouloir appliquer ces nouveaux processus et cetera. Donc là, pareil, on essaie de fournir de l'aide via les process helper et cetera. Et un des points vraiment qui est que nous on a pour aussi un peu difficile, c'est la difficulté d'avoir des une forme de métrique objective. Un parce que on voulait une métrique qui correspondait à l'ensemble des processus du playbook. Euh, donc nous on a on s'est décidé de mesurer le le retravail. Euh mais vraiment savoir quoi et comment on le mesure, ça peut être assez assez difficile, notamment parce qu'on peut pas vraiment faire, on va dire d'AB testing de il y a eu ce processus là ou il y a pas ce processus là sur le même projet, c'est pas vraiment possible. Donc ce qu'on peut savoir à la fin, c'est oui, les gens sont contents d'avoir utilisé, il y a eu peu de retravail. Mais est-ce qu'il y en aurait eu plus ou moins s'il l'avait pas utilisé, bah c'est difficile de savoir, on peut pas vraiment le savoir.
[00:38:13] Mais globalement ça marche. On a je pense c'est un truc sur lequel je suis le plus content, c'est que on a des personnes à l'extérieur du feedback group, du working group et de toute organisation de ce projet là qui ont décidé de d'ajouter un des processus qui qui leur trouvait important et qu'ils aimaient bien et qu'ils trouvait que ça marchait particulièrement bien chez eux. Donc ils sont venus nous voir en disant ah c'est bien ce que vous avez fait. Du coup l'importance de communiquer vraiment largement sur la présence et où est où est le Solution Discovery playbook. Et du coup, on les a intégré à on les a aidé à intégrer pour qu'ils aient le en fait le même le même format, euh comment essayer de mesurer et cetera et cetera. Côté adoption, euh, donc là, j'ai compté il y a pas très longtemps, par exemple pour le processus du PRD. Aujourd'hui, on compte plus d'une trentaine de de PRD créé en dehors euh des équipes qui le faisaient de base. Quand même pas mal. On a des dizaines des sessions de co-design et de design review qui ont été faites et cetera, et en fait, on entend de plus en plus de de retours positifs, de gens qui sont contents de travailler ensemble, euh et différentes parties de de des fois très large jusqu'au jusqu'au jusqu'au business et cetera et cetera.
[00:39:19] Euh par exemple sur un des projets, on a eu une diminution de du rework parce que on a du coup pu compter qu'on a eu que trois rework mineurs, donc vraiment on a changé la disposition de de labels et cetera pour un projet d'implémentation de 2 mois, donc on était plutôt plutôt content.
[00:39:33] Ouais, parce que même si on peut pas comparer avec enfin pour savoir comment ça serait passé sans les processus, euh on a quand même un beau ressenti que c'est assez inhabituel d'avoir juste trois rework mineurs pour pour cette taille de projet.
[00:39:05] session de co-design et de design review qui ont été faites et cetera et en fait, on entend de plus en plus de de retour positif de gens qui sont contents de travailler ensemble et différentes de des fois très large jusque jusque jusqu'au business et cetera et cetera. par exemple sur un des projets, on a eu une diminution de rework parce que on a du coup pu compter qu'on a eu que trois rework mineurs, donc vraiment on a changé la disposition de deux labels et cetera pour un projet d'implémentation de deux mois. Donc on était plutôt plutôt content. Oui, parce que même si on peut pas comparer avec enfin pour savoir comment ça serait passé sans les processus,
[00:39:35] euh on a quand même un bon ressenti que c'est assez inhabituel d'avoir juste trois rework mineurs pour euh pour cette taille de projet.
[00:39:51] Bon, si vous avez rien écouté, Élodie, tu nous fais un récapitulatif.
[00:39:54] Alors, quand vous sortirez de cette salle, c'est le moment de vous réveiller. Voici ce qu'il faut retenir. Donc, si vous voulez implémenter votre playbook collaboratif, il est important de le considérer comme un projet. Donc pensez aux objectifs, le casting et le planning. Encore une fois, le planning, il sera un peu inhabituel, mais il y a pas de date de fin. Euh donc par contre, il faut faire un planning pour les différents jalons. Et c'est très important qu'il n'y ait pas de date de fin parce que on veut toujours améliorer cette documentation. Ne négligez pas la création de l'Obsteam. Ça peut être un souci de ne pas avoir la majorité des expertises qui participent au projet, de ne pas enfin de qu'elles ne soient pas représentées dans l'Obsteam. Donc nous on l'a vécu en n'ayant pas de product manager, il y a eu plus des ingénieurs et designers de représentés dans l'Obsteam et ça a été un petit frein à l'adoption de de certains processus. Et c'est pas parce que nos product managers sont feignants, c'est qu'ils ont beaucoup beaucoup de travail. Mais ils faisaient partie des working group et des feedback group. Ne négligez surtout pas la stratégie de communication et la stratégie de communication elle commence au lancement et elle ne s'arrête jamais. Euh donc c'est très important de rappeler comme le disait Chris que ce playbook existe pour les nouveaux arrivants. euh quand il y a eu des projets qui ont utilisé des processus, essayez bah quand ils vont présenter leur projet d'indiquer on a utilisé tel ou tel processus du playbook. En amont du projet communiquer bah nous sur notre Slack channel, on va utiliser tel ou tel processus du playbook et cetera. Donc rabâchez-le constamment, ça peut paraître un peu répétitif. mais au final bah c'est comme ça que ça va rentrer en réflexe dans la tête des gens. Donc ça c'est vraiment le nerf de la guerre parce que sinon c'est juste une belle documentation qui est pas utilisée, vous avez perdu votre temps.
[00:41:45] Euh la documentation, encore une fois, elle est vivante, elle doit être maintenue et elle doit être améliorée par tous. Donc par tous, il y a pas besoin que tout tout le monde l'améliore, mais elle est elle est collaborative. Elle fait pas elle est pas juste améliorée juste par un tout petit groupe. Donc elle est améliorée sur chacun des processus, mais aussi elle est améliorée en ajoutant dans le futur d'autres processus.
[00:42:13] Et donc merci à tous pour votre attention.
[00:42:16] D'accord. Merci.
[00:42:24] Pour les questions.
[00:42:26] Est-ce que vous avez des questions ?
[00:42:34] Merci pour pour votre présentation, votre partage d'expérience. Euh, alors, j'ai peut-être loupé l'information, mais j'ai j'ai pas saisi comment la démarche elle avait été impulsée, en fait, qu'est-ce qui a fait qu'à un moment donné, vous êtes dit, OK, à un moment donné, on a besoin de de partir sur ce projet de playbook ? Ça c'est ma première question, et j'ai une deuxième question. Euh, c'est quoi une fonctionnalité de playbook ? Parce que j'ai pas compris non plus une fonctionnalité de playbook. À un moment donné, vous parlez de fonctionnalités, et je me suis dit, c'est quoi une fonctionnalité de playbook ? Voilà.
[00:43:04] D'accord. Merci. Euh, donc pour le lancement du playbook, on ne l'a pas dit, donc ça n'a pas été loupé. Euh c'est que au sein de l'équipe design, on a fait une rétrospective sur les choses à améliorer dans notre façon de travailler. Et ce qui était remonté, bah c'est que soit certains projets qu'on créait étaient mis en attente, ou des fois abandonnés, et que bah ce qu'on designait était souvent à retravailler quand l'implémentation commençait. Donc là, en voyant ce problème qui était commun à plusieurs designers, on s'est dit, OK, il va falloir qu'on qu'on agisse et qu'on parle bah à nos copains pour pour savoir comment on peut être plus efficace.
[00:43:43] Euh et pour les fonctionnalités, c'est par exemple en tant qu'utilisateur, j'aimerais pouvoir me connecter au site. Donc ça c'est une des fonctionnalités et en fonction des différents projets qu'on veut en fait amener, on a une liste de ces fonctionnalités qu'on aimerait avoir. Certaines sont plus importantes que d'autres, pour avoir plus d'impact que d'autres. Donc voilà, c'est ce qu'on entend derrière fonctionnalité.
[00:44:02] J'ai bien répondu.
[00:44:03] la priorisation des fonctionnalités c'est ça ? c'était sur la priorisation des fonctionnalités. L'objectif du playbook ?
[00:44:12] L'objectif du playbook ?
[00:44:14] vous parlez des fonctionnalités du playbook.
[00:44:18] Je pense que tout le monde m'a entendu hein. Mais en gros, oui, euh, vous parlez de je sais pas si vous pouvez revenir peut-être un tout petit peu avant là sur vos slides. Encore avant, encore avant.
[00:44:41] Ah, stop. À peu près par là, bon bref, euh du coup oui, euh, fonctionnalité de playbook. Bon, c'est pas grave, j'ai j'ai peut-être je suis peut-être la seule à pas avoir compris, mais...
[00:44:50] Ah, pardon.
[00:44:52] Parce qu'à un moment donné, vous parlez d'un MVP de playbook. Donc je suppose en gros, moi je considère qu'un playbook c'est un produit. Et donc il y a des fonctionnalités, et c'est quoi une fonctionnalité d'un c'est quoi ? C'est un exemple.
[00:45:02] Bah le MVP c'est en fait c'était le minimum de processus à lancer pour que le playbook soit efficace. Donc désolé de pas avoir compris.
[00:45:19] Euh bonjour, merci pour le partage. Euh, ma question, elle est sur, j'ai pas vu d'étape de formation. euh ni pendant l'implémentation, enfin ni pendant le le le déploiement, ni euh ni maintenant. Je sais pas si il y a eu besoin de formation euh à ce playbook. Et si vous formez des nouveaux arrivants par exemple ? Donc voilà.
[00:45:43] Je vais répondre. Euh donc la formation, en fait, on l'évoquait dans la stratégie de communication. C'était plus d'écrire lors des phases d'onboarding, qu'il y a ce playbook, voici les processus du playbook et montrer un exemple. Et après on laisse les gens lire en fait chacun des processus et le process, enfin on parlait de process helper dans dans chaque processus, on dit bah vous voulez le mettre en application, contactez telle personne et donc c'est cette personne-là qui va être un peu le coach pour que les équipes mettent en place le process.
[00:46:16] Bonjour, merci pour votre présentation.
[00:46:20] Dans le cas du PRD, en fait, il y a aussi beaucoup d'exemples de trucs qui existaient déjà. Euh donc là, c'est un document écrit, donc c'est assez facile, mais on peut toujours se référer à ah d'accord, il y a cette section, la façon dont ils sont en train d'écrire les différents trucs et cetera. Aussi beaucoup d'exemples. Parce que comme c'est des processus qu'on en fait qu'on vient tirer de bottom up, on a déjà des exemples d'application en fait.
[00:46:43] Euhm... Pardon. Oui, ici.
[00:46:48] Est-ce que vous pensez, est-ce que là on est à l'échelle d'un d'un produit euh pour le playbook. Est-ce que dans un environnement type agile, par exemple, on pourrait reporter ce ce playbook sur une granularité plus faible comme une feature, par exemple. Euh, sur 3 mois ou 6 mois, quelque chose comme ça. Est-ce qu'on pourrait avoir dégagé un playbook mais sur une granularité plus petite? Et du coup, sur quels éléments on pourrait jouer dans le playbook pour faire en sorte que ça s'adapte?
[00:47:19] Euh du coup dans dans les playbook, en fait, on a plein de process euh qui essaie de correspondre à chaque, on va dire étape d'un projet. Donc si on veut en écrire un pour comment décrire une fonctionnalité ou un truc comme ça, on peut le faire. Et nous le format qu'on a, en fait, précise quand est-ce qu'on peut utiliser du coup un certain processus et quand ne pas l'utiliser. Du coup, si on veut être aussi précis que ça, j'ai envie de dire c'est possible. Je pense pas qu'il y ait de contre-indication, c'est juste on va avoir beaucoup de si on est à cette granularité là, on risque en avoir beaucoup. Est-ce que c'est grave ? Je crois pas dans notre cas, je crois pas, étant donné que c'est les différentes équipes qui viennent piocher ce dont elles ont besoin ou est-ce qu'elles ont besoin de s'améliorer ? Donc oui, on pourrait, je pense.
[00:48:03] Euh donc vous nous avez expliqué que c'était très compliqué euh une fois la mise en place du playbook, d'AB tester. Forcément, on va pas faire deux fois la même chose une fois avec, une fois sans.
[00:48:12] Euh malgré tout, moi j'ai toujours une petite phrase en tête qui dit on améliore que ce qu'on mesure. Mais est-ce que avant, est-ce qu'une équipe avant de mettre en place le playbook, en tout cas de l'utiliser, elle mesurait son taux de rework? Et est-ce que vous pouvez voir l'impact du coup sur le taux de rework pas en mode A/B testing, mais en mode juste avant après?
[00:48:29] Euh, je pense pas qu'on le mesurait avant. Par contre, on fait beaucoup de de rétrospective en fait dans les différentes équipes et moi par exemple, je suis allé pas mal piocher sur les différentes équipes, enfin rétrospective d'équipe dans tous les Figma qu'on a. Et le problème de communication et de retravail et cetera, c'est un ça ça remonte absolument tout le temps. Euh de plus utiliser, en fait, tous ces points de friction ont été remontés par des gens en fait qui sont sur le terrain tout le temps, en fait, dans les différents expertises. Donc même si on n'est pas en mesure en fait de quantifier à quel point c'est problématique et à quel point on fait du rework, on sait que à chaque rétrospective, euh c'est remonté par beaucoup de gens. Voilà.
[00:49:13] Ou d'autres questions. Sinon on a un petit bonus.
[00:49:18] Petit, hein ?
[00:49:19] Petit, très petit.
[00:49:20] Il y a une question, il y a une question.
[00:49:22] Ah, on va on va prioriser la question.
[00:49:25] Pardon.
[00:49:27] Sur le donc sur la taille du du playbook, plus il va être gros, plus ça va être difficile et moins les gens vont avoir envie d'aller piocher dedans parce que parce qu'on a pas envie de se taper enfin voilà, c'est du knowledge management. Du coup, comment c'est comment vous voyez la gestion de de ce de la vie de ce playbook là-dessus et sa croissance ?
[00:49:50] Ouais. Alors euh déjà, on a déjà eu des propositions euh pour créer des processus qui étaient au final très proche de ce qu'on avait rédigé. Donc c'est déjà on essaie de voir bah quand c'est très proche et bah en fait, ça fait partie du même processus et il y a une option A et une option B s'ils sont vraiment différents dans la mise en en application. Comme ça on évite de créer trop de processus pour quelque chose euh de similaire. Euh, il y a aussi dans la façon dont on va présenter le playbook euh de bien catégoriser par étape du projet euh pour que chaque personne se dise, bah moi je suis intéressée d'améliorer telle étape. J'ai pas besoin de me de de me farcir tous les tous les processus des autres étapes.
[00:50:31] Et du coup, en terme de gouvernance, qui s'occupe de catégoriser ?
[00:50:36] Euh, donc ça c'est l'Obsteam.
[00:50:39] Après on a une méthodologie, enfin une un séquencement des étapes de projet assez commune, donc ça c'est assez simple, c'est un référentiel commun.
[00:50:53] Euh pour la prise en compte des feedback euh qui vous a permis justement après d'établir un bah cette documentation. Elle se fait en petit groupe, enfin à l'échelle de tous les métiers qui sont impliqués dans l'entreprise, et après il y a un système de voting qui est fait pour tendre à la solution finale, comment ça se passe à ce moment-là ?
[00:51:14] Alors, en fait, c'est la feedback group, donc pour les premiers processus, c'était la feedback group qui écrivait les différents retours. Et donc chaque personne de la working group qui avait rédigé le process, prenait connaissance de ce feedback et faisait un peu la sélection de OK, est-ce que tu es sûr que c'est un problème et cetera et donc voir si on l'améliore le processus ou au contraire si on le garde tel quel.
[00:51:40] Vous allez travailler en groupe ?
[00:51:43] Oui, oui, oui.
[00:51:44] Ouais ouais.
[00:51:47] Alors, après, tout le monde ne fait pas de retour. Enfin, ils peuvent, mais tout le monde ne fait pas le retour. Donc pour l'instant, c'est c'est ça reste une charge gérable.
[00:51:57] Une dernière question.
[00:52:05] Bonjour, merci pour le talk. Euh, un de vos problèmes initiaux, c'était la la présence des EM dans dans dans le process de Discovery. Euh, la question c'est, à quel moment du coup vous le faites intervenir ? Et du coup, quel rôle il a ? Est-ce qu'il a un rôle uniquement de EM, ou est-ce qu'il est lead dev, par exemple, d'une équipe ou ce genre de chose ?
[00:52:27] Je vais répondre. Alors, le problème qu'on avait avant, c'est qu'il y avait surtout les IM qui étaient impliqués au de tout au long du projet. Mais ceux qui avaient les mains dans le cambouis, donc les ingénieurs de chaque plateforme n'étaient pas suffisamment représentés et c'est là où en fait, on découvrait d'autres complexités. C'est pas que l'IM avait mal fait son job. C'est juste qu'il y avait d'autres complexités qui étaient remontées en mettant les mains dans le cambouis qui maintenant, en impliquant un un ingénieur de chaque plateforme dès le début du process, bah on évite en fait de découvrir des des gros monstres trop tard.
[00:53:02] Bah merci et c'est fini. Oui, merci.
[00:53:10] Si vous êtes intéressés pour nous aider à améliorer ce playbook ou autre chose, n'hésitez pas à nous contacter.

Transcription