Affichage des articles dont le libellé est analyse des tâches. Afficher tous les articles
Affichage des articles dont le libellé est analyse des tâches. Afficher tous les articles

08/09/2013

Documentation minimaliste ?... pas dans le nucléaire !

Sûreté de fonctionnement : gros pavé ?

Pour garantir la sûreté d'utilisation et de fonctionnement dans le domaine du nucléaire, il
faut une documentation volumineuse, coûteuse et  conçue par des ingénieurs  dans un format établi et immuable.

C'est à ce prix que l'on contribue à la qualité d'utilisation des outils, machines et mécaniques... non ?


La vanne qui ne fait pas rire... 

C'est le titre de l'article publié le 4 septembre 2013 par le Canard Enchaîné qui relate les (graves) problèmes de montage d'une  
"vanne destinée à injecter des additifs chimiques dans un circuit de sécurité" Elle a été montée à l'envers !
"Ce défaut de montage a été tardivement repéré, car, parmi les "facteurs aggravants", les inspecteurs disposaient d'une "documentation de référence peu lisible".


AREVA et le mode d'emploi

Et, plus grave, dans la documentation :

  "la position du moteur était erronée" ! Le mode d'emploi était écrit en chinois ?"

(Le Canard Enchaîné du 4.09.2013)

Minimalisme et nucléaire

Gageons que cette documentation n'appliquait pas les principes du _minimalisme_
Pourquoi ? 


Si la documentation de montage induisait l'utilisateur en erreur, c'est que le rédacteur n'avait pas suivi le 2e principe du minimalisme :

"Se focaliser sur les véritables tâches de l'utilisateur",

 c'est-à-dire :
  • appréhender ces tâches dans l'environnement de l'utilisateur (sur son lieu de travail)
  • faire une véritable analyse des tâches et des utilisateurs.
(Voir l'article du Dr. Hans van der Meij : Anchor the tool in the task domain .


 Analyse des tâches de l'utilisateur

Dans le cas présent, il fallait demander à l'ingénieur/technicien spécialiste des vannes de simuler, dans l'environnement de travail, une installation.

L'idéal est de filmer les manipulations et d'enregistrer les explications de l'expert-métier. Bien entendu, le rédacteur, pendant l'interview, ne se contente pas de commenter "ah oui, ah bon, ah c'est d'accord..."

 
Mais il lui faut poser les questions les plus saugrenues possibles :

"Pourquoi prenez-vous la vanne par ce côté ? Combien de personnes pour installer la vanne ? Pourquoi vous avez ôté cette vis ? Comment avez-vous pu identifier la bonne vanne ? Où sont les références ? Pouvez-vous me montrer l'alimentation ? Comment vérifier que le montage est correct ? etc."


 Illisible ou inintelligible, la documentation ?

Quant à la documentation de référence "peu lisible", on hésite : était-elle peu lisible parce
que rédigée en MAJUSCULES sur FOND NOIR  ou GRIS ? ou alors faut-il comprendre "peu intelligible", c'est-à-dire difficile à comprendre ?

Elle pêchait peut-être par omission (des esprits chagrins diraient que le rédacteur n'était pas très au fait de l'installation de vannes, alors il s'est contenté de documenter un minimum pour ne pas se tromper -ou se fatiguer à faire des recherches- MAIS ce sont là des propos de MAUVAIS ESPRITS...).

 

Supputations : comment en est-on arrivé à cette grave erreur ?

On peut fort bien s'imaginer que le rédacteur n'a pas vu ni manipulé la vanne et qu'il se soit contenté d'une illustration (fiche produit). A partir de là, il a probablement _imaginé_ comment l'installer sur les circuits existants. Ce qui expliquerait une autre grosse bévue relevée dans le rapport d'inspection :

"Pas de connaissance de l'existence de différences de diamètre entre les orifices"...

 

Conclusion : le minimalisme dans la réalité

 La documentation basée sur les principes du minimalisme, ce n'est pas le rédacteur qui s'investit de façon _minimaliste_ dans son job, mais au contraire, celui qui fait des recherches approfondies et précises sur l'environnement de travail de l'utilisateur pour lui fournir une documentation correspondant à ses besoins !



___________________________________________
N.B Évalué à son lancement en 2005, à 3,3 milliards d'euros, l'EPR devrait finalement revenir à 8,5 milliards d'euros. Des malfaçons ont émaillé sa construction. Un exemple : les consoles du bâtiment réacteur - 45 appendices destinés à soutenir un pont roulant - présentaient des défauts de soudure (quotidien Ouest-France du 6 septembre 2013)

26/08/2012

Analyser les tâches de l'utilisateur (User and Task Analysis)


Le premier principe de la rédaction minimaliste est de "choisir une approche orientée tâche"

Mais alors, comment se focaliser uniquement sur les tâches et les actions de l'utilisateur ?  Où les trouver, ces tâches-actions ?



En effet, le minimalisme nous demande de "respecter l'activité de l'utilisateur".



Mais comment analyser les tâches de l'utilisateur ?



Dans leur manuel User and Task Analysis for Interface DesignJoAnn Hackos  et Janice Redish nous guident pas à pas dans notre quête des activités de l'utilisateur, 
sachant que nous, rédacteurs, n'avons pas vocation à obliger l'utilisateur à 
suivre nos indications. 


L'essentiel est d'établir un lien étroit entre les concepteurs du produit (dans le cas présent, les rédacteurs) et les utilisateurs.





On définit l'analyse des tâches comme les processus d'interaction entre les concepteurs et les utilisateurs.


  • Pour les rédacteurs, il s'agit de se familiariser avec l'ensemble des actions des utilisateurs de base en les OBSERVANT pendant le déroulement de leurs activités.


Il n'est pas question ici d'interroger un groupe d'utilisateurs, en dehors de leur contexte, ni de se contenter d'interroger les managers (qui  eux n'ont qu'une vague idée des tâches quotidiennes des utilisateurs).


D'ailleurs, très souvent, l'utilisateur n'a pas vraiment eu l'occasion de prendre du recul et s'interroger sur les actions qu'il accomplit.
.

Il faut donc OBSERVER les utilisateurs dans leur contexte et repérer :


  • quels sont les buts de l'utilisateur (terminer aujourd'hui, à 17 heures, les feuilles de paie de l'ensemble du personnel)
  • quelles sont les tâches que l'utilisateur va exécuter pour atteindre son but (compléter un fichier Excel, se connecter au logiciel de paie ou sortir papier, crayon et calculette ?)
  • quelles sont les caractéristiques professionnelles et culturelles de l'utilisateur (son âge, son expérience, son ancienneté dans l'entreprise...)
  • quel est son environnement physique (bureau paysager bruyant, bureau sombre au fond du couloir, etc.)
  • quelle est l'influence de ses expériences professionnelles précédentes (facon de penser et d'aborder le travail, réminiscences...)
  • quelles sont les attentes de l'utilisateur  vis-à-vis du nouvel outil (encore quelque chose de nouveau, encore quelque chose à apprendre, le système actuel est très bon, pourquoi changer, ou alors : enfin un logiciel performant !) ?


En observant et écoutant, le rédacteur peut faire la liste des tâches que l'utilisateur doit accomplir et comprendre ses contraintes.

C'est déjà le bon début pour un manuel minimaliste et utile !