Storytelling: Was uns die Geschichte lehrt

Geschichten und ihre Helden

Das erste IT-Fachbuch, das ich gelesen habe, hieß „Mein erstes BASIC Programm“ [2]. Es handelt von Dino, dem Programmierer. Er brachte mir bei, wie man mit der Programmiersprache BASIC arbeitet. Dabei halfen ihm (und mir) der kleine, schlaue BASIC-Interpreter, die Programmschlange, das Flussdiagramm und andere liebevoll illustrierte Figuren. Nur der hinterlistige Fehlerteufel stellt dem angehenden Programmierer immer wieder kleine Fallen. In dieser lustigen Figurenwelt erklärt Rodnay Zaks das Programmieren mit BASIC auf leichte und amüsante Weise. Thematisch greift er auch Bereiche jenseits der eigentlichen Programmiersprache auf, darunter Algorithmen (die als Flussdiagramme visualisiert werden) und Fehlersuche.

Einer der Merksätze, die immer einprägsam mit kleinen Illustrationen dekoriert werden, lautet: „Denk daran: Jede Änderung kann neue Fehler bringen“. Wie wahr. Natürlich beschäftigt sich das darauf folgende Kapitel mit dem Testen. Lange lag dieses Buch griffbereit neben dem 8086-PC meines Vaters, um mir bei meinen BASIC-Gehversuchen zu helfen. Heute, mehr als zwanzig Jahre und ein Informatik-Diplom später, kann ich sagen, dass es dieser lösungsorientierten und erzählerischen Herangehensweise zu verdanken ist, dass ich mich ernsthaft für Softwareentwicklung zu interessieren begann. Umso enttäuschter war ich, als ich feststellte, dass viele andere Informatik-Fachbücher zwar sehr schöne Bucheinbände (einige ebenfalls mit Dinos oder Drachen) hatten, aber zwischen den Buchdeckeln die graue Theorie vorherrschte.

Ein literarisches Fachbuch – kein Widerspruch.

Der nächste Lichtblick war Tom DeMarcos „Der Termin“ [3]. Endlich traute sich jemand, das Thema Projektmanagement realitätsnah und mit einem Schmunzeln zu beschreiben. Die Geschichte handelt von Mr. Tompkins, Projektmanager eines Telekommunikationskonzerns, der nach seiner Entlassung auf eine Insel verschleppt wird. Dort bekommt er die Möglichkeit geboten, all seine Projektmanagementerfahrung anzuwenden. Er darf achtzehn Teams unterschiedlicher Zusammensetzung gegeneinander antreten lassen, um unter hohem Zeitdruck sechs Softwareprodukte zu entwickeln. Dabei entwickeln jeweils drei Teams mit verschiedenen Methoden parallel dasselbe Produkt. Seine Erkenntnisse fasst Mr. Tompkins in einem Tagebuch zusammen. Dieses Tagebuch öffnet den Blick für die Bildebene. Es ist für den Leser nämlich nicht immer einfach, in der eigentlichen Geschichte die fachlich relevanten Inhalte zu erkennen.

Dieser Herausforderung stellen sich alle literarischen Fachbücher. Einige nutzen deshalb die Geschichtenform nur sporadisch, um bestimmte Fragestellungen oder Sachverhalte anekdotenhaft einzuführen. Diesen Weg geht beispielsweise Kurt Schneider in seinem Buch „Abenteuer Softwarequalität“ [4]. Dessen fiktive Person Q, die zum Qualitätsbeauftragten eines Unternehmens ernannt wird und sich in dieser neuen Rolle zurechtfinden muss, taucht in Einschüben in einem ansonsten klassischen Fachbuch auf. Q stellt eine emotionale Bindung zum Leser her, der sich gut in dessen Rolle und Situation hineinversetzen kann. Dadurch wird das vermittelte Wissen erlebbar und besser nachvollziehbar. Und weil das Wissen in einen Kontext eingebettet ist, wird es im Gehirn besser abrufbar gespeichert. Einfacher ausgedrückt, bilden das „Was“ (Wissen) und das „Warum“ (Geschichte) eine logische Einheit, die man sich viel besser merken kann als das „Was“ allein.

Clarke Ching bezeichnet sein „Rolling Rocks Downhill“ [5] als „Business Novel“. Wo DeMarco seinen Mr. Tompkins in ein fiktives Land versetzt und dort mit allem ausstattet, was dieser für das Multiprojektmanagement benötigt, muss sich Steve, der Held in „Rolling Rocks Downhill“, mit den üblichen Problemen eines Herstellers von Softwareprodukten herumschlagen: Konkurrenzdruck, nahezu unhaltbare Termine – und zu guter Letzt auch noch dem drohenden Outsourcing der gesamten Softwareentwicklungsabteilung. Aus Sicht von Marketing und Produktentwicklung dauert die Softwareentwicklung nämlich immer viel zu lange. Glücklicherweise weiß Steve, wie man sie beschleunigen kann: Sein Zaubertrank ist die „Theory of Constraints“ von Eliyahu M. Goldratt. Mit dieser Managementphilosophie kommt wieder Schwung in die Entwicklerbude.

Denkwerkzeuge wie die Dilemma- oder die Konflikt-wolke helfen bei der Problemanalyse und bringen Veränderungsprozesse in Gang. Und am Ende wird alles gut. Das klingt schon fast wie im Märchen. Das aber möchte Chings Geschichte (die leider nie komplett veröffentlicht wurde) nicht sein. Warum eigentlich nicht?

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.