À la suite de l’émergence des nouvelles technologies et de la transformation numérique, de nombreux métiers ont évolué, nécessitant une adaptation aux nouveaux processus d’affaires. Le métier d’analyste d’affaires ne déroge pas à la règle et, contrairement à ce qui se faisait auparavant, l’analyste d’affaires (ou BA pour Business Analyst) est désormais amené à travailler sur le développement de nouveaux logiciels sur mesure.
De plus, l’analyste d’affaires travaille maintenant en collaboration tant avec les clients qu’avec les développeurs. C’est donc un métier de plus en plus orienté communication, écoute, transparence et flexibilité (grâce notamment à l’approche Agile dont Karine parle dans cet article).
Ce métier ayant évolué (et étant probablement encore amené à le faire), il n’est pas rare de se retrouver face à des interlocuteurs n’ayant pas la compréhension exacte du rôle d’un analyste d’affaires. Afin de vous éclairer sur ce sujet, j’aime utiliser la comparaison avec un métier bien plus connu de tous: le métier d’enquêteur ou de détective. Tout comme un enquêteur se doit de résoudre une enquête, l’analyste d’affaires se doit d’éclaircir un mystère: celui du besoin du client. Pour y parvenir, et comme tout détective qui se respecte, nous utilisons un schéma de résolution d’enquête bien précis chez Uzinakod.
Étape 1: Interroger les témoins – La collecte des requis
Pour connaître et comprendre les besoins du client, le plus efficace est de l’interroger directement sur ses processus d’affaires. L’analyste d’affaires organise donc des «réunions d’analyse» avec le futur utilisateur de la solution à développer afin d’identifier les requis et défis auxquels il devra faire face.
Il est tout à fait normal que la personne interrogée ne connaisse pas toutes les spécificités et configurations de la solution utilisée. C’est à l’analyste d’affaires de mettre en évidence ces besoins non exprimés afin de s’assurer que la solution développée réponde bien à tous les requis fonctionnels et requis d’affaires du client.
C’est également au travers de ces réunions que l’analyste peut proposer des solutions innovantes permettant à l’utilisateur d’effectuer ses tâches de manière plus efficace et agréable.
Étape 2: Partager les faits – La priorisation
À la suite de ces réunions d’analyse, il est nécessaire pour toutes les parties d’avoir une vision claire de la priorité des fonctionnalités à développer.
Tout comme un enquêteur soumettrait des preuves aux personnes n’étant pas sur le terrain, l’analyste partage ses découvertes avec les clients et développeurs afin de renforcer le savoir de tous sur les fonctionnalités à développer. Il conseille ensuite l’utilisateur sur la base de ces découvertes et lui expose des propositions de priorisation.
Les développeurs, quant à eux, interviennent en mettant en évidence les dépendances techniques qui nécessitent le développement d’une fonctionnalité prioritaire.
Étape 3: Décrire les suspects – La rédaction
C’est le moment de la rédaction des récits utilisateurs (ou User Stories). Le but est avant tout de définir la fonctionnalité à développer de la manière la plus simple et claire possible. Nous utilisons donc la méthode «En tant que […], je désire […], afin de […]» qui a pour objectif de définir, selon le point de vue d’un utilisateur précis, la fonctionnalité attendue et le but de cette fonctionnalité.
Un exemple simple du quotidien serait: «En tant que joueur de soccer, je désire avoir des souliers à crampons, afin d’avoir plus de stabilité sur un terrain humide». Le joueur de soccer est l’utilisateur, la fonctionnalité attendue est d’avoir de nouveaux crampons et le but est d’avoir plus de stabilité sur terrains humides.
En plus de cette définition du concept, il est nécessaire de définir avec plus de précision les éléments à développer. Souvent, des maquettes (ou tout autre support visuel comme l’explique notre collègue Audrey dans cet article) sont également créées afin de donner une représentation de la fonctionnalité au client et à l’équipe de développement.
Finalement, l’analyste d’affaires s’occupe de rédiger des critères d’acceptation qui ont pour but de définir les limites de la portée de la fonctionnalité.
Dans le cas où une fonctionnalité s’avère être plus complexe et technique, l’analyste d’affaires fera appel à un expert technique afin d’apporter des précisions au récit utilisateur et/ou d’aider l’analyste à le construire. Il est de la responsabilité du développeur et non pas de l’analyste d’affaires de valider la faisabilité d’une solution technique.
Étape 4: Rappel des faits et des suspects – Validation des scénarios de test
Une fois ces divers récits rédigés, il est parfois nécessaire d’organiser des réunions entre l’analyste, le responsable qualité et le développeur avant de commencer à travailler sur la fonctionnalité. Chez Uzinakod, nous appelons ces réunions: les réunions «3 amigos».
Durant ces réunions, nous ne discutons pas de notre combo fajitas/nachos favori, mais bien des scénarios de test pour la story concernée. C’est l’occasion de faire le point sur la story à développer et de déceler les éventuels problèmes que l’on pourrait rencontrer et auxquels nous n’aurions pas pensé.
La collaboration entre les différents membres de l’équipe est primordiale, elle permet la définition d’une solution claire et comprise par tous.
De plus, c’est lors de ces partages que l’on peut s’assurer de la bonne compréhension des besoins et des requis de l’utilisateur. L’analyste d’affaires reste donc toujours disponible pour répondre aux éventuelles questions des développeurs ou toute autre partie prenante au développement de la fonctionnalité.
Étape 5: Identification des suspects – Encadrement des tests d’acceptation de l’utilisateur (ou UAT)
Enfin, l’analyste d’affaires se charge de la création d’un document de tests d’acceptation de l’utilisateur (UAT) qui consiste en différents tests relatifs à la fonctionnalité développée. L’utilisateur final a donc accès à une plateforme «Test» sur laquelle il a l’opportunité d’essayer la fonctionnalité au travers des différents tests suggérés par l’analyste.
C’est ensuite à l’utilisateur final de pousser ces tests selon son utilisation quotidienne afin de s’assurer qu’il est capable d’effectuer toutes les tâches qu’il doit réaliser sur la plateforme. En cas de problèmes, l’utilisateur a la possibilité de le signaler dans le document UAT en décrivant l’obstacle rencontré. C’est alors à l’analyste d’affaires de faire le tri entre les requêtes reçues avec le responsable qualité et éventuellement d’interroger l’utilisateur pour obtenir plus de détails.
Suite à cela, d’éventuelles modifications, ajouts ou corrections sont apportés à la fonctionnalité développée afin de répondre au mieux aux besoins de l’utilisateur final.
Conclusion
Comme vous pouvez le constater au travers de cet article, il est rare que l’analyste d’affaires travaille tout seul! En effet, c’est grâce aux interactions et dialogues avec les différents intervenants tout au long du développement de la fonctionnalité que l’analyste peut s’assurer qu’elle corresponde aux attentes de l’utilisateur.
Que ce soit avec le chargé de projet, les développeurs, le client, l’expert qualité ou les autres analystes, l’analyste d’affaires peut toujours compter sur l’aide des différents intervenants. Vous l’aurez compris, le travail d’équipe étant extrêmement important, c’est une chance de pouvoir évoluer au sein d’une entreprise telle qu’Uzinakod!
Vous avez un projet technologique en tête? Notre équipe d’enquêteurs sera ravie de relever le défi. Contactez-nous dès maintenant!
