Client et AMOA : Comment mieux travailler ensemble ?

amoa_client

En tant qu’Assistance à Maîtrise d’OuvrAge, un de nos rôles, et non des moindres, est d’aider les clients à exprimer leurs besoins, de les traduire ensuite selon une logique plus informatique/technique dans les documents transmis à la maîtrise d’Œuvre.

Un langage parfois différent entre les deux parties

Le « client » représente le métier, l’utilisateur final, celui qui utilisera le produit que « les informaticiens » vont développer «pour lui», cet outil sur lequel il compte pour l’aider dans son travail, dans ses tâches quotidiennes. Le client utilise un langage et un vocabulaire précis et adapté à son métier.
Les langages varient donc selon le domaine fonctionnel dans lequel nous intervenons : tertiaire, industrie, transport, milieu hospitalier, assurances … chacun a ses propre acronymes, ses sigles, ses appellations.
Et là, attention aux faux amis, car des termes ou acronymes identiques employés dans deux entreprises peuvent représenter des notions complètement différentes !
L’AMOA quant à elle, utilise parfois des termes informatiques.

L’AMOA, dans ses différentes tâches :
• Recenser et détailler l’existant,
• Ecouter les besoins et s’assurer qu’ils ne sont pas déjà couverts par la solution en place,
• Conseiller le client sur la mise en place de la solution en limitant parfois ses ambitions et ses ardeurs (lotissement/phasage des projets, des livraisons …),
• Etudier la meilleure solution technique (avec les experts adaptés),
• Rédiger des dossiers de spécifications,
• Rédiger des plans des tests,
• Réaliser les recettes,
• Suivre les livraisons,
• Rédiger les manuels utilisateurs,
• Assurer l’accompagnement au changement avec les utilisateurs.

Pourtant, les échanges entre client et AMOA ressemblent parfois à des discussions entre étrangers, s’exprimant dans des langues différentes : au début, on ne comprend que l’idée générale, la phrase dans sa globalité. On entend bien des termes qui nous sont inconnus, mais on les ignore pour ne pas polluer l’écoute et l’attention.
Lors des premières réunions, tout le monde ouvre de grands yeux à l’évocation de termes nouveaux et barbares pour un néophyte.
Des explications sont parfois demandées en séance mais souvent, chacun estime que ne pas comprendre un mot ne remet pas en cause la compréhension globale ou alors on ne souhaite pas avouer son ignorance. Donc on passe outre notre incompréhension.
La difficulté intervient ensuite lors de la rédaction du compte-rendu par exemple et le doute s’installe. Tant pis, on continue en écrivant ce qu’on a compris et on laissera le soin au relecteur de corriger les erreurs et d’apporter les précisions manquantes. La rédaction finalisée, le document est envoyé pour relecture et validation. Pas de soucis … le compte-rendu est validé !
On est alors satisfait : finalement, on avait bien pris les notes, on a tout compris.

Des incompréhensions qui peuvent ralentir le projet

Le travail et le projet avancent, les phases s’enchaînent et de nouveaux dossiers sont élaborés et toujours validés de part et d’autre.
Puis un jour, au hasard d’une discussion, on évoque un point d’un dossier,et là, tout s’écroule… « Je n’ai jamais dit ça » , « vous n’avez pas compris ce que je voulais dire ».
Oups ! On ne s’est pas compris. Pourtant dans les documents validés, c’était déjà écrit comme ça. Oui, mais ça n’a pas été compris comme ça !
Finalement, on organise une réunion en urgence pour une mise au point avec une relecture commune du document. La lecture est lente, approfondie, les phrases sont lues, relues, reformulées, coupées par des demandes de confirmation de part et d’autre.
A chaque exercice de ce style on se rend compte :

  • Que la finalité de la demande est claire dans la tête du client,
  • Que le besoin n’est pas vraiment compris ni exprimé correctement,
  • Qu’il y a des non-dits de part et d’autre, car « implicites » pour celui qui détient l’information (mais pas pour tout le monde !),
  • Que la lecture du document a été faite en diagonale, aucune question n’a donc été posée,
  • Que des illustrations, schémas valent mieux que de longs paragraphes,
  • Que le client ne s’appesantissait pas sur les zones d’incertitudes, car il faisait confiance à l’AMOA,
  • Que chacune des parties avait adressé des mails « importants » à l’autre mais que ces mails étaient noyés dans le flot de mails quotidiens.

Trucs & astuces pour faciliter le travail entre le client et l'AMOA

AMOA et client sont parfois sur des lieux distants et limitent donc les déplacements. Mais pourquoi ne pas se retrouver plus souvent autour d’une table pour des réunions de travail ? Dans une salle, si possible, éloignée des bureaux, afin de ne pas être dérangé par les sollicitations quotidiennes.
Si de nombreux sujets peuvent se traiter par mails ou visioconférences, les réunions plénières rassemblent tous les acteurs autour d’une table et les discussions ouvertes servent à prendre les décisions importantes pour la vie du projet.
En plus, ces réunions font l’objet de comptes-rendus, dans lesquels on devrait trouver la trace des orientations prises. Ils sont en général déposés sur un serveur, accessibles de tous les acteurs. Mais eux aussi doivent être relus d’un regard critique et constructif, sinon, ils n’ont aucune plus-value !

Il faut parler, reformuler, questionner pour que les choses soient bien claires, car le temps « perdu » pour ces mises au point en amont pourrait être démultiplié si des quiproquos s’accumulent au fil des étapes du projet pour remettre en cause la solution finale au moment des recettes. Avant la rédaction de documents ou pendant, alors que l’écriture fait jaillir de nouvelles questions, il faut chercher à croiser les informations et les réponses.

Poser la même question à plusieurs personnes peut amener des réponses différentes mais souvent complémentaires et non contradictoires donc très constructives et importantes pour la suite du projet.
L’organisation de groupes de travail utilisateurs pour étudier un sujet précis, aboutit à des solutions mieux adaptées à l’ensemble des utilisateurs, mais solliciter les utilisateurs n’est pas toujours compatible avec leur activité et leur disponibilité.

Tous les échanges et entretiens avec le client/ les utilisateurs potentiels doivent être tracés et traçables :

  • Un échange téléphonique ou verbal doit être résumé dans un mail, diffusé au client et soumis à sa validation,
  • Les mails doivent être stockés sur un serveur, par exemple pour compléter tous les documents liés au projet,
  • Un tableau de bord (au format EXCEL) peut tracer ces échanges, les questions et réponses

Les documents à valider avec le client doivent :

  • Privilégier un langage ‘naturel’,
  • Être mis en page de manière simple et aérée, ne serait-ce que pour porter des annotations lors de relectures communes,
  • Utiliser des styles (gras, couleur, souligné, italique …) pour mettre en valeur des mots, des expressions,
  • Être ‘versionnés’, avec un historique des versions,
  • Préciser les références des autres documents utilisés pour la rédaction (les mails par exemple),
  • Bien sûr contenir une table des matières,
  • Éventuellement une table des illustrations, à condition de légender chaque image,
  • Contenir un glossaire, pour définir les termes spécifiques, tant métier qu’informatique,
  • Regrouper les notions clés et importantes dans un index, afin de trouver plus aisément les endroits du document où elles sont citées et abordées,
  • Les illustrations comme les schémas permettent de détailler un process et de garantir que les différentes étapes ont été envisagées et assimilées,
  • Des maquettes d’écran, réalisées à partir d’outils simples comme PAINT. Ils permettent d’une part au client de visualiser la manière dont son besoin sera intégré et d’autre part à l’AMOA de soulever de nouvelles interrogations,
  • Des tableaux qui synthétisent visuellement des affichages conditionnels (une information sera modifiable pour un état précis d’une donnée – une fonctionnalité sera accessible par tel profil applicatif),
  • Il ne faut pas négliger les annexes sans qu’elles soient redondantes avec les références. On peut déjà y porter des cas fonctionnels pour lesquels il faudra être vigilant tout au long de la réalisation et des tests.

Les modifications et évolutions des documents doivent être facilitées par :

  • Un plan adapté et une organisation hiérarchique des paragraphes (en début de document on développe les notions et exigences de base qui sont utilisées dans les paragraphes suivants),
  • Ne pas répéter une même information à plusieurs reprises, mais faire référence à un paragraphe dans lequel elle sera abordée, en utilisant des référencements dynamiques qui se mettent à jour automatiquement lors de l’évolution du document,
  • Lors de la rédaction de documents, de nouveaux points à aborder, de nouvelles questions, de nouvelles idées viennent en tête. Créez au fur et à mesure tous les paragraphes qu’il faudra leur consacrer, même si le contenu n’est pas encore défini, cela limite le risque de les oublier. Ils seront complétés au cours des prochaines réunions.

Voilà pour tous ces conseils, à vous de jouer maintenant !

Laisser un commentaire

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

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.