- Speaker #0
Bonjour à toutes et à tous, je suis Capucine, produit de designer en direct de la Grande Ours. C'est de nous rejoindre pour ce nouvel épisode d'Un poil du Wix. Aujourd'hui, nous accueillons Maximilien Humez, directeur de projet chez G2R La Mondiale. Tout d'abord, je te propose de te présenter et de nous en dire un peu plus sur ton parcours.
- Speaker #1
Oui, bonjour Capucine, merci pour cette invitation. Je m'appelle Maximilien Humez, je travaille chez G2R La Mondiale. Je suis directeur de projet depuis, et chef de projet chez HGV Arles Mondial depuis une dizaine d'années. J'ai commencé la gestion de projet il y a 20 ans. J'ai intégré une école de gestion de projet à Lille qui s'appelle Eficom Lille, où j'ai fait un master de gestion de projet informatique. Ensuite, j'ai intégré un éditeur de logiciel qui s'appelle Profilsoft pendant 5 ans. J'ai été intégrateur de logiciel chez des clients. qui souhaitait un logiciel de gestion de ressources humaines pour jamais n'en reprendre. J'ai fait ça pendant 5 ans, j'ai fait des formations, j'ai fait du développement, j'ai fait de la gestion de projet. Ensuite, j'ai intégré AG2R La Mondiale en tant que responsable applicatif et j'ai évolué dans la gestion de projet plutôt IT dans un premier temps et ensuite un peu plus de métier, donc avec des projets qui ont une orientation... type assurance et moins technologique. Ça m'a permis de voir depuis 15 ans un certain nombre de projets de différentes tailles et de différentes natures dans la société. J'espère justement pouvoir faire un retour d'expérience et vous donner un peu de lumière sur ce qu'est la gestion de projet.
- Speaker #0
Merci beaucoup, Maximilien. Nous avons hâte d'en savoir davantage sur ce sujet. Alors justement, aujourd'hui, nous allons pouvoir parler ensemble des méthodes au sein d'un projet. telles que les méthodes agiles comme le Scrum, le Safe, le Kanban, mais aussi celles dites plus traditionnelles comme le Cyclone V. Nous ferons un premier focus sur leurs définitions, puis nous entrerons vraiment dans le vif du sujet en échangeant sur les avantages d'avoir une méthode au sein d'une équipe, comment la mettre en place, puis tu auras de nombreux conseils à nous donner aux équipes et aux designers concernant ces différentes technologies projet. Alors pour débuter, qu'est-ce qu'un projet en entreprise ?
- Speaker #1
Un projet en entreprise ? projet à titre personnel, c'est la même chose. C'est un changement. On veut faire quelque chose, on veut évoluer, on a une nouvelle idée à mettre en œuvre. Donc, c'est un projet. Je souhaite faire quelque chose. J'ai des objectifs à atteindre. Je me suis fixé un certain nombre d'objectifs. Je souhaite réaliser ces objectifs dans un temps limité. Je souhaite démarrer la réalisation de ce projet à telle date et je souhaite terminer la réalisation de ce projet. projet à telle date, donc j'ai une date de début, une date de fin et j'ai besoin. Alors à titre personnel je peux être le seul acteur du projet ou ma famille peut être acteur du projet, mais en entreprise généralement on a besoin de coordonner des ressources. On a plusieurs équipes, on a un certain nombre d'acteurs dans l'entreprise. On va parler de projet à partir du moment où on a une, plusieurs équipes, plusieurs individus à coordonner au sein de l'entreprise. Donc un projet c'est un changement. une initiative qu'on souhaite mettre en œuvre avec une date de début, une date de fin, des résultats à atteindre et la nécessité de coordonner un certain nombre de ressources dans l'entreprise. Je peux donner un exemple, par exemple, j'ai un produit d'assurance à mettre en ligne sur le site AGD2A mondial. Pour faire ce produit d'assurance, il faut un expert, il faut déterminer aussi à qui s'adresse ce produit d'assurance. Alors ça peut être un produit d'assurance santé pour les jeunes. 30 ans et donc je vais voir les équipes qui expertent dans la construction de ces contrats d'assurance pour travailler le sujet. Je vais également aller voir un service marketing pour aller gérer la publicité. Puis je vais aller voir le service informatique pour m'assurer que les systèmes informatiques pourront accueillir ce nouveau contrat et ces nouvelles assurances. Donc en fait un projet c'est une idée qui va solliciter plusieurs services avec chacun. chaque service une compétence ou des compétences qui seront utilisées et avec un but partagé qui est la mise à disposition d'un nouveau contrat santé pour les jeunes. Donc ça c'est typiquement le genre de projet qu'on peut construire en entreprise et au-delà de ça je ne suis pas tout seul à lancer des projets, il y a tout un écosystème d'une entreprise à la direction, à un mode de gouvernance de l'entreprise. un mode de financement des projets qui vient s'adosser à cette nouvelle idée, à ce projet qui va mobiliser du temps et des efforts au sein de l'entreprise.
- Speaker #0
C'est très clair, merci beaucoup. Et du coup, qu'est-ce que l'usinologie projet a la différence ?
- Speaker #1
Alors, une méthodologie, un projet, c'est bien un objet, un changement. Une méthodologie projet, c'est une façon de faire, des règles de jeu, des règles de fonctionnement, des règles du jeu qui vont nous aider à construire, à formaliser, à dérouler le projet dans le temps. Donc, il y a plein de... Quand on déroule un projet, il y a des façons de faire qui sont plus ou moins pertinentes. Il faut déjà, pour premier élément, avoir un vocabulaire partagé. Il faut se mettre d'accord sur ce qu'est un chef de projet, un contributeur métier, un comité de projet, etc. Tout ce vocabulaire, ce glossaire projet va être porté par la méthode. Cette méthode va nous donner aussi des points de passage obligés. Réaliser un projet, on va nous proposer de le structurer avec des acteurs. Il faut y donc. les parties prenantes, identifier les rôles. On va construire ce qu'on appelle une méthode de proposer des outils de type principe. On va utiliser un fichier Excel qui va permettre de lister l'ensemble des acteurs, de définir leur rôle dans le projet et leurs contributions. Est-ce qu'ils sont là plutôt en acteurs, en informations, en contributions, est-ce que ce sont des décisionnaires, etc. Donc on va structurer, organiser, planifier le projet selon... les règles de la méthode. Donc c'est important pour nous d'utiliser la méthode pour mieux communiquer, pour mieux se structurer et pour être efficace dans le projet. C'est la finalité de cette méthode, c'est gagner en efficacité et atteindre les résultats qui étaient attendus le plus rapidement, le plus qualitativement et le moins sans dérater au niveau budgétaire. Il y en a plusieurs. projet, quand on crée une nouvelle application, si je prends un exemple relativement simple, si je décide de réunir des équipes et de dire, voilà, je veux une nouvelle application en ligne pour proposer le contrat de santé, si je ne donne pas les tenants, les aboutissants et je ne pilote pas en tant que chef de projet ces équipes, les personnes vont démarrer sans avoir des besoins clairement exprimés, pas de façon coordonnée, et donc au final, on va avoir un résultat. qui ne sera pas correcte, où on aura des freins qui vont se mettre en place, des dysfonctionnements qui vont se mettre en place durant la vie du projet. Donc ça, c'est important de poser dès le départ les règles du jeu en s'appuyant sur la méthode projet.
- Speaker #0
Pour que nos auditeurs comprennent chacune de ces méthodes, peux-tu nous les expliquer avec des mots très simples ?
- Speaker #1
Alors, on a plusieurs méthodes projet. Moi, je suis, on va dire, un peu ancien maintenant. avoir un peu d'expérience, on a commencé par ce qu'on appelait les méthodes projet cycle en V, méthode projet traditionnelle. Et donc, ces méthodes projet sont assez linéaires, très linéaires d'ailleurs, et on fait une étape à la suite de l'autre. Et il faut que la première étape soit complètement réalisée, selon les prérogatives de la méthode, pour passer à la suivante. Et donc, on va avoir une étape d'analyse, on va exprimer notre besoin, on va ensuite analyser, on va… concevoir, on va réaliser, troisième étape, puis quatrième étape, on va tester et ensuite livrer l'application. Donc ça c'est assez séquentiel, je ne peux pas passer à l'étape de conception si je n'ai pas exprimé correctement mon besoin, je ne peux pas passer à l'étape de réalisation si je n'ai pas finalisé la conception du produit, les spécifications en détail. Et ça c'est assez traditionnel, on pilote un projet avec un planning déjà long. des phases et le chef de projet s'attèle à ce que ce planning soit respecté, que les jalons soient tenus, que les livrables soient alimentés au bon moment. Et ça c'est toute la vie, très planifiée, très anticipée d'un projet. Et donc on faisait ça auparavant, on préparait énormément les choses avant de les lancer pour pouvoir dérouler, on va dire, un itinéraire ou une feuille de route détaillée. Aujourd'hui, on est plus dans l'agilité et on se dit que le monde est assez complexe. Entre le moment où j'exprime un besoin, le moment où je l'écris, je l'exprime, j'ai des incertitudes. Je ne sais pas trop où je dois aller. Je ne sais pas si le besoin est pertinent ou pas. En tout cas, je sais que je dois mettre une nouvelle application pour les jeunes, par exemple en contrat santé. Mais concrètement, ce que je vais y mettre dedans, ça dépend d'un certain nombre de choses. Je n'ai pas la maîtrise. Le besoin n'est pas clair. On peut avoir de la réglementation aussi liée au secteur de l'assurance qui peut intervenir durant la phase du projet. On peut avoir d'autres contraintes aussi internes à l'entreprise qui peuvent venir. se poser des problématiques d'architecture, des problématiques d'espace client qui ne sont pas suffisamment modernes pour accueillir ce genre d'application. Et donc en avançant dans le projet, on va avoir des aléas, des contraintes, des changements, des besoins qui peuvent être modifiés. Et donc la méthode cyclon V ou waterfall n'est pas forcément appropriée. Les équipes qui interviennent ne sont pas nécessairement non plus compétentes. ou pertinentes dès le début du projet. Elles ont besoin de prendre un peu d'expérience, elles ont besoin d'apprendre à travailler ensemble. Et donc, ce qui naît aujourd'hui dans les entreprises, et ce qui est plutôt adopté, c'est la tendance de ces dernières années, c'est de passer à l'agilité, où finalement l'agilité dit on va créer des équipes de petite taille qui vont être autonomes, qui vont apprendre à se connaître, qui vont apprendre à travailler ensemble, qui vont partager des compétences qui sont transverses. Et donc, on va avoir des experts techniques, des experts... métiers, des experts architecture, etc. Et donc parmi cette population ou cette équipe agile, on va fixer un timing, une séquence qu'on avait appelée des sprints, des périodes de 15 jours, 3 semaines, où l'équipe va faire des petites livraisons à période régulière et va démontrer ce qui a été livré, ce qui va permettre à chaque période de réajuster. et d'avancer, progresser avec l'équipe. Et donc on est aujourd'hui dans une tendance où le cycle en V, qui était je travaille très en amont, je prépare, je suis minutieux, je pilote avec beaucoup de visibilité, avec un principe agile, où je suis sur des plus petites équipes, avec une capacité à délivrer rapide, et une capacité à accepter le changement sur des périodes courtes, donc à horizon trois semaines. Et c'est ce qui se met en place dans les entreprises et les méthodes évoluent dans ce sens. Donc on va retrouver des méthodes de type Scrum, qui est le plus connu, au niveau des équipes produits, ou des méthodes de type Safe, qui sont finalement l'agilité qui a été appliquée à l'échelle de l'entreprise pour une dizaine d'équipes, pour des organisations qui sont complexes, où je n'ai pas une pizza team, donc une petite équipe agile à piloter, mais où j'ai un ensemble d'équipes à coordonner. pour pouvoir délivrer une application. Et là, on va parler de SAFE, qui est finalement la mise en application de l'agilité à l'échelle de l'entreprise. On a aussi d'autres méthodes. On a la méthode Kanban. La méthode Kanban, qui est un mot au japonais qui veut dire étiquette, finalement, c'est ma préférée. Je trouve que c'est la plus agile, quelque part. C'est celle qui permet de poser sur un tableau, de façon visuelle, l'ensemble des éléments. des travaux du projet, des activités du projet, de savoir ce qui est à faire, ce qui est en cours de réalisation et ce qui est terminé. Et donc visuellement sans avoir vraiment un bagage et une connaissance en gestion de projet, on peut très facilement adopter une méthode simple pour s'organiser et pour faire vivre une activité projet. Donc on a la méthodologie Kanban et puis ensuite on a la méthodologie ou les pratiques Lean. qu'on retrouve en entreprise. Alors là, sur ce sujet-là, on est plutôt sur, Lean veut dire sans gras, maigre, et donc on est plutôt sur des pratiques de dire, dans des équipes de gestion, il y a un certain nombre de processus qui peuvent être améliorés, qui peuvent être plus efficaces pour prendre des appels clients, pour travailler des dossiers clients, pour répondre aux clients. Donc sur ce processus, il y a un certain nombre de tâches qu'on peut simplifier, qu'on peut dégraisser. Et donc l'idée c'est d'avoir une pratique qui va permettre de faire plus efficace avec moins d'efforts dans les équipes, en simplifiant les processus. D'où la notion de sans gras et d'aller à l'essentiel pour produire plus de valeur pour le client. Donc ça ce sont des pratiques de fond, des fonctionnements à long terme dans la gestion de processus au niveau des équipes. et dans la simplification des tâches pour les équipes.
- Speaker #0
Merci beaucoup pour toutes ces explications. Et donc, quelles parties prenantes on va retrouver au sein de ces méthodes ?
- Speaker #1
Les parties prenantes, on a toujours les mêmes acteurs dans l'entreprise. Les hommes ne changent pas. On peut avoir des prestations externes, mais on a aussi des collaborateurs internes qui ne bougent pas. Mais par rapport à la méthode, on va avoir peut-être un vocabulaire différent et puis une organisation différente pour piloter, pour suivre, pour gérer. pour mettre en œuvre le projet. Donc, quand on parle de projet cycle en V, on va retrouver un chef de projet. Ça, c'est... Si on vous parle de chef de projet, c'est qu'on est sur de la méthode traditionnelle, si on veut, ou directeur de projet, ou directeur de programme. Là, on est sur une logique de gestion multi-projet. On retrouve ces méthodes traditionnelles. Le chef de projet, lui, il est là pour piloter et gérer le projet. Il doit s'assurer que le projet déroule bien et respecte le cadre qui lui a été fixé. C'est-à-dire un projet a des enjeux, des objectifs, des contraintes de coût. respecter, en tout cas un budget à respecter et puis un délai à respecter. Donc le chef de projet va gérer son projet de façon à respecter ces éléments. On va dans un projet type cycle en V retrouver souvent le terme de maîtrise d'ouvrage. Souvent c'est en train de se gommer cet aspect maîtrise d'ouvrage et maîtrise d'oeuvre, mais la maîtrise d'ouvrage représente souvent le métier. Donc ce sont les personnes qui vont nous permettre de poser le besoin, qui vont nous confirmer les attendus et les résultats souhaités lorsque le projet sera livré. Puis on va parler de la maîtrise d'oeuvre, MOE, et donc là ce sont les responsables de la réalisation, c'est souvent l'informatique dans une société de service comme la nôtre, l'assurance, la maîtrise d'oeuvre, c'est le service informatique, la direction informatique, la DSI, la direction des systèmes d'information, ils sont responsables de la réalisation. Pour la partie agilité, on a un vocabulaire qui est assez spécifique et qui est parfois nécessaire d'appréhender, puisqu'on est sur des mots essentiellement portés. Scrum, qui est la méthodologie agile appliquée à l'équipe. Le premier niveau d'agilité, on va avoir le Scrum Master. Le Scrum Master, ce n'est pas totalement un chef de projet. Lui, il est plutôt là pour, au départ, on assimile le chef de projet au Scrum Master quand on ne connaît pas plus. très bien l'agilité, mais le Scrum Master est plutôt coach, il est plutôt facilitateur, il doit s'assurer qu'en fait la méthode Scrum est bien appliquée. Donc son rôle c'est de poser la méthode et de faciliter l'adoption de la méthode. Celui qui va s'assurer que le besoin, les exigences attendues et posées aux équipes de développement soient bien priorisées et bien formalisées, c'est Product Owner. On va avoir cet acteur là qui peut être côté métier et qui pourrait être côté MOA si je fais de la similitude au maîtrise d'ouvrage côté cycle en V. Donc ce product owner il a la connaissance du besoin, il formalise en termes d'exigence ce que l'application ou le produit doit réaliser. Et ensuite on a les équipes de dev qui elles vont comprendre ces exigences. et réaliser durant un sprint. Quand on parle de SAFE, on pose l'agilité, donc les mêmes principes, un besoin de découper en période donnée les sujets, donc en agilité, on parle de sprint, et en SAFE, on parle d'incrément. Donc on passe à l'échelle supérieure, on va dire à la maille direction peut-être, peut-être pas la maille entreprise quand on parle de SAFE. En tout cas, on a besoin de coordonner et de faire fonctionner ensemble peut-être une dizaine d'équipes, une centaine de personnes. Et ces personnes, pour les mettre au diapason, on va avoir le RTE, le Release Train Engineer. Et ce RTE, c'est l'équivalent du chef d'orchestre pour un orchestre. Il est responsable du bon fonctionnement du train. Donc le Scrum, lui, s'assure quand on est au niveau équipe à ce que la méthodologie s'applique au niveau de l'équipe. Et le RTE s'assure. que la méthodologie SAIL s'applique bien à l'ensemble des 10 équipes ou de la centaine de personnes qui vont avoir besoin de se coordonner équipe par équipe. Donc on a un chef d'orchestre à un niveau supérieur qui est le RTE. On en parle également de product manager. Alors le product manager, c'est l'équivalent peut-être du product owner, mais pareil à l'échelle du train pour l'ensemble des équipes. Et lui, il porte une vision produit de l'ensemble des réalisations du produit que le train va délivrer. j'utilise le terme de train, je le définirai après, le product manager qui pourrait être le product owner, mais au niveau safe et à la maille train. Et on a le business owner, le business owner qui est le représentant métier. Alors lui va s'assurer de valider les objectifs, il va s'assurer que ce qui est produit par l'ensemble des équipes correspond bien aux attentes du métier. Donc ça pourrait être l'équivalent de notre MOA dans un projet cyclant de maîtrise d'ouvrage. SAFE, les trois termes qu'on va retrouver dès qu'on va parler de RTE, le Distri-Engineer, on va avoir le chef d'orchestre du train, le BO, le Business Owner qui va représenter le métier. et puis le Product Manager qui porte la vision du produit. Il y en a plein d'autres, je ne vais pas tout détailler, mais là je vous invite à regarder si vous êtes intéressé, soit la méthode qui est dans l'entreprise dans laquelle vous travaillez, soit SAFE qui est riche en documentation.
- Speaker #0
En effet, on retrouve vraiment beaucoup de parties prenantes dans ces différentes méthodes. Lors de tes expériences, quelles méthodes tu as utilisées ?
- Speaker #1
J'ai utilisé plusieurs méthodes. Quand j'étais responsable applicatif, et qu'on était donc sur des petites équipes en lien avec un métier et puis dans un écosystème assez maîtrisé, le Kanban a été un outil très efficace. Il permet finalement d'avoir une liste de choses à faire et de les prioriser et de les mettre en visibilité et de communiquer autour de ce Kanban. C'est un outil simple et facile à utiliser. Ensuite, le cycle en V, le projet traditionnel, je gère un projet où je le structure en amont, je le découpe, je le planifie, j'identifie les parties prenantes, les équipes, je travaille avec les équipes à l'organisation, je mets en place un comité de pilotage pour animer et arbitrer les décisions durant la vie du projet, des comités de projet qui se mettent en place pour discuter avec l'ensemble des acteurs projet, des comités opérationnels, quand on est plutôt à la DSI. donc à l'informatique, pour aller suivre de façon précise l'avancement des travaux. Donc tout ça, c'est des choses qui existent depuis une dizaine d'années, beaucoup plus, parce que les méthodologies ici sont datées du milieu du siècle dernier. En tout cas, ça, c'est des choses qui sont éprouvées, mais qui ont apporté leurs limites face à la complexité, à la rapidité du monde moderne. Aujourd'hui, il y a tellement de changements, il y a tellement de turnovers, des difficultés dans des grosses entreprises à délivrer, très compliqué de tout planifier parce que dès qu'il y a un changement, une réglementation qui tombe, ça vient chambouler l'organisation. Ces équipes ont du mal à échanger et à délivrer. Et donc, ces méthodes cycle en V se sont réduites. On va dire, en tout cas, le volume de projets autour de ces méthodes s'est largement réduit pour laisser place à des approches de type Scrum ou Safe. Moi, ce que j'ai expérimenté, et je trouve que c'est un bon compromis, en tout cas à l'heure actuelle, quand une entreprise n'est pas passée totalement à l'agilité sur SAFE et reste encore avec un mode de fonctionnement mixte, c'est-à-dire je fais du traditionnel mais j'aimerais passer à l'agilité, c'est les projets hybrides. Donc les projets hybrides, ce sont des projets cycle en V qui nécessitent d'être bien préparés en amont, donc j'exprime clairement mon besoin, je découpe mon projet. et ensuite je le réalise. Et à l'étape de réalisation, je sors du principe de dire je planifie les efforts équipe par équipe, j'organise de façon hebdomadaire des comités de suivi et on gère en comité de suivi un certain nombre de trains d'avancement et de risques. Là, on se dit je change de dimension, je me mets en équipe pluridisciplinaire, on va dire en tout cas crosse fonctionnelle. Autour de la table, je découpe mon activité en sprint de 15 jours. Je me file des objectifs à délivrer des choses prioritaires en 15 jours, en partant de l'essentiel, et je fais une démonstration au bout de 15 jours. Alors ça, c'est très efficace sur la période de délivrerie. On reprend les mécaniques de Scrum. On pourrait même, sur cette phase-là, faire venir un Scrum Master pour animer les équipes, qui permet d'avoir une phase de production. qui est dynamique, qui permet d'absorber le changement, qui permet aussi de compléter un certain nombre d'éléments en amont qui n'étaient pas suffisamment clairs, ou de réajuster s'il y a besoin de réajuster, et puis de livrer quelque chose. Donc c'est ce qu'on parle du fameux MVP, le minimum viable product, qui est je vais à l'essentiel, je livre ce qui produit de la valeur tout de suite pour le client et qui est essentiel au fonctionnement. Et donc cette partie des livrées, elle est intéressante à mettre en place. en mode Scrum dans un projet cyclon V. Et c'est ce qu'on appelle les projets hybrides. Et de plus en plus, on va dire de plus en plus, c'est ce qu'on retrouve dans nos sociétés où la difficulté de planification, de chiffrage en amont, d'évaluation des efforts des équipes reste compliquée.
- Speaker #0
Pourquoi il est donc important de mettre en place une idéologie projet dans son entreprise et dans son équipe ?
- Speaker #1
Alors, je pense qu'il faut toujours un plan d'action, un plan des règles du jeu formalisé. Si on part, quelle que soit la méthode, quel que soit le projet, il faut formaliser la façon dont on va fonctionner. Et la méthode propose sur étagère un fonctionnement. Donc on pourrait en imaginer une nouvelle à chaque fois. ça pourrait fonctionner. Mais là, aujourd'hui, on a des méthodes qui sont éprouvées, qui ont été réfléchies, qui sont sur étagère. Et donc, les méthodes Cyclone V sont documentées, les méthodes Save sont documentées, la méthode Scrum est documentée. Et donc, ça nous permet d'aller chercher sur étagère des façons de fonctionner qui sont déjà en place, qui expliquent les règles du jeu, qui permettent de poser un vocabulaire commun, qui permettent de poser finalement des sécurités, en disant par exemple, en organisant des délimitings. tous les matins en travaillant ce qu'a fait les travaux en cours de chacun et en exprimant les difficultés rencontrées tous les matins, ça permet d'animer une cohésion d'équipe, ça permet d'adresser très rapidement les problèmes et donc c'est cette méthode qui apporte le stand up du régulier et quotidien et donc c'est une sécurité en soi que la méthode apporte. La phase de démo Quand j'ai fini mes 15 jours, je montre aux utilisateurs les réalisations. Ça permet aussi de capter de l'information, de capter du changement et de se dire finalement je suis dans la bonne direction ou je ne suis pas dans la bonne direction, il faut que j'aie un certain nombre d'éléments et d'être réactif là-dessus. Donc la méthode, intrinsèquement, elle a été pensée pour nous rendre plus efficaces, pour proposer des tips, des pratiques qui sont déjà éprouvées et qui vont permettre d'éviter de tomber dans des erreurs. de débutants. Et donc c'est important d'avoir cette méthode partagée et comprise de chacun. Ça donne du sens à ce qu'on fait, ça donne de la sécurité, ça donne un pouvoir de communication qui est aussi important. Quand la méthode est comprise, quand on parle d'une phase, quand on parle d'une étape, les personnes comprennent ce qui est fait et donc sur toute la phase, on va dire organisation, administration, communication, il y a tout un volet simplifiant qui arrive. Donc prendre une méthode qui est connue va simplifier la vie de la communication pour le chef de projet ou pour le product owner et l'organisation qui est mise en place dans l'ensemble des équipes pour participer à ces événements. C'est hyper important en termes d'efficacité équipe, en termes de communication et en termes de sécurisation du projet. Quand je dis hyper important, c'est relatif, on pourrait, mais en tout cas c'est facilitateur sur ces trois points.
- Speaker #0
Et pour les projets dits agiles, on parle d'amélioration continue. Tu peux nous en dire un peu plus ?
- Speaker #1
Alors l'amélioration continue. Il y a deux aspects sur l'amélioration continue. Soit on parle de l'amélioration du produit, c'est-à-dire qu'on s'adapte au changement et on arrive à faire vivre le produit, à l'améliorer régulièrement. Soit on s'améliore en termes d'équipe projet, où on est plus efficace et on arrive à délivrer plus rapidement ce qui était prévu à moindre coût avec une meilleure qualité. Donc c'est ça, l'amélioration continue, c'est comment je peux travailler sur ces deux axes. Alors l'adaptation au changement, la méthode agile avec sa logique de sprint permet naturellement ou nativement d'embarquer cette adaptation. En phase de démonstration, on peut se réaligner. On a aussi des moments de rétrospective qui permettent de regarder derrière nous et de se dire, sur les 15 jours qui se sont écoulés ou les 3 semaines, quels étaient les points compliqués, qu'est-ce qu'on pourrait améliorer pour le prochain sprint. Donc on est dans une logique d'auto-amélioration de l'équipe en place. Pour être toujours plus efficace d'ailleurs, il y a des outils de pilotage qui sont proposés par la méthode pour mesurer l'efficacité de l'équipe en place. On part avec une équipe qui est peu efficace, qui peut produire peu de choses. Et puis, au fil des sprints, avec l'amélioration continue, l'équipe monte en expérience, en expertise, et devient de plus en plus efficace et en trois semaines, délivre de plus en plus. Et donc ça, c'est un point important à suivre et un indicateur de bonne santé de la vie du projet mené en agilité.
- Speaker #0
Et donc, quels sont les avantages pour une équipe ?
- Speaker #1
Alors les avantages d'une méthode au niveau de l'équipe, c'est de clarifier les rôles et responsabilités. On sait clairement qui fait quoi dans l'équipe et quelles sont les attentes. Deuxième point, la méthode permet une meilleure collaboration entre les équipes. À partir du moment où on a un vocabulaire qui est partagé, on a un planning qui est compris, des échéances, des instances, des événements qui sont posés dans les calendriers. des objectifs ou en tout cas des exigences qui sont clairement formalisées, on collabore mieux. Donc il y a une dynamique, une communication qui se passe naturellement entre les équipes.
- Speaker #0
ou plus facilement. Les réunions régulières posées par les stand-up ou les daily meetings participent à cette collaboration. On a également, à partir du moment où les personnes arrivent à échanger, se comprennent, partagent des enjeux, des objectifs partagés, des jalons communs, compris, on a une motivation qui augmente. On est motivé, on est content de travailler ensemble en équipe sur un projet. Et donc la communication, la méthode qui aide à la collaboration, participe à la motivation et à l'engagement, nous aide en tout cas à créer cet axe de motivation et d'engagement des équipes. La démo aussi donne du sens global, pas uniquement au niveau des équipes de dev, mais quand il y a l'équipe de dev qui présente ses réalisations au métier, ça les met en avant, ça montre aussi l'engagement des équipes de dev et au niveau métier, ça crée du lien. Il y a une synergie, une cohérence d'ensemble entre les développeurs et les métiers, qui sont les clients finaux, qui se met en place grâce à la méthode. On peut aussi gérer des priorités. La méthode nous aide à gérer des priorités. On peut prioriser par rapport à la valeur rendue, par rapport à la complexité. En agilité, souvent on commence par des choses simples, et puis on complexifie avec la maturité de l'équipe. On peut avoir d'autres axes de priorisation. par rapport à d'autres critères liés aux coûts, liés à la valeur, liés à la stratégie d'entreprise. Voilà, ça c'est décliner souvent des méthodes qui peuvent être, ou en tout cas des outils qui peuvent être insérés dans la méthode. Et on a une contrainte budgétaire, in fine on travaille dans un cadre limité en temps et en budget, donc la méthode va nous permettre de poser et de communiquer, de suivre le budget correctement. Soit la saisie des temps, si les personnes du côté doivent saisir leur temps sur le projet donné, si on doit faire des achats ou des investissements sur le projet, une centralisation et un suivi budgétaire. La gestion des risques. Un projet est soumis à un certain nombre de risques. Les risques peuvent être intrinsèques au projet. C'est inhérent. J'ai une personne essentielle dans le projet, un technique qui est absent. Et donc, on en risque le projet. Il faut prévoir la... un plan de secours. Donc, il faut gérer du risque intrinsèque au projet. Mais on peut avoir du risque extrinsèque, c'est-à-dire un autre projet, on attendait la livraison d'une machine pour développer, et puis finalement, l'autre projet qui gérait la mise à jour des logiciels prend du retard, et donc le nôtre aussi. Et donc là, on est sur un risque planning, on a des rances avec un autre projet, on a des risques extrinsèques. Et donc, la méthode va nous aider à mettre en avant ces risques, à les suivre et à poser les plans d'action. On n'a pas qu'un aspect organisationnel dans la méthode, on a un aspect pilotage et suivi, priorisation des actions à la maille du poids.
- Speaker #1
On comprend qu'il y a quand même pas mal de méthodes, mais pour toi, comment choisir la bonne méthode pour son équipe et pour son projet ?
- Speaker #0
Sur cette question, ce n'est pas forcément évident. Quelle est la bonne méthode ? Je pense qu'il faut… Par rapport au projet, poser la question de la maturité de l'équipe à travailler en projet. Il ne faut pas sortir d'une méthode compliquée avec une petite équipe qui est assez autonome et qui n'a pas l'habitude de fonctionner en mode projet. Ce sont plutôt des équipes qui font des tâches de gestion au quotidien et qui décident de mener un projet de simplifiant ou une petite évolution dans leur processus métier. Il ne faut pas sortir de la grosse machine. Il faut être pragmatique et se dire finalement le combat, ça répond assez simplement. à énormément de cas. À partir du moment où le projet va commencer à nécessiter de la coordination, à gérer des enjeux un peu plus lourds pour l'entreprise, avec des contraintes qui sont vagantes, il faut sécuriser. On a besoin de sécuriser, on a besoin de légitimer un certain nombre d'actions et d'expliquer comment on va le faire. Donc là, une méthode reste pertinente. Alors moi, soit l'entreprise, là on a deux cas, soit l'entreprise a une méthode, clé en main, et on dit voilà, dans notre entreprise, Vous faites du SAFE et c'est SAFE qui vous rentrez dans la mécanique de SAFE, dans la logique de train, d'équipe qui passe en train avec des incréments de trois mois et puis à l'intérieur de ces trains, des sprints au niveau des équipes. Vous rentrez dans cette dynamique-là, vous n'avez pas le choix. Donc, auquel cas, il faut appréhender cette méthode et rentrer dans la logique de planification et d'organisation SAFE. Soit vous avez la possibilité à votre main de faire du cycle en V ou du scrum parce que... la société propose, l'entreprise propose le choix des méthodes. Donc, je pense que tout dépend des compétences. Si vous avez des compétences en cyclant V, projet cyclant V, ça demande quand même un peu d'expérience pour ne pas se noyer dans les méthodes traditionnelles. Donc, si vous avez un peu d'expérience, en tout cas avec des équipes qui ont l'habitude de travailler en cyclant V, partir là-dessus. Et sinon... mettre en place du Scrum ou essayer de faire du Scrum en agilité, en s'appuyant sur du Kanban, ça peut être une bonne solution pour démarrer. Donc on ne s'improvise pas chef de projet, donc il faut essayer d'y aller progressivement, de prendre de l'expérience, mais surtout garder l'essentiel, c'est-à-dire qu'il ne faut pas mettre une méthode trop compliquée. où il y a un temps d'adoption de la méthode qui serait plus long que celle du projet, et donc rester sur des choses relativement simples pour rester efficace avec les contrôles. Alors, il y a quand même deux tendances. Si je reviens sur le choix de la méthode projet, il y a deux tendances. Si j'ai une équipe qui connaît bien son processus, qui connaît bien l'existant, qui connaît bien son système d'information, et qui doit... Prendre un besoin, qui est par exemple une nouvelle réglementation qui est arrivée sur le secteur de l'assurance, où on a un changement de taxation sur un contrat ou sur des contrats d'épargne. On est sur des équipes qui ont une bonne visibilité, qui ont l'habitude de travailler avec les parties prenantes. Et donc ça peut très facilement se planifier en amont. Comme je planifierais un voyage pour partir en vacances, j'ai l'habitude, je sais qu'il faut organiser en amont, réserver les billets, prévoir les étapes, réserver l'hôtel, etc. Les personnes sont assez à l'aise là-dessus. Je pense que les méthodes traditionnelles sont largement suffisantes sans forcément sortir toute la machinerie de la méthode cyclant V. On peut rester sur une logique de phase. J'exprime clairement mon besoin, j'analyse. Je réexprime les nouveaux processus à mettre en place, les changements à adopter dans les systèmes d'information. Je réutilise des dossiers de conception que je fais évoluer par rapport à des projets antérieurs. Et ensuite, je réalise avec des équipes qui ont l'habitude de travailler sur le sujet. En plus, ces équipes, généralement, en amont, on les sollicite pour donner des coups, pour savoir à quel moment elles peuvent travailler, etc. Et donc, elles sont très structurantes et vont aider le chef de projet à s'organiser. Ça c'est l'idéal pour les projets cyclant. Pour les projets agiles, j'ai un besoin, j'ai un nouveau site internet, mais j'ai des fonctionnalités à mettre en place, je ne sais pas par où commencer, est-ce qu'il est plus pertinent de mettre un espace documentaire en ligne ou est-ce qu'il est plus pertinent de mettre un espace d'actualité ? En tout cas j'aimerais y avoir les deux, il faut que j'adresse. Bref, il y a plein de choses qui viennent dans l'échange, on est en train de réfléchir en même temps, on avance dans la conception. Là on se dit, finalement il n'y a pas photo, il faut rester en agilité. Les équipes, c'est nouveau, c'est quelque chose de nouveau qu'on met en place. On est en train de réfléchir le besoin qui n'est pas très clair. On ne va pas engager un projet sur six mois, on va faire des phases de sprint, des itérations de 15 jours ou trois semaines, et puis on avancera et on se réajustera tous les trois semaines. Là, il y a un vrai sens à dire, je choisis plutôt l'agilité qu'obscurance. C'est la maturité et la connaissance du projet qui peut aussi aiguiller le choix de la méthode.
- Speaker #1
Merci pour toutes ces précisions. En effet, c'est beaucoup plus clair et on voit bien les différences qu'il y a entre toutes ces méthodes. As-tu des conseils pour une équipe qui travaille avec une de ces méthodes ?
- Speaker #0
Les conseils, je les ai un peu dilués dans le discours, mais si je les résume, un projet, il faut le découper. Il faut le structurer et l'organiser. Donc souvent, les projets informatiques sont compliqués parce qu'il y a des adhérences, il y a des liens avec plusieurs outils, il y a des interfaces à mettre en place, il y a un certain nombre d'acteurs variés, des architectes, des développeurs, des spécialistes de solutions. On va dire que l'écosystème projet est assez vaste et on peut se perdre dans le projet. Donc il est important de bien définir les objectifs, les enjeux, et de le découper le plus finement possible, de façon à le clarifier. Et de poser ce découpage, on appelle ça le WS, le Work Break Future en anglais. Donc en fait on découpe en briques. où on parait de petite taille et où on est capable de mettre un responsable sur ce... sur cette action, un budget. Et quand on a ce niveau de finesse qui est atteint, on voit plus clair. On peut faire des lots, on peut faire des chantiers, on peut se projeter dans le temps et organiser l'activité. Donc la première chose à faire, premier conseil, c'est de découper les sujets compliqués en plus petits sujets. Adapter la méthode en fonction de la maturité des équipes, du nombre d'équipes. Prendre une méthode, ça a du sens, mais il ne faut pas forcément prendre toute la méthode. Donc, gardez l'essentiel. Si vous avez un comité de pilotage à animer avec un sponsor, et puis des directions en métier, prenez les supports du comité de pilotage, et ensuite, animez votre propre comité de suivi avec vos équipes, en simplifiant les supports de présentation, de façon à ce que ça reste relativement simple à administrer. Donc prenez l'essentiel de la méthode sans prendre l'exhaustivité, adaptez-la. La méthode n'est pas une fin en soi, donc un projet réussi n'est pas une méthode qui a été bien exécutée. Un projet réussi, ce sont des résultats qui sont atteints par rapport aux objectifs initiaux. Et donc, utilisez la méthode comme un levier de réussite, pas comme une contrainte. L'autre point, c'est les équipes. En fait, tous les projets, peu importe la méthode, ce qui est important c'est... quitter un projet et d'avoir envie d'en faire un. Parce qu'il y a beaucoup de projets où la tension, quand la difficulté arrive, on pose plus de problèmes que de solutions. Donc il est important de garder une motivation, l'envie de contribuer à ce changement. Et donc pour moi, l'élément clé, c'est de faire un projet en fédérant les acteurs, en leur donnant envie de se retrouver le matin, pour travailler ensemble. Ça, c'est hyper important. Je pense que c'est peut-être même l'élément clé. C'est de se faire Soyez acteur et ayez envie d'atteindre les résultats. Et donc, c'est peut-être le point essentiel. Et le chef de projet, lui, doit être facilitateur, il doit mettre en avant les succès, il doit organiser des moments d'échange pour les fêter, pour mettre en avant les réussites. Et ça, c'est peut-être l'élément clé d'un projet. On peut enlever la méthode, on peut déraper, le planète peut déraper, le budget peut être sous-consommé, les résultats peuvent être pas à la hauteur, mais s'il y a une bonne... motivation, les équipes qui sont fédérées, elles vont s'améliorer, elles auront envie de faire mieux la prochaine fois. Et donc c'est cette expérience-là, c'est cette envie de recommencer, de s'améliorer qui est importante. C'est une opportunité, le projet dans une entreprise, c'est une opportunité de prendre de l'expérience, de faire vivre l'entreprise et de la faire grandir, de la rendre compétitive, de la laisser compétitive. Et donc ce changement-là... L'ensemble des acteurs doivent y participer et sont des acteurs clés. C'est ce qu'il faut faire ressortir dans les projets. Dans les conseils, c'est peut-être ça, la notion d'équipe, la notion de motivation et d'engagement des acteurs dans le projet.
- Speaker #1
Nous faisons maintenant un focus sur les designers. On intègre souvent des entreprises travaillant en méthode traditionnelle ou agile. En tant que designer, on doit s'adapter. Quels conseils aurais-tu à nous donner ? pour bien s'intégrer à une équipe qui est en traditionnel du coup plutôt qui est agile ?
- Speaker #0
Moi je pense que la première chose quand on intègre une équipe c'est de comprendre le vocabulaire utilisé. Quels sont les moments dans un projet ? Quels sont les éléments clés ? Qui pilote ? Quels sont les rôles de chacun ? Donc c'est de comprendre l'écosystème en identifiant les acteurs, l'écosystème on va dire projet. et les contributeurs du projet. Ça, c'est le premier élément. À partir du moment où on comprend où on est, on arrive à mieux naviguer, à mieux solliciter les personnes. Ensuite, c'est de comprendre aussi le timing et les enjeux du projet. Au final, on travaille pour quoi faire ? Quel est le but attendu de ce projet ? Donc, avoir la vision partagée commune avec l'ensemble des contributeurs de projet, c'est essentiel. C'est le deuxième point. Je sais avec qui je travaille, je sais pourquoi je travaille et quel est le but à atteindre. S'il y a des rituels, des événements, des animations qui sont planifiés régulièrement et qui ont des objectifs, soit de synchronisation entre les équipes, de priorisation, de gestion budgétaire, de mise en avant des réalisations, les sprint démos par exemple, il faut les identifier. et y participer si ça a du sens en tant que designer d'y être. Je pense que par exemple, participer à une présentation d'interface dans une démo sur un espace client quand on est UX et qu'on… il y a des retours utilisateurs à ce moment-là pendant la démo, c'est très intéressant d'aller capter l'information à ce moment-là. Donc, il faut s'insérer dans la vie du projet, il y a la réalisation du designer qui va faire ses processus, son activité du X, mais il y a aussi l'écosystème qui va le nourrir et qui va le rendre pertinent par rapport à ce qu'il va produire. Et donc, c'est sur ces événements-là. qu'il faut essayer de s'insérer et de se nourrir pour être efficace et pertinent.
- Speaker #1
Merci beaucoup, Maximilien. En effet, merci beaucoup pour tous ces conseils. Je suis sûre que nos auditeurs pourront en effet mettre en place tous ces beaux conseils. Avant de clôturer, as-tu un mot de fin pour nos auditeurs ?
- Speaker #0
Oui, j'allais dire, j'espère que vous avez envie de participer à un projet maintenant. La meilleure chose à faire quand on est dans une entreprise, je pense que c'est de participer à sa transformation. Alors il y a la vie du quotidien, mais si on a du temps un peu à passer et participer et donner sa matière grise à l'entreprise, à travers les projets, c'est très enrichissant et ça ne peut que nous faire prendre de l'expérience et de la maturité dans notre travail. Donc participez au projet, c'est-à-dire, cliquez en V, agissez, ce que vous voulez, comment, mais participez à la transformation.
- Speaker #1
Merci beaucoup Maximilien. on arrive à la fin du podcast alors merci à toi pour tant que tu nous as consacré pour échanger sur ce beau sujet des méthodes en entreprise merci à vous auditeurs d'avoir écouté cet épisode d'un poil du X et très bonne journée à tous
