et ben en tout cas merci beaucoup de m'accueillir aussi bien la mêl puis vous d'avoir tout organisé monter ce enfin de faire vivre ce ce Meetup là en tout cas c'est extra c'est vraiment extra je suis très contente de pouvoir partager avec la communauté produit aujourd'hui à Toulouse euh donc moi je viens vous parler retour d'expérience sur la mise en place d'une orga produit dans une start-up de la met donc moi je suis dans une start-up de la Medtech euh la start-up dans laquelle je suis c'est medexprime et medexprime on travaille sur la donnée de santé euh pourquoi la donnée de santé à quoi ça sert en fait juste vous avez besoin de comprendre un tout petit peu le produit enfin comment dire j'ai envie d'introduire un peu le produit pour que vous vous ayez une idée de en place derrière de bah quand on discute organisation au niveau de la quel est l'impact avec le produit sur lequel nous on travaille mais ça enfin voilà évidemment ça peut s'appliquer un peu partout et donc ici euh moi mesexprim m'ont fait donc de la donnée de santé de la donnée de santé là si je vais sur un cas enfin tout le monde là quand on se retrouve avec à être malade on va à l'hôpital on va à l'hôpital on va voir un spécialiste et le spécialiste il est il va essayer d'appliquer les meilleurs protocoles de soins qui existe et donc il y a un suivi individuel du patient qui est super on est très très bien là on est en France en plus au niveau de recherche il y a pas de souci on est super bien par contre ce qu'il faut se rendre compte c'est que derrière bah c'est de la donnée qui est individuelle et il y a que dans hop attendez il y a que dans 15 % des cas les essais cliniques où cette donnée au niveau du patient on va essayer de l'avir dans sa globalité est-ce que tous les patients qui reçoivent ce traitement là et ben est-ce qu'ils ont les mêmes effets secondaires est-ce que ça marche bien ça marche pas et cetera ça on le regarde que dans un petit lot de patient donc au final il y a 85 % des données médicales des données hospitalières où on va pas Leser regarder si ben en fait tous les gens qui ont un cancer du sein et qui sont traités d'abord par radiothérapie et qui appliquent telle crème machin truc bidule sur les les ils ont les mêmes effets secondaires ou pas on regarde on regarde que quand on est dans un protocole de recherche particulier dans les essaiis cliniques donc là l'idée de moi de ma ma mon entreprise nous on vient aider là-dessus à se dire bah toutes ces données elles sont pertinentes elles sont intéressantes pour la recherche la recherche aussi bien dans les établissements de santé la recherche au niveau académique enfin voilà au niveau des universités européennes et cetera et les recherche au niveau des industriels aussi tout le monde a besoin de ces données là et donc avoir ces données disponibles bah c'est le top donc nous on a une solution qui permet d'aller sur les sites de d'agréger la donnée et de l'anonymiser de la rendre disponible pour la recherche donc voilà en gros ce qu'on fait et làdedans bah c'est une start-up donc j'avais envie de moins de revenir sur le côté orga quand même on est ici on parler plutôt orga produit une petite start-up qui démarre ça démarre avec des bonnes idées d'accord donc des bonnes idées là moi dans le cas je décris c'est notre cas particulier mais je suis là pour faire le retour d'expérience donc voilà je parle de notre cas particulier puis on on en enfin on en discutera après de savoir si vous vous y retrouvez ou pas mais donc c'est une fondatrice un développeur des bonnes idées qu'est-ce qu'on fait on va les développer une fondatrice qui a des qui a des compétences en biomédical donc ce se dire bah moi je sais qu'aller chercher les images de les données d'imagerie dans les hôpitaux c'est super compliqué c'est un serveur à part machin et les récupérer en l'eau et ça moi je pense qu'il y a un vrai voilà il y a un vrai une vraie opportunité là-dessus donc elle est partie là-dessus je sais aller rechercher requetter des données les extraire en l'eau les anonymiser machin et donc elle est partie c'est top derrière bah une fois qu'on a eu une bonne idée de produit un peu de un commercial d'accord qui arrive et qui se dit bon comment le business model derrière qu'est-ce qu'on en fait fait et puis comme ça petit à petit ce qui s'est passé dans dans l'entreprise c'était de se dire d'abord ils ont recruté des gens plutôt multicasquette qui savaient un peu faire de tout qui étaient là qui ont fait du Dav du produit du chef de projet du support voilà que des gens un peu multicasquette ensuite ce qui s'est passé l'étape suivante c'est on s'est dit bon ben maintenant on a besoin de gens qui ont vraiment des compétences bien spécifiques et donc on a été chercher plutôt des spécialistes des spécialistes bah voilà mes bleus là c'est du développeur de la data science des chefs de projet mais qui faisaient que ça en fait ça y est maintenant on a identifié qu'on a des vrais besoins et des personnes qu'on peut occuper à 100 % sur un rôle bien précis et puis bah tant qu'on y est maintenant on se dit bon tant qu'à faire on commence à être nombreux faisons des équipes et donc voilà on se retrouve la première équipe chez nous ça a été support chef de projet et puis après ben on va classer un peu les gens développeurs produit data science et c'est parti et puis c'est parti puis après on se dit bon benah maintenant comment on fait en fait comment on fait pour faire grossir les choses comment on fait pour qu'est-ce que est-ce que ça marche parce qu'en fait ça ça s'est construit c'était complètement empirique ça s'est fait un un peu bah on a recruté la bonne personne au bon moment qui correspond à un besoin mais comment est-ce qu'on construit une entité des équipes en tant que T bah ça ça avait pas du tout été réfléchi en fait au départ ça s'est fait tout s'est fait naturellement petit à petit sans avoir une vraie euh question de pourquoi est-ce qu'on fait ça et où est-ce qu'on veut aller euh donc ici c'est euh pourquoi est-ce qu'on s'est posé les questions sur sur l'organisation bah c'est de se dire B en fait on a l'état des lieux c'était de se dire B on a quand même créé un peu des silos chacun son job dans son équipe et puis comment on fait pour que les gens bossent bien ensemble collaborent euh communiqu quel honership aussi parce qu'en fait on avait une belle équipe produit avec chacun des expertises mais pas forcément un produit voilà on avait des experts métier qu'on avait dit bon toi tu es produit ok voilà un radiologue par exemple voilà moi je suis dans l' imagerie un radiologue quelqu'un qui fait de l'anapath anatomopathologie et Machin mais pas forcément bah comment ils se placent eux par rapport au produits donc les questions sont des silos qu'est-ce qu'on veut faire et cetera il y a de la place devant vas-y installer au niveau donc du produit on a des experts métiers mais pas vraiment des gens qui sont product honur product manager et au niveau des développeurs bah ils ont été recrutés à chaque fois pour une fonction ben particulière et donc ils sont presque associés à une fonction ou une fonctionnalité ou un produit ce que vous pouvez retrouver chez vous aussi mais donc on se retrouve avec des gens qui sont vraiment bah dans une case est-ce que c'est la bonne case comment on fait pour grand pour sortir de cette case et cetera c'est pas simple et puis après donc se dire bah start-up scaleup licorne enfin vous savez la totale là comme on se dit qu'on va grossir mais comment on va faire pour grossir donc donc une fois qu'on a fait ce constat là il y a des inspirations qui on peut retrouver dans la littérature pas mal de choses nous les inspirations elles ont été euh réfléchies avec bah avec Olivier qui est là juste dans la salle qui est intervenu pendant pendant de mois dans l'entreprise aussi avec lequel on a construit un peu comment on allait faire construire cette organisation produit et donc les aspirations sont d'une part sur team topology si vous voulez savoir des choses sur team topology vraiment il y a plein de trucs sur Internet vous voulez une petite intro là il y a scruml la chaîne Youtube qui a fait une petite intro qui est vraiment sympa le bouquin il est pas très épais tout ça vous pouvez y aller l'idée de se dire c'est que dans Team topology il y a quatre types d'équipes ces quatre types d'équipes c'est le premier c'est streamline in team et donc c'est de se dire en fait c'est des équipes qui travaillent sur un flux de valeur sur vraiment une fonctional c'est la valeur business la valeur métier qu'on va apporter enabling team c'est ceux qui vont apporter du support aux autres coaching mentorat et cetera vous imaginez bien que dans une start-up en fait il y en a pas enfin il faut avoir une certaine taille quand même pour avoir ce type d'équipe euh la complicated sub system team celle où on dit attention ça à éviter c'est en dernière limite parce qu'en fait c'est c'est l'équipe où en fait si on est sur un sujet elle est pertinente si on est vraiment sur un sujet bien identifié qui est très complexe qui est nécessité par d'autres équipes s je sais pas moi la définition d'un dictionnaire enfin quelque chose qui est vraiment en tant que tel on a on arrive pas à se dire bon le flux de valeur il est là et mais ça tout le monde enfin on en a besoin mais il faut pas que ça devienne de se dire bah chaque équipe elle est vraiment super compliquée elle fait son petit morceau en fait faut vraiment réfléchir quand même plus de valeur donc le but c'est vraiment d'aller sur cette cette première topologie et puis le dernier c'est la plateforme team c'est l'équipe sont les équipes qui fournissent un service style l'IT le DevOps et cetera et donc ils sont en support des autres équipes donc ici startup petit on est 30 40 le but c'est quand même vraiment de de de trouver quels sont les streamite teams qui peuvent nous correspondre et donc la deuxème inspiration là-dessus pareil si vous voulez la littérature il y a plein de choses à aller lire voir et cetera euh la loi de Conway voilà si ça bon ça se voit pas très bien mais si je pourrais partager mes slides vous pouvez écouter la conf de Julien topsu làdessus sur le sujet moi je la trouve vraiment très sympa très voilà pour rentrer dans la matière et donc la loi de Conway c'est C c'est une loi empirique qui dit que bah au final on a le logiciel qui correspond à notre organisation donc suivant comment on est organiser benah on va se retrouver avec un logiciel de on a des organisations par pays ben on va avoir des modules logiciels derrière par pays enfin voilà donc c'est de se dire bah en fait on peut enfin l'architecture logicielle quoi qu'on fasse au final elle se elle se retrouve calquée sur l'organisation et donc il y a la loi Conway inverse qui dit aussi au final bah si vous voulez savoir comment vous organiseer c'est un peu l'idée bah essayez de de réfléchir quelle devrait être votre architecture produit pour en déduire l'organisation donc nous on est vraiment parti de ce concept là de se dire bah si on réfléchit notre organisation donc ouais si on repense notre architecture produit si on met au clair vraiment sur c'est quoi notre architecture produit et ben derrière on pourra en déduire notre organisation qui est l'organisation la plus adaptée et donc vraiment euh ce qu'on a fait en entreprise le comme point de départ c'était des ateliers qui amènent à réfléchir vraiment en profondeur l'architecture produit pour que l'organisation qui en découle pour faire évoluer l'entreprise vers quelque chose qui paraisse naturel pour tout le monde donc ce qu'on a mis en place là Olivier quand même faut que je te cite avec Olivier c'est donc trois ateliers de 2 heures qui se sont étalés sur un mois donc en gros c'était à peu près tous les 15 jours avec donc trois ateliers séquentiels un le premier ça a été le but ça a été définir le redéfinir d'avoir une vision claire du métier de l'entreprise et on a essayé d'embarquer le plus de monde possible de enfin plus de monde non d'avoir des représentants de de du plus de services possibles de l'entreprise donc commerce euh support donc pour nous le support téléphonique ceux qui viennent interviennent et puis corrigent les problèmes sur site le delivery qui va être ceux qui déploi et qui se servent de nos produits aussi sur sur site les développeurs et prod produ honur produ manager et donc voilà le but c'était d'identifier les principaux use case comment on a fait je le dis après je vous dis juste d'abord les trois étapes puis après je détaille un peu sur le comment ensuite on a fait un deuxème atelier qui était l'identification de l'AR l'architecture produit là on a commencé à ressérrer un petit peu on est resté on est revenu un peu sur ce qui était un peu plus technique genre les commerciaux ils nous ont bien aidé pour les US cas puis là on rentre un peu dans la technique pour identifier nos composants produits et puis le dernier là complètement avec juste l'équipe développeur product honur product manager c'était sur Tester dépendance estce qu'on a identifié les bons composants qui sont bien autonomes les uns et les autres donc comment on a fait ça on s'est le premier atelier on s'est projeté sur un autre monde en fait he se dire que il faut se décaler un peu pour pouvoir réfléchir autrement et vraiment identifier ce qui apporte de la valeur en faisant abstraction de tout ce qui est les technos disponibles enfin je sais pas les framework les machins les outils et cetera ça on s'en fiche on s'adaptera après donc c'est vraiment qu'est-ce qu' a de la valeur chez nous dans notre entreprise c'est quoi les use cas principaux qui fait que on sait que si on arrive à faire ça derrière on a de la valeur on a du business donc pour ça l'histoire qui a été inventée c'est qui a été construite ça a été de se dire finalement il y a pas eu la Seconde Guerre mondiale donc il y a pas eu l'avènement de toute la partie de tous les ordinateurs et ce qui a été mis en place c'était la mécanographie qui existait avant c'était avec les petites cartes troué là donc voilà c'est de se dire bon on est vraiment dans autre chose on se décale il y a pas les ordinateurs donc arrêtez de réfléchir à for c'est quoi la valeur de notre entreprise si on sort de sort de la partie vraiment technique et donc là ce qu'on leur a demandé de produire ça va être une brochure publicitaire de l'entreprise à la mode un peu produit box voilà et donc derrière bah qu'est-ce que qu'est-ce que vous produisez donc voilà c'était ça je voyz le travail de groupe on leur a demandé voilà réder la brochure la brochure de l'entreprise et puis présenter les atouts les promesses bénéfice de de ce qu'on peut apporter et donc on s'est retrouvait avec voilà un petit mirau des des brochures et avec donc voilà des réflexions évidemment on avait mélangé tout le monde on avait pas une équipe donc on avait trois équipes de C je crois 5ou quelque chose comme ça on avait dans chaque équipe des représentants un peu d'un peu tous les services et donc ce que ça a donné derrière c'était assez intéressant c'est de se dire qu'en fait les trois équipes ont identifié vraiment un seul et même use case principal au final donc déjà on s'est dit bon bah parce que c'était même pas quelque chose qui était sûr en fait par qu' on apporte de la valeur il y a quand même plusurs moyens de le faire ENF là sur la donnée ça peut être aussi euh enfin voilà je je vais pas le détailler ici mais il y avait on se posait des questions en tout cas et là ce qui est ressorti c'est vraiment un use case principal c'est celui-là qui est a traité en premier et donc ça c'était vraiment intéressant pour nous euh cet atelier il a permis vraiment de se projeter sans contrainte technique donc on a vraiment mis ça de côté et en même temps ça pas été si simple de se projeter dans un monde diff différencein voilà je c'était s'imaginer dans un monde sans informatique alors qu'on travaille dans l'informatique bon ça ça demande un peu quand même de ah oui mais qu'est-ce que qu'est-ce que j'ai le droit d'imaginer en fait ah oui c'est ça c'est rigolo je voulais je vis la faire la petite c'est on est dans un monde du milieu médical le milieu médical c'est aussi super sécurisé rgpd et cetera et donc quand même il y a le transport nous de la donnée le but c'est quand même d'amener de la donnée d'un endroit un autre on avait des doberman par exemple ils se sont dit ahouais mais la sécurité c'est super important donc comment on le fait là ben en fait ils sont avec leurs charrettes avec toutes leurs cartes perforées là et un doberman pour être sûr de pas se faire piquer la donnée et qu'on respecte tout donc voilà euh ce que ça a permis donc sortir du cadre faire émerger l'essentiel pour nous les difficulté qu'on qu'on a pu avoir c'est aussi quand même donc de se projeter dans un monde différent mais ça c'était le c'était le but donc bon bah oui c'est compliqué mais en même temps bah allez-y lâchez-vous ne pas comprendre la finalité parce qu'après ce qui est toujours compliqué dans ce type de d'atelier c'est d'en dire mais pas trop en dire parce qu'on veut aussi que ce soit en mode brainstorming créativité euh il faut évidemment avoir une vision de là où on va aller mais nous on veut pas non plus enfin on voulait pas non plus mettre un cadre trop trop contraint donc on a expliqué sans donner tous les détails et donc peut-être que ça a dérangé un peu certains et puis après ça pe êté si simple que ça de s'aligner entre les différents services et donc ça c'est rigolo quand même dans une boîte quand on est que 30 et qu'on se dit ah on n pas tout à fait la même vision c'est toujours utile de se dire ah c'est c'est vraiment c'est quoi donc voilà donc ça c'était la première partie de l'atelier qui nous a permis de sortir avec un use case c'est ce use case là qu'on veut traiter donc le deuxième atelier maintenant ça on a ce cas là ok quelle est l'architecture produit euh donc on a besoin de mettre en place pour répondre à ce use case et donc là euh on est parti sur euh réaliser donc un diagramme de séquence de flux de valeur de l'entreprise ça veut dire quoi ça donc là on est passé c'est pour ça qu'on avec des gens un peu plus techniques quand même donc là vous avez l'explication ici un diagramme de séquence c'est quoi je vais vous dire les définition Wikipédia je serai plus à l'aise donc là un diagramme de séquence c'est la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans en UML ok si je vous donne un exemple alors c'est un petit exemple que j'ai repompé sur Microsoft donc c'est pour ça qu'il y a exchange dans dans le machin il y a un serveur Exchange si on veut téléphoner à quelqu'un qu'est-ce qui se passe ben on a celui qui téléphone la plan celui qui va répondre au téléphone le destinataire et donc là dans notre diagramme de séquence ben en fait on va on va lister par ordre chronologique toutes les actions et toutes les interactions donc j'ai celui qui appelle je vais avoir mon serveur téléphonique je vais avoir aussi un répertoire qui va permettre d'avoir le numéro de téléphone et d'appeler derrière la bonne personne et donc là on va se retrouver à dire par exemple bah décrocher le serveur répond bah la tonalité maintenant que j'ai la tonalité je tape mon numéro de téléphone enfin voilà et donc petit à petit on a comme ça identifié quels sont les acteurs et quelles sont les actions temporelles qui sont nécessaires et donc bah c'est ça qu'on leur a demandé on leur a dit maintenant on connaît le use case voilà le use case on l'a retravaillé c'est celui-là on l'a vu ensemble essayer de définir ces diagrammes de séquence et pourquoi est-ce qu'on a demandé ça c'était pour ce qui nous intéressait là-dedans c'était vraiment d'identifier tous ces acteurs ici c'était de se dire quells sont là les les jobs qu'on on a appelé ça des bureaux en fait imaginez-vous des personnes dans une même pièce qui peuvent globalement travailler ensemble entre eux et qui vont juste aller chercher de la donnée enfin aller chercher des infos et interag avec les autres mais ils ont leur euh leur pertinence à être entre eux en fait donc ce ce qu'on a appelé un bureau et qui dans les diagrames de séquence s'appelle un acteur euh et donc voilà c'est le job qu'ils ont fait euh et ça a été vraiment enfin voilà ça nous a donné des choses un peu compliquées mais c'est le concept en fait hein de se dire bah c'est quoi les différents acteurs mais ce qui est intéressant c'est de se dire que trois équipes de nouveau ont travaillé trois des équipes ont quand même à peu près redéfini les je dirais pas à peu près ils ont identifier les ce que nous on appelait les bureaux donc les mêmes acteurs les mêmes composants qui étaient importants et il y en a un un groupe je crois qu'il y en avait mis un en plus mais qui était genre les 16 ou je sais plus ce que c'était mais c'est pas important mais c'était de se dire on a vraiment réussi à se dire ah mais tiens en fait ça c'est un vrai rôle utile et clé dans notre notre notre flux de valeur donc c'était vraiment intéressant de de pouvoir identifier ça et donc nous de pouvoir identifier ce qui est ce qui représente dans notre architecture produit dès qu'on ant qu'il soit autonome donc voilà conclusion là-dessus c'est ça nous permet d'identifier ce qui peut fonctionner de manière autonome l'idée qu' y a derrière quand même c'est vraiment un bureau c'est un produit un produit ça sera une équipe sû enfin c'est comme ça qu'on commencer à se projeter à se dire bon bah est-ce que ça va ça va le faire on on va voir et puis après ce qu'il faut se rendre compte c'est comme nos ateliers il étaient tous les 15 jours on n pas fait ça tassé en de jours il y a eu de la discussion en interne entre les deux en fait entre chaque atelier c'était ah mais oui mais qu'est-ce a compris pourquoi et ça et qu'est-ce que tu en penses et donc tout ce process de discussion en off il était aussi très intéressant euh les diff difficulté c'est de décider du bon niveau de détail on descend jusquou dans la liste des actions des interactions et cetera et puis euh toujours de se projeter on en fait quoi maintenant ça va servir à quoi comment comment on fait quoi et donc dernier atelier c'était euh bon bah on est censé avoir trouvé les composants autonomes qui sont est-ce que c'est vraiment est-ce que c'est vrai que c'est vraiment des composants qui sont autonomux et qui fonctionnent bien en autonomie justement et donc là la question de de poser aux participants qui étaient développeurs et les PO c'est si vous devez définir des API c'est quoi en fait quelles vont être justement euh les les les interactions entre un bureau et un autre euh et donc voilà ça le but était de vérifier que c'était pas si on se retrouvait avec quelque chose on avait dans tous les sens qui partait dans les c'est que on avait quelque chose qui était trop complexe et qu'il y avait des dépendances et donc là on essayie de voir si ce côté cette côté complexité bah où on en était et donc on a pu voilà ils ont fait aussi donc ce même travail en a certains qui sont repartis du diagramme de séquence d'autres qui ont fait en version posti mais on a pu se rendre compte que globalement bah ça pass ça passe sa enfin c'est fonctionnel les API on arrive à les imaginer et sur quelque chose de d'assez simple donc voilà on arrive sur une une architecture qui est pas trop complexe et qui paraît pertinente euh ça nous a permis donc confirmer l'indépendance de ces compos ce qu'on avait identifié comme des composants dans les bureaux et puis ouais tout n'était pas rose non plus dans les points positifs on peut dire ça nous a permis d'identifier aussi certaines fonctionnalités où on avait besoin de clarifier un peu parce que bah en fait on savait pas trop où le mettre ou est-ce que c'était vraiment là pas là ça fait quoi en fait ce truc là qu'on a toujours dans notre backlog c'est pas voà donc bah voilà le côté postit rouge là qu'on met sur le côté en disant bah il faudra le traiter mais on peut pas tout faire aujourd'hui et donc donc voilà ça nous a permis les identifier et en même temps c'est un peu toujours perturbant de se dire enfin quand on est là en atelier en train de se dire en fait ça je sais même pas où le mettre quoi donc est-ce que c'est normal ou pas bon ça ça fait partie du du boulot quo et donc après au niveau des difficultés le niveau de détail pareil et aussi on ne traitait que le flux là dans l'atelier 2h ne traitait que le flux nominal que ce qui marche on n' pas traité tous les cas d'erreur comment ça doit se comporter et cetera on s limité quand même au final donc euh hop ah oui j'ai ça donc voilà on a pu enchaîner ces trois ateliers qui vraiment euh le la logique a fait que on est parti de bah de de de l'ensemble enfin de l'ensemble des personnages de des personnes de l'entreprise qui ont réfléchi à ce que c'est no les use case pour arver jusqu'à quelque chose on a défini des composants autonomes qui qui qui sont là et qui nous paraissent en fait avoir une architecture produit qui soit vraiment logique donc derrière le but c'était de se dire bah quand même on repense l'organisation produit et donc euh et donc comment comment j'ai fait ça après derrière c'est que j'ai continué mais avec l'équipe là le but c'était d'embarquer tout le monde et de se dire bon maintenant on en fait quoi comment est-ce qu'on s'organise donc on a fait une journée euh d'équipe tous ensemble avec un focus sur l'organisation pour faire ça bien une petite intro du CEO qui dit blabla c'est mon fantastique euh et euh ça ça c'est très utile voilà un travail très intéressant euh sur sur l'organisation produit moi de mon côté une petite intro team toology où est-ce qu'on va pourquoi est-ce qu'on fait ça et puis après juste décider ensemble la liste de tous les topis de tous les sujets à décider ensemble la première étape ça été de dire bah là j'arrive avec une architecture produit où on a identifié qu'il nous faut un paquet sur les images un paquet sur la donnée structurée un paquet sur la data science un petit peu et ma question parce que moi en tant que manager j'avais pas envie de leur dire bon ben voilà regardez les équipes c'est ça je pense que là bla bla telle personne telle personne c'était moi ma question ça a plutôt été de leur dire on a identifié cette architecture produit vous vous voyez où vous dans cette architecture produit donc c'est vous arrivez chacun vous avez votre postite votre nom et allez-y o enfin comment vous pensez où vous pensez être et donc ça a été un enfin ça a été sans surprise et c'était cool aussi en fait parce que le process a fait que les gens se sont positionnés là où on on pensait que c'était une bonne chose et pour tout le monde en fait c'était il y avait pas eu de grosse discussion il y a eu en gros une personne qui était un peu entre les deux entre deux équipes parce que elle était po de de sujets elle savait pas trop où se mettre on a dit bah c'est bah c'est permet d'identifier le fait que bah soit tu es sur les deux mais au moins on le voit tu tu es transverse soit bah en fait il va falloir choisir et puis après je sais pas une développeuse aussi qui avait tellement touché à tout qu'elle dit mais je serais capable d'être partout je fais oui tu es capable d'être partout mais jour d'aujourd'hui où est-ce que tu penses que c'est pertinent que tu sois et donc là c'était bon aussi en fait et donc ça a été vraiment intéressant de se dire que on a pu restructurer non j'aime pas le terme restructurer faire évoluer er les équipes mais ça s fait tout naturellement quand on est arrivé à l'organisation des équipes tout le monde était ok pour se dire que oui c'est une bonne façon de de tenter les choses en fait c'est pas forcément en plus c'était pas c'est gravé dans le marbre évidemment c'est on essaye et puis on verra si ça ce que ça donne donc qui est dans quelle équipe la partie fun un peu c'est aussi quel nom d'équipe maintenant faut choisir des noms d'équipe donc avec les véaux les votes et puis finalement à la fin on a voté mais on a pas respecté notre vote mais c'est pas grave on était quand même d'accord sur décision qu'on a prise euh le côté bah on a fait des équipes avec bah tous les rôles regroupés dans une seule et même équipe enfin future team ou équivalent là mais streamline team mais bah il y a la communauté de pratique en fait les développeurs ils ont besoin de discuter entre eux pour techniquement ils se posé questions les PO aussi là on a une équipe de recherche aussi donc c'est comment on fait vivre cette communauté de pratique donc c'était une vraie question que là on s'est posé enant qu'est-ce qui est important pour vous euh qu'est-ce qui doit être du lors du rituel qu'on garde des choses à la demande les nonofficiels je sais plus je crois que les dev ils ont mis euh le café euh non il il y a pas un petit café d'è je sais plus mais enfin voilà c'est euh très bien c'était l'idée de se dire c'est important aussi de garder cette partie communauté de pratique euh moi mon job aussi ça a été de se dire bah ça on va pas le rajouter à l'existant donc maintenant on fait pas table ras parce que il y a aussi des choses qui marchent mais on reprend tout ce qui existe surtout au niveau des réunions enfin je sais pas vous mais nous hein on reprend tout ce qui existe au niveau des réunions on voit si elles sont encore pertinentes ou pas à quelle fréquence qu'elle durit quoi et c'est c'est c'est le moment de faire un peu du ménage là-dedans quoi donc voilà c'est ce qu'on a fait euh se poser la question de bah est-ce que dans les bureaux on bouge parce que voilà j'avoue que c'est la question moi je trouve qui est la plus délicate au final est-ce que les gens voilà parce qu'ils avaient enfin chacun aussi a ses habitudes on est dans une startup où les locaux font que bah certaines fois on a des pièces enfin voilà avec le télé-travail surtout c'est pas les locaux c'est le télétravail fait que bah certaines fois on a des pièces vides donc les gens bougent quand même on l'habitude de bouger les uns les autres mais ils avaient quand même leur groupe quoi et donc on l'a redéfini on l'a on l'a on l'a testé et je pense que euh au jour d'aujourd'hui on est arrivé à un à un enfin un entre de non un juste milieu plutôt de se dire juste après on a dit ouais d'accord maintenant il faut qu'on fonctionne en équipe donc chacun enilà c'était bien parce que ça a permis de créer de nouvelles interactions associations entre des gens qui bossaient pas tant que ça ensemble avant alors qu'ils étaient sur des sujets vraiment très proches donc ça ça a vraiment bien marché mais il y en a aussi on je sens ça qui ça a manqué en fait ils ont perdu des liens qu'ils avaient parce qu'ils étaient plus dans le même bureau et donc on voit maintenant des gens qui sont bah dans le bureau et puis ah bah le vendredi il y a moins de monde je viens avec toi et cetera et ça c'est cool aussi en fait c'est le but de retrouver aussi la liberté de bah en fait chacun s'installe où il veut mais ça a été mais je pense quand même au début ça a été important il y a vraiment sur deux sur deux trois deux équipes sur les trois sur lequel ça ça a vraiment créé une dynamique d'équipe et de groupes donc ça a été ce ce positionnement physiquement dans les bureaux ça a été vraiment intéressant et après ça ça a été fait plus tard le côté virtuel remet team propre et cetera c'était pas le jour J donc voilà au final la partie en amont c'était des ateliers toute l'entreprise réfléchir l'architecture produit et quand on est arrivé sur faire évoluer notre org on l'a fait ensemble en équipe et on s'est posé les questions de des équipes des communautés pratiques et cetera et avec vraiment le l'optique de bah on se laisse le temps de tester d'améliorer de garder ou pas ce qu'on veut et donc maintenant euh pour terminer sur la partie nos apprentissages mais franchement les retours que j'ai envie de vous faire sur le le déroulé en tout cas des ateliers ça a été vraiment très intéressant et la construction euh logique a fait que bah ça s'est bien enfin voilà ça a été assez fluide entre les ateliers les uns avec les autres et ça a été aussi une conruction ensemble au final et ça tout le monde a pu évoluer tranquillement parce qu'ussi alors c'est pas du temps long mais c'était pas du temp en cours non plus enfin ce que je veux dire c'est qu'avoir 15 jours entre chaque atelier c'était quand même intéressant au niveau produit ça nous a permis mais c'est plutô alors ça ça a été donc vous voyez les dates c'était mars donc mars de cette année les réflexions produit elles sont en cours en fait c'est maintenant qu'on se dit bon ça y est l'orgas c'est bon ça tourne machin et cetera si on revient sur les produits on se rend compte là tout de suite moi en fait chacun de nos composants qu'on a identifieré et cetera bah c'est pas super clair c'est quoi vraiment les limites les de ce qu'on veut faire les responsabilités de chaque composant où est-ce qu'on met les enfin les interactions avec un produit ou un autre et donc là on est vraiment en train de se reposer questions et d'ailleurs de se dire est-ce que c'est les bons noms de produit parce que c'est toujours aussi savoir trouver les bons noms pertinents et après sur un plus court terme au final au niveau de l'orga donc ce que je vous disais c'était aussi ah non ça c'est h pas de rapport le premier premier état oui c'est on ni pas du tout parlé dans la presse mais on a euh euh sur au niveau de leur g produit on a donc nous dans notre on avait les développeurs les PO et il manquait le dernier maillon de la chaîne qui est la partie support qui déploie en fait et donc là c'était de se dire bah est-ce qu'on arrive à les les inclure avec nous parce que c'est vraiment important d'avoir le flux de valeur du début à la fin euh on n' pas pu le faire parce que au final l'équipe qui gère le support elle était déjà enfin comment dire elle avait un fonctionnement où tout marchait super bien ils étaient au top de organisation et cetera et on avait enfin peur de les de casser un peu ça sur le moment donc on a plutôt choisi de se dire bah on va les inclure dans nos délit on va le faire venir un peu chez nous petit à petit là et puis euh et puis voir un peu pour voir avoir plus de liens sachant que bah cette équipe support enfin je veux dire à chaque fois qu'ils ont un bug évidemment qu'ils allaient parler au développeur donc le lien il existe déjà il existait déjà par contre ce qui s'est construit c'est aussi dans l'autre sens en fait les développeurs avaient moins l'habitude de se dire ah je suis en train de bosser là-dessus je vais le préparer on va le déployer machin tout ça et donc là d'inclure les personnes bah de la partie déploiement beaucoup plus en amont ça a été enfin rigolo mais les deux premières semaines on a enfin j'ai vu des discussions que j'avais pas vu avant après c'est tellement tombé dans la normalité que maintenant on s'en rend plus compte mais sur les enfin voilà tout au début c'était dire ah mais oui ça c'est une bonne idée ah mais oui ça avec le client machin et on s'est retrouvait ave que en fait avant c'était que dans un sens enfin voilà gen je te remonte les bugs et viens m'aider et maintenant on est passé dans l'autre sens bah je développe est-ce que tu as des des idées toi aussi donc c'était vraiment sympa ça a permis enfin c'est toujours le but souvent quand on fait évoluer les organisations de redéfinir pour que chacun a une place qui soit bien clair et là l'impact a été aussi beaucoup au niveau du travail collectif ça a permis de créer entre au début où en fait au final chacun avait sa fonctionnalité son produit et cetera quelque chose qui est beaucoup plus collectif et si s'il y a quelque chose qui en ressort vraiment c'est en plus cette envie maintenant de toujours de des équipes de dire on veut continuer vers encore plus de collectif donc c'est ça a été vraiment un déclencheur qui a dit bon maintenant on a vraiment envie de faire que les choses tous ensemble c'est plus pertinent on avance mieux et cetera et donc c'est vraiment continuer en collectif quel que soit le sujet et par oui voilà par contre la communauté de pratique elle est pas si active que ça donc c'est un vrai il faut vraiment vraiment enfin il mettent non c'est pas il mett de l'énergie en fait c'est je trouve en tout cas de mon côté côté start-up on est toujours un peu speed et on a toujours trop de choses à faire c'est laisser le temps lui laisser le temps d'exister à cette communauté de et c'est pas si simple voilà voilà voilà un peu ce que je pouvais vous partager sur la partie orga produit les réflexions qu'on a pu avoir dans notre entreprise