Cela faisait six mois que j’avais intégré une équipe de 25 personnes pour un poste de développement dans une grande banque d’investissement. L’équipe travaillait en agile (Scrum) avec une proximité utilisateur privilégiée. Ma curiosité et ma capacité d’analyse ont alors attiré l’attention de mon client qui m’a proposé le rôle de Business Analyst (BA) pour un sujet. J’ai accepté la proposition mais pour une durée limitée, le temps qu’il trouve un BA pour prendre le relais, puisque ce n’était pas dans mes objectifs de carrière professionnelle. C’était une première pour moi d’endosser ce rôle et, je l’avoue, j’avais beaucoup d’appréhension par rapport au sujet et ses multiples difficultés. D’un côté, je ne connaissais pas le métier et de l’autre, je ne connaissais pas tous les membres de l’équipe et réciproquement.
Mais en quoi a donc consisté mon rôle de Business Analyst et quelles ont été mes tâches ?
Nous avons fait un point avec le client pour savoir à la fois ce qu’il attendait de moi pour cette mission et quelles seraient les tâches affectées au poste de BA. Sa réponse a été la suivante : il s’agissait de recueillir le besoin utilisateur, de gérer le backlog et de valider les US (User Stories) réalisées. Immédiatement je me suis interrogée : n'est-ce pas le rôle du PO (Product Owner) ? Quelle est la différence entre le BA et le PO ?
D’après Walterspeople, le role de Business Analyst est une « interface indispensable entre les départements opérationnels de l’entreprise et le service informatique ». Son rôle consiste à « analyser le processus d’information et les stratégies mis au service de la prise de décision quotidienne de sa société afin d’en évaluer l’efficacité ou d’apporter les ajustements nécessaires ». Parallèlement à ça, dans de nombreux articles, le rôle du PO est corrélé aux approches agile, même si cette notion peut être séparée. Le ou la PO est défini(e) comme un membre de l’équipe qui connait le produit, crée et maintient le backlog en priorisant les US et il est surtout disponible pour apporter des précisions et des indications en cas de besoin. En réalité, le PO et le BA peuvent correspondre au même rôle. Dans les grands groupes, j’observe qu’on trouve souvent les deux car le BA remplace le PO qui, entre les déplacements et les tâches du quotidien, n’est pas disponible tout-le-temps.
Revenons au contexte de la mission. Pour mener à bien ma tâche, j’ai demandé à mon PO une demi-journée de formation sous la forme d’un atelier « vis ma vie ». Au cours de cet atelier, j’ai pu me rendre compte de la complexité de la tâche. En effet, la formation en une demi-journée a été intense. Il m’a présenté son métier et ses besoins et j’ai dû de les traduire sous forme de backlog à prioriser avec lui et suivre l’avancement des US. L'avantage de cette configuration pour l’équipe de développement est que je suis à proximité et disponible si besoin de précisions.
Mais être l’intermédiaire n’est pas toujours facile. En effet, l'importante difficulté rencontrée au cours de période a été d’apporter les bonnes réponses aux développeurs. Même si je préparais les scénarios BDD avant le début du développement de l’US, il m’est arrivé de ne pas couvrir tous les cas. Donc en l’absence du PO et devant les interrogations des développeurs, j’ai dû prendre des décisions qui ne se sont pas toujours révélées les bonnes. Du coup, lors de la démonstration de l’US, le PO a demandé des modifications, voire même enlevé des fonctionnalités. En soit, ce n’est pas très grave et je dirais même que c’est un des avantages des approches agiles que de se rendre compte au plus tôt de la pertinence ou non d’une US. En effet, même si lors de la priorisation des US, on donne une grande valeur à l’une d’elles, après démonstration, on se rend parfois compte que la priorisation n’est pas la bonne ou que des facteurs externes changent la priorisation (comme une réglementation européenne, par exemple).
La deuxième difficulté rencontrée a été de me cantonner à mon rôle. Etant une développeuse avant d’être BA, je n’arrivais pas à me contenter de préparer les US et les scénarios de tests. Parfois, lors de la rédaction des scénarios BDD ou d’une discussion avec mon PO, je commençais à concevoir la solution et la discussion prenait un autre tournant. Malgré le fait d’avoir pensé à la solution et d’avoir préparé le terrain aux développeurs, il y avait des questions auxquelles je n’avais pas pensé. En effet, en présentant les US à mon équipe, certains m’ont posé des questions face auxquelles je me suis trouvée sans réponse précise, juste avec des suppositions. Sur le moment, je m’en suis voulu car je me suis sentie négligente en quelque sorte. Mais d’un autre côté, j’étais fière de mes coéquipiers qui m’avaient prouvé qu’ils s’intéressaient au métier et je me suis sentie moins seule à gérer le besoin de mon PO. Suite aux différentes questions, nous avons préparé des scénarios à lui proposer pour l’aider à prendre une décision. J’ai bien aimé cet esprit. A mon sens, le développeur doit s’intéresser au métier autant qu’à la technique, et les développeurs peuvent bien entendu faire des propositions en termes métier !
Malheureusement ce n'est pas le cas de tous les développeurs. Je suis persuadée que ça peut changer et que je peux influer au moins sur mon équipe pour garder cet état d'esprit. Dès que l'occasion s’est présentée, j’ai insisté sur la notion d’équipe, de partage et d’intérêt du métier. Et surtout sur le fait qu’il ne faut pas oublier l’objectif de notre mission : délivrer de la valeur à notre client. Il arrive parfois qu’on dévie un peu de notre chemin. Ce n’est pas grave à partir du moment où on parvient à se remettre sur la bonne voie en douceur et sans douleur.
Ce que je retiens de cette expérience
Je suis persuadée qu’une équipe n’a pas besoin du rôle de BA à partir du moment où elle intègre un PO. Mais c’est l’implémentation qui est parfois difficile : comme le PO n’est pas toujours disponible, cela oblige l’équipe à faire appel à un BA. Cela assure un avenir aux BA, ce rôle n’est pas près de disparaitre, au moins dans les grands groupes. En revanche, on voit de moins en moins de BA dans les moyennes et petites entreprises : ce poste coûte cher et le cycle est tellement court entre les utilisateurs et les développeurs que ces derniers apprennent à bien maîtriser le métier, et tous les rôles intermédiaires s’évaporent rapidement.
En tant que développeuse, j’ai toujours été fière de mes réalisations en pensant avoir su apporter de la valeur à mes clients. Je me suis souvent demandé si les BA et les PO avaient le même ressenti, bien qu’ils n’aient pas écrit une seule ligne de code. Maintenant je peux vous l’affirmer : la réponse est oui. Eh oui ! Même si je n’ai pas saisi de lignes de code (chose qui m’a beaucoup manquée), je suis quand même fière de ce que nous (toute l’équipe) avons livré. Je considère l’application comme un bébé que j’ai conçu avec mon PO (oups ! Je pense que je vais regretter cette phrase un jour), vu naître et grandir itération après itération.
Pour conclure, je considère que mon expérience en tant que BA a été très enrichissante. Elle m’a permis d’un côté de monter rapidement en compétence en termes de métier et de l’autre côté d’avoir un regard différent sur la relation entre les utilisateurs et l’équipe de développement. Aujourd’hui, j’ai repris mon activité favorite, « le développement », puisque mon client a trouvé un BA pour prendre le relais.
A bientôt pour un prochain article !
Dorra
Références
http://blog.soat.fr/2014/10/a-la-decouverte-du-role-de-product-owner/
http://www.agilex.fr/2010/03/les-10-responsabilites-du-product-owner/
http://www.agilex.fr/2013/02/product-owner-qui-es-tu/
http://www.universalmind.com/blog/agile-transformation-product-owner-vs-agile-business-analyst/
https://www.walterspeople.fr/conseils-carriere/it-metier-business-analyst.html
http://www.agilex.fr/2013/02/product-owner-qui-es-tu/
http://blog.soat.fr/2014/10/a-la-decouverte-du-role-de-product-owner/
Hello Dorra, j’ai beaucoup apprécié ton article.
Je travaille actuellement comme testeuse UAT sur un projet et j’aimerais m’orienter sur un poste de BA. Un peu comme toi, ce n’était pas mon objectif de base mais depuis quelques temps ça me tente. Et ton article m’a aidée à appréhender un peu plus ce rôle et d’avoir un autre regard dessus.
Merci beaucoup !
Très bonne continuation à toi.
Merci pour ton message Katia.
Je suis ravie que mon article a permis de t’aider.
Bonne continuation à toi aussi et n’hésite pas à me contacter sur twitter ou sur mon mail Arolla si tu as besoin de plus d’informations et pour me raconter ton expérience aussi pour le poste de BA.
À bientôt 😉
En fait, l’essentiel, la raison d’être de l’analyse n’est plus présent dans les rôles d’analystes. Le rôle d’analyste est défini par des non-analysts. Tout Ceci n’est pas sans conséquences. Une réflexion plus profonde et un retour à la source s’impose. Les méthodes ne sont que la parti émergée de l’iceberg… le reste est plutôt ignoré.
Vous trouverez plus dans le fichier PDF @ http://bit.ly/2Z5h77G
Merci Axel pour ton message 🙂 Effectivement, on doit toujours revenir à la source pour comprendre le besoin initial. Merci pour le partage de ton livre, j’ai commencé à le lire et c’est bien intéressant 🙂