Dies ist die nullte Folge des Devlogs, meines wöchentlichen Entwicklertagebuchs. Das Ziel: Alles, was ich in meiner Beratung und in meinen Trainings so "predige", selbst in die Praxis umzusetzen und zu sehen, wie weh oder wie gut es tut.
Oben auf dem Bild sieht man den amerikanischen Arzt John Paul Stapp, wie er 1954 einen Selbstversuch auf einem Raketen-getriebenen Schlitten machte. Stapp wollte feststellen, wie sich starke Beschleunigung auf den menschlichen Körper auswirkt. Er ließ sich in diesem Selbstversuch auf 1000 km/h beschleunigen und dann innerhalb von 1,4 Sekunden abbremsen – es wirkte kurzzeitig eine Beschleunigung von 46g und für mehr als eine Sekunde immer noch 25g auf ihn ein.
Verglichen mit dem Raketenschlitten wird mein Selbstversuch hier ein Spaziergang werden, doch ein sehr interessanter, das kann ich versprechen.
Das zu lösende Problem
Als Trainer für DDD und Softwarearchitektur bin ich immer wieder vor die Aufgabe gestellt, Wissen und Erfahrung in erlernbare und verdaubare Häppchen zu zerlegen, damit ich sie meinen Kursteilnehmer/innen überzeugend und didaktisch gut präsentieren kann.
Ich muss also existierende Inhalte (z.B. aus meiner eigenen Erfahrung, aus Büchern oder auch aus Artikeln im Web) thematisch zerlegen, sie anhand der Lernziele des Kurses, den ich gebe, neu strukturieren, Übungen und anderes Material dazu erstellen und am Ende in eine zeitliche Struktur bringen, z.B. in ein zwei- oder dreitägiges Training.
Die Trainings muss ich regelmäßig an den neuesten Stand der Erkenntnis anpassen. Dazu brauche ich Zugriff auf die Struktur(en), die ich mir beim vorigen Mal ausgedacht hatte.
Und ich frage mich häufig: Wohin habe ich das ganze Material gelegt? Das selbst erzeugte Material (also Slides, Übungen, usw.) liegt in einem Ordner auf meinem Computer, das ist einfach. Doch wo liegt das ganze Ausgangsmaterial? Habe ich mir wirklich alle Quellen gemerkt? Was passiert, wenn sich eine Quelle aktualisiert hat und ich deshalb ebenfalls aktualisieren muss?
Das nervt.
Das Problem ist groß genug, um endlich einmal eine passende Lösung dafür zu machen, in Form eines SaaS.
Domäne und Ubiquitous Language
Das SaaS soll auf der ganzen Welt nutzbar sein, deshalb würde ich es gern auf Englisch entwickeln. (Ob ich mir tatsächlich Mehrsprachigkeit antue, möchte ich lieber später herausfinden. Ja, Matthias, ich weiß, dass das ein Fehler ist – wenn Du i18n nicht gleich am Anfang berücksichtigst, wirst Du es später bereuen!).
Das bedeutet, ich sollte über Domäne und System auch mit englischen Fachbegriffen sprechen. Nennen wir die Domäne also training design, die erste Benutzerrolle nenne ich trainer. Ich werde mich bemühen, alle Fachbegriffe kursiv zu schreiben, damit man sie als solche erkennen kann.
Um genügend Fachsprache kennenzulernen, sammle ich Domänen-Sätze eines Fachexperten auf, den ich (virtuell) befrage.
Domänenexperten befragen
Wenn ich einen trainer interviewte und fragte: "Please explain: How do you design a training?", würde er vermutlich nicht sehr strukturiert antworten, doch ich könnte seine Antworten sammeln und dann, nach gewissem Nachdenken und Rückfragen/Feedback, wohl so aufschreiben:
- First, I select a main topic about which I want to give a training.
- Then, I collect the raw material: from my own experience, from books, conferences, journals, Internet articles, all kinds of unsorted stuff.
- I take a coloured text marker to highlight certain snippets of the raw material that I find particularly interesting. I use different colours for different meaning that I discover in the original material.
- I collect all the highlighted snippets and group or sort them according to their meaning. I create what I call "buckets" and put all highlights that look similar into the same bucket.
- I create an overview of those buckets to see what I have so far.
- Now, I try to find out what my students will need to know or be able to do. I make notes about each knowledge or skill that they need.
- I group the knowledge-or-skill notes into buckets, too, to get an overview of what I will need in the training. And maybe I highlight them, too, just like I did with the raw material in step 3.
- At the end of this first cycle, I compare what I have (from step 5) to what I need (from step 7). I will discover gaps, or missing links, between what I have and what I need. And I will try to close those gaps.
- I run through another 2 or 3 cycles with steps 2 to 8.
- I keep re-arranging the snippets and buckets until I feel something like "yeah, it clicks", or, "yeah, things fall into place".
- Then, from the snippets that I have, I will create learning units and modules.
- A unit is something that I can teach to my students. It has a subtopic and contains facts, opinion, experience, and practical exercises.
- Several related units make a module. I typically teach in 90-minute time boxes that I call "time slots", where each time slot contains one or two modules.
- In the morning and in the afternoon, I teach two slots of 90 minutes each, with 30 minutes of coffee break in-between. We also take an hour for the lunch break.
- The trick is to fill the four daily time slots with enough but not too many modules. And: After lunch, there have to be more exercises than theory, so that my students don't fall asleep.
Puh, das ist erst einmal ein Haufen Zeug, und gleichzeitig konzentriert wie ein Espresso!
Wie es weitergeht
Als Nächstes werde ich überlegen, bei welchen dieser Schritte ein SaaS den trainer unterstützen könnte. Es scheint eine sehr anspruchsvolle Aufgabe zu sein, die der trainer da mit Zetteln, snippets und buckets durchführt. In der nächsten Folge des Devlogs schreibe ich ein paar User Stories auf, die den trainer hoffentlich glücklich machen werden.
Stay tuned.
