Les 5 moments les plus ennuyeux quand on est Business Analyst

Il est habituel, lorsqu’on cherche à se reconvertir, de vouloir identifier les activités qui nous plairont le plus dans notre futur « dream job ». Or, chaque métier a sa part d’ombre et d’ennui mortel, même si comme moi, on s’auto-proclame « business analyst enthousiaste ».

Un ingénieur d’affaires d’une ESN m’a une fois dit que mon regard archi-positif à la limite du pays des Bisounours pouvait masquer certaines réalités moins plaisantes du métier de Business Analyst. Il n’avait pas totalement tort.

Dans cet article, j’ai donc décidé de collecter, auprès de collègues business analysts, ce qui plombait le plus leur agenda et leur bonheur au travail. And the winner is…

Le Business Analyst n’est pas tout le temps sollicité de manière égale, que ce soit lors du cycle de développement d’un projet ou dans le cycle de vie de la solution logicielle.

En phase de pré-projet, ainsi qu’en début de projet, le Business Analyst a beaucoup de travail d’analyse (de l’existant, des besoins, comparative, financière, étude d’opportunité, cadrage, analyse des risques etc).

Pour produire ses différentes analyses, le Business Analyst prépare et anime de nombreux ateliers de travail, interviews, il/elle passe donc une grosse partie de ses journée à éliciter une information exhaustive et non ambiguë. Cette étape est souvent très intéressante car elle permet de comprendre les besoins métiers, les contraintes de l’organisation, du projet, ou encore de la solution technique (ERP, BI…).

Ses analyses conduisent ensuite à la phase de recommandation étayée, pour aider le dirigeant ou le manager à valider une solution cible macroscopique.

La phase de conception fonctionnelle est ensuite également un moment de forte sollicitation du business analyst, puisqu’il/elle va devoir s’immerger dans la description fine des fonctionnalités logicielles, qu’il/elle va modéliser précisément, tout en s’assurant de ne jamais perdre le cap de la vision stratégique et métier de l’organisation cliente.

La phase de développement

Et puis, à un moment, il est temps de passer la main à l’équipe technique, qui va à son tour avoir un pic de charge, s’approprier la solution conceptualisée, et la concrétiser en développant le logiciel cible.

Cette phase de développement est souvent un moment de creux pour le Business Analyst. Il a bien sûr d’autres occupations (préparation de la stratégie de test, de la conduite du changement…), mais son tourbillon d’activité rythmé par les deadlines des livrables se tarit pour un long moment, le temps du développement

La réunionite aiguë

Pour l’équipe de développement, la confusion est fréquente entre le rôle de Business Analyst et d’expert métier (Subject Matter Expert). J’ai déjà eu l’occasion de le dire et de le redire : non, un BA n’est pas un expert métier ! Il est la passerelle entre le « métier » et la « technique », il traduit « besoins métiers » en fonctionnalités logicielles, mais il/elle n’est ni comptable, ni logisticien, ni expert en X ou Y secteur (banque, aéronautique, transport, juridique…).

>> Lire aussiDoit-on être expert métier quand on est Business Analyst ?

Son rôle est donc de collecter une information de qualité, exhaustive, fiable et vérifiée. Il/elle est donc souvent en interview, atelier de travail, ou réunion de présentation auprès des décideurs.

Tant que son rôle est clair auprès de l’équipe projet et du client, il/elle gère son agenda – certes en flux tendus, mais du moins, avec efficience et efficacité.

A contrario, quand son rôle est mal compris, il est invité à toutes sortes de réunions et est sollicité à tort pour valider des choix « métier ».

>> Lire aussiOù s’arrête le rôle du Business Analyst (et où commence celui de l’équipe technique)

La réunionite aiguë frappe toutes sortes de catégories professionnelles, mais cette maladie est clairement identifiée par les business analysts comme un facteur pesant négativement sur leur productivité et leur plaisir d’exercer leur métier.

La phase de vérification et de validation documentaire

La vérification et la validation des livrables est indispensable pour s’assurer de la qualité de la conception fonctionnelle de la solution, avant de lancer le développement. On parle ici des projets gérés de manière traditionnelle, car les approches agiles soulagent heureusement la lourdeur documentaire à laquelle est soumis le Business Analyst travaillant dans les projets en cycle en V ou en cascade.

Concrètement, comment cela se passe-t-il ? Le Business Analyst a passé de longues heures à restituer, modéliser, conceptualiser une solution logicielle, il a écrit les règles métiers, le glossaire, les fonctionnalités dans leurs moindres détails.

Il va ensuite lancer la phase de vérification de ses livrables. Plusieurs approches sont possibles, mais souvent, il va envoyer ses documents pour relecture, et s’il n’a pas soigneusement préparé cette étape de « review », cette dernière peut vraiment s’éterniser.

>> Lire aussi : Comment éviter un processus de vérification qui s’éternise

On assiste ainsi à des allers-retours sans fin entre le BA et ses relecteurs, souvent des utilisateurs métiers qui ont d’autres priorités à gérer et qui se font tirer par la manche pour relire des centaines de pages et de schémas pas très sexy. Souvent, l’utilisateur métier n’est lui-même pas familier avec les « specs », ni les diagrammes UML, et met sous la pile d’autres urgences cette tâche fastidieuse de relecture.

Le Business Analyst, ayant des deadlines, doit passer du temps pour suivre la progression de la relecture, expliquer tel ou tel terme, telle ou telle phrase ambiguë ou mal formulée ou n’employant pas strictement le vocabulaire « métier ». Et c’est parfois à ce moment-là du projet qu’il découvre des éléments clés remettant en question tout ou partie de la conception fonctionnelle. Douche froide et déprime assurées.

Bref, vous l’aurez compris, cette phase de vérification et de validation n’est pas le moment le plus apprécié du Business Analyst !

Les tests de non-régression

De nos jours, la plupart des projets informatiques ne livrent plus d’un bloc la solution dans son ensemble, mais plutôt des « lots » de fonctionnalités, de modules, les plus indépendants possibles les uns des autres.

C’est ce qu’on appelle un développement incrémental.

Souvent aussi, la conception fonctionnelle et le développement logiciel sont itératifs, c’est-à-dire que leur version finalisée va faire l’objet de nombreuses corrections en cours de route, jusqu’à parvenir à une version satisfaisante.

Tout nouveau développement d’une brique ou fonctionnalité logicielle peut donc potentiellement avoir des effets de bord sur ce qui a été codé auparavant. Il faut donc réaliser des tests de non régression, pour vérifier que la nouvelle version n’a pas « cassé » les résultats testés avec succès précédemment.

L’équipe technique fait donc ses propres tests de non-régression technique, et l’équipe de business analysts procède de son côté à des tests de non régression fonctionnelle.

Je crois que personne ne trouve cela passionnant. Le Business Analyst non plus.

Maintenance évolutive et corrective : rien à signaler, capitaine !

Après le Go Live, surtout quand il est réussi, c’est Champagne ! Gros moment que la livraison en prod, tant attendue par le client et la maîtrise d’œuvre. Après le Go Live, il y a une période de garantie, pendant laquelle l’équipe projet corrige les inévitables bugs ou anomalies passés à travers les mailles du filet.

Le cycle de vie de la solution l’amène ensuite vers la maintenance évolutive et corrective : ça y est, le logiciel opérationnel est dans les mains des utilisateurs métiers, et il va continuer de « vivre », au gré des besoins métiers émergeant ou évoluant dans les mois et années suivant le Go Live.

Les business analysts qui travaillent dans ce contexte de maintenance évolutive et corrective sont unanimes : quel ennui quand tout va bien ! Cynique ? Euh oui, sans doute, mais imaginez votre journée de travail sans tâches ni objectifs précis…

Et vous, amis Business Analysts, quels sont les moments les plus ennuyeux que vous aimeriez partager en commentaire 😉 ?

Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!

Alice Svadchii
Alice Svadchii
Auteure du blog et Business Analyst enthousiaste
0 0 votes
Évaluation de l'article
Alice Svadchii

Alice Svadchii

Formatrice, coach, conférencière et productrice de contenus enthousiaste !

Cet article vous a plu? Partagez-le et suivez-nous sur les réseaux sociaux!

Découvrez des articles similaires

2
0
Would love your thoughts, please comment.x