Chloé Lemarié - Comment la méthodologie Shape Up permet de décliner la stratégie produit d'Evaneos ?

[00:00:03] Bonjour à tous. Euh alors quand je suis arrivée chez Evanos en 2023, c'était assez particulier parce qu'il y avait pas de backlog, pas de sprint, pas de ticket. Et pourtant les équipes, bah, elles avançaient, elles livraient, elles avaient l'air de prendre des décisions et d'avoir de l'impact. Et en fait, j'ai vite compris que c'était pas le fruit d'un hasard, mais le fruit d'une méthode qui était déjà en place là depuis quelque temps, c'est Shape Up. Et c'est ce dont je vais vous parler aujourd'hui. Euh donc moi, c'est Chloé, je suis dans le produit depuis 8 ans, euh je suis chez Evanos depuis 2 ans. Donc c'est pas moi qui ai mis en place la méthode Shape Up, mais je suis arrivée, elle tournait déjà bien, et je vais vous raconter un peu ce qu'on a fait et depuis comment on a itéré dessus aussi. Donc déjà pour vous donner un peu de contexte. Evanos, ça a été créé en 2009. Euh, ça a donc 15 ans d'existence, c'est une scale-up. Aujourd'hui, on est 170 personnes. Et l'idée, c'est de connecter des voyageurs, comme vous et moi, à des agences locales de voyage à destination, dans l'idée de co-construire un voyage ensemble et que ça soit du tourisme plutôt responsable. Ce qui est important à avoir en tête, c'est qu'en fait, on n'a pas d'agence physique, c'est pas comme Voyageur du monde ou d'autres acteurs. Tout se fait en ligne. Donc en fait notre produit, il est numérique et seulement euh en ligne. Et pour vous donner un peu une petite idée de qu'est-ce que c'est notre produit. Donc en fait, ce qu'on a, c'est la partie voyageur que vous, vous pouvez voir, donc sur internet, un site et une application mobile. Donc l'idée c'est de consulter de l'offre, des itinéraires, co-créer son voyage, avoir des infos pendant le voyage et à son retour. Et on a toute la phase euh de l'autre côté pour nos agences locales, où en fait, on a développé une Travel suite. Donc un CRM pour que nos agences puissent gérer leurs demandes de voyage, un outil pour créer des devis, un outil de quotation, de paiement et ainsi de suite. Donc ça, c'est un petit peu la photo d'aujourd'hui, et pour vous dire comment on a mis en place Shape Up, en fait, il faut revenir 5 ans en avant. À quelque chose que vous connaissez tous, le Covid. Euh bah, quand on est dans l'industrie du tourisme, ça fait mal, parce qu'en fait toutes les frontières se ferment petit à petit. On ne sait pas quand est-ce que ça va rouvrir, donc les voyages sont d'abord reportés. Puis annulé. Finalement, bah il y a un peu plus rien à faire. Donc il y a eu une vague de départs volontaires, la boîte a dégraissé de quasiment moitié des effectifs et du coup, ça laisse du temps. Du temps pour se poser des questions sur qu'est-ce qu'on veut faire, comment on redémarre? Donc finalement, ça a été une période assez propice euh de veille. Alors, j'ai mis produit parce que je suis PM mais aussi de veille tech, de se poser des questions sur nos pratiques, qu'est-ce qu'on veut faire? Comment les gens font ailleurs? Comment on pourrait s'améliorer? Et dans l'idée de se dire, on a envie d'améliorer deux choses. Euh déjà, comment on se concentre euh sur les bons sujets et comment on a de l'impact? Parce qu'en fait, à ce moment-là, Evanos c'était un peu une usine à fonctionnalité, il y en avait dans tous les sens, ça sortait, mais on se concentrait peut-être plus sur qu'est-ce qui sort le comment que sur le pourquoi. Et aussi, question un petit peu liée, l'idée de en fait comment on s'aligne? Comment on fait en sorte de garantir aux équipes qu'elles peuvent travailler, qu'elles sont pas sans cesse en train de se disperser ou de diluer l'effort. Donc en fait, c'était un petit peu ça qui nourrissait les échanges, et au milieu de tout ça, il y a un petit bouquin qui a émergé. Ce bouquin, du coup, c'est Shape Up. Donc c'est une méthodologie qui a été développée par Basecamp en 2019. Euh donc Basecamp, c'est une société basée à Chicago qui édite un logiciel de gestion de projets. Ehm. Et donc pour vous expliquer un petit peu, donc ça c'est un peu la grosse slide qui récapitule tout, mais après on va rentrer dans le détail de tout. Première notion importante, c'est des cycles de 6 semaines. Donc c'est plus long qu'un sprint classique, mais c'est non moins pas non plus trop long. Et donc en fait on a six cycles par an, donc ça passe assez vite, trois par semestre, et entre chaque cycle, on a des cool-down. Donc les cool-down, c'est ce que vous voyez sur l'écran, c'est des périodes de 2 semaines entre chaque cycle. Et après, il y a quelques notions importantes à avoir en tête, donc des notions de shape et de build. On y reviendra après un peu mieux, mais en gros, le shape, pour schématiser, c'est ce qui est cadré, faire sa discovery. Le build, on construit. Donc on itère, ces deux choses-là, on les fait en parallèle. C'est pour ça qu'on parle de dual track. Et au milieu, on parie. Donc c'est la phase de bette, on parie sur les sujets. Euh avant de rentrer un peu dans le détail de ce que tout ça signifie, il y a quelques points clés à avoir en tête. C'est qu'en fait les équipes, elles sont autonomes sur ce qu'elles shape, sur ce qu'elles build, sur ce qu'elles veulent faire et sur ce qu'elles proposent. Et en fait, c'est vraiment la phase de bête, où on valide ensemble euh collectivement sur la boîte et on parie sur nos sujets. Il y a pas de backlog, on en reviendra après, mais vraiment c'est pas du tout la façon dont les choses sont faites, et on n'est pas censé être interrompu pendant 6 semaines. Donc en fait, on livre ce sur quoi on s'est engagé sur les shape et le build, il y a pas de bug, de tâche support euh ou autre. Ehm, donc pour vous dire un peu dans quel contexte on l'a implémenté, je vais vous parler de notre organisation produit côté Evanos. Donc on est organisé en impact team, on en a 7 en tout, et en fait à chaque fois on a un objectif à atteindre. Donc on a un KPI à faire bouger et un North Star. Moi par exemple, c'est d'améliorer le taux de vente des agences locales. Donc je gère en fait mon périmètre vis-à-vis de ce KPI là. Et après ce qui est intéressant aussi, c'est qu'on a un peu enrichi la façon dont les équipes sont composées. Donc ça, vous connaissez sûrement, c'est le product trio, souvent on dit qu'en fait, il faut un profil tech, donc le tech lead ou l'engineering manager, un profil produit, PO PM, un profil design, et une équipe de développeurs.
[00:05:10] Nous, on a euh cette cette base là, ce socle, mais en fait, on l'a enrichi et on parle en interne de Product Orchestra. Donc en fait, on ajoute deux profils, un profil data, un data analyst. euh qui est pas à 100 % euh dédié à l'impact team, mais qui nous permet en fait de vraiment creuser la donnée, l'analyser, euh analyser les expérimentations et en fait nous enrichir de tout ça. Et un autre profil qui est dans l'orchestra, c'est un profil biz qu'on appelle le co-lead biz, et en fait, bah, c'est celui qui a des intérêts directement reliés aux nôtres. Donc moi typiquement, je vous disais, mon but c'est d'améliorer le taux de vente des agences locales, je travaille avec la personne qui coordonne tout le réseau d'agence locale, parce qu'en fait, on a le même objectif à la fin. On a des développeurs évidemment, et on a aussi des experts métiers. Donc c'est pas des gens à temps plein dans l'équipe, mais c'est quand même des gens qui dédient une partie de leur temps pour nous pour participer à des ateliers, à des workshops, à du brainstorming, pour regarder les maquettes, pour valider avec nous, et vraiment qui suivent l'équipe au fil de l'eau et qui nous infusent de leur euh vraiment expertise métier pour qu'on s'assure que tout ça aille dans le bon sens.
[00:06:14] Donc voilà pour notre regard produit. Et maintenant on va rentrer du coup dans le détail un peu de de ces grandes notions de Shape Up, donc on va commencer par la première, le shaping.
[00:06:24] Euh donc du coup dans la théorie, euh le shape, en fait, c'est vraiment une idée de défricher. On a un sujet, on veut le défricher. Donc en fait, c'est un cadrage ou une discovery, et ils insistent beaucoup sur le fait qu'il faut trouver le bon niveau d'abstraction.
[00:06:35] Ce qui signifie qu'au début le sujet il a l'air un peu obscur, il est très abstrait, il est shapé, mais l'aboutissement d'un shape, c'est pas une spec. En fait, ça doit rester un niveau un peu macro.
[00:06:45] Donc l'idée c'est de voir un peu les problèmes, les trous dans la raquette, les points noirs, mais il faut pas arriver sur quelque chose de trop précis. Nous concrètement, donc on se base sur ça, mais on a décidé un petit peu en fait de d'enrichir euh le côté shape pour aussi s'y retrouver. Donc en fait, on a différents types de shape qu'on associe à des types de Discovery. Donc on en a trois. Le premier c'est tout ce qui est shape exploratoire. Donc là l'idée, c'est vraiment d'identifier de nouvelles opportunités à valeur ajoutée. Donc c'est dans cette phase-là où on fait beaucoup d'interviews utilisateurs, on creuse la donnée, on analyse le produit, l'idée c'est vraiment de mapper toutes nos opportunités. Et le livrable à l'issue d'un shape exploratoire pour nous, c'est un arbre d'opportunité où vraiment on a bien tout ça qui est mappé avec d'une un ordre de priorisation. On a également des shapes qui sont un peu plus conductifs. Donc en fait, sur notre arbre d'opportunité, on va décider de se concentrer sur une opportunité précise, et celle-ci on a envie de la creuser et d'expérimenter et de mieux comprendre. Donc c'est dans un shape conductif, par exemple, bah qu'on fait des tests utilisateurs sur les maquettes, que vraiment on creuse, que des fois on fait des petits poc en production pour vraiment expérimenter. Et on a un dernier type de shape, qui est plus technique là, donc où le PM intervient beaucoup moins. Mais l'idée c'est plus d'explorer une solution technique, voilà, de préparer les aspects techniques d'un projet. Et d'évaluer tout ça. Moi, concrètement, je trouve que c'est hyper puissant pour le PM parce qu'en fait, souvent quand même, quand on est entre Discovery et delivery, la delivery c'est chronophage, ça prend beaucoup de temps, c'est de l'opérationnel, et c'est dur de se dédier du temps à toute cette partie Discovery. Là, le fait qu'on ait vraiment du temps qui soit institué dedans et que ça soit assez bien euh cadencé, bah c'est hyper puissant pour le PM. Ça nous permet d'être vraiment en maîtrise de notre périmètre, d'avoir le temps de faire du benchmark, d'étudier, de comprendre et d'avoir un peu sa stratégie produit pour son équipe. On a donc une deuxième notion assez intéressante, c'est la phase de build. Donc, euh build dans la théorie, c'est vraiment la phase où on met en production une solution. Donc en fait, c'est notre phase de delivery. Et dans la théorie, ils insistent un peu, pareil, je vous ai remis un schéma, sur le fait que quand on commence un build, on ne sait pas forcément exactement comment ça va être ni à quoi ça va ressembler. C'est ce que je vous disais juste avant, à la fin du shape, c'est encore un peu, c'est pas abstrait, mais c'est pas trop concret non plus, mais au fil du build, on apprend du coup à bien voir ce qu'on fait et à délivrer petit à petit.
[00:09:00] Pareil chez Evanos, on a repris cette notion là, mais on a deux types de build. Donc on a un build quand c'est une nouvelle fonctionnalité. Donc généralement, c'est issu d'un shape, on a eu une opportunité, on a testé, on pense que ça va avoir de l'impact, donc là, on l'industrialise. Donc on l'industrialise bien avec vraiment toute la chaîne de test et cetera, et on a un autre type de build qui là n'est pas dédié au fait de rajouter une nouvelle fonctionnalité. Mais plutôt de faire du refactoring. Donc de retravailler un peu le code des fonctionnalités existantes. Pour aussi maintenir une qualité excellente. Et euh ce qui est en tout cas à savoir euh chez nous en tout cas, c'est que les équipes techniques, elles sont hyper autonomes en fait sur la delivery de la solution. Moi, j'interviens assez peu. En fait, le PM chez Evanos ne découpe pas et ne rédige pas du S. En fait, c'est vraiment sur la partie shape que je transmets ça. On en parle beaucoup ensemble, bien sûr, mais c'est l'engineering manager en fait qui fait le découpage. euh et qui gère vraiment l'équipe tech entre back, front euh et ils sont hyper autonomes sur ça.
[00:09:58] Ehm. Donc là, on a parlé de nos cycles avec des shapes et des builds. On va maintenant parler de la période intercycle, donc c'est la cool-down.
[00:10:06] La cool-down, euh dans la théorie, donc c'est une période entre cycle qui a pas de travail programmé. Du coup, on profite de cette période-là pour corriger les bugs. Euh donc là par exemple, vous voyez sur notre channel Slack où on a nos bugs du support, on priorise, on le fait. Et l'idée aussi, c'est d'explorer de nouvelles idées et c'est le moment pour préparer le prochain cycle et passer un betting table. Ce que je vais vous expliquer juste après. Ehm, concrètement, donc nous on reprend cette trame, mais on a essayé de vraiment structurer nos deux semaines de cool-down euh bah pour s'assurer qu'on a le temps de bien tout faire. Donc la première semaine, en fait, on finalise vraiment le cycle et c'est là où on cale nos rituels d'équipe. Donc on passe en betting table, on fait aussi une rétrospective d'équipe, qui du coup n'arrive que toutes les 8 semaines, donc ce qui est assez moins souvent que en Scrum ou un modèle agile. classique, et on fait des démos produits à toute la boîte pour montrer aussi ce qu'on a livré à l'issue de notre cycle. Euh et on corrige les bugs, parce que quand même il y en a un petit peu. Et la deuxième semaine, on essaie de passer du temps par expertise. Donc en gros euh, les def front sont ensemble, les def back ensemble. Les PM ensemble, les designers ensemble, et l'idée c'est un peu d'harmoniser les pratiques. De plus être juste sur son impact team à faire des choses, mais de travailler collectivement euh ensemble, de de contribuer à des projets transverses euh ou annexe. Euh l'idée aussi derrière ça, c'est de faire un peu de veille, de faire de la de d'avoir un peu de prise de recul, pour pas être toujours le nez dans le guidon. Et il y a quand même un peu la volonté de se dire entre le cycle dans la cool-down, bah ça s'appelle cool-down pas pour rien, donc il faut aussi un peu recharger les batteries et d'attaque pour le prochain cycle. Dans les faits, euh moi je trouve que ça passe hyper vite, c'est vraiment 2 semaines qu'on voit pas passer. Finaliser le cycle, oui, il y a pas de souci. Prendre un peu de temps par expertise, oui, faire de la veille, honnêtement, c'est assez dur. En fait, il y a quand même enfin ça passe vraiment vite. Et pourquoi ça passe vite? Alors déjà parce que je vous c'est ce que je vous ai mis là. En fait, il y a la betting table pendant la cool-down. Et du coup, on va en parler, mais c'est quand même un rituel qui se prépare pas mal. Donc en fait, dans la théorie, l'idée, c'est qu'on arrive en betting table, donc c'est un rituel, on a des pitchs. Donc en fait, l'équipe vient pitcher les sujets sur lesquels ils souhaitent travailler au prochain cycle.
[00:12:09] Et donc l'idée c'est de convaincre ceux qui sont à la betting table, bah en fait, de miser et d'investir pour ces 6 semaines là. Normalement, dans la théorie, on ne parie que sur les builds. Donc sur ce que l'équipe va construire et industrialiser. Et elle est autonome sur les shape. Donc sur ce qu'elle souhaite cadrer ou explorer. Et c'est ce que je vous disais au début, il y a l'idée qu'il y a pas de backlog. Donc en fait les idées importantes reviendront. Ce qui signifie qu'on peut présenter un nombre de pitchs à une betting table. Ils sont validés, parfois il y a un peu de retravail derrière, il y en a qui sont retoqués, on le fait. Et en fait à la prochaine betting table, on repropose des pitchs. Donc parfois, c'est la suite logique de ce qu'ont été là, donc un shape qui peut se transformer en build. Parfois, c'est des recalés qui reviennent, parfois, c'est des nouveaux parce que de nouvelles idées euh ont émergé. Euh donc nous, concrètement, la betting table, alors on a décidé de parier sur les builds et sur les shape. Parce qu'en fait, on s'est dit que c'était quand même aussi important euh bah de cadrer ce sur quoi on passe du temps à explorer. Euh donc que ça soit fait de façon efficace, et il y a quand même des opportunités qui peuvent être plus ou moins grandes. Donc en fait, on parie sur les deux, et c'est ce que vous voyez sur ce petit schéma, donc on rédige des pitchs à chaque fois. Donc un pitch pour un pour une Discovery qui est technique, conductive ou exploratoire, un pitch pareil pour une nouvelle feature ou pour du refactoring. Euh pour le coup, on a pas mal itéré sur ça. Du coup, maintenant, c'est un rituel d'une heure par équipe euh toutes les 8 semaines. Donc du coup vu que c'est à chaque cool-down, donc avec le product orchestra que je vous présentais au début. Et après trois rôles qui sont au codir, donc CPO, CTO et un un codir sponsor. Donc qui dépendent selon l'équipe de où elle est. Euh et pour le coup, c'est très efficace hein, parce qu'on a quand même 1 heure pour revoir les. faire une petite repasse sur les précédents sujets, l'impact qu'on a eu, ce qu'on veut faire au prochain cycle. Et du coup, tout est templétisé, nous on utilise nos chaînes, et en fait, on utilise vraiment les mêmes templates d'une impact team à l'autre pour rédiger nos pitchs un peu de la même façon, donc pour être sûr de parler du problème à résoudre. des solutions qu'on souhaite, des KPI, enfin vraiment de tout, et ça nous permet aussi un gain de temps en fait parce qu'on remplit et ça enlève un peu de charge mentale. Sachant que en fait ce travail de préparation de betting table, il est quand même beaucoup à la charge du PM. C'est collectif pour toute l'équipe, mais c'est vraiment lui qui porte ce rituel là. Et en fait c'est un rituel qui se prépare. Vraiment, parce que c'est un moment d'échange d'une heure, donc faut être sûr de parler des bons sujets, au bon niveau de granularité. euh et d'anticiper les potentiels challenges, bah des gens du codir qu'on voit assez peu et qu'ont pas forcément toujours les mêmes problématiques que nous à l'esprit.
[00:14:38] Ehm. Donc voilà pour la betting table, et il y a une notion qui est assez importante derrière ça, c'est l'appétit. L'appétit, pour vous l'expliquer, en fait, c'est vraiment le temps qu'une équipe est prête à passer sur un problème spécifique. Donc en fait l'idée c'est pas de se dire combien ça prend de construire une fonctionnalité, mais plutôt quel temps on a envie d'y passer. En fait, combien on veut se donner dessus? Et du coup, la variable en fait d'ajustement, ça va être le périmètre. Parce que forcément, s'il y a moins de temps, bah il faut ajuster. Et du coup, on parle en terme de semaines. Donc un cycle, c'est 6 semaines, et en fait, moi j'arrive avec mes pitchs en disant j'aimerais passer 2 semaines d'appétit à explorer tel sujet, 3 semaines à build telle chose et ainsi de suite. Donc c'est pas une notion qui est toujours très simple à comprendre, notamment côté développeur. Parce que forcément, il faut quand même faire un petit ratio entre le temps qu'on a envie d'y passer, mais concrètement, est-ce que si on y consacre une semaine, on peut sortir quelque chose? Il y a quand même un équilibre à avoir entre les deux. Et en fait ce qu'on essaie vraiment de faire, c'est d'adosser cette idée d'appétit à l'impact, l'impact qu'on veut avoir in fine sur le produit. Et en fait souvent euh en gros, pour nous aider un petit peu enfin à matérialiser ça, c'est en fait c'est se demander comment en tant qu'équipe, si on a 6 semaines, admettons que 6 semaines ça représente un peu près 100000 € de coup, comment on veut les investir? En fait sur quoi on veut construire, où est-ce qu'on veut aller, comment on veut le faire pour essayer de rationaliser l'effort et de s'obliger à penser en fait ROI, quel retour sur investissement par rapport au temps qu'on passe sur ces choses-là.
[00:16:07] Ehm. Euh donc voilà là normalement vous avez à peu près tous les concepts de Shape Up. Donc si je récapitule, vous avez des cycles avec des shape, des build, des phases de cool-down pendant lesquelles on bette pendant la betting table sur des sujets. Et maintenant, je vais vous raconter un petit peu du coup nous chez Evanos, quel bilan on en tire. Sachant que du coup, c'est la 4e année. Donc on a eu le temps de le mettre en place, d'itérer d'une année à l'autre, pour s'ajuster et euh et on continue avec, donc c'est que ça se passe plutôt bien. Du coup, nos succès euh pour ça, alors déjà on trouve qu'on a beaucoup gagné en impact et en clarté. C'est ce que je vous disais au début, au moment du Covid où il y a eu toute une veille produit, il y avait une sensation un peu de dispersion, on sortait plein de choses, on savait plus trop pourquoi, on était interrompu, on se posait pas les bonnes questions, là ça remet en fait vachement de sens. De chaque équipe a un objectif et autonome pour travailler sur ses shape et sur ses build, et en fait derrière euh a eu des résultats concrets avec des métriques qui ont bougé, donc le taux d'engagement sur le site, les taux de conversion euh et ainsi de suite. Et ça nous a permis en fait de découvrir des vraies opportunités sur lesquelles on a capitalisé, expérimenté et où derrière ça a vraiment fonctionné. Euh autre chose qui est assez intéressante, c'est que du coup on collabore beaucoup avec les équipes métiers. En fait, le produit n'est pas à part dans la boîte, euh il est un peu enfin au milieu de tout parce que finalement, vu qu'on a tous des expert métier et un co-lead biz, en fait, il y a beaucoup de gens euh qui prennent part au quotidien des impact team.
[00:17:35] Et qui du coup interagissent euh presque quotidiennement avec les développeurs, designers et PM. Donc vraiment, c'est une collaboration assez riche qui fait que finalement tout le monde suit les évolutions produits.
[00:17:45] que ça soit autant côté voyageurs que côté agence locale. Et on avance vraiment tous ensemble. Et autre succès, c'est que côté PM, ça donne beaucoup d'autonomie. C'est un peu ce que je vous disais, du coup, on est moins sur le delivery parce qu'il y a vraiment une grande autonomie des équipes tech euh à vraiment être honneur de la solution, à découper, à travailler pour. Et du coup, le PM se ressent beaucoup plus sur l'aspect Discovery. Euh donc comment il anticipe en fait, comment il essaie d'avoir un coup d'avance pour le cycle d'après, sur quoi il a envie d'explorer, qu'est-ce qu'il a envie d'expérimenter et comment il veut le faire. Et donc ça je trouve que c'est assez puissant euh pour le coup.
[00:18:23] Bien sûr, tout n'est pas rose. Du coup euh, forcément il y a des choses qu'on a dû ajuster et sur lesquelles bah on itère encore en fait, c'est pas forcément parfait. Donc la première chose en fait, à avoir en tête, c'est que du coup, c'est très dirigé par l'impact, quel impact on veut avoir derrière, quel impact business. Et en fait, comme vous l'avez vu dans les cycles, du coup, il y a pas forcément dédié, de temps dédié à la santé technique ou à la dette technique.
[00:18:45] En fait, pendant les cycles, on avance, on itère, pendant les cool-down, on corrige, mais du coup, on corrige qui va pas, et il y a pas forcément ce temps-là qui est dédié à l'amélioration du produit.
[00:18:53] Euh donc c'est forcément un des alertes que peuvent remonter les équipes tech et en fait ce qu'on a instauré depuis quelques mois déjà.
[00:19:02] C'est du coup de se dire, en fait, on va allouer du temps de cycle, du coup, pas du temps seulement du temps de cool-down à la tech. Et en fait, sur le coup, pour le coup, sur ça, ils sont autonomes, ils ont environ 15 % du temps de cycle. Et c'est eux en fait qui s'auto-organisent, qui priorisent et qui décident en fait ce qu'ils veulent faire pour en fait améliorer le produit et le maintenir. Et autre chose pareil qu'on a instauré, c'est un rôle de Captain Terrupt. Donc en gros, l'idée de se dire, normalement, on n'est quand même pas pendant 6 semaines, en fait, on ne corrige pas de bug, on n'est pas interrompu. Après, ça c'est la théorie, bien sûr, parfois dans la réalité, il y a des incidents.
[00:19:35] Il y a des régressions majeures, donc en fait, on a quand même besoin d'être interrompu. Donc l'idée, c'est un petit peu de se dire par équipe, qui est la personne qui va être interrompue, donc qui est le point de contact euh qui va qualifier du coup, est-ce que ça mérite vraiment de s'interrompre ou pas? Et si oui, qui va le faire? Donc si cette personne suffit, elle le fera seule. Donc il y a un Captain Terrupt par euh équipe. Donc en fait, il y en a 7, ça veut dire tout le temps.
[00:19:57] Sinon, ils dépêcheront d'autres gens pour bosser ensemble sur ça. qui décident en fait ce qu'ils veulent faire pour en fait améliorer le produit et le maintenir. Et autre chose pareil qu'on a instauré, c'est un rôle de Captain Terrupt. Donc en gros, l'idée de se dire normalement, on est quand même pas pendant 6 semaines en fait, on ne corrige pas de bug, on n'est pas interrompu. Après ça c'est la théorie, bien sûr, parfois dans la réalité il y a des incidents, il y a des régressions majeures. Donc en fait, on a quand même besoin d'être interrompu. Donc l'idée, c'est un petit peu de se dire par équipe, qui est la personne qui va être interrompue, donc qui est le point de contact euh qui va qualifier du coup est-ce que ça mérite vraiment de s'interrompre ou pas, et si oui qui va le faire. Donc si cette personne suffit, elle le fera seule. Donc il y a un Captain Terrupt par équipe, donc en fait, il y en a sept, ça veut dire tout le temps. Sinon ils dépêcheront d'autres gens pour bosser ensemble sur ça. Euh, autre petit point qu'on a dû aussi un peu ajuster qui est assez lié au premier, c'est ce que je vous disais en fait, c'est Shape up ça force à prioriser par l'impact. Du coup, c'est pas forcément facile d'inclure des priorités qui sont pas business et qui n'ont pas forcément d'impact. Donc il y a des priorités tech, mais il y a aussi les priorités design. Euh, typiquement si l'UX est un peu vieillissante, que les parcours utilisateurs pourraient être optimisés, c'est pas un sujet en tant que tel qu'on peut forcément pitcher et faire passer en betting table. En fait, on va y arriver si on l'intègre à un build ou à une refacto, si on arrive à prouver que ça nous fait perdre des voyageurs, de la compréhension de la valeur, mais sinon c'est pas naturellement des sujets qui vont se retrouver, on va dire, en haut de la pile. Donc c'est pas toujours simple non plus à prioriser. Et il faut aussi trouver le bon équilibre entre shape, build, entre chaque cycle. En fait, c'est des cycles de 6 semaines, c'est assez cadencé parce qu'on a des shapes naturellement si c'est validé, ça passe en build et ainsi de suite, mais parfois la temporalité ne peut ne pas être la bonne. Et du coup, il y a un R&D mode. Alors ça pour le coup, c'est dans la théorie Shape up. Et nous on l'exploite un peu, c'est l'idée de se dire des fois on a un sujet, il y a beaucoup d'incertitudes et on n'a pas forcément envie de passer sur un cycle shape exploratoire, shape conductif, euh et build. Et en fait, ce qu'on fait, c'est qu'on passe en R&D mode et l'idée en fait, c'est de dérisquer. Donc ça peut être dérisquer d'un côté produit fonctionnel ou dérisquer techniquement et souvent en fait en sortie de ça, ce qu'on a, c'est un poc, donc qui est jetable hein, normalement on va pas itérer et construire dessus, mais c'est juste se montrer OK, on est capable d'avoir une solution dessus. On est capable de trouver de la itérance, il y a de l'usage. En fait, c'est vraiment pour se prouver que ça peut marcher avant d'aller plus loin et de du coup derrière industrialiser euh davantage. Et la dernière chose pareil un petit peu zone de friction, euh c'est tout ce qui est priorisation et backlog, c'est ce que je vous disais au début, du coup, il y a pas de backlog en Shape up. Pour autant, on passe notre temps à récolter des insights, que ce soit en faisant des interviews utilisateurs, en analysant la donnée, en ayant des petits bugs, des petites frictions. Donc en fait, il y a quand même plein de choses à gérer sur son produit. Et en fait, du coup, il faut une certaine discipline pour stocker ses idées, vu qu'il y a pas de backlog. Donc pour ça, il y a plusieurs outils et toutes les équipes Evaneos font pas forcément la même chose. Euh, il y en a qui utilisent beaucoup les arbres d'opportunités. Donc même si on sait qu'on se concentre sur telle partie de notre arbre, on note quand même au fil du temps toutes les autres opportunités qu'on a. Euh pareil, on a des outils pour stocker les retours utilisateurs, typiquement Dovetail, qu'on essaie d'avoir super propre, comme ça, on sait que si un jour on change de sujet ou qu'on a le temps, on peut retrouver un peu tous les pains utilisateurs, tous les points de friction pour iterer dessus. Et en fait, voilà, on a quand même un enjeu d'essayer de garder toute cette matière de retour qui est hyper riche, qui est hyper dense, mais qui n'est pas actionnable pour le prochain cycle en fait ou qui va pas être travaillé dans les prochains mois. Euh donc voilà un petit peu pour les zones d'ajustement. En fait, si je devais un petit peu résumer les forces et limites de Shape up. Bah, c'est ce que je vous disais la priorisation, elle est très orientée business. Donc selon ce que vous voulez en faire, en fait, c'est hyper utile parce que ça force vraiment euh bah à s'interroger sur ce qu'on veut faire. Il y a toujours 1000 choses à faire sur un produit, choses à corriger, à améliorer. Le fait d'avoir un objectif et de se dire je priorise à l'one que de ça, bah en fait, ça aide à le faire. Mais c'est ce que je vous disais, parfois peut-être un peu au détriment euh de la tech ou du design. Et après les cycles de 6 semaines, il y a des gens pour qui c'est beaucoup trop long, d'autres gens pour qui c'est beaucoup trop court. Donc ça dépend un peu de où vous en êtes niveau maturité de de votre produit. Nous typiquement donc on a des impact teams, mais en fait, on a une équipe qui est sortie de ce mode-là Shape up parce que il devait passer en mode poc. Et on voulait tester des choses avec l'IA. Et en fait, on s'est dit en cycle de 6 semaines, ça va être beaucoup trop long, la boucle de feedback, elle est hyper longue. On veut quelque chose de beaucoup plus rapide, beaucoup plus itératif. Au bout d'une semaine, on est capable de savoir OK, on continue, on réinvestit, non, on s'arrête. Donc eux ne sont plus en Shape up et c'est assumé parce qu'en fait, on s'est dit le modèle ne correspond pas à ce que souhaite faire cette équipe chez Evaneos.
[00:23:56] Euh, et donc si vous aussi vous avez envie de vous lancer sur la méthodo Shape up, un peu une slide qui relance les enfin qui recense les prérequis. Euh, première chose, je pense c'est avoir un produit stable parce que c'est ce qu'on se disait au début, pendant 6 semaines, euh bah on est censé être sur nos sujets et ne pas se disperser, ne pas corriger de bug ou de support. Donc ça signifie une certaine stabilité technique. Euh que nous on avait vraiment pour le coup, il y avait une très bonne stack technique chez Evaneos et c'est pour ça qu'on s'est permis de passer en Shape up. On a vu à un moment que du coup, peut-être elle était moins bien maintenue, qu'elle allait un peu se dégrader. C'est pour ça qu'on a décidé d'allouer 15 % du temps de cycle à ça. Mais du coup, c'est un prérequis si aujourd'hui vous l'avez pas, je dirais que c'est peut-être un peu bancal de se lancer dans Shape up. Euh deuxième point, c'est la confiance du leadership parce qu'en fait ce qu'on a vu, bah les équipes ont beaucoup d'autonomie. Alors en effet, un betting table ils valident sur quoi on va passer du temps en terme de shape et de build, mais en fait, c'est 1 heure toutes les 8 semaines et on se revoit pas tant que ça en dehors de ces 8 semaines en fait, on se voit une fois toutes les 8 semaines. Donc ça nécessite de la préparation, de la confiance et derrière de l'engagement. Donc euh voilà, il faut que ça marche, enfin pour que ça marche, il faut forcément que le management soit embarqué et une organisation produit plutôt mature. Euh donc c'est ce que je disais, vu que les cycles de 6 semaines, ça peut être un peu long, c'est pas forcément l'idéal si vous devez lancer un produit qui a pas de market fit. Euh mais aussi derrière organisation plutôt mature, je mets les profils qui sont derrière. Euh typiquement nous tech c'est tous des équipes tech assez seniors en fait, euh qu'on vachement l'habitude de s'auto-organiser. Notamment l'engineering manager qui en fait reprend aussi un peu une partie PO parce que c'est lui qui suit le delivery, qui découpe, qui s'assure en fait que tout est bien fait. Bah, ça veut dire que c'est quand même quelqu'un qui a de la bouteille et qui a pas commencé le dev euh il y a peu. Pareil, côté PM, c'est beaucoup d'autonomie, beaucoup de Discovery. Euh c'est très orienté KPI, ROI business. Donc ça signifie qu'il faut avoir un peu l'habitude de tout ça et qu'on n'est pas forcément mentoré, enfin que il faut être autonome tout seul quoi, avancer voilà. Donc un peu, je dirais, c'est trois gros axes si vous avez envie d'essayer Shape up euh chez vous. Euh et donc en conclusion, bah nous ça fait 4 ans euh que c'est chez Evaneos. Pour le coup, ça a été un vrai catalyseur. Ça nous a permis de corriger euh enfin plein de choses, d'avancer. On continue dessus. Après comme je vous montre à chaque fois, on a un peu itéré, il y a des équipes qui en sortent. Et du coup, si j'avais euh bah un point à dire, c'est qu'il y a quand même pas d'organisation parfaite. Là, je vous en ai parlé parce que je le vis, ça veut pas dire qu'il faut l'implémenter euh à tout prix. Et pour le coup, une orga produit, bah, il faut qu'elle évolue avec son produit, avec les équipes, donc sa séniorité, si ça bouge, si ça bouge pas et il faut pas qu'elle soit figée dans le temps. Euh du coup, si je devais refaire ce talk dans 6 mois ou dans un an, je pense que je dirais pas tout à fait la même chose. Euh et voilà, le voyage continue. Merci.
[00:26:54] Et si vous avez des questions ou des remarques en échange, je vous écoute.
[00:27:11] Euh, combien de personnes dans l'organisation au total ?
[00:27:13] En tout, on est 170 euh 7 PM et du coup, il doit y avoir une trentaine de développeurs. Il y a 4 dev par équipe.
[00:27:25] Oui, merci pour ta conf. Et j'ai une question sur la discipline des 8 semaines, il y a d'autres mécanismes où on tombe fatalement sur les moments de décision qui sont sur des périodes de vacances. Donc ta betting table, elle tombe entre Noël et le jour de l'an. On adapte, on n'adapte pas ? Ça s'est passé comment sur ces 4 ans ?
[00:27:41] Oui, c'est une bonne question. Euh, oui, on adapte un peu. Typiquement l'été, on fait pas une cool down de 2 semaines, on fait une summer cool down qui va durer juillet-août. Et en vrai, c'est pas mal, ça permet de corriger plein de choses, de voir l'expérience transverse parce qu'en fait juillet-août, les équipes sont trop morcelées et pareil, on fait en sorte que ça ne tombe jamais entre Noël et le jour de l'an, quoi, la betting table. Et après, il y a un peu un truc de normalement le PM, vu que les dates sont fixes, est censé ne pas être en vacances pendant les betting tables parce que c'est quand même un enjeu important. Moi, j'avoue, j'en ai loupé une, donc j'avais vraiment bien briefé l'équipe et beaucoup bossé en amont, mais c'est quand même un rituel où c'est mieux d'être là.
[00:28:20] Merci, c'était très intéressant. En fait, j'ai deux questions sur les paris, la betting table. Comment sont décidés ces bets, c'est vraiment toi, le PM qui décide ou qui propose et après c'est raffiné ? Ou voilà, ça c'est la première question. La deuxième, c'est l'amélioration continue, mais vraiment produit parce que là on parlait beaucoup de tech et des techniques, mais comment ça se passe si par exemple tu as un scope de ton de ton projet pendant euh pendant le le le shape et le build, mais après si c'est fini avec ce scope, comment vous décidez de l'améliorer si ça dépasse ? Est-ce que ça vient plus tard ? Est-ce que c'est une nouvelle proposition ? Voilà.
[00:28:55] OK. Euh pour la première question, du coup, oui, enfin, le PM est censé vraiment, c'est lui qui est garant de sujet à proposer en betting table. Mais en fait, il le fait pas tout seul, il le construit vraiment avec son orchestra. Donc le colead Biz par exemple a beaucoup d'infos à donner souvent un peu stratégiques de ce qu'il veut faire. Après forcément, il y a l'engineering manager. Donc on coconstruit, on va dire, à cinq ça. Après ce que j'ai pas beaucoup dit, c'est qu'en fait quand je dis que ça se prépare, l'enjeu quand même, c'est que peut-être tous les membres du Cotir ne découvre pas la betting table le jour même. Donc il y a aussi un peu de je te raconte un peu avant, c'est quoi tes enjeux, j'ai peut-être prévalidé avec une personne, enfin, un peu préparer le terrain, on va dire, pour qu'elle se passe bien. Euh donc voilà, et ta deuxième question c'était. Ouais. Bah, ça, en fait, on ne le fait pas tant que ça, mais je pense que c'est un peu un parti pris de se dire, on va améliorer telle métrique. Donc on y va à fond. Une fois qu'on juge que c'est satisfaisant, oui, on pourrait faire plus, on pourrait faire mieux, on pourrait améliorer le produit. Mais c'est vraiment un arbitrage de est-ce que c'est là où on a le plus d'impact ? Est-ce que c'est pas sur le truc d'à côté ? Et du coup, on assume de se dire, tant pis, la solution, elle est peut-être pas parfaite. Elle est qu'à 60, 80 % on va dire de son potentiel, mais il y a un autre enjeu à côté plus fort à l'état clé. Et des fois, on ne sait pas et moi, j'arrive en betting table en disant, on peut continuer sur ça, je pense que ça nous amène ça, il y a une conviction design qu'il faudrait continuer à itérer dessus, on peut aussi passer à autre chose. En fait, c'est quand même vous qui pariez, c'est votre boîte. Donc à la fin, dites-nous sur quoi vous voulez qu'on passe plus de temps. Et des fois, il y a des échanges aussi entre eux parce que le CTO n'est pas forcément d'accord avec le CPO et cetera, mais on sort du point en étant tous alignés sur ce qu'on fait.
[00:30:27] Bonjour. Vous m'entendez ?
[00:30:29] Oui. Ah ouais.
[00:30:31] Euh, merci pour la présentation, très intéressante. J'ai deux questions concernant le rôle du product owner. Euh j'ai pas bien compris comment vous jouez dans votre organisation. Et le la deuxième question concernant le support aux utilisateurs ou les problématiques de prod et comment vous les gérez, est-ce que vous en avez beaucoup ou pas ?
[00:30:53] Euh alors du coup, donc il n'y a pas de PO mais que des PM, donc que des product managers et pas de product owner. Euh c'est un peu ce que je disais, le product manager euh il gère un peu la strate de l'équipe où il va, il ne fait pas tant de delivery que ça, c'est les équipes tech sont vachement autonomes dessus. Et oui, on a une équipe support euh donc qui répond aux clients, hein, téléphone, message sur Freshdesk qui nous donne nos tickets support. Et pour le coup, la grosse nouveauté, c'est que soit c'est bloquant et on se dit un risque business et on corrige, soit on se dit bon bah, ça apporte un peu de friction, mais il y a une solution de contournement et entre guillemets, c'est pas grave et on ne corrige pas tout de suite, quoi. Donc il y a un peu ça de enfin c'est assumé, quoi.
[00:31:32] Ouais, par ici.
[00:31:35] Alors, euh ouais, merci pour le talk, très intéressant. Euh juste j'ai j'ai pas bien compris combien il y a d'équipes. Ça c'est un premier point et ensuite euh est-ce que tu as constaté des choses qui se sont standardisées un peu sur le fonctionnement euh pendant ces 6 semaines, soit en shaping, soit en build, euh entre les différentes équipes ou entre les différents PM. Est-ce qu'il y a des des toutes pratiques qui se sont qui ont émergé ?
[00:31:57] Alors, on est sept équipes, du coup, donc sept PM et cetera. Euh on est assez autonome sur la façon dont on veut s'organiser. Donc il y a des PM qui suivent plus le delivery que d'autres, on n'a pas forcément les mêmes outils. Après on se voit quand même en cool down pour un peu harmoniser les pratiques. Mais on a quand même une grosse autonomie sur ça. Donc on le fait nous parce que ça nous nourrit et qu'on en a envie, mais en aucun cas, c'est une obligation d'avoir la même méthodo pendant le cycle.
[00:32:26] Euh, merci beaucoup déjà pour le pour le talk. Euh moi, j'avais plutôt une question sur le le product orchestra dont tu parlais euh parce que je connais bien le product trio. Donc en fait, comment ça se passe plutôt au quotidien sur ce product orchestra ? Est-ce qu'il y a des événements entre eux cinq ? Donc je comprends euh comment ça se passe sur le terrain.
[00:32:43] Ouais, on fait un weekly orchestra à cinq et après moi, je fais pas mal de one-one. En gros, j'ai un one-one par semaine avec l'engineering manager, le designer, ouais, la data et les autres. Donc c'est quand même moi le point, on va dire, entre ces cinq-là, mais on se voit ensemble une fois par semaine en weekly et une fois par semaine avec toute l'équipe. Donc tech, expert métier, orchestra et tout.
[00:33:07] Bonjour. Merci pour la présentation. Moi, j'ai une petite question sur le le cycle qui est de 6 semaines, 8 semaines en tout et sur la partie apprentissage. Parce qu'on est beaucoup dans justement l'itération, apprendre vite et euh et du coup euh ajouter des itérations si nécessaire ou s'arrêter. Et je me demande, voilà, comment tu le fais parce que j'ai l'impression que c'est assez long et que l'apprentissage peut être du coup peut-être sur plusieurs cycles et euh et avoir une perte justement d'apprentissage ou de rapidité d'apprentissage.
[00:33:32] Ouais, bah parfois quand on est un peu convaincu d'un sujet, on se dit on fait une semaine de shape et en fait on est quasi convaincu que ça va être bon, donc on se dit on prépare du temps pour enchaîner avec 2 semaines de build par exemple. Sinon c'est une question un peu d'agencement de cycle, mais en effet, il faut quand même être assez fort, c'est ce que je disais sur les idées reviendront sur comment on recense tous ces insights, comment on s'en resserre au bon moment pour les ressortir et pas les oublier quoi. Donc il faut une certaine discipline quand même.
[00:33:58] Bonjour, merci beaucoup. Euh j'avais deux questions. La première, c'est euh tu disais qu'il fallait beaucoup de maturité aussi bien du côté produit que du côté tech. Et euh vous n'êtes pas petits, vous êtes quand même assez nombreux. Est-ce que il y a à ton avis une limite de scaling à partir duquel ça ne fonctionne plus ? Et la deuxième question, c'est est-ce que c'est compatible avec euh le télétravail ? Est-ce que vous faites en sorte de l'être tous sur place lors des bêtes et ainsi de suite ?
[00:34:27] Alors, c'est une bonne question parce que du coup, après COVID, bah comme tout le monde, Evaneos est passé en télétravail et a décidé de ne pas revenir forcément en présentiel. Donc on a soit un contrat hybride où on fait un peu comme on veut, on vient, soit un contrat full remote. Les développeurs sans surprise sont beaucoup en full remote, quasiment pas tous, mais en vrai, on a 30 % de la boîte qui est en full remote et c'est quasiment les équipes tech. Euh voilà, moi typiquement, tous mes développeurs sont à distance. Après, du coup, on a des rituels, on se retrouve sur Gather, qui est une plateforme en ligne un peu de plateforme enfin de bureau virtuel où on se parle tous les jours, il y a des rituels, mais ça fonctionne très bien et en fait, on doit revenir 2 jours sur place pendant les Evaneos Days, où là toute la boîte collectivement est là, a des rituels tous ensemble et tout le reste, on va dire, du mois, c'est un peu auto-organisation quoi. Et ta première question, pardon, c'était
[00:35:15] Est-ce que ça peut scaler ?
[00:35:16] Euh bah, du coup, pendant un cycle, on est quand même vraiment très concentré sur son équipe, ses problématiques. C'est un peu dur de voir ce que font les autres et d'être au courant. Donc la cool down sert à ça et après j'ai envie de dire nos leads servent à ça. On a un lead PM B2B, un lead PM B2C qui font aussi un peu cette synchro pour avoir une expérience uniforme du produit et savoir qui fait quoi. Donc je pense que ça pourrait scaler, mais que ça demanderait encore plus de rigueur peut-être sur ces rituels inter-équipes. Aujourd'hui, on n'a pas besoin d'en avoir tant que ça en fait.
[00:35:45] Bonjour, merci pour la présentation. J'ai une question, je suis pas sûr d'avoir bien compris le rôle du PM pendant le cycle de 6 semaines pour la partie tech, le build. Euh, je m'explique, du coup, euh, le 6 semaines, ça peut faire, ça fait pour moi un effet tunnel. Notamment si le PM, il est très concentré sur son rôle de PM, PM marketing. Et du coup, est-ce que c'est le one-one hebdomadaire avec le EM qui avec l'IM qui qui mitige ce risque ou est-ce que vous vous voyez plus fréquemment ? Parce que autrement, euh, voilà.
[00:36:05] Ah oui. Oui oui, on se voit toutes les semaines. Et en vrai, 6 semaines, mais c'est pas un tunnel dans le sens où sur 6 semaines, souvent on a quand même deux, trois sujets. Donc finalement, ça peut revenir à des sprints. Et pour autant, ça veut pas dire qu'il y a une livraison au bout de 6 semaines. Enfin, pour le coup, on est presque en livraison continue de si c'est prêt, c'est shipé, je regarde, je corrige, je fais des retours et ainsi de suite au fil de l'eau. C'est juste que c'est moins ma responsabilité en fait, ce en fait, typiquement, c'est pas moi qui suis censée tester, je le fais toujours parce que j'ai envie de voir à quoi ça ressemble et de temps en temps, je vois qu'il y a des choses. Mais en fait, les dev testent eux-mêmes et souvent, quand ils sont prêts à dev, ils ont un peu fait déjà cette phase, par exemple, de recette quoi. Et pareil, ils me posent des questions s'ils ont des questions sur la feature, ce qui n'était pas clair. Mais sinon ils s'auto-organisent, on va dire, si c'est clair pour découper et faire quoi. Mais on a des weekly et on se parle quand même toutes les semaines et après au bien sûr.
[00:37:06] Ouais, c'était quasiment la même question et j'ai je voulais l'approfondir. Euh parce que justement par rapport aux 6 semaines, euh en terme de cycle et de capacité d'évolution, parce que tu parlais, tu tu donnes un cap, tu donnes potentiellement des KPI. Et donc potentiellement combien d'itérations tu peux avoir sur un KPI purement business, hein, que que tu voudrais avoir et quel est l'équipe de enfin quel est ce nombre de cycles que l'équipe peut essayer de d'avoir.
[00:37:27] Ouais. En vrai, ça la réponse, ça va être selon derrière le ROI qu'on va avoir. Mais moi mon KPI, donc améliorer le taux de vente. En vrai, c'est sans fin, hein, je peux l'améliorer de plein de façons, enfin, j'ai fait une année dessus, je repars sur une deuxième année. Après, j'avais des proxy KPI plus précis, typiquement améliorer l'appétence d'un devis voyageur. Et ça, en fait, j'ai passé 4-5 cycles et des fois, justement, on avait un sujet hyper prometteur de proposer des alternatives aux voyageurs. On a fait un cycle en shape, on a fait un cycle en expérimentation et je pense qu'au prochain cycle, je vais reproposer une semaine d'appétit pour améliorer la fonctionnalité parce qu'en fait, elle est hyper porteuse, elle fonctionne bien et j'ai identifié des points où si on les corrige, bah, ça fonctionnera encore mieux. Mais par contre, si derrière on voit que ça ne marche pas, qu'il n'y a pas d'appétence, pas d'usage, on ne surinvestit pas dessus, quoi.
[00:38:17] Bonjour, merci pour ta présentation, c'est très intéressant. Euh je me posais la question sur, ça rejoint un petit peu l'idée du scaling, mais comment vous assurez qu'il y a une cohérence produit au niveau de la boîte entre les différentes, vous êtes sept équipes, si j'ai bien compris, 170 personnes au total. Euh, comment on fait dans les cool down, vous prenez le temps d'essayer d'assurer euh
[00:38:37] Bah, typiquement côté design, donc ils ont un design système très unifié, donc normalement, on va dire, il y a quand même une pâte, une identité Evaneos qui se retrouve partout. Les designers font des design review à chaque fois, normalement qu'il y a des nouvelles maquettes pour justement s'assurer de cette cohérence. Côté tech à chaque cool down et après nous on est censé un peu se parler. Mais pour le coup, c'est vrai, typiquement, on a l'espace perso Evaneos où interagissent plusieurs équipes parce que tu as ton espace perso avant le voyage, pendant après. Et il y a un moment en fait, on y allait tous de notre feature. On a rajouté tous un truc sur le même écran parce que moi ça servait mon objectif business, il y en a ça servait leur objectif. La page était moche, elle ressemblait à rien et on a pris la dernière summer cool down de cet été en disant, on pense cet espace perso comme un produit à part, quelle fonctionnalité on veut par rapport au voyage avant, après. Et là, typiquement, c'est un exemple de bah, ça a cohabité mal si on était chacun sur notre périmètre. Donc il a fallu faire un travail ensemble et on essaie d'identifier quand il y a ces sujets-là pour les travailler en cool down ou en summer cool down, quoi.
[00:39:34] Euh tu as dit qu'en fait c'était pas mal pour un produit déjà mature parce que du coup pour gérer les bugs, ça introduit trop de perturbations dans les cycles. Euh mais ça me paraît quand même plus fait pour développer un nouveau produit que sur un produit hyper mature où il y aurait plus beaucoup de fonctionnalités à rajouter. Je sais pas, c'est quoi ton point de vue là-dessus ? Sur le sa place dans le cycle de vie d'un produit ?
[00:39:54] Hmm. Bah, je pense qu'au tout tout début, quand il y a rien, qu'on veut poquer, c'est un peu tôt. Parce que 6 semaines en fait, c'est long, enfin, en fait, il faut que tester que l'heure des des un feedback plus rapide, quoi. Euh après, si tu es très mature, je pense que ça dépend de l'état du produit et de la stack technique, quoi. Mais ouais. Désolé, je ne sais pas plus.
[00:40:13] Euh merci beaucoup pour ta présentation, c'était très intéressant. J'ai une question, je voulais revenir sur l'organisation pendant les phases de shape et de build. Euh ma question c'était est-ce que euh pendant les phases de shape, il n'y a que le l'orchestra qui shape pendant que les développeurs sont tout le temps en build ou alors est-ce que les développeurs participent aussi au shape puis ensuite toute l'équipe euh en build ? Comment vous vous partagez euh les les deux cycles ?
[00:40:36] Ouais. Donc dans l'idée euh c'est quand même plus shape orchestra, on va dire et build développeurs. Mais des fois, on a besoin de ressources techniques sur le shape. Ou il y a plein de devs qui ont aussi envie d'en fait, de contribuer à cette réflexion aux ateliers et on essaie de l'anticiper à la betting table. Donc en fait, c'est ce que je montrais là sur nos pitch formaté. On a un encart ressources et des fois, on dit on aura besoin de quelqu'un d'une autre communauté, d'une autre équipe, on aura besoin de temps front, on aura besoin de temps back et on dit du coup, peut-être 2 jours d'appétit, enfin, grosso modo, mais on prend en compte ce temps parce qu'il y a tout l'aspect comment tu construis un cycle. Du coup, bah, tu as plein d'idées, tu as 6 semaines, donc qu'est-ce qui rentre, qu'est-ce qui rentre pas avec les vacances, la capa et cetera à faire quand même, quoi.
[00:41:19] Oui, moi je voulais savoir.
[00:40:32] euh possible le shape, puis ensuite toute l'équipe euh en bulle, comment vous vous partagez euh les deux cycles ?
[00:40:38] Donc dans l'idée, euh c'est quand même plus Shape Orchestra, on va dire et build développeur, mais des fois on a besoin de ressources techniques sur le shape ou il y a plein de dev qui ont aussi envie d'en fait de contribuer à cette réflexion aux ateliers et on essaie de l'anticiper à la betting table. Donc en fait, c'est ce que je montrais là sur nos pitch formatés, on a un encart ressource et des fois on dit on aura besoin de quelqu'un d'une autre communauté, d'une autre équipe, on aura besoin de temps front, on aura besoin de temps bac et on dit du coup peut-être deux jours d'appétit enfin grosso modo, mais on prend en compte ce temps parce qu'il y a tout l'aspect comment tu construis un cycle. Du coup bah tu as plein d'idées, tu as 6 semaines, donc qu'est-ce qui rentre, qu'est-ce qui rentre pas avec les vacances la capa et cetera à faire quand même quoi.
[00:41:19] Oui, moi je voulais savoir, euh vous avez parlé de plusieurs types de shape euh le constructif, c'est ça ou je sais pas. exploratoire et tout, ouais. Euh ça c'est des phases qui s'enchaînent ou c'est c'est des types de shape différents tout simplement. C'est-à-dire que selon le sujet, ben on va partir sur un truc plus technique ou plus conductif, je crois.
[00:41:38] Oui, ça.
[00:41:39] Voilà. Conduc.
[00:41:40] Euh ça dépend. En fait, on va dire que dans un cycle classique idéal, on explore. Donc on a plein d'opportunités, on se dit celle-là, elle a l'air plus prometteuse, donc on fait un shape conductif. C'est validé, on part en build, en vrai le shape technique on l'exploite pas tant que ça, j'avoue. Euh après parfois du coup, ça fait un cycle un peu long, exploration, conductif, build. Ça nous arrive d'avoir des fortes convictions, d'avoir déjà été ré vu que le produit existe, donc en fait on fait que du conductif du build. Ça nous arrive aussi pour des petits sujets de se dire bah en fait on chip, on build, on va pas faire un AB test, ça sert à rien quoi. Donc ouais, vraiment. Et des fois aussi de la confiance qu'ont nos lead dans ça et à quel point ils sont prêts à y aller ou pas quoi.
[00:42:32] deux questions en une. est-ce que ça arrive qu'en sortie de betting table, vous ayez tout jeté, enfin que on dise non à toutes tes idées ? et et c'est un peu lié, est-ce que du coup s'il y a eu même si c'est pas ta nor star mais si on se rend compte qu'il y a vraiment deux idées incroyables, est-ce que on peut se permettre de changer un peu les périmètres d'équipe ?
[00:42:51] Ouais, euh alors tout jeter non. Mais moi typiquement, ça m'est arrivé, on proposait quelque chose de très construit très bien et en fait nos notre leadership avait envie qu'on aille explorer autre chose parce qu'ils avaient l'impression que c'était hyper prometteur la coconstruction, ils voulaient qu'on y aille et nous on a eu un une attitude plus raisonnée en disant bah ça on a continué, on veut itérer dessus, on sait que ça un peu. Et ils nous ont un peu challengé sur est-ce que vous voulez pas switcher maintenant, c'est le début de l'année, explorer, prenez des risques, c'est pas grave si ça marche pas, s'il y a aucun héroïsme, mais on a envie de savoir. Donc du coup, on a un peu tourné autour et on a changé des pitchs quoi. Et ton autre question, c'était Ah oui, est-ce qu'on change ? Bah en fait, on fonctionne vachement par semestre, donc un semestre c'est trois cycles et l'autre semestre trois. Et typiquement nous l'année dernière, d'un semestre à l'autre, on a tous légèrement pivoté. Parce qu'en fait, on apprenait des choses au fur et à mesure, donc on s'est dit le deuxième semestre, il sera teinté plus voyageur, plus ceci et ouais. Et là pareil d'une année à l'autre, on refait un peu la strat produit, donc même si j'ai toujours le même KPI à faire bouger, c'est plus forcément le même angle derrière pour l'attaquer quoi.
[00:44:05] Est-ce qu'il y a certains moments, il pourrait y avoir des sujets imposés euh venu de plus haut, par exemple, un sujet de sécurité qu'il faut faire, personne n'a envie parce que ça plaît à personne, mais il y a pas le choix. Ou euh typiquement dans ma boîte, on est en train de migrer dans le cloud, bon bah c'est un enjeu business très fort, on est dessus depuis plus de 6 mois et on encore pour un long temps, euh voilà, c'est majeur par rapport à tout le reste, clairement tous les sujets produits dégagent. Est-ce que ça ça peut rentrer dans ce cadre-là ?
[00:44:36] Alors on a ça, je l'ai pas dit, une équipe plateforme ou du coup ça un peu les up, Ccu et cetera qui va peut-être prendre en compte un peu ces sujets justement pour qu'on ait toujours la bonne stack technique pour le faire. Et après il y avait des sujets de grosse migration de et tout front, bon les il l'ont fait de cool down à un cool down. Donc en fait je pense que ça aurait pu être fait en peut-être deux trois semaines collées, mais comme ça s'est étalé à chaque cool down parce qu'on voulait avoir nos cycles, finalement ça leur a pris 3 4 mois. Après je pense que c'était pas un souci, c'est juste que on avait acté que ça prendrait plus de temps quoi. Mais ouais.
[00:45:14] J'ai une autre question, est-ce qu'il vous est arrivé de louper un cycle de build ? la fin du build vous répondez pas à la problématique ou je ne sais quoi.
[00:45:22] Ça nous est arrivé de pas mettre assez d'appétit au regard de la complexité technique. Euh de se dire typiquement on avait des irritants et on voulait les corriger parce qu'on savait que c'était quand même compliqué dans l'expérience agent mais on ne voulait pas y consacrer trop de temps, ça rapporte pas trop de bise, on s'était dit deux semaines. Côté tech, ils avaient des risques rapidement en disant OK, ça tient, en commençant, on s'est rendu compte, non, ça tient pas en deux semaines. Euh et là du coup ce qu'on a fait, c'est qu'on a quand même levé les stylos à la fin du cycle, mais au prochain cycle on a racheté du temps, on a dit bah en fait voilà, on est désolé, on pensait arriver à ça, bon bah voilà, mal scoper, on a envie de racheter, on veut une semaine en plus quoi. Donc c'est pour ça que je dis en fait, c'est l'appétit, c'est quel temps on veut y prendre, mais il faut quand même être conscient du temps que ça met quoi, c'est un petit équilibre à trouver.
[00:46:14] Et du coup tu as un peu répondu, je me demandais si vous trichiez un peu dans ces cas-là donc là tu as avoué que vous pouviez tricher un peu. C'est-à-dire que là dans ce cas-là, vous avez remis à la betting table un sujet où peut-être c'était pas celui qui avait le meilleur héroïne mais vous dites on le finit pour une semaine. Et ma question corolaire c'est est-ce que des fois tu as de la frustration de pas avoir fini quelque chose justement avec ce système où c'est très orienté business, ta dette fonctionnelle des fois tu la résous jamais, comment tu le vis ?
[00:46:41] Moi j'ai pas trop cette frustration là mais je pense que les tex l'ont parfois un peu de du coup on avait deux trois semaines d'appétit, on l'a fait, c'est bien mais on aurait pu le faire bien mieux, on aurait pu refactorer plus et cetera donc les techs l'ont et les designers parfois un peu aussi de bah du coup vu qu'on a été contraint l'expérience, elle est bien, on sait que vu ce qui se fait aujourd'hui, pourrait y avoir du delight, ça pourrait être wahou, ça pourrait être mieux. Euh moi en tant que PM vu que j'ai tellement tellement d'enjeux d'entrant et tout, je me dis si c'est déjà bien, ça me va de passer à autre chose et je fais mon deuil, on va dire peut-être plus rapidement que les autres quoi.
[00:47:18] Est-ce que tu est-ce que ça te semblerait réalisable de se dire tout le monde n'est pas en shape up et j'ai peut-être justement des équipes et ça peut être tournant ou autre mais peut-être plus orienté à traiter les retours utilisateurs ou qui sont moins dans un objectif très business et plutôt de finioler ou ce genre de chose.
[00:47:35] Tu crois ? Bah je pense que ce qui se passerait c'est que peut-être enfin je sais pas s'il y a des des équipes qui naturellement auraient envie de traiter que des retours utilisateurs, mais après enfin pourquoi pas si c'était imposé et tout. Nous en vrai ça tourne bien, honnêtement, c'était un peu une de mes inquiétudes avant de rejoindre Revenos de OK le PM fait pas de delivery, gère pas les bugs et il y en a toutes les 8 semaines genre comment ça marche ? Bah ça fonctionne, après je connais pas la stack technique et cetera mais ça fonctionne bien et je pense que ça pousse aussi les équipes support à bien qualifier les bugs. S'ils sont importants, on les corrige et c'est ce que je disais sinon le produit il est pas parfait mais en fait ce qui fonctionne pas bien, c'est des petites choses, on se dit c'est pas grave. En fait ça n'empêche pas de réserver un voyage, d'avoir une bonne expérience de voyage, d'être en sécurité et de rentrer, en fait on est assez au clair sur quels sont nos objectifs principaux et le reste on fait le deuil quoi, c'est c'est pas grave.
[00:48:25] On attaque les deux dernières questions.
[00:48:28] Merci.
[00:48:32] Alors j'ai deux questions, désolé. Euh la première, c'est est-ce que vos développeurs sont full stack ? Et la seconde, c'est est-ce que il vous arrive de constituer des équipes éphémères parce que vous avez besoin d'expertise particulière ?
[00:48:47] Alors non, ils sont pas full stack, alors que moi avant j'avais beaucoup bossé avec des dev full stack, on a vraiment communauté front, communauté back, je pense que c'est aussi pour ça qu'ils sont assez senior et très expérimentés sur leur truc. Mais ce qui fait que si moi j'ai un bac en vacances ou deux, bah ils sont pas interchangeables, donc ça nécessite une préparation avant cycle pour savoir quelle ressource j'ai. Et après le côté équipe éphémère pendant les cool down, oui beaucoup, en fait du coup s'il y a des petits projets comme ça, trois 4 jours de développement sur un sujet spécifique, il se monte des petites équipes et en fait tous les dev se connaissent très bien du coup parce que à chaque cool down, ils bossent un peu tous ensemble ou avec des personnes différentes en fait.
[00:49:24] Du coup la la dernière question, c'est quoi le nombre de sujets shapés qui finissent en build ? Est-ce que il y a beaucoup de sujets qui sont mis de côté, qui sont jamais sur lequel en phase de bête, on met on met rien dessus ou pas.
[00:49:38] Ben c'est sûr qu'on shape beaucoup plus qu'on build, j'ai pas de ratio en tête. Mais on va dire des fois à l'issue d'un shape, moi j'ai détecté 4 5 opportunités et en fait on va se concentrer sur une et ça prend du temps donc trois cycles après je serai peut-être sur la même ou sur la deuxième, alors j'en ai toujours deux trois en stock. Mais normalement si j'ai bien fait mon shape, elles étaient moins importantes que les autres, donc tant pis entre guillemets. Euh et après de ce qu'ils se font vraiment recaler en betting table, normalement ça n'arrive pas de temps parce qu'il y a un peu ce petit travail de préparation en amont où tu as quand même parlé à tes lead, ton leadership, tu les as préparé. En fait l'idée aussi c'est que des fois tu leur donnes on envoie un préid, donc en fait ils disent aussi la doc avant pour avoir une idée de quelle interview, quelle data et pourquoi on propose ce choix. En fait l'idée c'est qu'en betting table on réexplique pas pourquoi on veut proposer ça mais qu'ils aient eu la doc en amont quoi. Donc il y a cette pédagogie avant oui.
[00:50:28] Merci Chloé.
[00:50:29] Merci. Ah.

Transcription