Organiser un pré-mortem dans Jira : repérer les risques avant la sortie

Une version peut sembler prête dans Jira alors que l’équipe conserve des inquiétudes non écrites. La réalisation est presque terminée, les tests sont en cours et le lancement approche. Quelqu’un soupçonne un comportement différent des anciens comptes. Une autre personne craint que le support explique mal les nouveaux contrôles.

Un pré-mortem donne un point de départ utile à ces inquiétudes : imaginez que la sortie se soit déjà mal passée, puis décrivez les causes. Cet exercice facilite la discussion des échecs plausibles avant que l’équipe soit occupée à y répondre.

Dans ce guide, nous mènerons un pré-mortem pour une version fictive de portail client et organiserons les résultats dans Risk & Pre-Mortem Grid de Power Pack. Le résultat est une courte liste de risques avec responsables clairs, signaux d’alerte et mesures de réduction.

Choisissez un résultat de version précis

Notre équipe ajoute des préférences e-mail au portail. Les clients pourront activer ou désactiver les messages facultatifs tout en continuant de recevoir les essentiels. Maya répond du résultat produit, Leo réalise la modification, Priya dirige les tests et Sam prépare le support.

L’équipe choisit le ticket décrivant le résultat commun comme emplacement du pré-mortem. Les tickets de développement et de test restent liés dans le processus Jira habituel. Garder la discussion à côté du ticket de version facilite son réexamen.

Avant la séance, Maya écrit un périmètre simple : examiner l’expérience client, le comportement des e-mails et la préparation du support pour la première version des préférences. L’équipe considère le lancement et la première semaine d’usage. Cette limite évite une revue de tous les problèmes imaginables du portail.

Imaginez un échec avant de discuter des solutions

Commencez par une question concrète : « Une semaine après le lancement, les clients sont perdus, les demandes de support augmentent et nous avons dû suspendre le déploiement. Que s’est-il passé ? » Le résultat imaginé doit inciter à réfléchir sans présenter l’échec comme inévitable.

Accordez quelques minutes de calme pour que chacun écrive indépendamment des causes possibles. Cela permet aux préoccupations des tests ou observations du support d’entrer dans la discussion avant qu’une première explication assurée domine. Demandez des causes descriptibles plutôt que « la qualité était mauvaise ».

Partagez ensuite les scénarios à tour de rôle. Lors de ce premier passage, recueillez la préoccupation et clarifiez-la. Gardez pour plus tard le débat sur la meilleure solution. Chacun doit pouvoir évoquer une possibilité gênante sans défendre immédiatement un plan correctif complet.

• Les clients existants voient des préférences qui ne correspondent pas à leurs réglages actuels.
• L’interface laisse croire que les e-mails essentiels peuvent être désactivés.
• Les instructions de support décrivent des contrôles modifiés avant la sortie.
• La mise à jour de préférence semble réussie alors que la modification sous-jacente échoue.

Ces scénarios sont fictifs. Votre liste doit venir des personnes qui connaissent le travail, les dépendances et l’expérience client. Power Pack consigne la discussion ; l’équipe apporte son jugement sur ce qui peut se produire.

Transformez les inquiétudes en risques reconnaissables

Un risque utile décrit un événement possible et sa conséquence. « Migration » est un sujet. « Les valeurs existantes sont mal converties, donc certains clients reçoivent des e-mails facultatifs qu’ils pensaient arrêtés » est un scénario à investiguer.

Regroupez les doublons sans perdre les conséquences distinctes. Plusieurs inquiétudes sur les anciens comptes peuvent partager une cause. Un libellé trompeur et un enregistrement raté peuvent tous deux dérouter les clients, mais demandent des contrôles différents et doivent généralement rester séparés.

Pour chaque scénario, demandez ce que l’équipe remarquerait tôt. Un signal d’alerte est un indice observable qui mérite attention. Ici, une divergence entre les paramètres existants et les valeurs prévues après migration est plus utile que « les clients pourraient se plaindre ». Elle se vérifie avant le lancement.

Convenez du sens de la probabilité et de l’impact

Power Pack propose une matrice 3×3 ou 5×5 et calcule une gravité en multipliant probabilité et impact. Utilisez ce score pour discuter et trier. C’est une appréciation subjective, pas une prédiction de fréquence ni un calcul de perte attendue.

Pour une première séance, l’équipe choisit 3×3 et des définitions simples. Une probabilité de un signifie peu d’indices actuels ; deux, un scénario plausible à examiner ; trois, de bonnes raisons de le prévoir sans action. Ce sont les définitions de travail de cette équipe.

L’impact est défini selon les conséquences pour les clients et la sortie. Un signifie une gêne limitée, deux une perturbation notable avec suivi, trois un problème client grave ou une raison de suspendre la sortie. Une autre équipe peut avoir besoin d’autres définitions.

Priya attribue deux en probabilité et trois en impact à la migration incorrecte, soit six. L’équipe discute les hypothèses : la nouvelle conversion n’a pas été répétée avec des anciens comptes représentatifs. Les preuves manquantes comptent davantage que la précision apparente du nombre.

Gardez la même échelle pour comparer les premiers risques. Changer la taille de matrice remet les évaluations à l’échelle : vérifiez les positions obtenues. Une nouvelle position ne constitue pas une nouvelle preuve sur la version.

Ajoutez les risques à Power Pack

Ouvrez Power Pack sur le ticket choisi et sélectionnez Risk & Pre-Mortem Grid. Utilisez la carte thermique pour la répartition des évaluations et le registre pour les entrées. Vous pouvez ajouter un risque depuis une cellule si sa probabilité et son impact initiaux sont connus.

Pour chaque entrée, renseignez titre, scénario d’échec, signal d’alerte et catégorie. Ajoutez les évaluations convenues, un plan de réduction et un responsable. Power Pack prend aussi en charge des points de contrôle, un statut et une référence Jira facultative.

Le responsable peut être un utilisateur Jira ou une personne externe enregistrée. Choisissez quelqu’un qui coordonnera la réponse et rapportera les preuves manquantes. Le nommer dans la grille ne crée pas de tâche, n’attribue pas de tâche existante et ne donne pas accès au ticket.

Vérifiez l’enregistrement avant de considérer la grille actualisée comme partagée. Les changements sont stockés sur le ticket ; un état local ou de nouvelle tentative ne confirme pas qu’un collègue voit déjà la dernière entrée.

Donnez une réponse pratique à chaque risque important

« Tester soigneusement » est difficile à suivre. Pour la migration, Priya propose une répétition avec des états de compte représentatifs, puis une comparaison des préférences obtenues et du comportement e-mail attendu. Leo examinera les divergences. Priya reste responsable du risque et présente le résultat à la revue de sortie.

Découpez la réponse en points de contrôle rendant l’avancement visible. L’équipe peut choisir des cas représentatifs, exécuter la répétition, examiner les divergences et consigner l’incertitude restante. Les points organisent la réponse ; les preuves restent dans le travail de test ou de réalisation concerné.

Si une mesure nécessite un ticket Jira, créez-le et attribuez-le par le workflow normal, puis ajoutez sa clé au risque. Cette référence facilite le suivi du lien ; elle ne crée pas automatiquement le travail et ne gère pas sa réalisation.

Réexaminez le statut lorsque les preuves changent

Power Pack propose Identified, In Progress, Mitigated et Accepted. Utilisez Identified lorsque le scénario est consigné, et In Progress lorsqu’une personne travaille à la réponse. Convenez des preuves attendues avant de décrire un risque comme Mitigated.

Accepted peut décrire une décision consciente de poursuivre avec une exposition restante. Maya pourrait accepter une petite lacune du guide après confirmation d’une réponse provisoire par Sam. Consignez la raison et réexaminez-la si les hypothèses changent. L’acceptation doit être une décision comprise, pas un moyen de ranger la grille.

Lors de la revue de sortie, interrogez les responsables sur les signaux d’alerte, les résultats des mesures et les incertitudes. Examinez indépendamment tout changement important de périmètre, dépendance nouvelle ou résultat de test inattendu. Actualisez les évaluations lorsque les preuves le justifient et expliquez pourquoi.

Vous pouvez exporter la grille en Markdown ou CSV pour une discussion de planification. Identifiez le ticket Jira comme référence actuelle. Un export partagé est un instantané qui peut ne plus refléter la dernière appréciation.

Utilisez la séance pour modifier les prochaines étapes

Une grille remplie est utile si elle influence la préparation. Pour notre équipe, le pré-mortem mène à une répétition de migration, à une formulation plus claire et à la vérification que le guide correspond au candidat de publication. Chaque action répond à un scénario précis soulevé par les personnes qui réalisent le travail.

Commencez par une version, une courte discussion animée et quelques risques pertinents. Utilisez Power Pack pour garder scénarios, responsables et réponses visibles à côté du ticket. Ramenez ensuite la fiche à la prochaine discussion de sortie afin d’évaluer ce qui a réellement changé.