La MOA pragmatique du SI (Business Analysis, Analyse d'Entreprise, Maitrise d'Ouvrage)

Acquérir la confiance et le respect des différentes parties prenantes de vos projets est primordial pour pouvoir jouer pleinement votre rôle de facilitateur et d'influenceur. Si les gens vous respectent, vous pourrez plus facilement désamorcer les conflits. Si les gens vous font confiance, vous obtiendrez plus facilement l'adhésion aux décisions prises. Mais comment en arriver là ? Comme aujourd'hui je suis d'humeur optimiste, commençons par la méthode Coué :

Si vous avez confiance en vous-mêmes, vous inspirerez confiance aux autres.
Johann Wolfgang von Goethe.

On respecte un homme qui se respecte lui-même.
Honoré de Balzac.

Communiquez, faites circuler l'information

Si vous faites circuler l'information, à bon escient évidemment, on vous reconnaitra comme quelqu'un de confiance. Celui qui fait de la rétention d'information n'est pas vu comme quelqu'un de confiance, mais plutôt comme un incompétent. En effet, si il était compétent, il n'aurait pas besoin de faire de la rétention d'information pour se valoriser.  

Ne réagissez pas aux objections infondées

Si on sur-réagit à des objections infondées (qu'elles soient émises par mail, en réunion ou par tout autre média), c'est qu'on est sur la défensive et donc que l'on a des choses à se reprocher. Dans ce cas là, mieux vaut ne pas réagir du tout. Laisser un blanc dans une réunion suite à une objection infondée fera clairement comprendre à son interlocuteur qu'il s'est lourdement trompé. Et cela vous assurera le respect.

Prenez vos responsabilités, assumez les erreurs

Nous commettons tous des erreurs. En tant que MOA, vous devez accepter vos propres erreurs (par exemple un oubli dans une spécification ou une erreur de conception fonctionnelle), mais vous devez également assumer les erreurs de toute l'équipe projet face à vos sponsors. Inutile de rechercher et identifier le coupable idéal, cela ne vous apportera rien. Face au sponsor, soyez efficace : quelle erreur a été commise, quels sont les impacts, quel plan d'action pour y remédier. Savoir gérer et assumer les problèmes vous aidera à gagner la confiance des parties prenantes de vos projets.

Finalement, acquérir confiance et respect dans le milieu professionnel est un travail sur le long terme. Éthique, déontologie, développement durable sont des concepts à la mode que l'on peut appliquer pour soi au quotidien. Pour une fois c'est mon côté Candide, ou l'optimisme qui parle.

Le travail éloigne de nous trois grands maux : l'ennui, le vice et le besoin.
Voltaire.

Lean, Six sigma, Kanban... les méthodes et outils de l'industrie "lourde" ont débarqué sur le front du SI. Avez-vous déjà visité une usine de production ? Il n'y a que peu de similitudes avec un open space où l'on fait évoluer un système d'information. C'est une critique assez souvent entendue de ces méthodes appliquées à l'informatique : "Un développeur n'est pas un ouvrier sur une chaîne de production, c'est un artisan.". Et la maitrise d'ouvrage du système d'information ? Elle travaille sur des sujets qui sont tous différents, impossible de reproduire une méthode à l'identique, chaque projet a ses contraintes et ses spécificités, aucune solution ne marche deux fois. Alors, comment conserver un esprit créatif quand ces méthodes poussent à l'uniformisation et à la rationalisation ?

Conserver son esprit critique

Un cadre méthodologique permet d'avoir des repères et d'être opérationnel plus rapidement. Mais si cela nous semble nécessaire, il ne faut pas hésiter à sortir de ce cadre. Il n'y a pas de vérité absolue sur la manière de recueillir un besoin ou de modéliser un processus métier. Il faut absolument conserver son esprit critique et remettre en cause le process si celui-ci ne semble pas efficace. D'ailleurs le Lean se base sur le principe Kaizen (amélioration continue)  pour atteindre ses objectifs de performance.

Prendre son temps

Certaines activités intellectuelles ne sont pas compatibles avec le micro management. Parfois, seul le temps permet de démêler des sujets complexes, et une méthode centrée sur le "à faire" / "fait" ne prends pas forcément bien en compte ces temps de réflexion. Il faut apprécier le temps où l'on ne réalise rien comme un temps nécessaire et non pas du temps perdu.

Utiliser les outils de la créativité

Brainstorming, veille concurrentielle, cartes heuristiques... Il existe plein d'outils pour catalyser la créativité. Une ambiance d'équipe sereine permet aussi de laisser libre cours à l'initiative et la créativité, alors qu'une ambiance tendue risque de freiner les propositions de peur d'être rabroué.

Je suis convaincu que l'utilisation de méthodologies et d'outils adéquats permettent de faciliter le travail de la MOA et d'augmenter les performances d'une équipe projet. Mais il ne faut pas agir sans comprendre, et il ne faut pas oublier que ce n'est pas aux équipes projet de s'adapter aux méthodes, mais que ce sont les méthodes qui doivent être adaptées aux équipes. 

L'ordre est le plaisir de la raison, mais le désordre est le délice de l'imagination.
Paul Claudel.

Nous avons vécu beaucoup d'innovations dans les interfaces homme-machine ces dernières années : terminal tactile multipoint, moniteurs informatiques et téléviseurs en 3D relief, réalité augmentée (pour faire son shopping par exemple), retour des "tablettes"... Mais est-ce que la MOA doit s'intéresser à ces technologies ?

Pas de Système d'Information sans technologie...

Sur ce blog, je traite plutôt du rôle de MOA vis à vis du système d'information. Il est de plus en plus difficile de trouver un processus métier dans une entreprise qui n'utilise pas l'informatique. Et le premier contact des utilisateurs avec leur SI, c'est via les interfaces graphiques des systèmes. Il est donc très important d'être curieux dans ce domaine : essayer les dernières versions des navigateurs Internet, suivre l'évolution des applications open source majeures... et également assurer une veille technologique ! Même si la MOA analyse le fonctionnel ou le métier, il est bon de savoir ce qu'il est possible ou sera possible de faire avec l'outil informatique. Par exemple, la puissance des téléphones portables permet aujourd'hui de développer de nouvelles interfaces en 3D plus immersives (voir cette news sur pcinpact .com : Intel et Nokia travaillent sur des téléphones à interface 3D). Ne voyez-vous pas des applications possibles dans votre domaine ?

... mais n'oublions pas nos objectifs

Mais attention, on croit que les rêves, c'est fait pour se réaliser. C'est ça, le problème des rêves : c'est que c'est fait pour être rêvé (Coluche). Car vous avez un budget à tenir, et les stratégies IT des grands groupes ne doivent pas simplement suivre les modes. Inutile donc de lancer des POC (Proof Of Concept) à tout va, il faut savoir cibler en fonction de la stratégie du SI. N'oubliez pas également que vos utilisateurs sont toujours réfractaires au changement. Alors, évitez les interfaces trop éloignées des standards de fait.

Vidéo : Hiro III, un robot hyptique et une interface tactile en trois dimensions

"Les cas d'utilisation, c'est bien, mais leur description détaillée est un peu lourde. Finalement, nous ce qui nous intéresse c'est la spécification des écrans.", voilà ce qu'un développeur m'a récemment dit concernant des spécifications fonctionnelles que j'avais rédigées. L'approche par cas d'utilisations (use case) pour expliciter les exigences fonctionnelles d'un système est un grand classique de la MOA. Mais alors si les développeurs les jugent indigestes, à qui et à quoi servent-ils ? C'est en lisant ce billet Use cases: a personal history (and a bit of a love affair) de Laura Brandenburg, que je me suis rendu compte que je n'étais pas le seul à me poser ces questions.

Rappels sur les cas d'utilisation

Un diagramme de cas d'utilisation en UML permet de figurer le comportement d'un système face aux stimulations d'acteurs externes, le tout avec un formalisme extrêmement simple.Voilà un exemple décrivant le fonctionnement d'un restaurant :

Un cas d'utilisation est représenté par une "patate". Chaque cas d'utilisation peut ensuite être décrit de manière détaillée avec par exemple le formalisme suivant :

Les cas d'utilisation pour discuter avec le métier

L'avantage d'un diagramme de cas d'utilisation est qu'il est très simple à comprendre. Hormis les associations de type "extends" ou "includes", le formalisme se comprend de lui même. Donc pour appréhender un système existant ou pour expliciter le périmètre d'un projet, ce genre de diagramme me parait indispensable. Et même si on travaille avec des "user stories" dans le cadre d'une méthode agile, réaliser un diagramme de cas d'utilisation permet d'avoir une vision d'ensemble, nécessaire pour les discussions au niveau d'un processus.

Les cas d'utilisation comme outil d'analyse

A moins d'être sur une évolution très simple ou d'être un expert du sujet, il me parait impossible de passer directement du besoin exprimé par l'utilisateur à une maquette détaillée de l'interface prête à être réalisée par l'équipe de développement. Alors comment mener l'analyse qui permettra de rédiger une spécification fonctionnelle détaillée ? Et bien par exemple en utilisant le modèle présenté précédemment pour expliciter les cas d'utilisations car il permet de :

• Formaliser l'exécution normale du cas d'utilisation ;
• Découvrir les cas alternatifs, qui sont souvent oubliés par les différentes parties-prenantes ;
• Découvrir les règles métiers, même celles qui ne se traduiront pas par une règle dans l'interface graphique.

Même si finalement les développeurs auront tendance à se focaliser sur la description des IHM, les cas d'utilisation facilitent la conception de ces IHM et permettent d'avoir rapidement une vision globale du système ou processus étudié. Alors oui, ils peuvent paraitre trop simplistes sous forme de diagramme et trop complexes lorsqu'ils sont explicités de manière détaillée, mais il me semble que c'est un outil indispensable à toute analyse fine du métier.

Que ce soit la préparation (définition de la stratégie de recette et des plans de test) ou son exécution, une recette consomme beaucoup de ressources. J'ai souvent vu des projets sur des systèmes critiques pour l'entreprise avec des tests de validation qui représentaient 20% de la charge globale du projet. Ainsi il est important d'optimiser les activités de test.

Demandez à votre MOE un rapport d'exécution des tests unitaires et tests d'intégration

En plus de l'application à tester, votre MOE doit vous livrer un rapport d'exécution des tests unitaires et tests d'intégration. De nombreux outils existent pour faciliter le développement et le reporting de tests unitaires. Il peut être très coûteux de mettre en place des tests unitaires pour une application existante, il faut donc y penser dès le commencement du projet et que les charges de développement prennent en compte le temps nécessaire à la réalisation des tests unitaires. Pour cela, la MOA doit être prête à sponsoriser cette surcharge de travail.

Plan de test

Il faut utiliser un outil ou a minima un fichier Excel pour consigner les plans de test et les réutiliser. Cela doit permettre de spécifier le plan de test, planifier les campagnes de test, suivre l'exécution des tests et effectuer un reporting sur l'avancement des tests. Les tests des nouvelles fonctionnalités deviennent ensuite des tests de non régression, et on peut les réutiliser.

Tests fonctionnels automatisés

Et pourquoi ne pas aller plus loin et essayer d'automatiser les tests fonctionnels ? Voici un article intéressant vu sur le blog d'Octo Technology : Démarches de tests fonctionnels. Il y est question de deux outils qui permettent d'automatiser les tests fonctionnels et même de documenter les fonctionnalités du système (d'où le terme de "spécifications exécutables") :

• Fitnesse

• GreenPepper

Le principe de ces outils est de décrire le plan de test dans un Wiki sous un format semi structuré (des tableaux). Les données composant le jeux d'essai, les fonctionnalités du systèmes, les résultats attendus, tout est décrit dans un Wiki ce qui est censé offrir de la flexibilité pour documenter et une facilité de prise en main qui permet aux MOA d'écrire les scripts de test. Une fois les tests décrits, il suffit d'exécuter le script de test et la page va s'agrémenter de vert ou de rouge en fonction des résultats des tests. Mais ce n'est pas magique, et il faut coder des "Fixtures" afin de faire le lien entre des outils et les applications à tester. Donc il reste une charge de travail non négligeable côté MOE, à faire en plus des tests unitaires "techniques".

Behavior Driven Development

Le Test Driven Development consiste à commencer par écrire des tests qui vont échouer avant même de développer la fonctionnalité. Au delà de cette approche, Dan North a inventé le concept de Behavior Driven Development :

My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing.

Introducing BDD - DanNorth.net

Cucumber par exemple est un framework qui permet de décrire en langage naturel comment le système devrait se comporter :

Il existe des applications plus riches qui permettent de décrire les Feature et Scenario plus facilement, comme par exemple Lowdown :

http://lowdownapp.com/

Vous pouvez consulter ce billet sur le blog d'Octo Technology : Cucumber pour la MOA pour aller plus loin.

Testeur - Un vrai expert

Finalement, on se rend compte que les techniques de test sont aujourd'hui nombreuses et parfois complexes. Le métier de Testeur est donc devenu un métier en lui-même où l'expertise est dure à obtenir. Si votre structure est trop petite pour avoir une équipe dédiée aux tests, alors il ne faut pas hésiter à faire appel à un expert externe pour aider à la mise en place de bonnes pratiques pour une démarche de test qui doit être intégrée à tout le cycle de vie d'un système.