La recette au cœur de la communication projet

27 09 2008
« Plus un projet est vaste et complexe, plus la conduite de projet s’éloigne du domaine de la technique pour se rapprocher de celui des relations humaines ».

Une particularité d’un projet recette est liée à la communication envers tous les acteurs du projet global. En effet, il faut que les testeurs communiquent avec les acteurs représentants le client (métiers, MOA, MOE, etc.), les développeurs (intégrateurs, TMA, etc.) et l’équipe de recette en interne.

« Si tu ne connais rien de toi et de tes ennemis alors l’heure de la défaite sonnera certainement. » Sun Tzu
Il faut communiquer afin d’aller recueillir les informations nécessaires à l’organisation et la préparation des recettes. De plus, communiquer permet d’organiser et participer aux réunions d’anomalies permettant de les qualifier, avec l’aide du client et de l’intégrateur. Enfin, cela permet de présenter le suivi des recettes et la remontée des indicateurs aux chefs de projet impliqués.

Mais il faut aussi, souvent communiquer pour éduquer et faire de la pédagogie auprès des clients et des développeurs. Car dans l’esprit de ceux-ci les testeurs sont synonymes de « tester est inné, on ne peut pas systématiser les tests, n’importe qui peut tester, un bon testeur est celui qui trouve le plus de bug, les testeurs ne doivent pas gêner le développement, juste contrôler rapidement, etc. ».

Pour changer les mentalités il faut commencer par comprendre les interlocuteurs.

Mentalité du client :

La mentalité des « clients » (entreprises, DSI Directeur des Systèmes d’Informations, etc.) est très égocentrique et se traduit par des exigences métiers. Les clients, par définition, n’ont que très rarement conscience des problématiques qu’engendrent leurs exigences au niveau des projets. C’est aussi pour cela que les testeurs ont un rôle de « traducteur » entre les métiers, la MOA, la MOE, les développeurs.

Pour assurer au mieux notre rôle de testeur il est important de comprendre les trois grandes logiques clients. La « Logique métier » où l’utilisateur pense que sa logique métier est suffisante et ne se soucie pas des spécificités de l’informatique.
Puis la « Logique liée à la maquette » qui est la présentation d’une IHM « alléchante » mais uqi ne révèle qu’une face mineure de la complexité informatique.

Enfin, la « Logique qui dis que l’informatique suivra ». Dans ce cas les utilisateurs ont tendance à penser que les systèmes d’informations sont capables de résoudre n’importe quel problème.

Mais il faut avoir toujours à l’esprit que le client (MOE, MOA…) est celui qui connaît le mieux son métier, son entreprise, les contraintes et les applications. Nous sommes mandatés par lui pour contrôler le produit qu’il a commandé et c’est l’interlocuteur parfait pour les informations dont vous aurez besoin. Les testeurs ont aussi un devoir de conseil envers lui.

Il achète un logiciel et ses défauts, son intérêt est de détecter les défauts au plus tôt avant la fin de garantie et de sécuriser la mise en production du logiciel.

Ce qui au final se traduit par des cahiers des charges ou des expressions de besoins très légères avec des informations de type « Nous voulons gérer la facturation bien mieux qu’actuellement… ». Charge aux testeurs d’aller creuser et chercher l’information dans les têtes des métiers et des développeurs, souvent sous forme d’atelier organisé avec tous les acteurs partie prenante.

Mentalité des développeurs :

La plupart des équipes de développement ont le « Syndrome du Top gun » qui déclare : « Nos ingénieurs sont très bon, ils maîtrisent nos méthodologies et normes de développement. Il ne peut y avoir de bugs ! ». Au-delà de ce « syndrome » M. Weinberg (The Psychology of Computer Programming) expose les points suivants : les erreurs peuvent être plus facilement repérées par d’autres et programmer / coder s’apparente souvent à une création personnelle, un programmeur ne sait pas ou ne veut pas voir ses erreurs.

Alors que si les programmes sont montrés aux autres ils deviennent moins personnel (« egoless programming ») et on admet plus facilement ses erreurs.

Ce qui illustre bien le fait que pour tester il n’est pas recommandé « d’être juge et partie ».

Au même titre que la logique des clients il est important de comprendre celle des développeurs.

La « Logique informatique » où l’ingénieur a tendance à croire que la technologie se justifie par elle-même. Le développeur est très souvent plus sensible à la prouesse technique qu’à la satisfaction du client final. La « Logique de transposition des technologies », car il est toujours très tentant de transposer une technologie qui a fait ses preuves et que l’on maîtrise, dans un certain contexte sur un autre contexte.
Il y a aussi la maturité de l’organisation de développement qui ne dépend que des personnes qui la constituent et de leurs méthodes de travail. Enfin, l’implication du client où le fournisseur aura tendance à « mouiller » son client dans des décisions où il n’a aucune compétence. Il pourra ainsi justifier les éventuels problèmes rencontrés.

Les testeurs ont donc un rôle d’interface très important entre ces acteurs. Car nous devons vérifier et nous assurer que les exigences clients sont bien respectées et de bonne qualité en production.

Il faut donc établir un canal de communication clair avec les autres acteurs :


Figure : Acteurs d’un projet de recette

(Intégrateur est souvent synonyme de développeur)

Concrètement que faire ?

Il existe plusieurs manières d’améliorer la communication et les relations entre les testeurs et leurs interlocuteurs. Il faut commencer par une collaboration plutôt que par des conflits et rappeler à chacun l’objectif commun de systèmes de meilleure qualité. Il faut aussi communiquer les découvertes sur le produit de façon neutre et factuelle sans critiquer la personne responsable, par exemple, écrire des rapports d’incidents (ou des résultats de revues) objectifs et factuels. De plus, il faut également essayer de comprendre ce que ressent une autre personne et pourquoi elle réagit comme elle le fait. Enfin, confirmer que l’autre personne a compris ce que l’on a dit et vice versa.

Enfin, les personnes et les projets sont dirigés par des objectifs. Les personnes ont tendance à aligner leurs plans en fonction des objectifs mis en place par le management et les autres responsables, par exemple, pour trouver des défauts ou confirmer qu’un logiciel fonctionne.
De ce fait, il est important de spécifier clairement les objectifs des tests.

Le chef de projet doit communiquer pour que le client ait en permanence une visibilité sur les activités de l’équipe de tests et ainsi éviter le « fameux effet tunnel ».
Concernant l’estimation des charges, il doit veiller à ne pas décevoir le client et toujours promettre moins et en faire plus.

Composition d’une équipe de recette type

Une fois les acteurs définis passons en revue l’équipe de test, leurs rôles et responsabilités. L’équipe de recette type est la suivante :


Figure : Equipe de recette type

Les trois profils sont les chefs de projet, l’analyste et l’ingénieur de test. Les rôles de chacun sont décrits ci-dessous.

Le chef de Projet test a les responsabilités suivantes :

  • le pilotage et suivi du projet, animation de l’équipe,
  • être l’interface privilégiée avec le client pour les aspects organisation et suivi du projet,
  • organiser et animer les comités de suivi du projet,
  • planifier les tâches et gestion des ressources,
  • élaborer avec le client des indicateurs d’avancement et de suivi (tests, anomalies) et les tableaux de bord de suivi du projet,
  • présenter les tableaux de bord.

L’analyste de test doit effectuer les tâches suivantes :

  • organiser les tests sur un des domaines du projet en coordination avec le chef de projet, selon projets, encadrement d’une équipe d’ingénieurs de qualification.
  • spécifier et concevoir les tests,
  • exécuter les plans de test,
  • vérifier les résultats,
  • faire l’édition de synthèse des résultats de test,
  • rédiger les rapports d’anomalies.

L’ingénieur de test doit procéder aux activités suivantes:

  • exécuter les plans de test,
  • vérifier les résultats,
  • faire l’édition de synthèse des résultats de test de sa partie,
  • rédiger les rapports d’anomalies.
Il faut noter que les profils de type « Ingénieur de test » se font de plus en plus rare. Ce terme est surtout utilisé pour décrire un collaborateur ayant un tarif plus bas que celui d’un analyste (bac + 2 au lieu de bac + 4 par exemple). Ce profil de simple exécutant de fiches de tests existe aussi en cas d’externalisation des tests en Inde, au Maroc, etc. Et dans ce cas uniquement l’ingénieur de test ne fait qu’exécuter les fiches de tests.

Quels sont les qualités d’un bon recetteur ?
Comme expliqué ci-dessus c’est tout d’abord être un bon communicant mais aussi avoir une bonne synergie entre savoir-être et savoir-faire :


Figure : Synergie entre savoir-être et savoir-faire

Le savoir-faire est composé des formations et expériences acquises lors de la vie professionnelle d’un salarié. Ce peut être des formations suivies en interne ou bien des cursus comme ceux que proposent les organismes comme le FAFIEC, le FITEC ou bien le CNAM.
Le savoir-faire est donc un acquis.
Comme on le constate l’expérience acquise est très importante pour monter en compétence sur les métiers du test.

Le savoir-être est composé des qualités principales comme la rigueur, la souplesse et la faculté de ne laisser passer aucun détail. Lever les ambiguïtés sur une fonctionnalité, prévoir tous les risques potentiels, noter chaque décision et vérifier la bonne prise en compte.
Les autres qualités sont d’identifier toutes les tâches sans en oublier une seule, identifier toutes les questions restées en suspend et n’en laisser aucune sans réponse et enfin garder des traces de chaque décision.
Tous ceci est différent de la raideur, soit l’impossibilité d’accepter de changer d’idée, de s’adapter à une nouvelle situation, à un nouveau contexte.
Il faut être bon communicant et savoir exprimer ces idées à l’oral et par écrit et savoir écouter : être ouvert au dialogue. Soit essayer de comprendre les autres (à l’écrit et à l’oral), avoir une certaine ouverture sur leurs idées.
Il faut aussi être convaincant (≠ « avoir un mauvais caractère »), et prendre en compte les positions de la hiérarchie ou de la maîtrise d’ouvrage qui sont quelque fois à l’opposé des conditions optimales pour la réussite du projet. Il est important de faire entendre sa parole et de convaincre ses interlocuteurs avec des arguments factuels et concrets.

Et surtout il faut construire sa crédibilité auprès des autres acteurs. Cela peut prendre des semaines, voir des mois pour la construire mais quelques minutes suffisent pour la détruire. Ce qui implique d’être aussi factuel que possible dans les documents, comités et autres rapports avec les autres acteurs.


Actions

Information

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s




%d blogueurs aiment cette page :