Les analystes d’affaires sont de plus en plus recherchés dans le domaine des technologies de l’information: on peut expliquer cet engouement en partie par la croissance générale des dépenses en logiciels métier (qui a plus que doublé entre 2009 et 2019*), mais ce n’est pas le seul facteur. Cela signifie également que les compagnies du domaine des technologies de l’information prennent de plus en plus la mesure de l’importance de l’analyste d’affaires dans un projet de développement logiciel.
Vous êtes client d’une compagnie de développement logiciel (de préférence Uzinakod…) et vous vous demandez comment l’analyste d’affaires peut apporter de la valeur à votre projet? Vous êtes développeur ou analyste en assurance qualité et vous vous demandez comment l’analyste d’affaires s’intégrera à votre équipe et interagira avec vous? Ni l’un, ni l’autre, mais vous êtes simplement curieux? Cet article est fait pour vous!
L’analyste d’affaires, c’est la personne qui gère la documentation du projet, non?
Pas exactement. La documentation d’un projet de développement logiciel peut prendre différentes formes (spécifications fonctionnelles, documentation du code, cas de tests, documentation utilisateur etc.) et tous les acteurs d’un projet logiciel sont en fait appelés à maintenir une forme de documentation plus ou moins élaborée à leur niveau.
Cela dit, la documentation produite par l’analyste d’affaires (quelle que soit sa forme) doit cependant être compréhensible par un vaste public: le client, qui doit pouvoir s’assurer que ses requis ont été identifiés, les développeurs, les analystes en assurance qualité et les autres membres de l’équipe de livraison qui doivent pouvoir bien comprendre lesdits requis. Les capacités de rédaction d’un analyste sont donc un atout important.
En résumé, l’analyste se doit de bien rédiger sa documentation, mais est loin d’être la seule personne à écrire autre chose que du code dans le projet!
Les requis, qu’est-ce que c’est exactement?
Les requis sont en quelque sorte les objectifs et critères que le logiciel et chacune de ses fonctionnalités doit remplir du point de vue du client.
Les requis sont à différents niveaux:
- Les requis d’affaires: qui sont les objectifs métier que l’on souhaite remplir via la fonctionnalité. Ces objectifs sont en fonction du processus client et de leur contexte de manière générale.
- Les requis fonctionnels: l’ensemble des actions/activités que la fonctionnalité doit permettre à l’utilisateur d’effectuer ainsi que les résultats attendus.
- Les critères de performance, de sécurité ou d’expérience utilisateur que la fonctionnalité doit respecter (temps de réponse moyen, nombre d’utilisateurs simultanés etc.) que l’on appelle «requis non-fonctionnels».
En tant que client, est-ce que je dois déjà savoir tous ces éléments avant de parler à l’analyste d’affaires?
Pas du tout! La définition des requis est avant tout un processus de découverte tant pour l’analyste que pour le client. Il n’est pas rare que les clients découvrent des informations sur leurs processus et/ou le logiciel qu’ils utilisent actuellement en discutant avec l’analyste d’affaires.
Le cœur de la définition des requis est la compréhension de vos processus actuels et de vos enjeux. Toutefois, il est très fréquent que les processus actuels ne soient pas documentés et reposent sur l’expérience et les connaissances de certains acteurs. Il arrive également que lorsque le client a déjà une application métier en place, son équipe s’adapte à certaines règles et comportements de l’application plutôt que l’inverse. L’analyste joue ainsi le rôle d’un enquêteur qui part à la recherche des besoins d’affaires en détectant des indices et des pistes d’amélioration dans les éléments décrits par le client.
Dans ce contexte, il est fortement recommandé d’impliquer les acteurs qui utilisent le processus dans les activités d’analyse afin de s’assurer que leur réalité est bien prise en compte.
En tant que développeur ou analyste en assurance qualité, quelles seront mes interactions avec l’analyste d’affaires?
L’analyste joue globalement un rôle d’intermédiaire entre le client et les autres membres de l’équipe de livraison (développeurs, QA, etc.) tout au long du développement: tout d’abord, en recueillant et en transmettant les requis du client à l’équipe, mais également en jouant le rôle de porte-paroles du client lors de l’élaboration des fonctionnalités en s’assurant qu’elles correspondent aux requis et au contexte des utilisateurs. L’analyste peut par ailleurs être appelé à participer à la définition de solution ou même créer des maquettes ou prototypes de la fonctionnalité.
L’analyste d’affaires assiste également l’équipe dans l’identification des scénarios d’utilisation principaux afin d’orienter les tests d’assurance qualité en privilégiant les scénarios les plus fréquents et/ou les plus critiques.
Est-ce que l’analyste d’affaires est aussi présent dans un projet en mode Agile?
Grande question. La réponse courte est: oui! Le développement Agile ne signifie pas absence totale de documentation et encore moins que l’analyste d’affaires n’a pas de rôle à jouer dans le projet. Et d’ailleurs, comme nous l’avons vu précédemment, l’analyste intervient à chaque phase du cycle de développement en tant qu’intermédiaire entre l’équipe et le client.
La réponse longue? Elle viendra dans un prochain article!
Conclusion
L’analyste d’affaires est un acteur aux multiples facettes tout au long d’un projet de développement logiciel. Son rôle principal est d’être le pont entre le client et l’équipe de livraison. Côté client, l’analyste doit comprendre le contexte, les défis et les besoins du client.
Côté développement, l’analyste traduit ces besoins en requis fonctionnels et joue le rôle de porte-paroles du client dans la définition plus détaillée des fonctionnalités.
Tour à tour enquêteur, interprète, porte-paroles et contremaître, l’analyste d’affaires est un acteur incontournable qui a une vision globale du projet et établit le lien entre les différentes parties prenantes d’un projet de développement logiciel.
**
Va faire un tour sur notre page Carrières et embarque avec nous!
*Source: Statista
