Articles « Info » : Développeur

MOA - MOE : Dossier à décharge par Christophe Thiry [CThiry]

Christophe Thiry, présenté plus en détail ici ([CThiry]), confesse "un lourd passé de chef de projet", et a eu l'occasion de pratiquer la relation "client / fournisseur" des 2 côtés de la barrière.     Sa réaction est simple : « Vous avez instruit le dossier à charge mais pas à décharge ».     Cela est vrai et rejoint mes remarques faites dans la page d'Avertissement ! : un article partiel et partial!     En effet, je ne peux nier avoir exprimé beaucoup de doute sur la validité d'une telle organisation MOE et MOA (Maître d'OEuvre et Maître d'OuvrAge) ... Cette relation me paraît source de conflit plus que de collaboration et trouve un écho inquiétant dans une culture très verticale, à la française... Mes "remarques" sont en [italique rouge entre crochets]. Les renseignements essentiels de cet entretien sont en gras italique rouge.

    J'avais bien noté également la difficulté de traduire ce concept en anglais : le concept lui même n'existe pas. Mais le concept de "client / fournisseur" existe dans les 2 cultures. 
    Contrairement à vous, je suis de plus en plus persuadé, au fil de ma pratique (j'ai été des deux côtés de la barrière), que ce concept Moa/Moe est LE bon concept. 
Pour plusieurs raisons: 

1/ le client n'a pas à se préoccuper de solutions techniques. 
Sinon, la réaction du fournisseur est sans appel : "monsieur, faites donc le travail à notre place" 
De plus, le temps passé à définir les solutions techniques n'est pas passé dans la recherche et l'élaboration des besoins, ce qui est un métier autrement plus difficile. Il faut aller convaincre sa hiérarchie, ... 
Le fournisseur doit maîtriser ses solutions techniques. 
[Cela est vrai : tout ce qui se trouve en amont d'un projet (les études préalables, les campagnes quasi-politique pour débloquer les budgets, les négociations internes, les prototypages et autres forums - "workshops" disent-ils... - pour étudier les différentes options entre évolution de l'existant, refonte complète, ajout de nouveau système... tout cela reste encore très obscur pour la plupart des informaticiens!]

    Une anecdote : 
    J'ai eu un cas récent où un collègue (MOa) en connaissait plus que le fournisseur sur un point technique (cela concernait du k-shell, il me semble) Le fournisseur livrait des trucs non testés mais passés au crible par le collègue en question. Conclusion : le fournisseur n'a jamais fait l'effort d'apprendre, et mon collègue a du consacrer une bonne partie de son temps à reprendre le travail. C'était devenu la foire d'empoigne. C'en était venu aux hurlements. 

    MOa-MOe : ne pas se tromper de "séparation"
    Vous parlez de séparation des pouvoirs. Alors qu'il s'agit d'une séparation des rôles. 
    Les organigrammes sont alors très simples. [au contraire de ce que je dénonce en fin d'article de MOa et MOe]
    Si la MOa décide de se faire assister c'est qu'elle n'a pas le personnel pour remplir sa mission. Alors interviennent les assistants MOa. Ce sont des consultants qui sont "loués" par les SSII (je n'apprends rien à personne), une fois passé l'accord financier, ils sont assimilés à l'équipe et doivent se comporter comme des MOa. 
Ceci ne remet pas en question la définition de MOa - MOe. 
Les assistants MOa ne sont pas davantage déconsidérés que les autres membres de l'équipe. C'est une vue de l'esprit. 
[Et cela explique sans doute pourquoi MOa-MOe est le "bon" concept pour Christophe Thiry, surtout pour des français : si l'on s'en tient à une stricte séparation des rôles, en effet tout va bien :
- chacun sait ce qu'il a à faire ;
- tout apport extérieur, comme l'AMOA - Assistance à Maîtrise d'Ouvrage -, sait également ce que l'on attend de lui.
Hélas, comme je le fais remarquer dans l'article Informaticien et Français ? - Verticalement - Dur!, pour un français, l'aspect relation prime sur la tâche! On est alors plus vite tenté, dans cette culture, de séparer non seulement les rôles (ce qui est l'intention louable de "MOa-MOe"), mais aussi les pouvoirs... d'où conflits et organigrammes compliqués] 

2/ Syndrome « moi (Moa), je sais mieux faire que le fournisseur (Moe) »
    Vous parlez du consultant qui rentre à regret en France. [Oui, ici]
    Mais le phénomène qui se passe, c'est que les MOa sont extrêmement tentés de faire de la solution technique. 
-> il y a le symptôme du "moi, je sais mieux faire que le fournisseur" 
-> il y a aussi le fait que ce sont des anciens informaticiens qui font de la MOa. Ils ne savent pas distinguer les besoins des solutions. 
     J'ai pu observer cela plusieurs fois : les ex-informaticiens qui rédigent des expressions de besoin font des "expressions de solutions" ou "specs de solutions". [cf. Les spécifications (Besoin)]
[Cf. également "développeur sur un projet en manque d'itération"]
    Anecdote
    J'ai en ce moment un autre collègue qui illustre bien le phénomène. 
Ses expression de besoins contiennent par exemple "l'identification de l'utilisateur sera insérée dans une base de donnée sécurisée"... ce qui est une solution.
Si on avait écouté sa solution, le système aurait mis une donnée dans une base et rien n'aurait été sorti de la base. Alors, un peu de "maieutique" [ce qui peut se traduire dans ce contexte par "reformulation"] plus tard avec lui, il se rend compte que ce qu'il voulait dire c'était "le système doit filtrer les individus non reconnus" ce qui est le besoin. Je luis explique la différence entre besoin et solution. Il comprend, il corrige, et 2 semaines après, il refait la même boulette. 

    Autre anecdote
    Un ami responsable technique travaillant en MOe chez un grand groupe industriel français a démarré un nouveau projet. 
    Lecture du cahier des charges du client - assez épais, d'ailleurs. Tout à coup il voit des algorithmes en pseudo C avec des pointeurs ! 
    Il téléphone au client qui lui explique qu'il a fait réaliser son Cahier des charges par un assistant maîtrise d'ouvrage. Ce mec n'y connaissait rien : il a fait 70% du cahier des charges en "specs de besoins". Mon ami a été bien embêté, parce que la solution proposée par le client était totalement irréalisable sur le SGDT qu'il devait utiliser. Et il insistait du style "Mr le fournisseur, vous devez faire comme c'est écrit. Je n'ai pas payé un assistant MOa pour rien pendant 6 mois".
[C'est en effet la caractéristique d'une spécification : c'est une bible. Mais si la maîtrise d'œuvre découvre des solutions techniques dans la spécification de besoins(!), sa marge de manœuvre est en effet très réduite!]
     Ils sont restés coincés comme ça ... un certain temps. Je lui ai conseillé de découper le cahier des charges client pour séparer les besoins des specs de solutions, en essayant d'extrapoler les besoins effectifs cachés derrières les solutions apparentes et de formuler leur offre globale en ne prenant en compte que les besoins. Cela a au moins débloqué la situation : ils ont fait la version 1. 
    Cette approche n'empêche en rien une absence de "process" (steps ou milestones). Dans les projets français aussi il y a des planning avec jalons !


Conclusion générale
    Toute la difficulté d'exercer ce métier viens de notre façon habituelle de vivre au quotidien. 
Je m'explique: quand vous avez soif, que faites vous ? Vous allez directement chercher un verre d'eau, vous le remplissez, vous buvez.
(sauf Louis XIV à qui n'avait pas à chercher de l'eau lui même ...) 
Autrement dit, vous pensez directement à la première stratégie venue et vous la mettez en place immédiatement. 
    Tout cela illustre bien que :
1. il est important de maîtriser les besoins et de ne pas confondre les rôles. Dès que l'on fait autrement, tout part en vrille. 
2. si l'on souhaite faire plutôt de la technique (la motivation initiale qui nous fait faire de l'informatique), il vaut mieux rester côté MOe, parce que côté MOa, ce n'est plus le même métier.