Découvrez le témoignage de Cindy, Business Analyst senior passée par les plus grands compte en France et au Luxembourg.
Nous suivre
Je me présente, je suis Cindy, je travaille depuis presque 10 ans entres autres en tant que maîtrise d’ouvrage technico-fonctionnelle dans le domaine bancaire. Au cours de ces 10 dernières années et de mes différentes missions, j’ai eu l’opportunité de connaître de nombreux changements dans la manière d’exercer ma profession et également, dans ma manière d’interagir avec la MOE. J’ai travaillé au fil du temps avec une trentaine de MOE et même si, dans la majorité des cas, cela s’est toujours bien passé, on ne peut pas dire qu’à mes débuts, c’était toujours la Love Story entre MOA et MOE. En effet, à cette période, les fonctions de MOA et de MOE (maîtrise d’œuvre) étaient davantage qu’aujourd’hui séparées, cloisonnées. C’est encore malheureusement parfois le cas dans certaines équipes, encore aujourd’hui. Dans mon cas, tout est parti d’une volonté commune de l’équipe: au lieu de rester chacun face à ses difficultés techniques ou fonctionnelles, nous avons promu le principe suivant: “au lieu de t’apporter du poisson, on va apprendre à pêcher”. Et c’est comme ça que MOE et MOA ont commencé à s’initier chacun au domaine de l’autre, à partager les expertises. Puis Agile est arrivé…
Il y a quelques années, les projets étaient menés en modes dits « Waterfall » ou en cycle en V. Dans ces modes de fonctionnement, les rôles étaient alors bien définis : A la MOA, le recueil des besoins, les spécifications fonctionnelles, en veillant bien à tout décrire, de manière exhaustive. Puis, la « spec » passait côté MOE.
La MOE définissait les solutions techniques et en réalisait l’implémentation jusqu’au moment où les développements étaient finalisés et livrés à la MOA pour qu’elle réalise les tests.Les échanges se limitaient à quelques points de clarification sur des éléments unitaires de la spécification fonctionnelle.
Bien souvent, le livrable final contenait des écarts par rapport à ce que le MOA avait en tête. Et souvent, dans mes premières années d’expérience, le débat se résumait à cette question : « Est-ce que c’est dans la spec ? », un débat pour définir les responsabilités de ces écarts. Cette vision est un peu caricaturale mais je pense qu'elle fait écho à un certain nombre d’entre vous.
Puis, les organisations ont entamées une transformation « Agile ». Sans entrer dans les détails et les raisons de cette transformation, les deux fonctions se sont regroupées pour former des « DEV team ». Elles ont alors commencées à adopter une vision commune en termes d’objectifs et de livrables. La « vision » du produit chère à Agile. MOA et MOE sont devenues complémentaires dès la phase de conception du produit. Il ne s’agit plus de travailler de manière linéaire. Une des grandes révolutions de cette nouvelle approche est que les deux fonctions ont commencées à … se connaître, à mieux comprendre les pratiques, les qualités et les difficultés de l’autre. A noter que la fonction de QA entre désormais progressivement dans cette dynamique.
Mieux se connaître dans ses compétences propres a permis de lever toutes sortes de stéréotypes et de préjugés.
Attention – caricature alerte :
La MOE est un couteau suisse : elle doit savoir coder dans différents langages, avoir de solides connaissances en infra et en sécurité, être expert dans les outils de continuous improvement/delivery, être toujours prêts à développer de nouvelles compétences techniques pour suivre la tendance etc … Dans son quotidien, elle doit souvent revenir plusieurs fois sur le même bout de code, parfois parce que la spécification contenait une erreur, parfois parce que l’expression de besoin était incorrecte ou sa compréhension du besoin erronée.
La MOA de son côté fait souvent naturellement soupape de protection face aux pressions subies dans le cadre d’un projet ou d’un incident. Elle doit toujours être en mesure de travailler sur n’importe quel sujet avec bien souvent comme seule source d’information de la documentation datée et des utilisateurs qui n’ont pas toujours le temps de répondre à ses questions. Elle a des idées plein la tête qui se heurtent souvent à de la dette technique qui empêche de les concrétiser.
Une fois ces principes compris par tous, il est plus facile d’expliquer pourquoi les specs contiennent des erreurs, pourquoi un développement qui semble simple prend plus de temps que prévu, pourquoi telle fonctionnalité ne pourra pas être réalisée exactement comme elle avait été imaginée etc… La dev team peut alors collectivement réfléchir à des solutions.
Sous forme par exemple de définition of ready, de definition of done ou de sprint retrospective les deux fonctions travaillent ensemble à construire un cadre favorisant l’amélioration continue. Ces outils permettent de poser les bases d’un contrat clair entre MOE et MOA qui reprend ce qui est attendu de la part de chacun pour permettre de travailler dans les meilleures conditions et de répondre aux attentes de l’autre.
La dev team travaille désormais dans un effort commun et partage les responsabilités en termes d’échecs mais aussi de succès.
Au fur et à mesure de cette assimilation des deux fonctions, la MOA a commencé à devenir plus technique, la MOE a intégré le contexte fonctionnel de ces développements. Les différentes cérémonies Agile ont largement contribuées à cette dynamique : les business requirements sont désormais expliqués en séance, les solutions débattues, les impacts potentiels identifiés en amont et connus de tous. Cela a permis de d’optimiser le temps de tous et de fluidifier les échanges.
Un exemple personnel qui pour moi illustre cette dynamique : En temps que dev teams, nous avions identifié que la phase de test était toujours longue et fastidieuse car le produit que nous développions était extrêmement dépendant d’autres outils souvent down ou ayant un comportement inadapté à nos attentes en environnement de test. L’équipe, sous l’impulsion de la MOE, a collectivement décidé de créer un outil de mock, configurable par n’importe qui (MOA/MOE) pour permettre de réaliser les tests manuels. A faible coup, cet outil nous a permis d’augmenter notre vitesse de validation des développements et de réduire considérablement la charge de tests.
A mon sens, les métiers de MOA et MOE vont progressivement s’assimiler. C’est le sens de l’histoire depuis l’introduction d’Agile. D’ailleurs, de plus en plus d’équipes IT recherchent des profils avec la double compétence. A terme, je pense qu’on ne parlera plus de profils MOA ou MOE mais de profils IT avec des compétences spécifiques en fonction des besoins. Les outils basés sur l’intelligence artificielle tels que les agents conversationnels de type ChatGPT ou tels que Copilot vont permettre de faciliter le passage d’une fonction à l’autre. Un développeur pourra demander à l’IA de lui réaliser des spécifications sur la base d’expression de besoin fonctionnel. La MOA pourra demander, quant à elle, à ces outils, sur la base d'instructions business, de générer du code. Dans un premier temps, il faudra certainement des connaissances fonctionnelles ou techniques suffisantes pour pallier les imperfections de ces technologies. Mais à terme, le scénario me semble tout à fait plausible.
Maintenant, on peut se poser la question suivante : dans cette perspective et en se plaçant au moment où ces outils seront suffisamment aboutis pour ne plus commettre d’erreur, pourquoi ne pas demander directement à l’utilisateur final de les utiliser (et par extension, de se passer des MOA/MOE)? C’est une question qui pourrait faire l’objet d’un article à part entière. Néanmoins, je peux vous livrer une première hypothèse basée sur mon expérience et ma connaissance des deux fonctions. Imaginer qu’il est possible, à court ou à moyen terme, de remplacer ces deux fonctions c’est ignorer une de leur qualité principale. La capacité d’appréhender, dans sa globalité un SI. Garantir la cohérence fonctionnelle et technique, savoir challenger un besoin ou une solution, créer du neuf, de l’innovant par une approche globale des tenants et des aboutissants constituent la plus-value de ces fonctions. Cette caractéristique essentielle est malheureusement bien souvent sous exploitée dans les organisations. Comment, dans les termes évoqués précédemment, une IA peut-elle combiner des besoins en provenance de différentes sources, parfois contradictoires, sans les traiter de manière séquentielle ? Comment va-t-elle construire un modèle qui prend en compte l’éventail du « non-dit », entre autres, tout ce qui est lié à la stratégie long terme d’un produit et pas uniquement ponctuelle ? Par expérience, ces cas sont nombreux et c’est cette capacité particulière des MOA et MOE qui leur permettra de mettre en avant leur caractère indispensable dans le domaine du développement de logiciels informatiques.
Quoi qu'il en soit et sans se projeter aussi loin, travailler les rapports entre MOA et MOE est essentiel pour donner du sens à ces fonctions et gagner en efficacité. Néanmoins, comme dans toute love story, cela passe nécessairement par une envie commune. Parfois, il arrive que les équipes aient l’impression de “subir” ces transformations, qu’elles sont inutiles et pesantes car toutes les conditions ne sont pas toujours réunies pour que les choses coulissent parfaitement. J’ai envie de dire qu’heureusement qu’il n'est pas nécessaire que toutes les étoiles soient alignées pour agir! D’après mon expérience, la sommes des vertus que l’on peut attendre de cette “dynamique Agile” surpasse de loin en bien être, en satisfaction et en qualité des livrables tous les efforts à fournir au démarrage.
%20(2).jpg)
Découvrez en plus sur CQRS à travers des bonnes pratiques et des points de vigilance !
