Faut-il supprimer la MOA ?

Posté le par Rémy Christophe Schermesser

Chez OCTO, avant de publier un article, on effectue une revue interne. Et il faut dire que cet article a lancé un grand débat. Il y a eu deux camps : ceux qui pensent que ce n’est applicable que sur les projets innovants, et ceux qui pensent que c’est applicable sur tous les types de projet.

Et vous qu’en pensez vous ?

Disclaimer : Nous allons parler du rôle MOA, pas des personnes de la MOA. De plus, nous parlons ici de la MOA informatique « classique », pas de l’expert fonctionnel/métier (le business analyst hors de nos frontières).

Le nom MOA nous vient des métiers du bâtiment. Elle représente l’entité porteuse du besoin, définissant l’objectif du projet, son calendrier et le budget consacré à ce projet (source Wikipédia). En informatique, elle représente les sachants fonctionnels : ceux qui connaissent les utilisateurs/le métier et qui retranscrivent le besoin en texte compréhensible pour la MOE, nous informaticiens.

Ce rôle dans un projet est-il vraiment encore utile, surtout au vu des nouvelles méthodologies Agile et Lean ? N’oublions-nous pas un peu rapidement le vrai but d’un projet informatique : rendre les utilisateurs plus efficaces dans leurs tâches (ou sur le web : améliorer la vie des utilisateurs).

Adieu MOA

Depuis quelques années, le mouvement agile nous explique que la MOA doit disparaître, certes pas dans ces termes mais c’est l’idée globale. Avoir des gens qui écrivent des spécifications de ce qu’ils pensent être utile aux utilisateurs finaux, qui seront retranscrites en d’autres spécifications puis enfin développées est un non-sens. Ceci produit de l’inventaire, du stock donc du gâchis.

Les agilistes ont donc supprimé ce rôle pour le remplacer par un autre : le PO, le product owner, celui qui a la vision produit. Et ils ont surtout intégré ce rôle directement dans l’équipe de développement. De plus, l’équipe (PO compris) rencontre régulièrement le sponsor du projet, généralement toutes les semaines lors de la démo.

Donc globalement, le rôle MOA n’existe plus dans un projet agile. Je suis persuadé que cette façon de fonctionner a grandement amélioré la qualité (du point de vue des utilisateurs finaux) des logiciels développés.

Arrêtons-nous 30 secondes et regardons ce qu’il se passe. On nous parle de PO, de sponsor mais jamais d’utilisateur. C’est pourtant bien lui qui devra utiliser le produit, pas le PO ni le sponsor.

Mais où est-il ?

Au revoir PO

Si on résume, le PO est (encore) un intermédiaire entre l’équipe et les utilisateurs. On a donc remplacé un proxy, la MOA, par un autre, le PO. Et les utilisateurs sont encore oubliés.

Il est vrai que certaines méthodologies agiles préconisent des tests utilisateurs. Mais le « sachant » reste le PO. Quelle est sa légitimité ? En sait-il plus que les utilisateurs ? A-t-il accès à une boule de cristal magique ?

Je ne crois pas.

Le seul et unique sachant sont les utilisateurs. C’est lui qui sera devant son écran à cliquer sur des icônes toute la journée. C’est lui qui devra utiliser le produit pendant plusieurs années.

Alors pourquoi ne pas lui demander son avis directement ?

Bonjour utilisateurs

Bon facile me direz vous, on kidnappe des utilisateurs, et on les questionne jusqu’à avoir la substantifique moelle de leur besoin, et hop c’est gagné.

Malheureusement, ce n’est pas si simple. Le soucis avec les utilisateurs c’est que globalement ils ne savent pas ce dont ils ont besoin avant d’avoir pu l’essayer. Il est donc impossible de trouver du premier coup la fonctionnalité qui les satisferons.

C’est ici qu’intervient le Lean et plus particulièrement les idées issues du Lean Startup : les hypothèses produits. L’idée est simple, on applique la boucle du PDCA :

  • On pose une hypothèse sur le produit
  • On effectue la plus petite action nécessaire pour la réaliser
  • On mesure son utilité pour les utilisateurs
  • On en tire des conclusions

Les hypothèses produit sont une intuition sur une fonctionnalité à développer pour améliorer le produit du point de vue des utilisateurs. Elles sont généralement émises par les PO/PM (product manager). Oui, le fameux PO que l’on a excusé un peu plus haut. Il n’est toujours pas un utilisateur, mais il est celui qui les connaît sûrement le mieux et est donc le plus à même d’émettre des hypothèses au début du projet. Puis, au fur et à mesure de l’avancement du projet, c’est l’équipe entière qui devient capable d’émettre des hypothèses, car elle acquiert de l’expertise sur qui sont les utilisateurs. Précisons que l’équipe décrite ici est une équipe composée de tous les profils nécessaires au bon déroulement du projet. Elle inclut (de manière non exhaustive) : les développeurs, les UX, les designers, le marketing, etc.

Une fois que l’on a notre hypothèse il faut l’implémenter. C’est cette étape qui est à mon sens la plus complexe, pas parce que l’hypothèse peut nécessiter beaucoup de code ou de cadrage. Mais parce qu’il est crucial de trouver l’action la moins coûteuse pour valider l’hypothèse. Par exemple, si l’hypothèse est « mon utilisateur veut pouvoir effectuer une simulation de prêt », l’action la plus petite n’est pas de réaliser un simulateur de prêt complet. Elle est de vérifier que l’utilisateur veut effectivement bien un simulateur de prêt.

Lors de l’implémentation de l’hypothèse il faut garder à l’esprit que le but est de mesurer si notre hypothèse apporte de la valeur aux utilisateurs. Il faut donc s’équiper pour pouvoir la mesurer. L’implémentation va donc grandement dépendre de la façon dont la mesure sera effectuée. Si on est sur le web on peut utiliser des outils comme google analytics. Mais si on décide d’aller directement rencontrer des utilisateurs on peut ne réaliser qu’un questionnaire, et donc 0 ligne de code.

La dernière étape est celle où l’on regarde les métriques et on prend une décision : « Oui, à plus de 90%, les utilisateurs souhaitent un simulateur de prêt. Alors passons donc à réalisation »

La suite est simple, on recommence cette boucle. Notre utilisateur souhaite un simulateur de prêt, alors réalisons le plus simple simulateur possible et mesurons comment et qui l’utilise, ce qui nous permettra de l’améliorer en gardant toujours l’utilisateur au centre de nos préoccupations.

Conclusion

Je ne pense pas que demain la MOA et les PO vont disparaître. Ils restent les sachant fonctionnels, ceux qui, par exemple, savent comment calculer un prêt. Mais leur rôle se doit d’évoluer, pour aller encore plus au contact des utilisateurs : comment recueillir le feedback rapidement, comment valider au plus tôt les fonctionnalités, … Il doit aussi évoluer pour aller plus proche des projets pour apporter le plus efficacement et rapidement de la valeur à ceux-ci.

Si vous souhaitez aller plus loin, je vous conseille les livres Lean Startup et Running Lean, sans oublier les sessions USI (ici et ici).

22 commentaires sur “Faut-il supprimer la MOA ?”

  • Thierry
    Bj, pour plus de clarté j'aurai fait la distinction entre des utilisateurs "internes" et des utilisateurs "externes" (webnautes). La problématique peut etre sensiblement différente. Ensuite ce qu'on appelle MOA peut avoir un role en dehors des projets, en particulier dans le processus de gestion de la demande et dans la maintenance des modèles descriptifs des concepts métiers (processus et objets métiers). A+ Thierry
  • Patrice
    Ajoutons les outils d'ergonomie aux méthodologies Agile et Lean. Ils permettent d'aller encore plus loin dans le recueil des besoins et du feedback. Les "personas", par exemple, permettent de développer l'empathie des concepteurs envers les utilisateurs réels. Un jour peut-être basculerons-nous de la conception centrée concepteur (ou pire encore la conception contrée décideur) à la « Conception Centrée Utilisateur ». Un peu à l'image du basculement des états vers la démocratie... à quand une révolte des utilisateurs d'un logiciel d'entreprise devant le bureau de leur DSI ?
  • Stephan
    A mon expérience les meilleurs POs combinent une compétence technique très forte ainsi qu'une capacité de "négocier" avec des utilisateurs. Ils sont donc médiateurs à double titre (pas évident). En supprimant les POs vos pauvres utilisateurs devront directement parler aux équipes techniques. On connaît ce que ca donne...
  • Rémy-Christophe Schermesser
    @Stephan, vous dites que lorsque les utilisateurs parlent aux équipes techniques on voit ce que ça donne. Pourriez-vous en dire plus ? De mon expérience, ça se passe justement beaucoup mieux. Les développeurs se sentent mieux considérés et comprennent mieux ce qu'on leur demande de réaliser. Ce qui a tendance à augmenter la qualité du produit.
  • Rémy-Christophe Schermesser
    @Thierry, en quoi les utilisateurs internes sont différents des internautes ? Ce sont pourtant les mêmes personnes. De plus, il est beaucoup plus simple d'aller rencontrer les utilisateurs internes. On sait où ils se trouvent et qui ils sont. Ce qui rend beaucoup plus facile les relations avec eux
  • Olivier Durand
    Je trouve toujours très enrichissant d'avoir des avis au sujet de la MOA. Je vais donc me permettre de faire une looooongue réponse et prêcher un peu pour ma paroisse. C'est un "vieux" débat, une vieille guerre de tranchées. Je me rappelle de ce billet de Claude Aubry il y a plus de 3 ans : "Se passer de la MOA ou se passer de l'agilité" (http://www.aubryconseil.com/post/Se-passer-de-la-MOA-ou-se-passer-de-l-agilit%C3%A9). Si vous pensez vraiment que "Si on résume, le PO est (encore) un intermédiaire entre l’équipe et les utilisateurs. ", alors vous n'avez pas compris le rôle d'un PO. Je vous invite à regarder cette vidéo qui explique en 15mn ce qu'est le rôle d'un Product Owner : http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell Tout comme une MOA dans une organisation qui colle au cycle en V, le PO recueille et analyse LES besoins DES parties-prenantes, il a le pouvoir de dire NON aux utilisateurs et est capable d'arbitrer entre deux demandes qui vont dans des sens opposés. Il a une vision long terme/stratégique et une vision court terme/tactique. Il n'a pas vocation à couper la communication entre les utilisateurs et l'équipe de réalisation. Je ne pense donc absolument pas qu'un PO n'est qu'un "proxy". Ou alors vous avez toujours travaillé avec de mauvais PO. Ne confondons pas non plus la MOA et l'expert d'un domaine. La MOA ou le PO n'est pas forcément le "sachant fonctionnel" (Business Analyst VS Subject-matter expert). Même si il est vrai que ces deux rôles se fondent souvent dans une même personne. Concernant les techniques d'enquêtes ou A/B testing, pour mesurer correctement, il faut avoir bien défini les indicateurs, avoir posé les bonnes questions. Une bonne MOA ou un bon PO aura justement les compétences et connaissances nécessaires pour utiliser correctement ces techniques. Mes remarques par rapport à votre point de vue exprimé dans cet article sont très théoriques. Sur le terrain, en fonction des personnes (compétences, connaissances, séniorités) et des organisations (éditeur de logiciel, startup sur des applis mobiles, banque...), en fonction de l'aspect stratégique du projet et de sa complexité fonctionnelle, avoir une MOA ou un PO dédié aura du sens ou pas. Donc pour moi il n'y a aucun intérêt à répondre à la question "Faut-il supprimer la MOA ?". J'ai l'impression que votre point de vue concerne surtout le développement d'applications web ou mobiles, avec des cycles très courts (vous parlez de sprints d'une semaine), où seuls les utilisateurs de l'application doivent être satisfaits. Si vous pensez qu'il faut supprimer la MOA (ou le PO), pourquoi ne pas supprimer aussi les ergonomes, les marketeux, les commerciaux qui sont aussi des "proxy" entre les développeurs et ce que veulent les utilisateurs ? Par rapport à votre conclusion, je suis d’accord que la MOA doit évoluer pour s’intégrer aux méthodes agiles. Cela fait longtemps que la profession l’a compris, cf. les nombreux échanges sur le sujet dans les blogs et la prise en compte par l’IIBA de l’agile : http://www.iiba.org/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx
  • Rémy-Christophe Schermesser
    Bonjour Olivier, Merci pour votre looooongue réponse. Votre vision est très intéressante, mais je la trouve très théorique. Effectivement, le PO n'est pas, théoriquement, juste un proxy, mais dans les projets que j'ai pu voir il n'apportait pas de autant de valeur qu'il aurait dû. Je ne suis pas pour donner toute la puissance aux développeurs. J'explique dans l'article qu'il faut redonner du pouvoir à toute l'équipe de développement, équipe qui est composé de plusieurs compétences et rôles, dont les ergonomes, le marketing, etc. Par contre, je suis pour supprimer au maximum les intermédiaires entre l'équipe et les utilisateurs finaux.
  • Stephan
    Bonjour, Le leader fonctionel de l'équipe informatique devrait assumer le rôle du PO. Justement les PO sans bagage téchnique sont d'une utilité limitée. Ils risquent de se faire "diriger" par les volontés et envies des devels. Stephan
  • Fabrice Croiseaux
    I love you
  • alex
    Excellent article! La moa a la trappe!! :) Un logiciel est un système complexe (voir cours de cybernetics)! La prise de conscience du système et le système lui mème co-émergent dans une relation causale circulaire. La vision classique (cycle en V - besoins => analyse ==> solution) qui est une causalité linéaire et qui justifit la MOA est inadaptée aux développement de système complexe que sont les logiciels. Bravo encore pour ton analyse! :)
  • Syl
    Qu'est-ce qu'un "simulateur de prêt" et qu'est-ce que "calculer un prêt" ? La MOA a manifestement encore de beaux jours devant elle ...
  • alex
    La division MOA(ceux qui concoivent)/MOE(ceux qui excécutent) telle qu'elle est définit dans le batiment est inappliquable au génie logiciel. La programmation étant une activité de développement (de conception) et non pas de fabrication, les programmeurs devraient faire partie de la MOA. La MOE serait plutôt la machine qui exécute les plans spécifiés des programmeurs. En France on désigne souvent les utilisateurs et experts fonctionnels par le terme MOA alors qu'ils ne font en réalité qu'exprimer des besoins.
  • alex
    Le seul bon langage de spécification apte à spécifier les fonctions d'un système d'information est le langage de programmation parce qu'il est conforme au cahier des charges d'un langage de spécification: cad être formel, lisible et compréhensible à la fois par le concepteur (le programmeur) et par l'exécutant (la machine). Les spécifications écrites en langage naturel ou pseudo formel telles que produites par la MOA, constituent souvent un gaspillage de précieuses ressources qui seraient mieux employées en développement pour le plus grand bénéfice des utilisateurs. Comme le dit l'article, ça fonctionne le mieux quand: les utilisateurs (expert fonctionnels) et les développeurs collaborent, développent et programment la machine dans un processus incrémental, émergent, cyclique (causalité circulaire) où on ne peut plus distinguer le besoin de la solution.
  • slz
    Quid: - de la priorisation lors d'afflux massif de besoins (deux utilisateurs se crêpant le chignon via service informatique) ? - du budget alloué par la boîte pour réaliser les besoins des utilisateurs (avec plusieurs corps de métier comment fait on pour distribuer les ressources de développement; souvent les ressources de dev sont le goulot) ? - dans le cas d'un produit c'est l'équipe qui porte la vision produit et plus des rejetons du marketing ? On peut imaginer à chaque fois des systèmes basé sur une analyse coût/valeur pour remplacer ces fonctions du PO/MOA , mais il y'aura un effet 'dictature de la majorité' ou 'produit consensuel'. mmm y'a t'il des retours sur le cette pratique ?
  • Rémy-Christophe Schermesser
    @alex je ne peux dire qu'une chose : je suis tout à fait d'accord :) @slz - Pour la priorisation, on a rarement que 2 utilisateurs pour une application. Donc le cas doit vraiment être au limite. Il faudrait voir plus en détail une cas concret. - Pour le budget alloué, je ne comprends pas votre question. - Pour le cas produit, c'est soit un Product Owner/Product Manager, et plue le projet est "vieux" plus toute l'équipe partage la vision. Le marketing fait partie intégrante de l'équipe, donc rien n'empêche que le PO/PM soit une personne du marketing. - Les retours de cette pratique sont nombreux, je vous conseil de regarder la session USI : http://www.usievents.com/fr/conferences/11-paris-usi-2012/sessions/1053-lean-startup-1-an-apres-innovation-produit-dans-la-dsi
  • A.K.
    Bonjour, Point de vue intéressant et force est de constater que certaines questions nous viennent à l’esprit en lisant votre article. Malheureusement, pour moi en tout cas, ces questions m’amènent à penser que la MOA et le PO ne disparaîtront pas au profit d’une démarche Lean startup. Et que le lean startup n'est pas une solution. Je m’explique : Adieu MOA ? La MOA est défini dans le cas d’un commanditaire et d’un contractant. Prenons le cas ou le contractant est un sous traitant. En tant que contractant, vous voyez vous avoir plusieurs interlocuteurs, plusieurs signataires ou plusieurs décisionnaires (avec chacun un objectif différent)? Personnellement je ne prendrais pas ce risque. Au revoir PO ? En tant que sous-traitant, vous réalisez un logiciel pour une bonne centaine d’utilisateurs. Vous pensez vous passer de PO? Faudra t il attendre l’accord de cette centaine d’utilisateur pour établir les priorités et valider les fonctionnalités développés? Ne faut il pas quelqu’un pour trancher sur les choix à faire ? Si on se passe du PO, stock de Dolipranes et d'anxiolytiques (ou une corde) à prévoir pour les développeurs. Bonjour Lean start up ? Vous proposez la piste du Lean Starup. Dans son ouvrage, Eric Ries, explique comment tester des hypothèses stratégiques auprès des utilisateurs. Il s’agit d’adapter son offre (mais aussi l’entreprise) à l’évolution du marché et donc du besoin potentiel des clients. A aucun moment il n’est question d’une offre basée sur la demande du client. Jamais. C'est d'ailleurs le gros point noir de cette méthode qui utilise le terme "Lean" à des fins marketing (on est plus dans l'organisation apprenante que dans le Lean). Il est d'ailleurs étonnant de mettre en exergue le Lean dont on commence à remettre en cause: en terme de production qualitative (les retours toyota de 2010), de condition de travail et de santé (considéré comme pire que le taylorisme par les études de l'UE). Je vais prendre un exemple pour montrer que le Lean startup ne peut pas s’appliquer dans une relation commanditaire / contractant : Mon entreprise à besoin de changer son logiciel métier, celui ci est devenu obsolète. Pas de produit adapté sur le marché, il faut en développer un. Je n’ai pas les compétences internes pour réaliser ce développement, je fais donc appel à un prestataire. Ce prestataire m’explique que l’utilisateur est au centre de tout mais que malheureusement il ne sait pas exactement ce qu’il veut. Le prestataire me propose donc de mettre en place le lean startup pour réaliser LE produit. Ok. Mais, en tant que commanditaire, je vous demande à ce moment là (à vous le prestataire): ça va me coûter combien tout ça ? Vous allez me répondre : « je ne sais pas car personne ne connaît le besoin mais je vous assure que les utilisateurs aurons un logiciel sur mesure » Pensez-vous que je vais signer un chèque en blanc ?
  • Rémy-Christophe Schermesser
    @A.K. Je vais répondre à vos points Adieu MOA Si vous voyez les contractants comme des prestataires et non des partenaires, je comprends vos réticences. Heureusement, tout le monde n'est pas de cet avis. Et je pourrais vous citer plusieurs cas où avoir une relation de partenaires est beaucoup plus bénéfique. Au revoir PO Notez bien que je parle d'abandonner le PO au profit d'un product manager, donc il y a bien toujours quelqu'un pour arbitrer et faire des choix. Bonjour Lean start up Je ne fais pas de bonjour Lean Startup, mais bonjour utilisateurs. L'idée de mettre les utilisateurs au centre du produit est une mouvance un peu plus vieille que le Lean Startup (cf. Inspired & co). Le Lean Startup offre simplement un cadre. Pour votre exemple, vous parlez d'une refonte d'un logiciel. Je pense que cette méthode est d'autant plus utile dans ce cas là car vos utilisateurs savent déjà ce qu'ils veulent et ce qui ne fonctionne plus sur leur outil. Donc un cadrage "classique" permettra d'avoir un chiffrage (si c'est ce qui est important pour vous). De plus, les produits qui réussissent sont rarement construits dans une démarche client/fournisseur.
  • A.K.
    Merci pour votre réponse, Soit pour la partie PO, je comprends mais quelque soit le nom donné on en revient à la même chose: un représentant. Pour la partie MOA, vous me prêtez des propos qui ne sont pas les miens. Je vais donc reformuler. Deux entités distincts ne peuvent communiquer que par des représentants: le représentant de l'entité A et le représentant de l'entité B. En l'occurrence une MOA et une MOE dans le cadre commanditaire/contractant (on les nomme ainsi de manière légale, aucune interprétation à faire sur leur type de relation...votre interprétation n'est pas mon propos). Donc si la MOA disparait... avec qui la MOE va t elle échanger? De la même manière, sur le Lean votre remarque "si c'est ce qui est important pour vous" me laisse perplexe. Je comprends bien qu'il y avait un peu de provocation dans votre remarque (enfin, je l'espère). Votre société ne travaille pas gratuitement et en face il y a bien quelqu'un qui va payer. Vous-même, achetez vous quoique ce soit sans en connaitre le prix?
  • A.K.
    J'ajouterai juste un dernier point: les parties prenantes d'un projet ne limitent pas aux utilisateurs. Merci à vous d'avoir pris le temps de répondre.
  • Anas
    Au vu de la description faite par ce papier de la MOA, il s'agit plus d'AMOA que de MOA. Si la suppression d'un intermédiaire peut marcher pour l'implémentation verticale d'une section de processus métier sous forme d'application, elle ne marchera certainement pas pour l'implémentation horizontale d'un processus métier de bout en bout sous forme de projet SOA ou BPM car très rares sont les utilisateur directs qui ont la connaissance globales du processus métier de bout en bout et quand il y en a, il n'ont pas la connaissance du détail. Les connaissance horizontale et verticale du besoin métier ont tendance à être antinomiques. Seul quelque rare urbanistes ont la capacité de profondeur et de vision globale simultanément. Pour résoudre cette équation, les équipes d'expression de besoins sont généralement constituées de consultants ayant une connaissances détaillée cadrés par un urbaniste projet. Le rôle d'AMOA est indispensable en tout cas pour un projets d'implémentation d'un processus métier de bout en bout impliquant plusieurs applications. Cela dit, il est vrai que pour certains projet verticaux, il est possible d'optimiser l'expression de besoins en réduisant les intermédiaires.
  • Erik
    Vous oubliez plusieurs éléments. Les utilisateurs n'ont tout simplement pas forcément le temps d'être impliqués dans les projets. Ou bien très peu. D'où l'existence des MOA. Une MOA n'est pas quelqu'un d'inculte, si c'est un ancien utilisateur il aura une bonne vision et impliquera les bonnes personnes. D'autre part un projet informatique n'est pas que la création d'un logiciel, le déploiement et la formation des utilisateurs sont des tâches qui peuvent être lourdes. Avoir un chef de projet MOA qui gère cela et un autre qui gère le développement peut s'avérer utile. Le tout est de travailler intelligemment ensemble. Alors vous les appelez PO et SM ne change rien à l'affaire. Les experts fonctionnels sont généralement "dans" la MOA, ne les mettez pas en dehors...et cela prend du temps d'être expert métier, c'est un vrai métier. Bref, tout cela pour dire que l'on a besoin d'une fonction MOA, quelque soit le nom que vous donnerez car le travail réalisé demande du temps et des compétences qu'il est difficile de fusionner avec des compétences de gestion d'une équipe informatique (où des compétences en système d'information sont elles aussi nécessaires).
  • Michel
    Ce qu'il ressort principalement de ce que je lis ici, c'est que les DEV veulent aller en direct au contact des utilisateurs sous couvert de "le produit sera meilleur, on pourra mieux coder. Soit. En tant que PO, je n'ai jamais été contre qu'un de mes dev aille justement au contact d'un métier. Mais si la question devient "adieu le PO/la MOA, on peut faire sans", vous vous faites énormément d'illusions sur le monde capitaliste dans lequel vous évoluez. Oui vous pouvez dév sans MOA & PO, encore heureux. Mais qui va prioriser les activités de l'équipe? Négocier? Décrocher les budgets? Je pense que vous n'avez qu'à vous faire à l'idée que sans "commercial"/chef de projet (et donc de PO), il n'y a juste pas de projet. Une entreprise ne dépense rien sans responsabiliser une personne spécifique dans une entreprise. Un PO.

      • Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha