Bonjour, merci beaucoup pour ce forum qui est une découverte. J’ai une question : Je suis stagiaire et j’aide sur un projet d amélioration d un logiciel pro. obsolète. Nous allons commencer les sprints et je m’aperçois que nous n’avons pas mesuré l’impact. On me demande de trouver les gains, bénéfices à mettre en avant sous forme « d’ordre de grandeur ». C’est aussi pour convaincre les utilisateurs ainsi que la hiérarchie. Je sais que l’ancien logiciel avait des bugs, problèmes ergonomique et très complexe à remplir. Je suis un grand débutant qui découvre la méthode agile et scrum ! Je ne sais pas trop comment procéder pour mesurer approximativement un impact ? Chronométrer le temps passé sur l’ancien logiciel avec et sans bug ? Chronométrer les perte de temps ergonomique ? Des membres de la communauté ont ils d’autres idées ?
Ne te considère pas pommé Charly tu as trouvé un bon endroit pour t’accompagner.
Bon je ne saurai pas te répondre dans l’immédiat ou probablement suite à réflexion. Mais sache que l’énoncé de ton sujet m’a de suite intéressé par le terme « projet d’amélioration ». A voir les différentes questions suggérées je pense que des réponses vont t-être proposées par les experts n’est il pas ?
Bonne route pour ton stage et bienvenue sur Scrum Life.
Il y a plusieurs approches possibles pour ce problème :
Le plus classique est effectivement delta-temporel pour réaliser une tâche X, multiplié par le nombre de fois que l’action est faite chaque année ;
Si on est sur une nouvelle fonctionnalité, on compare l’action avec l’application avec la méthode précédente. Il est important de tenir compte qu’on ne va probablement pas recruter tous les utilisateurs immédiatement et qu’ils ne vont pas forcément utiliser la fonctionnalité tout le temps ;
Lorsqu’un bug se produit, combien de temps ça prend à l’équipe pour corriger les données, assister les utilisateurs, rendre du compte du problème. Une bonne base de travail c’est de prendre les SLA d’une prestation de TMA, s’il y en a une, comme première hypothèse. On multiplie par le nombre d’occurrence annuel ;
Pour un bug « théorique » on peut partir sur une approche probabiliste : combien d’occurence de la fonctionnalité visée, on multiplie par une probabilité d’occurence ;
Tu peux aussi te rapprocher de ton RSSI pour discuter des risques sécurité que l’application peut faire courir au SI et à l’entreprise et les impacts business redoutés en cas d’exploitation d’une faille applicative. Là aussi on utilise une approche probabiliste, type « assuranciel » (risque redouté x probabilité d’occurence) ;
L’impact le plus important mais qui reste difficile à mesurer, c’est la dérive en terme de maintenabilité. Quand chaque correctif coûte 30 jours au lieu de 3 jours, ça fait un budget. Mais souvent les parties-prenantes sont paradoxalement peu réceptives aux problèmes structurels et d’architecture. C’est souvent perçu comme la conséquence d’un mauvais travail de l’équipe de développement (et c’est pas toujours faux). C’est pourquoi la qualité doit devenir un prérequis assuré par l’équipe dans tous les travaux et non pas une option qu’on peut décider d’acheter ou d’économiser.
Quel est la vision partagée actuellement pour votre solution ? Quel est l’élément déclencheur à l’origine de la création de cette solution ? De même, pourrais tu dire que vous avez une vision claire de la raison d’être de chaque fonctionnalité ? Parallèlement à ça, comment observez vous le process actuel que vous vous proposez de modifier ?
Autre point important, là j’ai donné des outils pour la mesure de l’ergonomie (approche par temps passé). Parfois on a d’autres objectifs, comme la notoriété ou le taux d’adoption. Dans ces cas là il faut évidemment adapter ses outils à l’objectif recherché.
Bonjour Samuel,
Élément déclencheur : perte de temps colossale, des bugs qui efface tout ce qu’ils ont passé à écrire en 30 min . Ils doivent du coup tout re remplir les champs.
Trop d’administration, trop de temps à passer sur le logiciel plutôt que de faire leur métier. Nous avons simplifié au max les process, et mis le strict minimum des exigences. Reste à convaincre que ce nouveau logiciel est meilleur que l’ancien. D’où les mesures d’impact !
En effet on est aussi sur la prévision d’un taux d’adoption et d’utilisation supérieur à l’ancien logiciel. Car c’est clairement un frein. Ils contournaient le logiciel en adoptant des méthodes différentes qui empêchait le travail en équipe (utilisation de word, de note etc.).
C’est difficile de donner une réponse très pertinente sans savoir ce que fait exactement ce logiciel, mais vu ce que tu dis la promesse principale a l’air d’être autour de réduire les pertes de temps.
Idée :
Liste les principales tâches que les gens doivent pouvoir réaliser avec le logiciel
Estime combien de temps ça devrait prendre dans l’idéal avec un logiciel bien fait, et combien de temps ça prend en pratique avec la solution actuelle (pour le savoir, fais des entretiens avec les utilisateurs actuels, voire regarde les faire)
Estime combien de fois chaque tâche doit être faite chaque semaine et par combien de personnes
Et avec ça tu devrais avoir une idée de la différence entre l’état actuel et un état « idéal » que tu vas essayer d’atteindre avec ton nouveau produit.
Donc vos utilisateurs ont eu une mauvaise expérience et ont abandonné le produit.
Et vous avez corrigé les problèmes et vous avez maintenant une application qualitative ?
Vu ce contexte, ce dont vous avez besoin c’est carrément de faire de la com’ !
Les chiffres rationalisent, mais n’auront probablement pas l’effet souhaité.
Vous devriez peut-être investir le champ émotionnel plutôt que le champ rationnel.
Les démonstrations seront primordiales pour regagner la confiance des utilisateurs.
Montrez que l’utilisation de la nouvelle application fait vraiment plaisir en comparaison.
Vous pouvez vous faire aider par un UX (un vrai, pas un graphiste ou un métier déguisés).
Vous pouvez aussi utiliser quelques stratégies de com’ bien sales, comme changer la charte graphique et le nom du produit pour prétendre que c’est un tout nouveau truc (la technique de la banderole « nouveau gérant » sur une devanture de restaurant).
En tant que qualiticien (ex :)) … si j’ai bien compris, il s’agit d’identifier des indicateurs « d’impact »! Il me semble essentiel de penser à mesurer la satisfaction des utilisateurs et mesurer son évolution avant/après au moyen d’une enquête de satisfaction qui pourrait intégrer des question ouvertes pour identifier, par exemple, les dysfonctionnements corrigés et les améliorations préférées. Je pense que j’essayerai également de mesurer le « coût de la non qualité » (ça prendrait du temps de développer ici) et de montrer que ce coût a baissé (souvent mesuré en JHETP = Jounée Homme Équivalent Temps Plein car il s’agit souvent de perte de temps)! Enfin, mais il me semble avoir déjà lu ça au dessus, on peux donc estimer la réduction du risque, ce qui sera d’autant plus facile à faire si une analyse de risque avec un « plan de réduction des risques » existe déjà (mais c’est rarement le cas)! Pour fini une suggestion puisque ça fait le lien avec un autre sujet à la mode dans cette communauté, avez-vous pensé à utiliser une IA? Je suis curieux de voir ce que proposerai ChatGPT!
,