- La question porte sur les outils et techniques efficaces pour transmettre à d’autres personnes un modèle mental permettant de comprendre un système ou un produit, et le faire évoluer ensemble
- Parmi les façons de développer un modèle mental, l’expérience consistant à construire et maintenir soi-même un système est évoquée
- Les modes de transmission relèvent plutôt d’explications informelles, comme griffonner sur une serviette, expliquer avec des gestes à côté de quelqu’un, ou verbaliser ensemble en réfléchissant au problème
- Une documentation qui répertorie exhaustivement une liste de fonctionnalités ou les zones de surface peut être complète, mais insuffisante pour créer ou transmettre le modèle mental du sujet
- L’expérience directe d’utilisation d’un outil ou d’un produit bien conçu peut aider à la fois à développer et transmettre un modèle mental
Point central de la question
- Le cœur du sujet est de savoir quels outils ou techniques sont efficaces pour transmettre et faire évoluer des modèles mentaux
- La question traite simultanément deux axes
- Comment développer un modèle mental
- Comment transmettre un modèle mental à d’autres personnes
Exemples et problématique
- Comme exemple de développement d’un modèle mental, il est question de construire et maintenir un système
- La transmission d’un modèle mental prend la forme d’un alignement de compréhension sur le terrain, par exemple :
- Griffonner sur une serviette
- Expliquer avec des gestes, côte à côte
- Expliquer en réfléchissant ensemble à une situation
- Un document qui énumère les fonctionnalités ou catalogue le périmètre superficiel peut être exhaustif
- Mais ce type de document ne conduit pas nécessairement à créer ou transmettre le modèle mental du sujet concerné
- L’expérience directe d’utilisation d’un outil ou d’un produit bien conçu est présentée comme une façon de parvenir à la fois au développement et à la transmission d’un modèle mental
- La question finale demande quels outils et techniques ont été efficaces pour chacun, et pourquoi ils l’ont été
1 commentaires
Avis de Lobste.rs
Les ologs sont un bon formalisme pour transmettre une ontologie
Pour un processus de longue durée avec beaucoup d’état interne, les diagrammes d’état et statecharts sont utiles pour documenter le système
Les utilisateurs d’un système perçoivent généralement mal la structure du système réelle. Une des raisons est que le Nakatomi space n’est visible que pour les utilisateurs qui détournent le système, et qu’il existe des zones de l’espace d’états dédiées à des comportements non intentionnels, comme les weird machines
Une autre raison est que, comme dans la perspective the purpose of a system is what it does, les utilisateurs peuvent se construire leur propre raison d’être à partir de ce que le système fait pour eux, sans percevoir l’objectif global voulu par les concepteurs et les mainteneurs
Il suffit d’écrire un livre et d’embaucher un éditeur
J’ai l’impression qu’on touche ici au problème central de l’éducation. J’ai vu deux catégories, apprendre en faisant et être guidé par un expert, et la troisième est enseigner
La question plus importante est de savoir si l’on peut créer des modèles plus faciles à acquérir en réutilisant des principes et des conceptions similaires, ou si l’on peut réduire le besoin de les acquérir complètement grâce à l’abstraction. Mais il faut alors bien définir où l’abstraction fuit
À ce sujet, The Programmer's Brain de Felienne Hermans est intéressant. J’ai trouvé frappant que l’approche « regarde-moi résoudre plusieurs exemples » utilisée pour enseigner les maths aux jeunes enfants fonctionne aussi plutôt bien pour l’apprentissage de la programmation
Dans un contexte professionnel, pour l’onboarding, cela pourrait prendre la forme de « regarde comment j’enquête sur ce bug » ou « regarde comment je me refamiliarise avec ce sous-système que je n’ai pas touché depuis un moment »
En génie logiciel, il est utile de séparer les modèles mentaux entre user stories et implémentation technique
En général, les user stories sont les exigences de premier ordre, c’est-à-dire la valeur à atteindre, et l’implémentation technique est l’élément de second ordre nécessaire pour atteindre cet objectif
Les user stories décrivent la valeur livrée au client, et l’implémentation technique explique comment les contraintes du système construit limitent ces user stories
Parfois, les deux se chevauchent : une user story est contrainte par l’implémentation technique, ou inversement on choisit une implémentation technique pour atteindre une user story. Mais de nombreux comportements système peuvent être cadrés par l’un ou l’autre
Ensuite, il suffit de choisir l’outil le plus adapté. UML est bien pour cartographier les objets, les organigrammes pour expliquer les flux. Les diagrammes d’état conviennent pour décrire les états autorisés ou interdits et les transitions, et les variables ainsi que les tables d’état sont utiles pour énumérer toutes les valeurs possibles
La meilleure façon d’apprendre à représenter un système est de demander à trois personnes différentes de dessiner chacune leur propre schéma. Même pour une même idée, la diversité des modes de représentation est étonnante, et la plupart sont tout aussi valides tout en révélant des aspects différents du sujet. C’est proche de l’art
J’utilise surtout une schématisation plus formelle. Cela dit, quand je gribouille en direct pendant un partage d’écran, il m’arrive de sortir jspaint, et si c’est quelque chose que d’autres regarderont plus tard, j’utilise aussi des outils comme Figjam
Si la schématisation et le fait de montrer du doigt fonctionnent si bien, c’est parce que ce sont nos plus anciens outils de guidage de l’attention, et qu’ils restent utiles. Avant même de parler, nous pointons et pleurons, et pour la position et la navigation, pointer reste bien plus immédiat que le langage, ce qui explique que le marché des pointeurs laser existe toujours
The Geometry of Meaning: Semantics of Conceptual Spaces de Peter Gårdenfors traite assez en détail de ce sujet. Barbara Tversky a aussi beaucoup travaillé sur la schématisation et la structuration spatiale de la cognition, et « What Constitutes an Effective Representation? » de Peter Cheng propose des critères assez quantitatifs de ce qui rend une représentation efficace
Le shadowing, le pairing et les sessions au tableau blanc sont utiles. Dans ce cadre, les deux parties doivent dessiner et poser des questions
Il y a aussi des méthodes comme choisir et réaliser ensemble un projet qui étend ou modifie le modèle, les quiz, le fait que l’apprenant réenseigne à son tour, la mémorisation, puis la réécriture à la main
La simple mémorisation doit toujours être combinée à d’autres méthodes, et ne jamais devenir la seule. Schématiser ou gribouiller hors tableau, faire une analyse des écarts par comparaison avec d’autres modèles ou solutions, et même des temps de réflexion plus contemplatifs et à moitié inconscients comme le hammock time peuvent aussi aider
À mon avis, il faut distinguer entre les représentations destinées à la transmission et celles destinées à l’exécution réelle d’une tâche. Ces dernières n’ont pas été mentionnées ici, mais elles sont plus proches de l’« exécution »
Les modèles exécutables transmettent souvent mal les choses, généralement à cause de mauvaises frontières d’abstraction. En informatique, ce sont presque toujours des abstractions qui fuient
Comprendre ce que fait quelque chose peut être masqué par la montagne d’efforts accumulés pour le rendre efficace. D’où le besoin de griffonner sur une serviette et d’expliquer : « au niveau d’abstraction qui correspond à ton modèle mental actuel, ce système fonctionne comme ça »
La documentation étant un artefact distinct, elle a tendance à prendre du retard sur le modèle d’exécution, sauf si elle est maintenue avec énormément de soin. Une approche plus difficile consiste à coupler directement la documentation au code, ou à placer la documentation avant le code, comme en programmation lettrée
Donc, pour transmettre un modèle mental, la bonne approche est souvent celle qui demande le moins d’effort et de maintenance : des croquis sur une serviette, puis du temps passé à manipuler ensemble le système réel
Si les nouveaux commencent par corriger des bugs simples plutôt que rédiger des documents de conception, ce n’est pas sans raison
Un nouvel arrivant doit apprendre en faisant, donc un tutoriel est sans doute ce qui convient le mieux. Mais après avoir déjà mis un peu les mains dedans, il y a de fortes chances qu’il ait accumulé quelques malentendus, et une explication appuyée sur un croquis de serviette peut les dissiper
Donc, si l’on décide d’écrire un tutoriel, il ne faut pas essayer de produire une documentation sur « tout », mais rédiger un bon tutoriel clairement focalisé
La réponse, c’est l’écriture
Le logiciel est assez intéressant comme média dynamique personnel
Je pense que les systèmes interactifs sont utiles. Par exemple, un débogueur visuel pour enseigner Python et les variables représentées sous forme de boîtes