Warum Tutorials nicht funktionieren...

Wir zeigen auf, wie praxisnahe Methoden ineffiziente Tutorials ersetzen können, und dabei die Integration von neuen Teammitgliedern fördern.

Die Szenarien sind bekannt: Ein neues Gesicht kommt ins Unternehmen, ein neues Mitglied verstärkt das eingespielte Team oder es muss sich jemand ein neues Themenfeld erarbeiten. In all diesen Fällen wird gerne und oft auf ein Tutorial zurückgegriffen. Wie sieht das dann aus?

Nehmen wir als Anschauungsobjekt Stefan:

“Hier schau mal Stefan. Mach doch bitte mal dieses Tutorial. Danach solltest du es verstanden haben.”

Nicht selten läuft es genauso ab. Aber wie gut funktioniert das eigentlich? Auch wenn Stefan das ganze Tutorial durchgearbeitet hat, stellt sich die Frage: Konnte er sich damit das notwendige Wissen aneignen? Und im besten Fall so, dass er danach selbständig in diesem Themenfeld mitarbeiten kann?

Fangen wir mit dem Aufbau vieler Tutorials an. Was sollen sie vermitteln? Und wer schreibt die denn eigentlich? Und für wen werden sie überhaupt geschrieben?

Schauen wir uns mal an, wie ein typisches Tutorial für Programmierer gestaltet ist. Ich habe mich zunächst für das Framework ROS (http://wiki.ros.org/ROS/Tutorials) entschieden. ROS ist ein Framework für Roboter-Applikationen. Verfügbar in Python und C++. Wenn nun ein neuer Mitarbeiter in die Situation kommt, mit diesem Framework arbeiten zu müssen, ist es heutzutage fast schon ein “normales Vorgehen”, dass als erstes an diverse Tutorials verwiesen wird.

Unser Stefan fängt zunächst gewissenhaft von vorne an und arbeitete sich durch jeden Punkt bis zum letzten. Was bleibt ihm als Lernerfolg?
Ziemlich wahrscheinlich die Erkenntnis wie ein “Hello-World”-Beispiel in diesem speziellen Framework aussieht. Danach geht es durch grundlegende Strukturen und Kommunikationsweisen dieses Frameworks. Meiner Meinung und Erfahrung nach sind die meisten Tutorials so aufgebaut: als erstes werden die Grundfunktionalitäten besprochen und im zweiten Schritt wird auf weiterführende Funktion eingegangen. Hier stellt sich mir die Frage, ob eben diese weiterführenden Funktionen zu diesem Zeitpunkt überhaupt von Stefan verstanden werden können. Ob es nicht besser wäre, zu verstehen, WANN man WAS tut und es für den Anfang kein MUSS ist, alle Features zu kennen.

Prinzipiell durchlaufen Tutorials alle Features, gehen jedoch meist nicht in die Tiefe… so mein Eindruck. Aber warum sehen die meisten Tutorials denn so aus?
Ich vermute, dass die Erschaffer dieser Tutorials am liebsten alle Features dem Benutzer näherbringen möchten. Sie sind selbstverständlich stolz auf ihre Arbeit und möchten zeigen, wie gut ihr Framework ist. Woraufhin ich zu meiner nächsten Frage komme: Ist Stefan, in seiner Rolle als neuer Mitarbeiter, denn dann die richtige Zielperson für solch ein Tutorial?
Nein, denn Stefan hat einen anderen Blickwinkel darauf. Ein Mitarbeiter sollte wissen, wie er das Framework für seine Probleme, die er lösen muss, einsetzten kann. Steht im Tutorial etwas über Stefans anfängliche Probleme? Meistens nicht. Oder wann Stefan welches Feature für welches Problem verwendet? Auch nicht…

Schlimmer wird es dann noch, dass Stefan wahrscheinlich nach dem Tutorial das Gefühl hat, es verstanden zu haben. Denn er hat es ja schließlich gemacht, folglich muss er alles verstanden haben. Oder wie ich des Öfteren schon von neuen Mitarbeitern gehört habe: “Nur ein, zwei Punkte muss ich mir nochmal anschauen.” Dabei wirken sie auch ziemlich entspannt. Denn sie haben die Ansicht, das neue Framework verstanden zu haben und sind der Meinung, dies auch sicher einsetzen zu können.

So Stefan, ab ins Projekt und los geht’s… Erste Aufgaben werden zugewiesen und dann… Dann merkt man, dass es doch nicht verstanden wurde, dass über viele Details gar nicht nachgedacht wurde. Das sichere Gefühl ist dann schnell weg. Panik kann sich in den Augen des Mitarbeiters breitmachen. Auf jeden Fall Stress bei allen Beteiligten, denn der Vorgesetzte muss darauf reagieren, Hilfe organisieren, den Zeitplan anpassen. Eventuell den Kunden informieren, dass man in Verzug kommt.

Was ist passiert? Das Verständnis für eine konkrete Technologie ist nach einem Tutorial nicht vorhanden, es stellen sich schnell Fragen nach grundlegenden Entscheidungen für die Umsetzung einer Lösung. Es sind oft Kleinigkeiten, die im Verlauf eines Projektes zu großen Schwierigkeiten führen, weil die im Tutorial erwähnten Funktionen nicht das tun, was in der kurzen Zeit zu verstehen war. Der Hintergrund zu einzelnen Beispielen fehlte, es lässt sich also oft auch gar nicht in realen Anwendungsfällen verwenden. Hinzu kommen unverständliche Ergebnisse….

Das größte Missverständnis ist, dass Tutorials nicht für die Probleme, Anforderungen und Lösungen, die konkret im Projekt gelöst werden müssen, geschrieben wurden. Klar das ist mal mehr oder wenig richtig, aber es trifft eigentlich immer zu. Was könnte man ändern, um das Tutorial passender zu machen? Ein eigenes schreiben? Sicherlich ist das nicht die Lösung. Wenn man sich vorstellt, dass sich Jemand damit befassen muss, was denn alles wichtig ist. Wie denn die Probleme genau aussehen und dafür Lösungen anbieten. Wer das schon einmal versucht hat, weiß, dass dies zeitaufwendig ist und es durchaus vorkommen kann, dass das Projekt noch vor dem Tutorial beendet ist.

Ein besserer Ansatz wäre, das Tutorial, oder wie man es dann auch immer nennen möchte, sehr nahe am täglichen Arbeiten anzusiedeln. Die Lösungsansätze und Technologien erlebbar zu machen und Erklärungen anzubieten. Wie wäre denn ein Projekt? Mit welchen Werkzeugen und Methoden wird gearbeitet? Wie entwickelt sich so ein Produkt oder Projekt? Ein Projekt sollte über einen längeren Zeitraum existieren. Gerne über mehrere Jahre. Und im besten Fall mehrere Disziplinen abbilden.

Wir, in unsere Robotik-Abteilung, haben uns entschieden, einen Büro-Roboter von Grund auf zu entwickeln (https://github.com/Abidat/abidat_robot_construction). Sehr wichtig war uns dabei das nicht als Spielprojekt zu sehen, sondern als ernsthafte Entwicklung. Wird ein Teil für den Roboter entwickelt, geschieht das mit in Projekten üblichen Prozessen und Methoden. Konzeptphase, Design, Implementierung (gültig für Software) und Testen. Das Projekt muss ab der ersten Minute ernstgenommen werden!

Das Besondere ist hierbei, dass der Mitarbeiter ein Teil für das Lernprojekt beiträgt. Beiträgt zu einem System, das bereits andere Mitarbeiter entwickelt haben. Es existiert somit Interesse Seitens der Kollegen an einem konkreten Ergebnis in Form von Produktkomponenten, das kann Hardware, Software, Dokumentation oder anderes sein. Ist die Lösung gut? Oder anders gesagt: ist das Team zufrieden mit der Umsetzung? Man merkt, ohne ein weiteres Zutun des Vorgesetzen, dass bei allen ein Interesse an der Arbeit des neuen Mitarbeiters besteht. Die Beteiligten lernen sich also gegenseitig einzuschätzen und die Fähigkeiten und Begeisterungsfähigkeit der einzelnen Personen für einen Arbeitsbereich kennen.

Ein weiterer Punkt ist, dass es nicht nur eine Übung ist, die dann wieder verworfen wird. Ich durfte beobachten, dass Mitarbeiter, nach dem sie ihren Teil abgeschlossen hatten, weiterhin kontinuierlich ihren Teil verbessern wollten. Die intrinsische Motivation der kontinuierlichen Verbesserung wurde bei ihnen geweckt, nachdem sie mehr Erfahrung hatten und wussten, dass sie ihre “alte” Lösung immer weiter verbessern können.

Ein konkretes Beispiel ist unserer Büro-Roboter Marvin. Wie man den Titel entnehmen kann, ist er nicht nur ein Roboter, sondern er ist auch depressiv. Marvin ist sehr unzufrieden mit seiner Existenz, denn er soll für seine Ansicht “nur” Personen, die sich im Büro aufhalten, authentifizieren. Wobei er ja über ein Gehirn so groß wie die gesamte Cloud verfügt.

Marvin. Roboter von ABIDAT.

Wie man sieht, gibt es auch eine Geschichte zu Marvin, also zu dem Projekt. In so einem Projekt hat man die Freiheit dies zu tun und ich rate auch stark dazu dies zu nutzen. Es fördert den Spaß der Beteiligten und ganz nebenbei spielen auch untypische Punkte eine Rolle, wie die Gefühlslage einer Maschine oder eben Marvins.

Marvin verfügt über gängige Sensoren, die in der mobilen Robotik zum Einsatz kommen. In einer zwar abgespeckten Form und Qualität, aber sie sind vergleichbar mit teuren Sensoren, die in den eigentlichen Projekten zum Einsatz kommen. Oder die Antriebe sind beispielsweise bei Marvin von Lego, also eigentlich Spielzeug. Sie verfügen aber trotz allem über alles, was ein “professioneller” Motor auch zu bieten hat: Steuerbus, Regler und Feedback.

Der Roboter ist Lego-kompatibel, somit ist auch kaum mechanischer Aufwand notwendig, ihn zu verändern. Wir haben Teile entwickelt und gedruckt, die mit Lego erweitert wurden. Somit ist keine mechanische Werkstatt notwendig, um neue Teile anzubringen. Dies ist natürlich ein wichtiger Punkt für die Arbeitssicherheit im Büro. Alle Mitarbeiter sind somit in der Lage eine Veränderung vorzunehmen. Damit wird niemand ausgeschlossen, man muss keinen Mechaniker, der in der Werkstatt arbeitet, bitten, Modifikationen zu erledigen.

Anzeige der aktuellen Features von Marvin in RViz. Lokalisierung mit Mapping

Nicht immer findet man ein Projekt, das zum Lernen geeignet ist. Oder es gibt keine Möglichkeiten dafür. Hierfür haben wir eine Alternative, die auch gut funktioniert und die Anforderung erfüllt, für das Projekt spezifisch zu sein. Jedoch müssen hier die Mitarbeiter der Projekte oder der Abteilung erstmal Aufwand betreiben. Es geht dabei darum, Aufgaben zu definieren, die alle lösen dürfen.

Ich meine hier Methoden, die man von Einstellungstests kennt. Übungsaufgaben, die zeigen, wie gut jemand ein Problem löst. Jedoch sollte diese nicht aus der Luft gegriffen sein. Sie sollten typische Probleme abbilden, die im Projekt gelöst werden müssen. Beispielsweise kann ein Teammitglied, wenn es ein interessantes Problem vor der Nase hat, eine Aufgabe daraus machen und diese allen anderen zugänglich machen und fragen, wie sie das lösen würden. Man kann hieraus einen Art Wettbewerb machen. Ich bin mir sicher, dass innerhalb des Teams von sich aus Lösungen verglichen werden. Bis hin zur Diskussion, was denn die beste Lösung ist. So wird das Team trainiert, ohne groß einen Rahmen zu schaffen. Eventuell möchte man sogar die beste Lösung an eine prominente Stelle publik machen.

Wenn dies während jedem Projekt gelebt wird und die Aufgaben und Lösungen gesammelt werden, kann ein neuer Mitarbeiter diese Aufgaben durcharbeiten. Es ist nicht so nah am täglichen Arbeiten wie die oben beschriebene Ansatz, aber es befasst sich mit den Problemen, die im Projekt vorkommen. Dieser Ansatz ist somit für mich besser geeignet als ein allgemeines Tutorial, das technologiezentrisch schnelle Ergebnisse in vielen Basisfunktionen einer Technologie zeigt, aber alle anderen Aspekte einer realen Produkt- oder Projektentwicklung ignoriert.

Fazit

Ein generalisiertes Tutorial ist nicht zielführend, um sich in ein konkretes Thema einzuarbeiten. Es hilft, einen Überblick zu bekommen, jedoch bleibt nicht viel hängen. Ich würde es vergleichen mit einem Vortrag oder Unterhaltung. Am Ende bleiben wenig relevante Informationen übrig. Problematischer jedoch ist, dass das Tutorial nicht auf die Lösungsfindung und Herausforderungen des alltäglichen Arbeitens vorbereitet oder es fördert. Somit ist der Mitarbeiter nicht bereit, das Gelernte in einem konkreten Projekt anzuwenden.

Deswegen sollte ein Tutorial nicht die Wahl sein, einen Mitarbeiter oder ein Team an neue Technologien heranzuführen. Hier wurden zwei Methoden genannt, die nach meiner Ansicht eine bessere Alternative sind. Diese sind aber auch nur Vorschläge. Jedes Team oder jede Organisation sollte hier ihren eigenen Weg finden. Und der ist, nach meiner Erfahrung, eigentlich offensichtlich für die Beteiligten. Man sollte hier auch nicht zu kompliziert denken. Und was man eventuell nicht als natürlich empfindet: Arbeit darf auch Spaß machen! Und sollte es eigentlich auch…

Autor: Christian Wendt