Parfois, vos parties prenantes vont vous prendre pour le Père Noël et vont vous soumettre un besoin, qui n'en est finalement pas un.

J'ai besoin d'une nouvelle moto pour aller bosser.

Je voudrais une Ducati Hypermotard SP

Puis, vous allez interviewer les différentes parties prenantes :

En tant que marketeux, je pense que vous devriez rouler en BMW R 1200 RT.

En tant qu'assureur je pense que le plus raisonnable serait une Honda CB 500 X.

En tant que banquier je pense que vous n'avez pas le budget.

En tant que Sécurité Routière, je pense que c'est trop risqué de rouler en 2 roues.

En tant qu'expert, je pense que ça tombe bien, c'est le salon de la moto, allons essayer une présélection de modèles puis on fera une analyse comparative.

...

Alors là, je dis STOP. On est allé trop vite. Avant de détailler, modéliser, valider ces exigences, il faut avoir vérifier que le besoin était bien compris. Dans le Business Analysis Body of Knowledge, on parle de "elicitation". Ce terme a été traduit dans la version en français par "élicitation" et est défini comme suit :

L’élicitation peut se définir de la manière suivante : se renseigner pour connaitre divers éléments (latents ou potentiels), poser des questions,  s’informer pour obtenir de l’information ou des réponses.

Les techniques à utiliser pour cette phase critique de la gestion des exigences sont : brainstorming, étude de la documentation existante, groupes de discussion, interviews, storyboards, sondage/questionnaire... Des techniques assez ouvertes qui facilitent la découverte.

Dans mon exemple, le vrai besoin de cette partie prenante est de se rendre au boulot en moins d'une heure. Et comme la batterie de sa moto actuelle est faible, elle ne démarre pas. Finalement il suffira juste de recharger la batterie de sa Honda Hornet, et ça roule.

Le Système d'Information, c'est pareil.

Attention, auto-promo à l'intérieur de ce billet !

Cela faisait longtemps que je n'avais pas écrit sur ce blog ! Je vais essayer de contribuer plus régulièrement.

J'ai profité de cette absence sur ce blog pour co-écrire un livre sur la maitrise d'ouvrage du SI. Pour cela, nous avons utilisé la plateforme Leanpub qui permet d'écrire un ouvrage de manière collaborative, en suivant les principes du Lean. L'idée c'est donc d'écrire une première version du livre que l'on publie assez tôt afin d'obtenir un retour rapide des lecteurs.

Donc si vous êtes intéressés par les sujets évoqués sur ce blog, vous aimerez ce livre qui présente des techniques très utiles pour réussir en tant que MOA. Il y est notamment question de : gestion des exigences, valeur métier, Minimum Viable Product, vision, business case, modélisation UML, story-board, maquette, user story, Behavior Driven Development, Acceptance Tests Driven Development, conduite du changement, rétrospective... En téléchargeant ce livre maintenant, vous pourrez l'avoir pour 0€ et en plus vous pourrez influencer son contenu en nous faisant vos commentaires sur ce qu'il faut étoffer, ajouter ou corriger. 

Si vous souhaitez plus d'information, c'est par ici :

Les certifications pour la MOA ne sont pas très nombreuses. Et il y en a encore moins si on parle des certifications francophones. Indépendamment du débat "Êtes vous pour ou contre les certifications ?", voici quelques idées de certifications utiles pour une MOA.

Les certifications en Business Analysis

Le International Institute of Business Analysis (IIBA) propose deux certifications portant clairement sur le métier de maitrise d'ouvrage :

• La certification CBAP^® (Certified Business Analyst Professional^®) pour les “Business Analyst” expérimentés.
• La certification CCBA^™ (Certification of Competency in Business Analyst^™) pour les profils intermédiaires.

(plus d'information ici : Certifications IIBA - CBAP et CCBA)

Ces certifications sont sérieuses, elles demandent à la fois des connaissances sur le Business Analysis Body of Knowledge (BABOK) et également une quantité importante d'expérience sur des activités de la Business Analysis. Je ne pense pas que la certification CBAP soit très connue en France, mais c'est certainement la certification qui me semble la plus intéressante et la plus valable pour une MOA.

Les certifications associées à des méthodologies

En tant que MOA on peut être amené à travailler en suivant différentes méthodologies. Il peut donc être intéressant d'obtenir une certification sur une ou plusieurs méthodologies en vogue. Par exemple, si vous travaillez en tant que Product Owner sur un projet en mode Scrum, pourquoi ne pas passer une certification sur ce thème proposée par la Scrum Alliance ?

• Certified Scrum Product Owner

On est sur un type de certification plus "light" que celles proposées par l'IIBA, mais cela permet de prendre un peu de recul sur sa compréhension de Scrum, et cela donne accès à une communauté qui saura vous aider sur certains aspects de Scrum si vous en avez besoin.

Les certifications plus ciblées sur des outils, des langages, des progiciels

Ensuite, en fonction d'éléments plus spécifiques à votre profil et domaine d'expertise, vous pouvez opter pour des certifications sur un langage de modélisation ou un progiciel.

• OMG Certified UML Professional
• Certification SAP

Là on est sur des certifications d'expert. On s'éloigne un peu de la MOA, mais il est vrai qu'une MOA est souvent également un expert sur un domaine en particulier. Il peut donc être intéressant de valider cette expertise via une certification.

Il existe donc un choix intéressant de certifications pour la MOA, même si les certifications purement MOA sont encore limitées en nombre. Ensuite, chacun doit faire en fonction de son profil, de ses souhaits d'évolution et du temps qu'il souhaite et peut y passer. Finalement reste l'éternel débat, comme pour toutes les professions du système d'information, la certification est-elle valorisée dans l'entreprise ?

Faut-il automatiser tous les processus manuels ? Informatiser un processus manuel répond souvent à des exigences de traçabilité, de reporting, de pilotage. Mais faut-il éliminer toute action manuelle ? Quels sont les risques lorsque l'on remplace l'homme par la machine ? On sait faire danser les robots, mais sont-il capables d'improviser ?

CEBIT 2011: A Nao robot performs at Intel's Cebit news conference

Les règles métiers doivent rester la propriété du métier

Il existent des systèmes dédiés à la gestion de règles métiers, et quoi qu'il en soit, tous les systèmes d'information implémentent des règles métier. Mais parfois certaines parties prenantes refusent la mise en place de règles métiers exécutées automatiquement. Pourquoi ? Parce qu'elles ne veulent pas perdre la connaissance et la gouvernance de leurs processus. Il faut faire très attention à ce que la mise en place d'outils de gestion des règles métiers et des processus métiers se fasse sans déposséder les "métiers".

Calculer le retour sur investissement selon l'axe financier et celui de la flexibilité

Calculer le retour sur investissement selon l'axe financier est une chose primordiale, mais il ne faut pas oublier celui de la flexibilité. Développement durable, agilité sont des termes souvent entendus associés à de lourds projets d'automatisation de processus métiers. N'oublions pas que l'être humain est très adaptable, bien plus que le meilleur SI aussi agile soit-il.

Inutile donc de vouloir tout automatiser à tout prix. N'oublions pas que le SI supporte les règles métiers et les processus métiers, mais qu'il n'est pas le métier.

Cela fait quelques mois que je travaille sur un projet utilisant la méthodologie Scrum. Cette méthodologie dite "agile" bouleverse le travail de la MOA dans les organisations classiques où les rôles MOA et MOE sont gérés par des personnes distinctes, voire des équipes distinctes. Après vous avoir expliqué quelques bases sur l'agilité et la MOA dans un précédent billet (Le rôle de MOA est-il compatible avec les méthodes agiles ?), je me propose ici simplement de vous livrer mon retour d'expérience sur l'impact d'une telle méthodologie pour la MOA.

Ce qu'on a dit sur le rôle de la MOA dans les méthodes agiles...

On a beaucoup parlé des méthodes agiles depuis quelques années. Et on peut avoir l'impression par exemple que Scrum a été conçu par des développeurs, pour des développeurs. Je dis cela car la communauté agile s'est très vite rendue compte du problème que posait la MOA pour mettre en œuvre Scrum :

Scrum, Agilité et Rock'n roll : Se passer de la MOA ou se passer de l'agilité ?

J'ai dit à N. qu'une meilleure solution serait de supprimer la MOA. MOA et MOE c'est fait pour les travaux publics, pas pour le développement de logiciel. C'est le bon moment en période de crise pour éliminer les gaspillages...

Bon, c'était une boutade, on ne peut pas supprimer la MOA du jour au lendemain.

L’autre population qui est mise en porte-à-faux lors du déploiement de SCRUM : la MOA. Là aussi, le rôle de MOA tel que nous le connaissons est en grande partie absorbé par l’équipe : clarification du besoin, qualification des demandes, tests, … Quelle position la MOA peut-elle alors adopter pour continuer à apporter de la valeur à un projet ?

La solution en laquelle nous croyons aujourd’hui est que la MOA soit partie intégrante de l’équipe.

Et ce n'est pas seulement un problème franco-français ou un problème de la métaphore MOA/MOE issue du BTP. C'est simplement que les méthodes agiles veulent mettre le client au cœur du process de développement d'un système informatique, en limitant les gaspillages : documentation inutile, intermédiaires superflus entre le développeur et le client. Ces sujets touchent principalement les activités de la MOA.

... et ce que j'ai expérimenté : User stories et storyboards,

Sur mon projet actuel, nous avons donc mis en place Scrum. En tant que MOA, on m'a dit : "Maintenant, tu rédiges des user stories.". Ok. J'ai en fait pris le rôle de Product owner, délégué. Avant cela, j'ai quand même fait une étude préalable qui a abouti sur la rédaction d'un cahier des charges chargé d'une étude de l'existant et d'une liste d'exigences. J'ai ensuite décliné ces exigences en user stories. Ces user stories sont un outil très pratique pour planifier les sprints. Au départ j'ai simplement accompagné ces user stories d'un storyboard et de maquettes réalisées via Axure.

quelques spécifications fonctionnelles "old school"

Pas suffisant. J'ai rapidement bifurqué vers une spécification fonctionnelle détaillée ! Aïe, de la documentation ? Mais pourquoi ? C'était impossible d'avoir une vision globale du système sans cela. Et la traçabilité n'était pas suffisante, j'avais toujours l'impression d'aller à l'encontre d'un choix de conception fonctionnel fait plus tôt dans le projet, faute de me rappeler des motifs de ce choix. De plus il était très difficile de discuter avec les projets non Scrum sans un document de spécifications fonctionnelles. J'ai donc décidé de maintenir ce document, enrichi au fil des sprints en essayant d'avoir toujours un ou deux sprints d'avance. De plus certaines réglementations demandent que le système d'information soit documenté, donc impossible de passer outre une documentation fonctionnelle.

et les critères d'acceptation !

Oops, malgré cela, je me suis rendu compte que j'avais oublié un élément capital dans les user stories : les critères d'acceptation ! Pour faciliter la recette au fil de l'eau, il est important d'avoir ces critères d'acceptation au niveau des users stories, même si ceux-ci font souvent référence aux spécifications fonctionnelles. Je pense aussi qu'une automatisation des tests fonctionnels est capitale pour tirer tous les bénéfices d'un mode de développement avec des itérations courtes.

Au final, un bilan positif ?

Finalement, nous avons mis en place Scrum, mais j'ai quand même gardé certains outils propres aux cycles en V. Pourquoi ? Surement parce qu'on ne peut pas changer ses habitudes aussi facilement, mais aussi parce que Scrum ne se suffit pas à lui-même. Comme toute méthodologie, il faut l'adapter au contexte. Tous les développeurs ne sont pas capables de gérer les aspects fonctionnels, les clients ne sont pas forcément prêts à rédiger des users stories, et les équipes avec lesquelles vous devez interagir ne sont pas forcément "agiles". Les itérations courtes, les démos, la collaboration, la recherche du consensus, le pilotage par la valeur ajoutée sont par contre autant d'éléments très positifs de la méthodologie.

Je pense donc que le rôle de MOA ou AMOA s'inscrit parfaitement dans cette méthodologie du moment que l'on accepte que le product owner puisse être en fait une équipe composée d'un sponsor métier, d'utilisateurs clés et d'un ou plusieurs MOA. Dans ce cas,  la ou les MOA doivent clairement avoir la délégation et la capacité pour arbitrer les points en temps réel, quitte à remonter ensuite les points les plus problématiques lors des comités de pilotage du projet. La MOA peut alors apporter toute son expertise en terme d'analyse, de modélisation et de construction de lien fort entre le SI et le métier.