Une IA pour une conduite de projet assistée

Silvere Duval
Just-Tech-IT
Published in
6 min readFeb 10, 2023

Oublions l’effet de mode et profitons-en pour utiliser l’IA (ou Intelligence Artificielle) comme une aide dans notre rôle de Product Owner ! Devenons les early adopter de cet outil qui va sûrement être de plus en plus présent dans votre vie !

Une conduite assistée comme pour une voiture

Malgré votre expérience, vous ne pouvez pas toujours tout prévoir. Et si vous utilisiez l’IA comme une check-list ? Ses réponses pourraient :

  • Vous conforter dans votre décision,
  • Vous faire réaliser que vous aviez peut-être oublié quelque chose,
  • Vous faire réfléchir,
  • Vous apporter une vision bien différente de la vôtre qui pourrait enrichir votre gestion de projets !

Mais, comme tout conseil humain ou autre, sachez, tout de même, faire la part des choses sur la pertinence de ses réponses et restez critique. Les propositions peuvent ne pas être adaptée à votre projet ni à votre équipe. Malgré tout, elles auront eu le mérite de vous faire réfléchir !

ET SURTOUT ne divulguez pas d’informations personnelles ou confidentielles !

Passons aux questions

Pour avoir une réponse la plus adaptée à votre problème, il est nécessaire de structurer votre question, par exemple de cette manière :

En tant que Product Owner,

Mon contexte est ..

Ma problématique est …

Ce que j’attends de l’IA

Et maintenant, lançons-nous !

Nous allons expérimenter quelques problématiques rencontrées par les équipes. Vous constaterez que les réponses sont assez généralistes, mais elles ont le mérite de vous faire revenir aux bases que vous auriez peut-être oubliées … ou même de vous aider à monter en compétence sur votre poste si vous êtes nouveau Product Owner.

Voici quelques thématiques :

La remontée de risques

Question : Je suis product owner.
J’ai une équipe de 2 développeurs.
Un développeur a rencontré une problématique technique sur une userstory.
Quels risques dois-je remonter et à qui ?

Mon analyse : Les 3 aspects sont bien remontés : délai, coût et qualité, sans omettre la communication à toutes les parties prenantes du projet. Ce sont de bons réflexes à avoir.

Question : Je suis product owner.
On vient de me remonter un risque humain car un développeur de l’équipe a démissionné.
Comment puis-je gérer cette situation ?

Mon analyse : Cette réponse pourrait aider, par exemple, un Product Owner débutant pour bien gérer ses risques.

La communication

Question : Je suis product owner.
Je dois présenter un décalage de planning à mon métier à cause d’un problème technique.
Quelle serait la meilleure communication à donner ?

Mon analyse : Je n’ai rien à redire à sa réponse. Elle parle de transparence, de proactivité, de préparer de plan de mitigation et d’écoute des problématiques des parties prenantes, ce sont des points essentiels pour donner de la confiance aux équipes et à son Métier.

Question : Je suis product owner.
Je constate que le daily ne fonctionne plus.
Qu’est-ce qui pourrait m’être proposé ?

Mon analyse : Pour cette réponse, il y a des axes d’analyses intéressants à étudier, mais il manque tout de même l’aspect collaboratif (des Rétrospectives, par exemple).

Question : Je suis product owner.
je n’arrive pas à faire travailler les développeurs avec le métier.
comment résoudre ce problème ?

Mon analyse : Les points remontés dans sa réponse sont de bons reflexes à avoir pour éviter les silos, la relation client/fournisseur et pour favoriser l’esprit “One team !”. Il faut aussi gérer la frilosité du Product Owner qui a souvent peur d’une incompréhension entre le Métier et des développeurs trop techniques. D’où, justement, l’intérêt de les faire se rencontrer et échanger le plus possible pour avoir un vocabulaire commun et une vision commune du futur produit.

Les indicateurs et le suivi de la backlog

Question : Je suis product owner.
Je constate un goulet d’étranglement dans mon kanban.
Que faire pour le réduire ?

Mon analyse : Cette question fait partie des problématiques répandues dans les équipes et la solution n’est jamais simple car elle dépend du contexte et de la maturité de l’équipe. Des points très intéressants à analyser dans ce genre de situation : la priorisation, la limite sur en cours (WIP), l’automatisation et l’esprit d’équipe. Cependant, on sait que sa réponse sur l’ajout de ressources n’est pas une bonne solution, car le fait de former de nouvelles personnes ralentit l’équipe et donc réduit sa vélocité.

Question : Je suis product owner.
Je voudrais suivre mon projet en Agile avec des indicateurs.
Quels seraient-ils ?

Mon analyse : Les thèmes sont bien là : valeur apportée aux utilisateurs, le Lead Time pour mesurer la durée, les résultats clés (satisfaction, qualité) pour vérifier que l’on a bien apporté de la valeur et, dans le cas contraire, il faudra revoir les objectifs de la prochaine version. N’oublions pas les coûts pour la rentabilité de nos développements reliés à la valeur ajoutée.

Question : Je suis product owner.
Le Diagramme de Flux Cumulé indique un grand décalage entre la courbe de développement et celle de test.
Comment faire pour réduire ce décalage ?

Mon analyse : Pour bien suivre son projet et gérer les risques au plus tôt, il est essentiel de le mesurer. Pourtant, les équipes utilisent trop peu les indicateurs tels que le diagramme de flux cumulés. La raison est qu’elles n’arrivent pas à interpréter les courbes. La réponse de l’IA pourrait aider les équipes à mieux les comprendre et à leur donner des idées d’axes d’améliorations, dont la priorisation de tests majeurs et leur automatisation pour éviter d’avoir des nièmes tests de non régressions manuels.

Et pour aller plus loin …

Question : Je suis product owner.
La vélocité par développeur est de 3 userstories par semaine. La release dure 5 semaines. 20% de l’équipe sera en congés pendant la release. L’équipe est formée de 5 développeurs. Dans les userstories, on traite en moyenne 1 bugs pour 5 userstories.
Calcule-moi la prédictibilité moyenne de l’équipe pour cette future release.

Pour ce cas, je lui ai posé 2 fois la question en lui indiquant, après sa 1ère réponse, qu’il s’était trompé dans son calcul car il considérait que la “vélocité d’équipe” était une vélocité par développeur … Après, je me demande bien ce qu’elle aurait fait si je lui avais donné une correction erronée !

Sa réponse après lui avoir indiqué son erreur.

Voici sa réponse, après avoir constaté son erreur :

Mon analyse : Dans cette réponse, je n’aurai pas mis le nombre de Userstory par développeur, pour éviter l’effet compétition/pression sur l’équipe. J’aurai plutôt indiqué le nombre total pour une Release (hors bugs), à savoir une moyenne de (15–3 bugs) = 12 Userstories, qu’il faudra — bien sûr — pondérer.

En conclusion

Intéressant, non ? J’avoue être fan ! Comme vous le constatez, l’IA peut être force de proposition et apporter des axes de réflexion intéressants. Cependant, il ne s’agit que d’un assistant car la décision finale sera bien la vôtre !

Une IA doit être cependant consommée avec modération car sa consultation a sûrement un impact Carbone, d’autant plus si la demande est complexe !

N’oubliez pas le “collaboratif humain”. Vous avez la chance de faire partie d’une équipe, voire même d’une communauté de pratiques, aussi, n’hésitez pas à les solliciter pour vous aider !

A vous de tester et faites-moi part de vos expériences !

Source de cet article

ChatGPT — https://chat.openai.com/

🫰Merci pour la lecture de cet article.

--

--

Silvere Duval
Just-Tech-IT

Product & Agile Transformation Consultant /Product Owner at AXA France— “From a Project culture to a Product culture”