Liens connexes :
- Comment élaborer un plan de gestion de la qualité
- 10 meilleurs logiciels de gestion de projet de 2023 : revue d’experts
- Les meilleurs outils de gestion des exigences de 2023
- Les meilleurs outils de suivi des bugs pour identifier, suivre et résoudre les problèmes plus rapidement
- Chef de projet ou leader de projet ? (avec Rebecca Germond)
- Le podcast du Digital Project Manager – Apple Podcasts
- Le podcast QA Lead
- Formation en gestion de projet
- Rejoignez notre communauté de membres
- Rejoignez la communauté Digital Project Manager
Lisez la transcription :
Nous testons la transcription automatique de nos podcasts à l’aide d’un logiciel. Merci de pardonner d’éventuelles fautes, le robot n’est pas fiable à 100 %.
Ben Aston :
C’est frustrant quand les choses ne fonctionnent pas, et quand on passe des semaines, voire un mois, à construire un projet pour finalement être trahi par un bug sournois lors de la recette utilisateur finale. Mais pourquoi cela arrive-t-il presque toujours et peut-on y faire quelque chose ? Eh bien, si les bugs vous dérangent, continuez à écouter puisque dans l’épisode du jour, nous allons voir comment bien faire les choses grâce à un produit et un processus améliorés, et la magie d’un plan de gestion de la qualité.
Merci de nous écouter. Je suis Ben Aston, fondateur de project managers. Bienvenue sur le podcast DPM. Nous avons pour mission d’aider les chefs de projets à réussir, d’aider les personnes qui gèrent des projets à livrer mieux. Nous sommes là pour vous permettre de passer au niveau supérieur dans votre gestion de projet. Rendez-vous sur thedigitalprojectmanager.com pour en savoir plus sur nos formations et ressources proposées via l’adhésion. Ce podcast est sponsorisé par Clarizen, le leader des logiciels de gestion de projets et de portefeuilles à l’échelle de l’entreprise. Visitez clarizen.com pour en savoir plus.
Aujourd’hui je suis en compagnie de Michael Luchen qui est l’un de nos experts DPM résidents. Il est coach produit chez Crema, une agence numérique qui conçoit des applications web et mobiles pour des sociétés disruptives et leaders de leur secteur. Il travaille normalement à distance depuis Washington D.C. et aide ses clients à améliorer leur collaboration pour analyser et résoudre des problématiques complexes. Il a travaillé avec Adidas, Callaway Golf, entre autres, et il est coach chez Crema. Nous allons donc discuter aujourd’hui avec lui sur la mise en place d’un plan de gestion de la qualité. Bonjour Michael et bienvenue sur ce podcast.
Michael Luchen :
Salut Ben, comment ça va ?
Ben Aston :
Ça va bien, merci. Je suis curieux car cela fait des années qu’on discute et enregistre des podcasts, ton rôle a évolué et je m’intéresse justement à ton poste actuel de coach, qui est un nouveau titre si je comprends bien. Peux-tu nous expliquer en quoi consiste ce rôle de coach ? Coach produit – qu’est-ce que ça signifie chez Crema ?
Michael Luchen :
Oui. Comme tu l’as mentionné, cela fait environ sept ans que j’exerce concrètement en gestion de projets et de produits. Et pour tout dire, ce poste est encore en définition actuellement. On essaie de cerner ce que signifie “coach” chez Crema. Pour l’instant, on l’aborde comme un leader-serviteur, en aidant les clients à comprendre la mise en pratique Agile afin qu’ils deviennent la meilleure version d’eux-mêmes. Typiquement, je peux servir de facilitateur, stratège produit ou de penseur design pour les aider à reformuler les problèmes et trouver des approches innovantes. Mais ce qui me plaît dans ce nouveau rôle et cette nouvelle aventure pour Crema, c’est l’essai de créer une différence sur un marché très concurrentiel en l’abordant d’un angle vraiment unique et non prescriptif. Il existe énormément de processus de coaching prescriptifs, et nous souhaitons être différents.
Ben Aston :
Donc, dans ce rôle, tu interviens avec une petite équipe, directement avec le client. Est-ce que c’est un poste plus stratégique lorsqu’il s’agit de définir la roadmap du projet ou du produit ?
Michael Luchen :
Oui, tout à fait–
Ben Aston :
Ou c’est plus axé sur la livraison ?
Michael Luchen :
…C’est un mélange de ce que tu viens d’évoquer. C’est un peu plus large, plus centré sur les personnes. Ce que j’aime dans la gestion de projet, c’est de pouvoir me concentrer sur la création d’un environnement sain pour que les équipes puissent donner le meilleur d’elles-mêmes. Donc ce rôle consiste surtout à transmettre aux clients des outils et une mentalité pour leur permettre d’instaurer une culture et un environnement productifs et sains dans leurs équipes, afin d’obtenir d’excellents résultats.
Ben Aston :
Et donc, quels types de défis rencontres-tu en aidant les clients à faire évoluer leur approche de la livraison ?
Michael Luchen :
Oui, il y a de nombreux défis, mais je pense que le principal tient au fait que les résultats ne sont pas toujours immédiats. Ce n’est pas quelque chose où j’arrive en disant : “Faites ceci et ça ira mieux.” On propose souvent ce type de choses, “apprenez la méthode X et votre équipe réussira”. Mais ce qui importe, c’est d’avoir le contexte global de la culture dans l’organisation et de comprendre que, quand on cherche à responsabiliser les leaders, il faut du temps pour expérimenter et voir comment ces apprentissages s’intègrent.
Ben Aston :
Oui, absolument. Je pense moi aussi qu’il n’existe pas de processus universel qui conviendrait parfaitement à toutes les organisations ou agences. Si on suit simplement les étapes, on n’obtiendra pas comme par magie ces résultats extraordinaires. Il n’existe pas de recette miracle, de “balle d’argent” qui résoudra tous les problèmes soudainement. Certains pensent parfois “Oh, l’Agile, c’est la solution”, mais il faut bien définir ce que cela implique. Ton rôle semble donc passionnant. Tu l’exerces principalement à distance ou vas-tu parfois chez les clients ?
Michael Luchen :
C’est un mélange des deux. Actuellement, pendant cet enregistrement, c’est 100 % à distance. Mais je pense qu’on crée de belles relations en personne, donc c’est toujours mieux si on peut démarrer le coaching en présentiel. J’ai tout de même constaté qu’il est tout à fait possible de mener une conversation productive et engageante via Zoom ou Loom Screen Shares pour conseiller, répondre à des questions ou collaborer sur des boards mural. On peut donc vraiment le faire dans les deux contextes.
Ben Aston :
Oui, et puisqu’on parle du travail à distance… On est en pleine quarantaine liée au Corona, et tu as récemment animé un atelier sur ce thème pour nous. Pour ceux qui l’ont manqué, ou même maintenant alors que tout le monde travaille à distance, quels sont, selon toi, les hacks ou techniques les plus efficaces pour ne pas devenir fou quand on travaille seul de chez soi ? Comment éviter la solitude du télétravail ? Je sais que d’habitude tu allais parfois dans des espaces de coworking. As-tu des conseils pour garder le moral ?
Michael Luchen :
Très bonne question et d’actualité ! Mentalement, j’essaie de me rappeler que je collabore avec d’autres êtres humains. Donc faire autant de visioconférences Zoom que possible a été très précieux. Ça paraît simple, mais dans cette période – et quand on voit que Zoom est l’appli gratuite la plus téléchargée – il faut prendre le temps de collaborer vraiment. Je saute volontiers sur un appel Zoom avec mon équipe pour discuter, car voir le langage non verbal a énormément de valeur, surtout en gestion de projet. Je me débrouille même parfois pour garder un deuxième écran uniquement pour voir les visages même quand je partage le mien.
Ben Aston :
Bon conseil ! Zoom est un super outil, et on a tendance à zapper la communication non verbale, surtout quand on échange par Slack et qu’on oublie que discuter en visio permet aussi de nouer des liens. Donc habillez-vous et faites un Zoom, ça vaut le coup !
Tu parles de coaching, à distance et en présentiel. Peux-tu donner des exemples de projets sur lesquels tu travailles actuellement ?
Michael Luchen :
En ce moment, je termine complètement ma transition de la gestion produit vers le coaching. Je finalise un gros projet de développement sur plusieurs années, et c’est super chouette de l’aborder avec un œil de coach car il y a beaucoup d’interactions entre les deux quand on ramène le coaching au niveau praticien. Sinon, je prépare l’offre et la différenciation de nos futurs services de coaching, et la façon dont Crema veut faire la différence pour servir ses clients avec humilité et assurance.
Ben Aston :
En réfléchissant aux difficultés que rencontrent les clients et auxquelles tu réponds, quels sont les principaux écueils de livraison que tu identifies et que tu pourrais transformer en opportunités dans ce nouveau rôle ?
Michael Luchen :
Oui, j’ai trouvé une métaphore intéressante : on aborde le coaching comme un semestre universitaire, car je pense que l’efficacité du coaching passe beaucoup par l’expérimentation. Les personnes coachées apprennent plus en expérimentant par elles-mêmes. Mon rôle est donc davantage celui d’un facilitateur, d’un guide et mentor avec une expérience terrain.
Il s’agit d’organiser des points réguliers, des rétrospectives, d’observer, de partager des notes, de dire : “Essaie ceci lors de ta prochaine réunion.” Il s’agit surtout de créer un rythme pour qu’au bout de quelques semaines ou mois, on puisse se retourner et constater l’amélioration. Que l’équipe est capable de produire plus.
Ben Aston :
Lorsque tu aides une organisation à devenir plus Agile, comment l’aides-tu à hiérarchiser les zones à améliorer ? Dans un grand groupe, il y a plein de process. Comment aider à déterminer les aspects prioritaires à aborder sous l’angle Agile ?
Michael Luchen :
Je commence par un questionnaire, une discussion. Pas juste avec un seul interlocuteur, mais aussi avec des chefs de projets, des développeurs, d’autres parties prenantes. Ce questionnaire sert à cerner la perception de ce qui est essentiel à résoudre. Ensuite, avec mon équipe, on analyse à la fois les réponses formelles et ce qu’il y a en filigrane, afin de recommander d’agir sur deux ou trois domaines pour obtenir rapidement des résultats significatifs.
Ben Aston :
Très malin. Bonne chance à toi avec tout ça !
Michael Luchen :
Merci.
Ben Aston :
Je voudrais revenir sur ton article et le thème de départ, la gestion de la qualité. Si vous ne l’avez pas lu, jetez-y un œil sur thedigitalprojectmanager.com. Il s’intitule “Comment élaborer un plan de gestion de la qualité”. Michael y détaille étape par étape la création du plan de qualité. Pour nos membres, vous pouvez accéder à des modèles tels que le plan de gestion qualité, la liste des appareils cibles, ou le template de contrôle qualité, pour tout mettre en application facilement.
On ne va pas trop détailler ici le processus, mais en résumé Michael explique comment créer un plan qualité pour votre projet ou produit. Je voudrais commencer par cette notion : la définition de la qualité. Pourquoi, selon toi, est-ce si compliqué à cerner ?
Michael Luchen :
Oui, tout d’abord, pour planter le décor, je vois la qualité sous deux angles : la qualité du produit et la qualité du processus. La qualité du produit, c’est la qualité concrète de votre livrable (physique ou numérique) : tout ce que l’équipe design et/ou développement livre… La qualité du processus, c’est là où le PM intervient beaucoup : cela concerne la façon dont on gère le projet pour permettre à l’équipe d’avoir de bons résultats. Un indicateur que l’on connaît tous par exemple est la vélocité d’équipe.
Obtenir une compréhension commune de la qualité est compliqué car c’est très subjectif – et parfois émotionnel. Il y a de nombreux acteurs, chacun avec des attentes différentes. Par exemple, le client veut que la qualité réponde à ses attentes, tandis que le développeur veut du code propre et parfait. Il faut donc faciliter l’équilibre entre ces approches.
Ben Aston :
Oui, parlons justement de cet équilibre ! Pour moi c’est un peu un casse-tête. En Agile, on définit des critères d’acceptation pour chaque user story. On dit “voici ce que doit faire cette tâche, ces critères doivent être remplis pour que ce soit terminé”.
Ensuite, il y a une définition du “terminé” applicable à toutes les user stories. Avec l’Agile, on raisonne “livraison de valeur en itératif”. Parfois, j’ai l’impression que la notion de qualité entre en conflit avec l’agilité où il y a la question : qu’est-ce qui compte le plus ? Les critères d’acceptation ? La valeur livrée ? Faut-il avancer plus lentement pour conjuguer les deux ?
Michael Luchen :
Excellente question, j’adore car elle touche à ce que j’aime dans le métier. Pour moi, le focus sur la qualité n’est pas en opposition avec l’Agile—au contraire, c’est un accélérateur, un facilitateur pour les équipes agiles. Quand une équipe définit ensemble dès le début ce qu’est (et n’est pas) la qualité, cela sert de guide, de “pare-œillères” sains pour avancer et livrer en gardant le bon cap.
Et même dans l’exécution, les critères d’acceptation sont aussi des outils au service de l’Agile. Si, par exemple, une équipe bosse sur une user story mais rencontre une difficulté technique et doit modifier un critère, on ouvre la discussion, on l’ajuste rapidement, et cela sert la qualité sans tout ralentir pour autant.
Ben Aston :
C’est plutôt une question de posture : la qualité fait partie de la valeur délivrée, on ne doit pas les opposer. Si on livre quelque chose qui ne correspond pas au niveau de qualité défini, c’est qu’on n’apporte pas toute la valeur possible. Repenser la qualité comme un composant central de la valeur produite, c’est essentiel.
Michael Luchen :
Absolument.
Ben Aston :
Tu abordes la question du partage des responsabilités autour de la qualité. Souvent dans les grandes agences il y a une équipe QA, parfois c’est le PM ou le dev qui s’y colle. Tu insistes sur l’importance d’un véritable testeur : pourquoi, selon toi ?
Michael Luchen :
Question pertinente. Par expérience, à mes débuts, c’est moi qui faisais la QA ! Maintenant je travaille avec des ingénieurs tests, et ça change tout. Leur regard critique est primordial. C’est, à mon sens, le meilleur partenaire du chef de projet. Ils examinent les détails techniques et la globalité de ce qu’on livre à l’utilisateur, ce que personne d’autre ne fait au sein de l’équipe. Quand ils sont intégrés, ils bonifient le travail des devs, designers… et bien sûr le mien.
Ben Aston :
C’est vrai que l’approche d’un testeur ou d’un QA est très différente de celle d’un PM. En tant que PM, on testera sur le “chemin idéal”, car on sait comment ça doit marcher, et on aimerait que ça marche pour ne pas perdre de temps. Mais le spécialiste QA va vraiment chercher à casser le produit, faire des tests exploratoires, trouver des cas limites. C’est ce niveau de rigueur qui fait qu’au final, on livre un produit bien plus solide.
Ça soulève une question : quand il s’agit de déterminer la liste des appareils cibles, c’est toujours délicat – surtout quand les clients ont encore de vieux téléphones ou veulent que ça marche partout, même sur d’anciens navigateurs. Comment fais-tu pour poser des limites et accompagner le client là-dessus ?
Michael Luchen :
Déterminer les appareils cibles est un de mes exercices préférés ! Cela permet de concentrer les efforts sur la qualité mais aussi de se recentrer sur ce qu’on veut vraiment offrir à l’utilisateur.
Quand un client veut que ça fonctionne partout, cela ouvre justement la discussion sur les besoins réels des utilisateurs. Parfois, il s’agit quand même d’applications très spécialisées… donc parfois il faut ce support. Mais l’objectif est de prioriser selon l’essentiel et le temps disponible, afin de cibler là où ça compte et éviter de se disperser.
Ben Aston :
Oui ! Juste un conseil : quand vous rédigez votre cahier des charges ou les critères d’acceptation, soyez précis sur quels appareils vous allez supporter, et n’écrivez pas juste “tous les mobiles et desktop à jamais”, car vos produits ne fonctionneront pas dans tous les cas, et les navigateurs changent tout le temps. Fixer précisément la liste permet d’éviter bien des soucis par la suite.
Pour les scénarios de tests, entre TDD (test-driven development), test “sur le tas” ou avec une documentation très poussée : quelle méthode préconises-tu pour générer le plus de valeur ?
Michael Luchen :
Chez Crema, l’idée c’est que la qualité est l’affaire de tous. Les développeurs pratiquent le test driven development (TDD) pour garantir les intégrations-cles dans le code, puis quand la fonctionnalité arrive au testeur, celui-ci peut se concentrer sur les tests manuels, explorer des cas limites et rédiger des tests automatisés.
Ben Aston :
Oui, mais si tout le monde est responsable, personne ne l’est vraiment ! Concrètement, comment impulsez-vous la qualité comme valeur clé de l’organisation ?
Michael Luchen :
Il faut commencer par l’éducation : avoir un canal Slack dédié à la qualité, en discuter régulièrement… Mais surtout, côté process, le chef de projet doit mettre en place des contrôles qualité tout au long du cycle. Par exemple, sur JIRA, on configure des jalons pour le code review avant passage sur la préprod, puis une phase QA, etc. On peut ainsi vérifier à chaque étape que la couverture des tests est suffisante.
Ben Aston :
Intégrer la qualité au process même, ce n’est pas juste “on développe puis on teste vite fait”. Le test et la QA font partie du développement. Même les tests unitaires. Ça soulève la question de l’automatisation des tests : quelles sont les limites ? Quand est-ce que ça vaut le coup de les automatiser ?
Michael Luchen :
Bonne question. Les tests manuels sont faciles à mettre en place, idéals pour des expériences utilisateurs complexes ou dans le cas où automatiser prendrait trop de temps (par exemple, les interactions drag-and-drop). Les tests automatisés sont parfaits pour des tâches répétitives, comme des formulaires complexes à remplir. Bonus : si votre testeur automatise la saisie avec tous les caractères farfelus, c’est le top !
Ben Aston :
Ça rejoint ton approche du plan de gestion de la qualité : bien faire, en intégrant ça au process mais aussi en adaptant méthodologies et tests à chaque projet et composant. Cela semble très organique, évolutif – comment arrives-tu à l’équilibre pour être sûr de prendre la bonne direction ?
Michael Luchen :
Bonne question. J’aime beaucoup cette idée de processus organique. Comme pour la vélocité qu’on mesure sur quelques sprints, il faut ajuster au fil du projet. L’article offre un bon cadre pour débuter, mais il faudra ajuster selon l’expérience, surtout si l’équipe se découvre. L’important, c’est d’être ouvert à l’évolution, sans changer du tout au tout non plus. Parfois, après lancement, la liste des “devices” doit évoluer car personne n’utilise certains appareils. Il faut savoir s’adapter, tout en capitalisant sur l’expérience du projet précédent.
Ben Aston :
Le bon sens est primordial en gestion de la qualité. On peut tomber dans l’excès inverse, vouloir “surdocumenter” et faire du contrôle pour le principe, alors qu’il faut adapter – comme tu le dis. C’est la voie d’un Agile réaliste : on a des planifications, mais aussi la souplesse pour du test exploratoire quand il le faut, afin de livrer plus de valeur…
Michael Luchen :
Exactement.
Ben Aston :
Nous venons justement de lancer un podcast sur notre site partenaire, intitulé QA Lead. Si la QA vous intéresse ou si vous travaillez avec des ingénieurs QA, faites-leur découvrir QAlead.com. Et pour les chefs de projet, lisez bien l’article, il est hyper complet et contient des modèles accessibles via l’adhésion.
Si vous n’avez jamais utilisé de plan de gestion de la qualité, essayez-en un ! Cela vous fera réfléchir à votre process, vos projets et produits, et vous permettra de livrer plus de valeur grâce à une meilleure qualité.
Tes conseils sont précieux, mais ce qui m’a le plus marqué, c’est qu’au fond, l’état d’esprit qualité doit se cultiver dans toute l’organisation. Ingénieur QA ou non, il faut intégrer cette pensée qualité, pas seulement se demander “est-ce cassé ou pas ?”. La qualité, c’est aussi le reflet de nos process, de toute l’organisation, de la façon dont on travaille et s’améliore. Merci beaucoup Michael pour tes éclairages !
Michael Luchen :
Merci à toi.
Ben Aston :
Et vous, qu’en pensez-vous ? Quelles sont vos astuces pour livrer des produits/projets de qualité ? Partagez vos conseils, succès ou échecs en commentaires.
Pour aller plus loin et progresser dans votre carrière, rejoignez la communauté DPM via thedigitalprojectmanager.com/membership pour accéder à notre Slack, des modèles, ateliers, permanences, eBooks et bien plus. Si l’épisode vous a plu, abonnez-vous et restez connectés sur thedigitalprojectmanager.com. Merci de nous avoir écoutés et à bientôt !
