Elicitation et collaboration

[VIDEO] E02 – Le quotidien d’une Business Analyst : la phase de découverte

image quotidien du business analyst E02

Dans ce deuxième épisode, je vous parle d’élicitation : comment collecter les toutes premières informations nécessaires au démarrage d’une mission ou d’un projet ?

Retranscription de la vidéo ci-dessous pour celles et ceux qui préfèrent lire 😉  

>> Voir aussi : [VIDEO] Episode 1 – Le Quotidien d’une Business Analyst – Le Premier Jour

Bonjour à toutes et à tous,

Bienvenue sur bestofbusinessanalyst.fr. C’est la deuxième vidéo de cette série que je consacre au quotidien du Business Analyst.

Dans ce deuxième épisode, j’avais envie de vous décrire la première activité que l’on fait lorsqu’on commence.

Alors la première activité on va dire « logistique », commence par la présentation à l’équipe. J’ai pu donc rencontrer les différents collaborateurs de ce service – entre parenthèses, c’est un service qui est localisé sur un seul site, ce qui est aussi quelque chose à prendre en compte quand vous êtes BA, car vous avez parfois des missions qui sont multisites dans le monde entier, ce qui peut complexifier la présentation. En ce qui me concerne, c’est vraiment simple au niveau logistique puisque toute l’équipe ou presque avec laquelle je vais travailler est réunie sur le même site.

Après cette première présentation qui m’a permis de voir les différents pôles d’expertise et les différents sujets sur lesquels travaille le département, le Product Owner m’a expliqué en face à face de manière informelle les objectifs du département, ce qu’il produisait, il m’a réexpliqué les différents pôles d’expertise, et ça a duré je pense environ une heure et demi de présentation « découverte ».

Je lui ai demandé de me donner des slides, des PowerPoints, qui me permettraient de mieux absorber toutes ces informations. Donc ça aussi normalement on vous les donne mais si on ne vous les donne pas, n’hésitez pas à les demander, il y en a en général dans tous les services – à minima un organigramme, une présentation « plaquette » de communication sur ce que fait le service. Si ce n’est pas le cas, surtout prenez des notes pour ne rien oublier.

Après cela, j’avais déjà une bien meilleure idée de ce que faisait le service, je comprenais mieux également en quoi ma mission pouvait les aider, mais bien entendu, ça reste encore à ce moment là très stratosphérique. Donc on a besoin d’aller collecter plus d’information. Cette collecte exhaustive claire et non ambiguë s’appelle l’élicitation. Ce terme d’élicitation provient du BABOK®, qui est le corpus de connaissances de l’IIBA®.

>> Voir aussi : Les certifications

Première activité importante: l’élicitation.

Aller chercher de l’information : OK, mais auprès de qui, et chercher quoi comme information ? Car potentiellement, c’est gigantesque.

Tout d’abord, gardez toujours à l’esprit votre mission.

En ce qui me concerne, c’est une mission très créative, qui est centrée sur le parcours de la « data », qui est à la fois orientée vers les systèmes d’information mais également vers la communication, le marketing, donc c’est vraiment très vaste. Aussi quand on voit que c’est adressé à autant de besoins, on se doute bien que notre solution va nécessiter de bien cadrer, « scoper », d’établir un périmètre clair et précis, d’établir une road map claire et précise de la mission.

Donc pour arriver à cela, il va falloir chercher l’information.

>> Voir aussi : [VIDEO] Les techniques de collecte de l’information (Part 2)

En ce qui me concerne, c’est un sujet sur la « data ». Un sujet à la mode, on voit la data partout, les dirigeants veulent de la data partout, mais quelque part c’est assez abstrait pour ces dirigeants-là et chacun y va de sa petite définition. Ainsi, la première mission que je me suis donnée à moi-même, c’était « ok, tu vas collecter ce que veut dire la data pour ce service ». Pour cela (la data c’est quoi : simplement une information digitalisée), j’ai décidé d’aller me renseigner auprès des différents pôles d’expertise, pour savoir ce que cela signifiait pour eux.

>> Voir aussi : Pourquoi les « data » sont-elles aussi importantes pour les dirigeant ?

Au niveau de l’organisation, il faut prendre des rendez-vous avec les contributeurs, aller trouver dans leurs agendas des créneaux pendant lesquels ils sont disponibles.

Comment faîtes-vous pour trouver vos premiers contributeurs ?

J’ai tout simplement demandé au Product Owner de m’indiquer les bonnes personnes, l’organigramme ne me permettant pas de le savoir. J’avais besoin de contributeurs qui me permettraient de découvrir le contexte – je n’en suis pas encore à écrire les spécifications fonctionnelles détaillées, je veux juste découvrir, comprendre le contexte, et les contraintes.

Donc j’ai commencé à planifier des rendez-vous, parfois cela pouvait se faire en face à face de manière très rapide. La chance avec cette méthodologie agile, et surtout dans ce département je pense aussi, c’est que les collaborateurs essaient de se rendre disponibles parce qu’ils savent bien que sans information, vous ne pouvez pas avancer. Donc j’ai pu enchaîner en une semaine environ huit ou dix entretiens. Sachant qu’à chaque entretien, ça me permet d’avoir de l’information complémentaire, de comprendre un peu plus à chaque fois comment travaille le service, la thématique que je dois aborder, et de découvrir d’autres contributeurs potentiels pour approfondir l’information.

>> Voir aussi : Comment gérer un contributeur difficile

Comment se passe une séance d’élicitation en face à face pour la première fois ?

Déjà vous prenez de quoi noter. J’ai commencé par un bloc-notes, mais réécrire ses notes à l’ordinateur après ça prend trop de temps, donc évidemment j’ai rapidement récupéré un ordinateur portable, et j’ai commencé à prendre des notes sur tout ce qu’on m’expliquait.

Je vous conseille aussi de ne pas vous éparpiller pendant l’entretien.

En ce qui me concerne c’étaient des entretiens d’une heure environ, et si vous n’êtes pas concentré sur un objectif, ça part dans tous les sens. Donc en commençant la séance d’élicitation, gardez à l’esprit votre objectif qui est de comprendre « grosses mailles » ce que fait la personne, et comme son activité vous permet de mieux comprendre le sens de votre mission. Je me focalisais donc sur des questions comme celles-ci : « Qu’est-ce que tu as comme data, comment tu la collectes, comment tu la transformes, comment tu la restitues et à qui, quelle est la valeur que tu produis, quels sont les problèmes que tu rencontres, et quels seraient les bénéfices que tu pourrais retirer du sujet que je vais traiter dans ma mission ?».

Donc vous voyez, ce n’est pas un entretien qui va dans tous les sens, il est quand même cadré sur un objectif. Cette trame de questions, je l’ai utilisée avec tous les contributeurs que j’ai rencontrés, et ça m’a permis d’ores et déjà de comprendre ce que je pouvais apporter, avec la compréhension de la « data » au sein du service, et à l’extérieur.

Identifier les « clients »

Ça m’a permis également de comprendre quels étaient les clients dans le sens large du terme, c’est-à-dire qui pourrait être intéressé à récupérer cette valeur liée au parcours « end-to-end » de la data. Est-ce que les clients finaux sont intéressés à comprendre comment circule la donnée, à savoir quels types d’information sont traités. Est-ce que les clients en interne, d’autres départements, seraient intéressés, est-ce que les collaborateurs au sein même de ce département qui m’accueille seraient intéressés pour minimer leurs problématiques actuelles, ou au contraire obtenir un gain quelconque ?

Repérez les problèmes

Essayez aussi de repérer des phrases du type « j’aurais bien aimé avoir telle information », « ah ça, c’est effectivement un problème car… », « c’est dommage que… ».  Dès qu’il y a un problème, vous devez le garder en tête car potentiellement pour vous ça peut être un besoin que vous transmet le contributeur et qui va vous permettre de voir à quel endroit vous pouvez apporter de la valeur.

Un Business Analyst est là pour fournir une valeur. Il recommande, définit et aide à produire une solution qui doit apporter de la valeur. A qui ? A vous de le définir et ce sont ces entretiens qui vont vous permettre de savoir progressivement à qui vous allez fournir de la valeur.

>> Voir aussi : Business Analyst : un métier incontournable

D’abord le problème, puis la solution

Autre point, ne restez pas focalisé sur ce que l’on vous a dit en préambule de la mission. En ce qui me concerne, on m’a quasiment présenté la solution qui devait être « designée », parce que forcément, chacun voit la situation depuis sa propre problématique, et il anticipe déjà une solution. En réalité, il faut d’abord comprendre le ou les problèmes avant de décider quelle solution sera la meilleure. Donc les jeunes BA souvent font l’erreur d’être focalisés sur « oulala, on m’a dit de faire telle et telle chose », et ils oublient de s’assurer que le besoin en amont correspond bien à la solution qu’on leur a demandé de mettre en œuvre.

Donc n’oubliez pas : d’abord comprendre le besoin, avant de proposer une solution.

Un autre point sur la partie élicitation: je suis sur une phase très en amont du projet, c’est-à-dire que je vais devoir faire une étude d’opportunité. En fonction de votre mission, vous arrivez à une phase ou à une autre du projet. Vous pouvez très bien arriver alors que le projet est déjà mature, cette analyse a déjà été faite, la road map, le projet a été cadré, il y a un chef de projet… Si vous arrivez un peu plus tard dans le projet, en général votre objectif est déjà beaucoup plus tard et on devrait vous le dire. Quand je dis « on », c’est en général le chef de projet qui devrait vous attribuer des tâches, des activités précises, avec une road map précise.

Le cas dont je vous parle est particulier, c’est ma mission, elle n’est pas cadrée, l’étude d’opportunité n’a pas encore été faite, la road map n’a pas encore été faite, le projet n’a pas encore été lancé, il n’est pas encore inséré dans le « train » SAFe etc…

Voilà, pour cette deuxième vidéo c’est terminé. La prochaine fois je vous donnerai des informations sur la road map – ou feuille de route. Lorsque celle-ci n’a pas encore été écrite et diffusée, c’est à vous, Business Analyst, de le faire. Je vous donne donc rendez-vous dans trois semaines pour cette troisième vidéo.

J’espère que celle-ci vous a été utile, et à bientôt sur bestofbusinessanalyst.fr !

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

Envie de devenir Business Analyst?

Téléchargez dès maintenant mon e-book GRATUIT et apprenez enfin les fondamentaux de ce métier!

Recevoir le livre !

2
Poster un Commentaire

  S’abonner  
plus récent plus ancien Le plus populaire
Notifier de
stephan

Passionnante 2e video. Je recoupe beaucoup de choses. Votre site étant contributif j’essaye de l’enrichir par les point suivants. Le besoin présenté (« declaratif ») est comme vous le disiez souvent déjà une solution.. … souvent très éloignée du besoin. Que ce soit en début de projet ou pour une reprise de projet il ne faut pas hésiter à remettre en cause ce trompe l’oeil : – « quels sont les besoins sous jacents », – « pourquoi ces besoins »….pourquoi pourquoi pourquoi…, les enjeux doivent être mis sur la table. – Ce sont eux que je décompose en besoins primaires (validés avec le client) et… Lire la suite »