- Es geht um die Frage, welche Werkzeuge und Techniken wirksam sind, um ein mentales Modell zum Verständnis eines Systems oder Produkts an andere zu vermitteln und gemeinsam weiterzuentwickeln
- Als Methode zum Aufbau mentaler Modelle wird die Erfahrung genannt, ein System selbst zu bauen und zu warten
- Die Vermittlungsformen ähneln eher informellen Erklärungen wie Skizzen auf einer Serviette, gestisches Erklären neben jemandem oder gemeinsames Durchdenken und verbales Ausformulieren
- Dokumente, die Funktionslisten oder oberflächliche Bereiche lückenlos erfassen, können zwar umfassend sein, reichen aber möglicherweise nicht aus, um ein mentales Modell des Themas aufzubauen oder zu vermitteln
- Die direkte Erfahrung mit gut gestalteten Werkzeugen oder Produkten kann zugleich dabei helfen, mentale Modelle aufzubauen und zu vermitteln
Fokus der Frage
- Im Kern geht es darum, welche Werkzeuge oder Techniken wirksam sind, um mentale Modelle zu vermitteln und wachsen zu lassen
- Die Frage behandelt zwei Richtungen zugleich
- Wie man mentale Modelle aufbaut
- Wie man mentale Modelle an andere vermittelt
Beispiele und Problemstellung
- Als Beispiel für den Aufbau mentaler Modelle wird genannt, Systeme zu bauen und zu warten
- Die Vermittlung mentaler Modelle erfolgt in Formen, bei denen man vor Ort gemeinsam ein Verständnis herstellt, etwa:
- auf eine Serviette kritzeln
- neben jemandem mit Gesten erklären
- in einer gemeinsamen Problemsituation erklären
- Dokumente, die Funktionen auflisten oder den oberflächlichen Umfang katalogisieren, können umfassend sein
- Solche Dokumente führen aber möglicherweise nicht so weit, dass sie ein mentales Modell des jeweiligen Themas schaffen oder vermitteln
- Die direkte Nutzung gut gestalteter Werkzeuge oder Produkte wird als ein Weg betrachtet, der sowohl das Wachstum als auch die Vermittlung mentaler Modelle ermöglichen kann
- Die abschließende Frage lautet, mit welchen Werkzeugen und Techniken andere gute Erfahrungen gemacht haben und warum sie wirksam waren
1 Kommentare
Meinungen auf Lobste.rs
Ontology Logs sind ein guter Formalismus, um Ontologien zu vermitteln.
Bei lang laufenden Prozessen mit viel internem Zustand sind Zustandsdiagramme und Statecharts nützlich, um ein System zu dokumentieren.
Nutzer eines Systems nehmen die tatsächliche Systemstruktur normalerweise nicht wahr. Ein Grund ist, dass der Nakatomi Space nur Nutzern sichtbar wird, die ein System missbrauchen, und dass es eigene Bereiche des Zustandsraums für unbeabsichtigtes Verhalten wie weird machines gibt.
Ein weiterer Grund ist die Sichtweise the purpose of a system is what it does: Nutzer sehen nur, was das System für sie tut, und können daraus ihren persönlichen Daseinszweck ableiten, bemerken aber möglicherweise nicht den Gesamtzweck, den Designer und Maintainer beabsichtigt haben.
Man schreibt ein Buch und engagiert einen Lektor.
Das klingt für mich ziemlich nach dem Kernproblem von Bildung. Zwei Kategorien wurden genannt: Lernen durch Ausprobieren und Anleitung durch Experten; die dritte ist Lehren.
Die wichtigere Frage ist, ob man Modelle schaffen kann, die durch Wiederverwendung ähnlicher Prinzipien und Designs leichter zu erlernen sind, oder ob man durch Abstraktion den Bedarf reduziert, sie vollständig zu erlernen. Allerdings muss gut definiert sein, wo die Abstraktion leckt.
In diesem Zusammenhang ist Felienne Hermans’ The Programmer's Brain interessant. Beeindruckend fand ich, dass die Methode „Ich löse mehrere Beispiele vor, schau zu“, wie man sie beim Unterrichten von Mathematik für Kinder nutzt, auch in der Programmierausbildung ziemlich gut funktioniert.
Beim Onboarding im Arbeitsumfeld sähe das wohl so aus: „Schau zu, wie ich diesen Bug untersuche“ oder „Schau zu, wie ich mich wieder in dieses Subsystem einarbeite, das ich eine Weile nicht angefasst habe“.
In der Softwaretechnik hilft es, mentale Modelle in User Stories und technische Implementierung aufzuteilen.
User Stories sind in der Regel primäre Anforderungen, also der Wert, der erreicht werden soll; die technische Implementierung sind die sekundären Elemente, die nötig sind, um dieses Ziel zu erreichen.
User Stories beschreiben den Wert, der an den Kunden geliefert wird, und die technische Implementierung beschreibt, wie die Einschränkungen des gebauten Systems die User Stories begrenzen.
Manchmal überschneiden sich beide: Eine User Story wird durch die technische Implementierung eingeschränkt, oder umgekehrt wird eine technische Implementierung gewählt, um eine User Story zu erfüllen. Viele Systemverhalten lassen sich aber in einen der beiden Rahmen einordnen.
Danach wählt man das am besten passende Werkzeug. UML eignet sich gut, um Objektkarten zu zeichnen, und Flussdiagramme sind gut, um Abläufe zu erklären. Zustandsdiagramme eignen sich gut, um erlaubte und nicht erlaubte Zustände sowie Übergänge zu erklären, und Variablen- und Zustandstabellen sind gut, um alle möglichen Werte aufzulisten.
Die beste Methode, das Zeichnen von Systemen zu lernen, ist, drei verschiedene Personen zu bitten, jeweils ihr gedachtes Bild zu zeichnen. Selbst dieselbe Idee wird erstaunlich unterschiedlich dargestellt, und die meisten Darstellungen sind gleichermaßen gültig, zeigen aber unterschiedliche Aspekte des Themas. Es ist ein bisschen wie Kunst.
Ich nutze vor allem formalere Diagramme. Wenn ich während eines Screen-Sharings in Echtzeit kritzle, hole ich trotzdem manchmal jspaint hervor; wenn es später für andere sehenswert sein soll, nutze ich auch etwas wie Figjam.
Diagramme und Zeigen funktionieren so gut, weil sie zu unseren ältesten und immer noch nützlichen Werkzeugen zur Aufmerksamkeitslenkung gehören. Schon bevor wir sprechen, zeigen und weinen wir, und bei Position und Navigation ist Zeigen viel unmittelbarer als Sprache – deshalb gibt es den Markt für Laserpointer weiterhin.
Peter Gårdenfors’ The Geometry of Meaning: Semantics of Conceptual Spaces behandelt dieses Thema recht ausführlich. Barbara Tversky hat ebenfalls viel zu Diagrammen und zur Strukturierung kognitiver Räume geforscht, und Peter Chengs „What Constitutes an Effective Representation?“ formuliert die Kriterien für wirksame Repräsentationen ziemlich quantitativ.
Shadowing, Pairing und Whiteboard-Sessions sind gut. Dabei sollten beide Seiten zeichnen und Fragen stellen.
Ebenfalls hilfreich sind: gemeinsam ein Projekt auswählen und umsetzen, das das Modell erweitert oder verändert; Quizfragen; Lernende wieder selbst lehren lassen; auswendig lernen und von Hand aufschreiben.
Reines Auswendiglernen sollte immer mit anderen Methoden kombiniert werden und nie die einzige Methode sein. Auch Diagramme oder Kritzeleien außerhalb des Whiteboards, Gap-Analysen im Vergleich mit anderen Modellen oder Lösungen sowie nachdenkliche, halb unbewusste Reflexion wie Hammock Time helfen.
Ich denke, man muss zwischen Repräsentationen zur Vermittlung und Repräsentationen zur tatsächlichen Aufgabenerledigung unterscheiden. Letztere wurden hier zwar nicht erwähnt, kommen aber eher dem „Ausführen“ nahe.
Ausführbare Modelle sind oft weniger gut vermittelbar, meist weil ihre Abstraktionsgrenzen schlecht sind. In der Informatik sind es fast immer leaky abstractions.
Zu verstehen, was etwas tut, kann von dem Berg an Arbeit verdeckt werden, der hineingesteckt wurde, damit es das effizient tut. Deshalb muss man manchmal auf eine Serviette kritzeln und erklären: „Auf der Abstraktionsebene, die zu deinem aktuellen mentalen Modell passt, funktioniert dieses System so.“
Dokumentation ist ein separates Artefakt und neigt dazu, hinter dem Ausführungsmodell zurückzubleiben; um das zu verhindern, muss sie sehr aufwendig gepflegt werden. Der noch schwierigere Weg ist, Dokumentation direkt an den Code zu koppeln oder sie, wie beim literate programming, dem Code voranzustellen.
Deshalb ist beim Vermitteln mentaler Modelle meist der Ansatz richtig, der minimalen Aufwand und minimale Wartung erfordert: Serviettenkritzeleien und das gemeinsame Arbeiten am realen System über die Zeit.
Es hat einen Grund, dass neue Mitarbeitende nicht mit dem Schreiben von Designdokumenten anfangen, sondern mit einfachen Bugfixes.
Neue Mitarbeitende müssen durch Ausprobieren lernen, daher kann ein Tutorial am passendsten sein. Nachdem sie aber eine Weile etwas angefasst haben, haben sich wahrscheinlich einige Missverständnisse eingeschlichen, die man mit einer Erklärung über einer Serviettenkritzelei auflösen kann.
Wenn man sich also entscheidet, ein Tutorial zu schreiben, sollte man kein „Alles“-Dokument erstellen, sondern ein gutes Tutorial mit klarem Fokus.
Schreiben ist die Antwort.
Software ist ein persönliches dynamisches Medium und daher ziemlich interessant.
Ich denke, interaktive Systeme helfen. Zum Beispiel ein visueller Debugger, der Python und boxed Variables lehrt.