🎲 Article Aléatoire

Alors, à 15h45, en pleine phase d'User Acceptance Test (UAT) ou "Recette Utilisateur", l'atmosphère est souvent électrique. C'est le moment de vérité où la technique rencontre la réalité du terrain. Voici exactement ce que je fais à ce moment-là, dans les coulisses de mon rôle de Business Analyst : 1. Posture de "Guide de Haute Montagne" (Accompagnement des métiers) Je ne laisse jamais les utilisateurs finaux seuls face à l'écran avec une simple feuille Excel. Je suis à leurs côtés (en atelier ou via Teams/Zoom) pour : Démystifier la plateforme : Je m'assure qu'ils comprennent la logique des nouveaux flux qu'on a modélisés. Dérouler les scénarios de test : Je les guide pas à pas à travers les cas nominaux (le chemin idéal), mais je les pousse aussi à tester les "cas aux limites" (les erreurs de saisie, les comportements imprévus). 2. Le Rôle de Juge de Paix : Bug vs Évolution C'est la partie la plus stratégique et subtile de mon après-midi. Quand un utilisateur s'exclame : "Ça ne marche pas !", mon cerveau de BA passe en mode analyse instantanée pour faire la distinction cruciale : Le Bug (Anomalie) : Le système ne fait pas ce qui avait été explicitement spécifié dans les user stories. (Exemple : Le bouton de validation reste grisé alors que tous les champs sont remplis). Le Changement de Scope (Évolution/Feature request) : L'application fonctionne exactement comme prévu dans les ateliers initiaux, mais maintenant que l'utilisateur l'a sous les yeux, il se rend compte qu'il aurait besoin d'autre chose. (Exemple : "Ah, ce serait bien si ça générait aussi un PDF automatique !"). Mon approche : Je reste diplomate. Je valide la frustration ou le besoin de l'utilisateur, mais je protège le planning et le budget du projet en recadrant gentiment ce qui est "hors scope" pour la version actuelle. 3. Chef d'Orchestre sur Jira / Azure DevOps Une fois l'anomalie qualifiée, je ne perds pas une seconde pour la documenter de manière ultra-précise pour l'équipe de développement. Je crée ou mets à jour les tickets en y intégrant : Les "Steps to Reproduce" (Étape 1, Étape 2, Étape 3). Le comportement attendu vs le comportement observé. Les captures d'écran ou vidéos du problème. Ensuite, je priorise en direct ou lors d'un point flash avec le Product Owner (PO) : Blocker / Critical : L'UAT est bloquée, les dévs doivent corriger ça immédiatement. Major / Minor : On peut continuer les tests, ce sera corrigé dans un second temps. En résumé, à 15h45, je suis le pont indispensable entre la vision business et l'équipe technique. J'absorbe le stress des utilisateurs, je filtre le bruit, et je traduis leurs retours en actions concrètes et priorisées pour que le produit final soit non seulement fonctionnel, mais surtout adopté.