Transcription

• Speaker #0

  Focus Projet

• Speaker #1

  Bienvenue sur Focus Projet, le podcast du management de projet. Le management de projet, qu'est-ce que c'est ? Ça va être les différentes techniques et outils qui vont nous permettre de mener à bien nos projets. Planning, coût, risque, gestion d'équipe, changement, communication, définition du besoin. Au fil des épisodes, on va voir tout cela ensemble. Alors que tu sois le directeur de projet de la prochaine Gigafactory, ou que tu te retrouves à t'occuper des projets de ton entreprise en plus de ton travail, abonne-toi. Ce podcast va simplifier la réussite de tes projets. Bonjour, bienvenue sur Focus Projet. Cette semaine, je reçois Johan Pagnoux, formateur et consultant en management de projet, qui va venir nous parler de la... du lien entre le produit et le projet et comment arriver à bien développer son produit tout en gérant correctement son projet, ce qui n'est pas forcément évident. Bonjour Yoann.

• Speaker #0

  Bonjour Tanguy, merci de me recevoir sur ton podcast.

• Speaker #1

  Tu peux peut-être commencer par te présenter un peu plus.

• Speaker #0

  Oui, bien sûr. Très rapidement, en quelques mots, comme tu l'as très bien dit, moi actuellement je suis formateur et consultant en management de projet depuis 4 ans maintenant. Auparavant, j'avais évidemment une expérience de chef de projet puisque j'ai repris mes études il y a une dizaine d'années. Et donc, j'ai pu voir différentes thématiques, que ce soit en tant que chef de projet et salarié ou avec mon propre activité. À la base, j'ai un cursus dans l'informatique, mais au fur et à mesure, j'ai pu voir d'autres types de projets en marketing, en RH, création un petit peu de sites Internet, toujours aussi en connexion avec l'informatique et même des projets formation, puisque en étant formateur, on est obligé de s'y mettre. Donc c'est différents projets que j'ai pu mener ou auxquels j'ai pu participer et qui aujourd'hui constituent un petit peu tous les ensembles des connaissances et des compétences que j'ai que j'apporte soit au travers de formations ou de consultings.

• Speaker #1

  Le sujet du jour c'est le lien entre le produit et les projets. Peut-être que tu peux commencer par définir les deux, à la fois ce qui est un produit et ce qui est un projet.

• Speaker #0

  Bien sûr. Un projet, ce n'est pas forcément le produit. Dans le projet, on va retrouver le produit, évidemment, mais le projet permet d'atteindre un résultat spécifique tout en gérant des paramètres qui sont inhérents à tout projet, coût, délai, qualité, ce sont des choses qu'on connaît. Le projet permet non seulement de les gérer, mais ensuite de répondre aux besoins du client ou de l'utilisateur. Et ça, ça passera forcément par le produit. Le projet va permettre non seulement la conception, la réalisation du produit, mais aussi la gestion de tous ces paramètres qui gravitent autour. Non seulement, comme je disais, le budget, le temps et la qualité, mais aussi tout ce qu'il va falloir mettre en place pour faire en sorte que le produit soit réalisable. Si jamais on parle de créer, je ne sais pas, par exemple une voiture, il y a une voiture qui va être créée, ça c'est le produit, mais derrière, il va falloir penser aux techniciens qui vont créer la... pour concevoir la voiture, ça c'est de la gestion de projet. Il faut avoir les bons techniciens qui puissent non seulement la concevoir, mais ensuite la réaliser. Il y a aussi toute la partie peut-être, les équipements, les unités de production, par exemple, ça aussi, c'est de la gestion de projet, qui rendront possible le produit. Et tout ça, en fait, constituera le projet en lui-même, qui permettra à la fin, comme je disais tout à l'heure, d'obtenir un bénéfice particulier.

• Speaker #1

  Tu as cité déjà plusieurs projets pour réaliser ce projet, au final.

• Speaker #0

  Exactement.

• Speaker #1

  C'est un peu au-delà avec un programme complet, mais c'est encore un autre sujet.

• Speaker #0

  C'est ça, mais c'est justement là où je voulais en venir, parce qu'en fait, on parle souvent de gestion de projet, mais les entreprises font de la gestion de portefeuille de projet, et dedans, on va retrouver plein de projets différents. Si je reprends le cas de la voiture, on va peut-être trouver dedans un projet marketing pour rendre visible la voiture, dire voilà, on en a créé une nouvelle, c'est une nouvelle gamme, et en fait, essayer de...... de convertir les intéressés en clients. Et au travers de ce projet marketing, il y a des objectifs spécifiques à atteindre. Atteindre tel niveau de client, pouvoir le diffuser sur tel niveau, tel canot d'acquisition par exemple, tout ça, c'est spécifique au projet marketing. Et après, comme je disais tout à l'heure, il y a d'autres projets qui vont venir se greffer à ça, ce qui va constituer un programme dans un portefeuille de projet.

• Speaker #1

  Donc, c'est un tout, et tout le but de l'ensemble, ça va être de développer le produit en lui-même.

• Speaker #0

  Voilà, c'est ça. Si je reprends mon cas marketing, le produit, ça va être la stratégie marketing. Et le produit, il va falloir le concevoir d'une certaine façon tout en gérant les aspects, comme je disais tout à l'heure, de coût, délai, qualité. avec les objectifs à atteindre à la fin.

• Speaker #1

  Pour continuer dans les définitions, comment va-t-on définir la gestion de produit et la gestion de projet ? Comment on les définit et quelles sont les différences ?

• Speaker #0

  Les deux ont un cycle de vie qui est particulier, mais qui n'est pas le même. Le produit a un cycle de vie beaucoup plus long qu'un projet en lui-même. De mémoire, c'est lancement, distribution, maturité, déclin. Donc en fait, au travers de ces étapes-là du cycle de vie du produit, il y a des projets qui vont se lancer en fonction de la position du produit dans son cycle de vie. Quand on est dans une phase de maturité, on va lancer des projets peut-être d'amélioration. Quand on est en une phase de lancement, on va lancer un projet de conception. Et le projet, lui, va avoir son propre cycle de vie, qui va être généralement, comme défini par le PMI, initialisation, planification, exécution, contrôle et clôture. Et en fait, au travers du projet, on va devenir un objectif spécifique à atteindre qui permettra d'avoir un produit peut-être en totalité ou un morceau du produit et le projet dépendra évidemment du produit dans sa position, dans son cycle de vie. Donc en fait, c'est la grosse différence. On a le cycle de vie du produit qui est défini de sa création jusqu'à son déclin et tout le long de son cycle de vie, on va lancer plusieurs projets. et chaque projet devra être bien spécifié, sera géré par différentes équipes, aura un budget spécifique, et c'est pour ça que les entreprises doivent à la fois imaginer le produit dans l'ensemble de son cycle de vie, pour ensuite anticiper les projets. Un projet de maintenance, ça peut coûter très cher, sauf que ce n'est pas le projet qui va être démarré dès le début. D'abord, on va lancer un projet pour concevoir le produit, un autre projet pour faire le marketing, comme je disais tout à l'heure. Mais tout ça, il faut l'anticiper parce qu'il faut pouvoir avoir le budget et se dire, si le produit, on le lance à la fin, combien ça va nous coûter tout le long du cycle de vie ? Et au travers de ça, on va pouvoir analyser, ce produit-là va nous coûter tant dans telle phase, il faudra lancer tel projet, il va falloir mobiliser telles équipes, etc. Donc le produit, si je pourrais résumer, c'est vraiment un cycle de vie qui est très long et au travers de ce cycle de vie, on va lancer différents projets qui auront eux aussi leur propre cycle de vie, qui permettront d'obtenir… Quelque chose de plus spécifique.

• Speaker #1

  Ça me fait penser à une définition particulière du projet. La définition, c'est que c'est un outil qui va permettre de changer l'état et de faire avancer le produit dans son cycle de vie.

• Speaker #0

  Exactement.

• Speaker #1

  Ce que tu me dis là illustre bien cet aspect-là. Le projet va être un outil qui va permettre de modifier le produit et de le faire évoluer dans son cycle de vie.

• Speaker #0

  Exactement. Et en fait, on fait constamment ce qu'on appelle de l'analyse de la valeur ou de l'ingénierie de la valeur. On essaie de voir ce que peut dégager comme bénéfice le produit, autant pour l'utilisateur que pour l'entreprise en elle-même. Ça va être des bénéfices spécifiques, bien différents, mais qui vont passer par le même produit. Et quand on lance un projet, comme tu disais, on est sur des phases beaucoup plus d'amélioration. Et on va toujours se poser la question, comment on peut améliorer le produit ? Qu'est-ce qu'on peut rajouter ? Qu'est-ce qu'on peut enlever ? Qu'est-ce qu'on peut optimiser ? Et derrière, quand on déclenche ce genre de projet-là, il faut le cadrer, savoir combien ça va coûter, qui va devoir travailler sur ça, combien de temps ça va prendre et quels résultats on veut obtenir à la fin. Et c'est comme ça qu'en fait le produit évolue dans son cycle de vie.

• Speaker #1

  Et c'est comme ça aussi qu'on fait les arbitrages entre plusieurs évolutions possibles et celles qu'on va finir par choisir.

• Speaker #0

  Et oui, voilà, c'est ça. Et il y a le ROI à la fin. Les entreprises ne font que, quand elles lancent un produit, enfin quand elles lancent différents projets au travers du produit, savoir en fait combien ça peut rapporter. Et on arbitre, comme tu dis très bien. Et comme je disais tout à l'heure, il y a des projets très différents dans un seul et même produit. Et il y en a certains qui vont être prioritaires plus que d'autres. Et donc, ils auront plus ou moins d'argent ou plus ou moins de ressources. Et c'est comme ça qu'une entreprise fait son management de portefeuille de projet.

• Speaker #1

  Pour rentrer peut-être un peu plus dans l'aspect opérationnel, quelles vont être les différences entre la gestion qu'on va faire du produit et la gestion de projet ? C'est deux choses qu'il faut gérer. Quelles sont les différences et les particularités qu'on va avoir dans les deux ? Si tu veux, on peut aussi commencer par les similarités, mais je pense que les différences sont peut-être mieux pour commencer.

• Speaker #0

  Oui, en fait, il faut bien comprendre que le produit, quand on le conçoit, on va choisir une approche spécifique. On va faire des itérations, on va faire de l'agile, on va faire du cascade, etc. Peu importe. Tout ça, ça nous permettra à la fin d'obtenir le ou les produits qu'on va vouloir développer. Et autour de ça, en fait, il va falloir faire de la gestion de projet. Et en fonction de ce qu'on va choisir comme mode de développement, si par exemple on est en itération, qu'on voit qu'on va devoir mettre en place 5 ou 6 itérations pour obtenir notre produit, eh bien on va devoir venir greffer. toute l'ensemble de la gestion de projet autour de ça. On a cinq ou six itérations. Combien on a besoin de ressources pour toutes les itérations ? Combien ça va coûter ? Combien de temps va prendre une itération ? Et là, on mêle à la fois la conception et la gestion du produit plus la gestion du projet. Donc après, il faut bien définir les deux. C'est-à-dire que, comme je disais tout à l'heure, un projet va amener la conception d'un produit qui va mettre en place une organisation spécifique. Comme je disais, on peut avoir cinq itérations par exemple. Et tout autour de ça, on va pouvoir développer notre projet. produit, puis gérer les aspects importants pour le client, coût, délai, qualité. Et comme je disais, on va avoir plusieurs projets qui vont se lancer au fur et à mesure du cycle du produit, et par rapport au produit en lui-même, ça va être un aspect beaucoup plus stratégique. En fonction des résultats qu'on a, de la stratégie qu'on souhaite employer, le produit en lui-même, eh bien, en fait, on va devoir se poser, se dire, bon, on est à telle étape du produit, il va falloir développer tel nouveau projet. avec telle nouvelle fonctionnalité, tel nouvel élément en plus pour l'améliorer, pour obtenir plus de valeur. Et là, en fait, on organise l'ensemble de notre projet. On part sur une itération, deux itérations, trois itérations. On part sur du waterfall, on fait quatre livrables, peu importe. Ça dépendra évidemment de ce qu'on veut faire. Mais les deux vont venir se greffer. Ce n'est pas juste la gestion de produit, on fait ça, la gestion de projet, on fait ça. On est obligé de mêler les deux. En fonction, comme je disais tout à l'heure, de la position du produit dans son cycle de vie, ça va déclencher un ou plusieurs projets. Et chaque projet va devoir être amené d'une façon différente, d'être organisé de façon différente. Et ça, on va devoir le cadrer à chaque fois. On ne pourra pas se dire, on ne fait que de la gestion de produits. Ça, ce n'est pas possible. Parce que derrière, on ne pourra pas gérer des aspects élémentaires de la gestion de projet, coûts, délais, qualités, ressources, risques et plein d'autres éléments qui sont inhérents.

• Speaker #1

  Oui, c'est sûr que… que notamment les risques, je pense, sont rarement pris en compte, voire pas pris en compte du tout dans la gestion de produits.

• Speaker #0

  Non, pas trop. Enfin, comme je disais un petit peu tout à l'heure, on essaie d'anticiper, en fait, quand on crée un produit, son cycle de vie. Quand on est dans une phase maintenance, par exemple, du produit, on anticipe les risques de dysfonctionnement. Ça, il faudrait le faire. Et malheureusement, ce n'est pas tout le temps le fait. Moi, j'aime bien prendre l'exemple de Toyota qui font que de la gestion de risques sur la conception de leurs produits. de leur voiture parce qu'en fait ils sont dans une démarche de ligne et eux pour eux le dysfonctionnement du produit c'est quelque chose qui ne peut pas apparaître dans leur démarche ligne donc ils sont tout le temps dans de l'analyse de risque à la fois fonctionnelle technique sur chaque voiture sur chaque produit sur chaque projet qui déclenche donc il faut autant le mêler sur l'aspect produit que projet autant sur la conception du produit que sur l'aspect livraison management des équipes ou management du budget etc

• Speaker #1

  Première similarité du coup, il faut quand même bien prendre les risques sur les deux. Tu as d'autres similarités et d'autres choses qui vont être assez similaires dans la gestion du produit et du projet ?

• Speaker #0

  Je dirais les estimations, puisqu'en fait,

• Speaker #1

  on a le budget aussi.

• Speaker #0

  Oui, il va falloir estimer le budget. Oui, c'est un très long sujet, très grand sujet, très passionnant pour certains en plus. Mais oui, il y a les estimations de budget, par exemple. Il faut autant estimer combien ça va nous coûter pour concevoir le produit. que pour faire le projet, avec tous les éléments qui vont graviter autour. Je disais tout à l'heure, la voiture, il y a la voiture en elle-même. Combien vont coûter les pièces pour créer la voiture, mais aussi combien ça va coûter pour employer les techniciens, pour mettre en place les unités de production ou des choses comme ça.

• Speaker #1

  Fabriquer l'usine.

• Speaker #0

  Et ça, il faut le calculer sur les deux.

• Speaker #1

  D'autres éléments, on a vu les risques, l'estimation, je ne sais pas, dans les décimilarités, peut-être plus dans le... dans les modes de fonctionnement et de gestion ? Je ne sais pas si tu en as à donner ou pas.

• Speaker #0

  Alors comme ça, peut-être qu'il y a des similarités qui vont se faire. Mais généralement, ça va être quelque chose qui va être interconnecté puisqu'on ne peut pas faire de produit sans projeté pour moi et inversement. Cependant, on va pouvoir utiliser évidemment des outils spécifiques. Si par exemple, on souhaite développer un produit, à la base, c'est pour résoudre un problème. Donc, on va faire de la résolution de problème. On va utiliser des outils pour savoir d'où vient le dysfonctionnement et essayer de le régler. Et en fait, c'est la même chose quand on gère des équipes. À un moment donné, on va faire de la gestion de conflits, il y a des problèmes qui vont se créer dans notre équipe, on va essayer de comprendre pourquoi, essayer de le régler et mettre en place des solutions pour ça. Donc en fait, il y a même, j'ai envie de dire, de la gestion de produits, même quand on fait un projet dans nos équipes. On met en place des éléments qui vont nous permettre de faire notre travail. Et ça, c'est la même chose, on gère ça de la même façon. On va devoir comprendre d'où vient le problème et ensuite mettre en place nos éléments, nos outils qui nous permettront de faire notre activité et derrière de pouvoir réaliser le produit qu'on souhaite obtenir à la fin. Donc on a des outils qui sont assez transverses et qui peuvent s'appliquer autant sur la conception du produit que la gestion du projet. Il faut juste en fait les connaître avant tout et savoir comment on peut les appliquer.

• Speaker #1

  Des exemples peut-être de ces outils dont tu nous parles ?

• Speaker #0

  Oui, là le premier qui vient en tête, c'est peut-être le diagramme Ishikawa. C'est un des outils qui est assez connu, c'est le fameux diagramme en arrêt de poisson. En fait, on va analyser les différentes thématiques.

• Speaker #1

  L'analyse des causes, c'est bien ça ?

• Speaker #0

  Voilà, l'analyse des causes qui permettent de savoir d'où vient le problème. Si par exemple, on a un problème de conflit dans l'équipe, on essaie de savoir pourquoi. Est-ce que c'est un problème matériel ? Exemple. un problème de méthode, de management. C'est à nous de voir. Et quand on essaie de mettre en place un produit, si par exemple on a un produit qui fonctionne mal, on essaie de savoir d'où vient le dysfonctionnement. Est-ce que c'est un problème mécanique, donc matériel ? Est-ce que c'est un problème de méthode, donc de méthode de production ? Est-ce que c'est un problème de main-d'oeuvre parce que les gens n'ont pas assez de compétences pour le faire ? C'est la même chose. On essaie de lister un petit peu les causes qui amènent au dysfonctionnement. Et un deuxième outil aussi, on parlait de l'analyse des risques tout à l'heure, Pour moi, je vois que l'AMDEC peut faire autant sur le produit que sur le projet. On essaie d'analyser au préalable les risques qui peuvent apparaître, on calcule leurs criticités, et après on essaie d'y apporter des solutions, soit pour essayer de diminuer le risque, soit pour essayer de l'éliminer, soit pour le transférer, etc. Et ça, c'est autant sur le produit que sur la gestion du projet en lui-même.

• Speaker #1

  Pour avancer, du coup, dans les entreprises ? Il y a toujours un peu cette question entre les rôles liés aux produits et aux projets. Quelle est pour toi l'organisation ou en tout cas la différenciation qu'il est nécessaire de faire ? Je sais qu'après, les organisations sont forcément adaptées à la taille de l'entreprise et à sa manière de fonctionner. Mais peut-être, d'une manière générale, les grandes lignes qui te paraissent nécessaires pour bien faire cette différence entre les deux et arriver à ne pas gérer le produit comme on gère le projet et inversement.

• Speaker #0

  C'est ça. Donc déjà, il y a toujours la partie un petit peu client et moi, ce que j'appelle l'équipe technique. Sachant que l'équipe technique, ça peut être une équipe en interne comme un sous-traitant. Quand on est dans une configuration d'entreprise qui est un petit peu plus grosse, qui a un peu plus de moyens, qui n'a pas les moyens en fait en interne de développer son produit. Cependant, donc, il y a deux aspects. L'aspect business, donc ça, c'est côté client. On va s'imaginer le produit, comment il peut nous rendre service, comment on va pouvoir le commercialiser. Comment on va pouvoir le mettre en valeur pour le vendre, par exemple, ou comment il va nous aider à être plus productif. Et derrière, on va travailler avec une équipe technique qui va nous apporter la solution technique et qui va rentrer en correspondance avec nos objectifs business qu'on souhaite atteindre. Donc, en fait, il y a des rôles qui vont se spécifier ensuite. On a le client. Du côté client, on va avoir peut-être une équipe produit, peut-être qu'il y a un produit déjà existant qu'on souhaite améliorer avec des objectifs business particuliers. et donc une équipe technique va nous apporter la ou les solutions techniques. Mais ensuite, on a en fait, dans un aspect peut-être un petit peu plus réduit, quand on a une petite entreprise par exemple, là on peut très bien se faire aider par un consultant externe si on n'a pas les moyens en interne. Donc là, on va faire de l'assistance à maîtrise d'ouvrage par exemple et des rôles vont se définir et peut-être même que l'assistance à maîtrise d'ouvrage va se transformer en maîtrise d'œuvre ensuite. Donc il y a toujours cet aspect business et ensuite technique. plutôt côté opérationnel. Et là, il y a des rôles qui vont se créer. Suivant l'entreprise, si elle est grosse ou pas, il y a des rôles plus spécifiques qui vont se créer. Il y a des chefs de produit, par exemple. Il y a des business analysts qui vont récupérer les données qui vont permettre de lancer de nouveaux projets. Il y a des équipes techniques très spécifiques qui vont pouvoir créer des produits de manière très spécifique. Et là, ça dépendra évidemment de la grosseur de l'entreprise et du projet à mener.

• Speaker #1

  Si je comprends bien, plutôt la partie business qui va représenter le produit et sa volonté d'évolution, c'est bien ça. Et une partie plus technique qui va être l'équipe projet et qui va du coup mener à bien cette évolution.

• Speaker #0

  Exactement. Généralement, on n'a pas énormément, je pense, de projets de réelle innovation et de nouveaux produits qui n'existent pas. Généralement, les entreprises ont déjà un existant. qui est là depuis un petit moment et qu'elles essayent d'améliorer continuellement, soit pour prolonger le cycle de vie du produit, parce qu'on essaie de faire en sorte de le prolonger autant que possible, soit parce qu'à un moment donné, le produit est devenu obsolète, il faut le changer, mais il faut que ça réponde aux mêmes besoins à la base. Donc, on va peut-être créer un produit beaucoup plus évolué, beaucoup plus fonctionnel, beaucoup plus performant, mais qui en substance répondra aux mêmes besoins. Donc là, on aura toujours des phases d'amélioration qui vont déclencher des projets et là, une équipe projet va se créer. qui permettront d'atteindre les objectifs business d'entreprise.

• Speaker #1

  Pour revenir un peu là-dessus, je pense que l'élément principal pour toi, c'est d'arriver à quand même bien séparer ces deux aspects, la partie technique qui va correspondre à la gestion de projet et la partie business qui est la volonté d'évolution du produit et d'une certaine manière la gestion du produit en lui-même. en lien avec les objectifs business de l'entreprise.

• Speaker #0

  Oui, c'est ça. Sachant qu'il ne faut pas que les deux soient séparés non plus. Il faut qu'ils travaillent ensemble. Voilà, c'est exactement ça. Je pense que tu le sais très bien.

• Speaker #1

  Il y a forcément des liens et c'est fortement lié. On est d'accord, mais…

• Speaker #0

  Mais par exemple, le produit, le produit en lui-même, quand il va être conçu techniquement, c'est l'équipe technique qui le fait. Ce n'est pas normalement le client qui va dire je veux ça techniquement. À part si c'est un expert technique, dans ce cas-là, c'est lui qui le fait. Il n'a pas besoin d'une équipe projet. Mais en soi, quand une équipe technique va définir le produit, c'est elle qui est maître du produit techniquement, c'est elle qui va devoir cadrer comment elle va le développer, comment en fait il va être réalisé. Derrière, il y a un chef de projet qui va les aider à bien gérer le budget qu'il leur a attribué, la gestion des ressources, etc. Et ça permettra la réalisation du produit ou des fonctionnalités, juste la gestion des livrables en globalité. Comme je disais tout à l'heure, il n'y a pas que le produit en lui-même, il y a peut-être des plans, il y a peut-être la réduction d'un cahier des charges. Il y a peut-être des rapports de test à la fin qui devront être livrés. Tout ça, ça fait partie du produit.

• Speaker #1

  C'est l'ensemble, mais ça fait aussi partie du produit. C'est tout ce qui permet d'arriver à son but. Ce n'est pas forcément l'objet ou le service final.

• Speaker #0

  Non, c'est ça. L'objectif du projet, comme je disais, c'est à la fois livrer le produit, mais tout ce qu'il y a autour. Parce qu'il y a un transfert qui va se faire ensuite de l'équipe projet au client. Donc, il y a toute une phase de documentation à faire, par exemple. Et en fait, la documentation, lui, le client va la récupérer. Et si jamais il a un problème, il est obligé de consulter la documentation ou ça l'aidera peut-être à déclencher de nouveaux projets ensuite parce que ça lui permettra de transférer ça à une autre équipe. Ils verront, ils ont fait ça avec telle technologie, ils ont produit ça, ils ont mis ça en place. Nous, on va pouvoir récupérer ça et faire une amélioration du produit.

• Speaker #1

  Peut-être des conseils à donner sur la gestion de projet et la gestion de produit pour finir ?

• Speaker #0

  Alors, le premier que je donne toujours, c'est partir du besoin constamment. Parce qu'on parle de produit, on parle de projet, mais c'est vrai que quand on se positionne en tant qu'entreprise, si on veut le produit en lui-même, on s'en fiche. Ce qu'on veut, c'est les résultats à la fin. Donc, il faut toujours se positionner par rapport aux besoins à satisfaire. Tout à l'heure, je parlais de voiture. Ce n'est pas une voiture dont j'ai besoin, c'est de me déplacer. Après, ça peut être une voiture, ça peut être autre chose. Ce n'est pas la solution, le produit qui compte. C'est quel résultat j'obtiens à la fin. Donc, moi, le conseil que je donne par rapport à ça, c'est toujours partir du besoin et avoir cet aspect. à la fois fonctionnelle et technique. Fonctionnelle pour bien comprendre le besoin, bien définir les objectifs à atteindre, pouvoir les quantifier, pouvoir mener nos premières estimations. Et après, la partie technique, évidemment, pour trouver là où les solutions et ensuite planifier l'ensemble de la livraison de notre projet et gérer les aspects connexes. Donc, budget, communication, ressources, risques, etc.

• Speaker #1

  Autre chose ou d'autres questions que j'aurais oublié de poser éventuellement ?

• Speaker #0

  Non, non, non, mais je conseillerais aux gens de se tourner sur des pratiques qui existent depuis très longtemps. Il n'y a pas que les approches agiles, par exemple, sont très, très efficaces sur certains points, mais il n'y a pas que ça. Il y a des outils qui existent depuis très longtemps en termes de conception de produits ou de gestion de projets qui ne changeront pas forcément comme ça. Donc, ne pas rester en fait focus que sur une seule méthode, une seule pratique, une seule approche. Essayez de s'ouvrir le champ des possibles. Quand on est chef de projet, on est censé avoir une boîte à outils. Et dans cette boîte à outils, on va venir piocher l'outil, l'approche, la méthode qui nous convient. Donc, il ne faut pas rester focalisé que sur une seule pratique. Il faut voir l'ensemble. Moi, dans mon domaine, je suis autant sur la conception de produits que sur la gestion de projets, que sur des approches traditionnelles, que sur des approches agiles. Et ça, c'est un petit peu fondamental quand on est dans ce domaine-là. Parce que si à un moment donné, on est en face d'un client et qu'on... On ne peut pas l'aider parce qu'on n'a pas la solution, c'est justement parce qu'on n'a pas les solutions à notre disposition pour pouvoir l'aider. Donc ça, c'est fondamental pour chacun.

• Speaker #1

  Pas forcément assez d'outils ou de méthodes pour trouver l'élément adapté.

• Speaker #0

  Exactement, c'est ça. Donc il faut autant que possible se former, évidemment, et pratiquer, essayer de découvrir autant que possible de nouvelles pratiques qui sont... peut-être pas forcément qu'horrescentes. Il y a des outils d'il y a une centaine d'années qui sont toujours appliqués. Et puis, garder cette ouverture d'esprit. Ça, c'est fondamental. Et apporter de la nuance dans les outils, ne pas se dire ce outil ne marche pas, il est obsolète, donc je ne l'utilise pas. Ce n'est pas vrai. Il n'est peut-être juste pas adapté à la situation. Voilà, c'est ça. Ça dépend du contexte.

• Speaker #1

  Très bien. L'outil à adapter au contexte, je pense que tu n'es pas le seul à le dire. Mais je pense qu'on ne le dit toujours pas assez.

• Speaker #0

  Ah oui, je suis tout à fait d'accord. Il faut le marteler constamment, constamment, constamment, parce que sinon, on se retrouve avec des gens formatés qui n'appliquent qu'un seul outil. Et puis, quand ça ne marche pas, on va taper sur l'outil, pas sur la personne qui, en fait, ne connaît qu'un seul outil.

• Speaker #1

  Merci à toi pour cette intervention. Ce qu'on a oublié de dire aussi, c'est que tu as un podcast toi aussi, Project It, c'est ça ?

• Speaker #0

  Oui, c'est ça. J'ai un podcast format audio et vidéo. J'ai une chaîne YouTube, les gens peuvent aller le voir s'ils le veulent. Je propose des prestations diverses et variées, mais si vous voulez juste du contenu gratuit, il y a mon podcast et ma chaîne YouTube. Puis s'ils veulent me suivre aussi sur LinkedIn, il n'y a aucun souci, je poste pas mal de choses de temps en temps. Merci à toi Tanguy de m'avoir invité. J'espère qu'il y aura d'autres intervenants qui viendront, peut-être pas forcément confortés, mais apporter de nouvelles choses que moi j'ai pu apporter aujourd'hui.

• Speaker #1

  Oui, l'idée est de continuer cette série de podcasts, donc ça devrait arriver prochainement. Merci et à bientôt.

• Speaker #0

  Merci à toi.

• Speaker #1

  Au revoir. Merci Yoann encore une fois pour cette discussion autour des projets, des produits et de leur interaction. J'espère que... que cet épisode vous aura permis de mieux comprendre l'articulation entre la stratégie d'entreprise, ses produits et ses projets. Vous souhaitez approfondir le sujet ? Venez nous partager votre point de vue et vos questions sur LinkedIn. On en discutera ensemble. Si cet épisode vous a plu, abonnez-vous à Focus Projet sur votre plateforme préférée et parlez-en autour de vous. A la semaine prochaine !