🎲 Article Aléatoire

Voici une immersion dans mon quotidien à ce moment précis de la journée : 🕒 15h45 – En direct de la Phase d'UAT (User Acceptance Testing) La fin de journée approche, mais c'est le moment le plus critique de mon sprint. Je quitte mes tableurs et mes diagrammes BPMN pour entrer dans l'arène avec les utilisateurs finaux. C'est l'heure du Challenge Recette. Voici concrètement ce que je fais à la minute près : 1. Accompagnement et Posture d'Écoute Je suis en session de co-working (ou en visioconférence) avec les "Key Users" (les équipes métiers). Mon rôle : Je les guide à travers les cahiers de test que nous avons co-construits. Je m'assure qu'ils ne se contentent pas de cliquer, mais qu'ils valident la conformité de l'outil face à leurs processus réels. L'ambiance : C'est un moment de vérité. Il faut faire preuve de pédagogie, rassurer face au changement et capter le moindre signe de friction sur l'ergonomie. 2. Le Rôle d'Arbitre : Qualification des Anomalies C'est ici que mon expertise de Business Analyst est la plus sollicitée. Dès qu'un utilisateur s'exclame : "Ça ne marche pas comme je veux !", je m'interpose pour analyser l'écart. Je dois immédiatement trancher de manière factuelle : Est-ce un Bug ? Le système ne respecte pas les spécifications fonctionnelles qui avaient été validées. (Ex: Un calcul de marge erroné dans le rapport). Est-ce une Demande d'Évolution (Hors Scope) ? L'outil fait exactement ce qui était prévu, mais l'utilisateur réalise à l'usage qu'il aurait besoin d'une fonctionnalité blockhaus supplémentaire. Ma règle d'or : Rester ferme mais diplomate. Si c'est un changement de scope, je documente le besoin pour plus tard, mais je ne laisse pas le sprint dériver. 3. Industrialisation et Traçabilité dans Jira / Azure DevOps Pendant que l'utilisateur teste, mes doigts s'activent sur mon second écran. Je formalise tout en temps réel dans notre outil de ticketing : Création des tickets d'anomalies : Avec des "Steps to Reproduce" limpides, des captures d'écran et la configuration technique pour que l'équipe de développement puisse coder sans perdre de temps. Priorisation flash : J'attribue une sévérité (Bloquant, Majeur, Mineur) en fonction de l'impact direct sur le business. Si un bug empêche la validation d'une commande, il passe en haut de la pile. Objectif de cette fin de journée Nettoyer le terrain pour l'équipe de build. À 17h00, lorsque je rendrai mon rapport de recette, le Product Owner et les développeurs sauront exactement ce qui doit être corrigé en priorité absolue pour garantir un déploiement fluide et sans stress. La data et les processus, c'est bien. Mais à 15h45, c'est l'humain et l'efficacité opérationnelle qui priment !