Redaktionshandbuch vs. Gummibändel

“Bitte schauen Sie da nicht so genau hin! Da finden Sie nur Fehler.” Das hat neulich ein Abteilungsleiter Technische Dokumentation zu mir gesagt, als wir gemeinsam in die Bedienungsanleitung geschaut haben. Und das klang nicht sehr freudig.

Mal wieder das alte Qualitätsproblem also. Technische Redakteure müssen an so viele Dinge gleichzeitig denken. Es versteht sich von selbst, dass natürlich alles technisch korrekt sein muss. Das ist rechtlich erforderlich und daher gibt es dafür in vielen Firmen eine Qualitätssicherung.

Was aber mit all den Aspekten, die rechtlich weniger relevant sind? Z.B. die Modularisierung der Inhalte, übersetzungsgerechtes Schreiben, Mehrkanalfähigkeit für PDF, Browser und App oder – ganz banal – die Frage ob der Hyperlink am Satzende den Punkt mit einschließt oder nicht.

Ich höre oft: “Dafür haben wir eigentlich ein Redaktionshandbuch.”

Genau! Und warum eigentlich nur eigentlich? – Stellen Sie diese Frage mal an einen Leiter Technische Redaktion.


“Wir brauchen kein Dokument sondern einen Kulturwandel.”


Mit einiger Wahrscheinlichkeit bekommen Sie eine Antwort wie diese: “Wir haben zwar ein Redaktionshandbuch, aber das ist nicht aktuell und wird – wenn überhaupt – von Neueinsteigern gelesen. Wir brauchen kein Dokument sondern einen Kulturwandel.”

Clean Code!

Mich erinnert diese Situation an eine Truppe von Programmierer-Kollegen. Die hatten das selbe Problem mit ihrer Software: Dort geht es nämlich um ganz ähnliche Themen: Durchgängige Terminologie, Modularisierung, Abstraktion, Formatierung, etc.

Jeder Programmierer macht das eben – genau wie die technischen Redakteure – ein kleines bisschen anders. Genau so, wie er das am besten oder am effizientesten findet. Und in der Softwareentwicklung führt genau das auch zu den gleichen Problem wie in der technischen Dokumentation: Es ist alles nicht so ganz durchgängig, nicht so ganz wartbar, nicht so ganz stabil und nicht so ganz performant.

Und natürlich gibt es in der Softwareentwicklung das Pendant zum Redaktionshandbuch. Dort heißt das Redaktionshandbuch: “Coding Guideline”.

Meine Kollegen fanden eine für mich erstaunliche Lösung: Clean Code.

Clean Code?

Die Clean Code Initiative will die Qualität von Programmcode per Kulturwandel verbessern. Sie beruft sich dabei auf ein – für Programmierer – sehr lesenswertes Buch von Robert C. Martin mit dem Titel Clean Code.

Mein Clean Code Buch

Im Buch gibt es Kapitel für jedes Thema, also wie oben angesprochen z.B. Terminologie, Modularisierung etc.


Aber das ist ja schon wieder ein Buch! Wir wollen keine Bücher!


Jetzt rufen Sie laut: “Aber das ist ja schon wieder ein Buch! Wir wollen keine Bücher!” – Genau. Und jetzt kommt die Clean Code Initiative ins Spiel.

Die Clean Code Initiative nimmt das Clean Code Buch als Basis. Als Bibel sozusagen. Und jetzt beginnt die Arbeit:

Stück für Stück – Kapitel für Kapitel – wird das Buch gelesen, verstanden, umgesetzt und die Umsetzung wird (selbst) kontrolliert. Vorgeschlagen wird:

  • Nehmen Sie sich 3 Wochen Zeit für Kapitel 1.
  • Dann nehmen Sie sich 3 Wochen Zeit für Kapitel 2.
  • Dann nehmen Sie sich 3 Wochen Zeit für Kapitel 3.
  • und so weiter bis zum Schluss.
  • Und dann?
  • – Ja dann nehmen Sie sich wieder 3 Wochen Zeit für Kapitel 1 und beginnen von vorn.

Das kann doch nicht Ihr Ernst sein!?


Jetzt sind Sie empört: Das kann doch nicht Ihr Ernst sein! Ich soll 3 Wochen lang ein Kapitel lesen? und dann noch eins? Und wann soll ich arbeiten?! – Und darin liegt gerade der springende Punkt: Sie arbeiten nebenher. Oder eigentlich: Sie beackern das Buch nebenher. Während Sie arbeiten.

Und damit Sie das Beackern im Alltagsstress nicht ganz vergessen, tragen Sie ein Gummiband am Handgelenk. So einfach ist das.

Clean Code Armbänder (von: http://clean-code-developer.de/die-initiative/armbaender/)

Für jedes Kapitel im Buch gibt es ein eigenes Armband in einer eigenen Farbe.

Clean Thinking

Lassen Sie uns jetzt mal Clean Code auf den Kulturwandel in der Technischen Redaktion übertragen. Ich nenne das: Clean Thinking.

Das Pendant zum Clean-Code-Buch – also Ihr Leitfaden fürs Clean Thinking – ist natürlich Ihr Redaktionshandbuch (oder meinetwegen auch die Tekom-Leitlinie). Nehmen wir mal an, Kapitel 1 sei die Modularisierung (z.B. rotes Gummiband). Dann liegt der Fokus für Sie als Redakteur jetzt 3 Wochen lang auf der Modularisierung:

  • Zu Beginn müssen Sie sicherlich mal das Redaktionshandbuch lesen.
  • Bei jeder Modularisierungsfrage halten Sie kurz inne und denken nach.
  • Beim Kaffee mit Ihrem Kollegen diskutieren Sie nicht schon wieder über Donald Trump sondern über Modularisierung.
  • Und durch das rote Armband erinnern Sie sich immer wieder daran.

Das alles kann jeder für sich alleine machen. Viel mehr Spaß (und viel mehr Erfolg) bringt es aber natürlich im Team. Meine Kollegen haben sich folgendes ausgedacht: Zu Beginn jedes Themas erklärt sich jeweils ein anderer Kollege bereit, eine kurze Zusammenfassung des Themas zu geben. Also: Was steht im Redaktionshandbuch? Was sind bei uns im Team die Best Practices? Was wollen wir vermeiden? Wo haben wir Diskussions-, Entwicklungs- oder Nachholbedarf? Im Anschluss wird kurz diskutiert und dann sofort gearbeitet. Natürlich mit dem entsprechenden Fokus.

Das ganze ist also eine einzige stetige Fortbildung. Mit stetiger Verbesserung und jeder Menge Übungspraxis. Ein Kulturwandel eben. Hin zu mehr Professionalität.

Nicht umsonst lautet das Motto des Clean-Code-Buches:


“Writing clean documentation is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.”


Okay, ich habe ein wenig geschummelt. Im Original steht natürlich nicht “documentation” sondern “code”.

Klappt das?

Sie fragen: Glauben Sie wirklich, dass das klappt? – Ja – hm – also.

Ich gebe zu: Clean Thinking ist sicherlich kein Allheilmittel, welches immer und überall funktioniert: Können Sie sich einen 63-jährigen Redakteur eines schwäbischen Maschinenbauers vorstellen, der seit 45 Jahren im Unternehmen ist, mit technischer Ausbildung, und der, bevor er was beschreibt, das Ding erst mal auseinander schrauben muss? Zieht der jetzt einen roten Gummibändel ans Handgelenk? – Hmm.

Was ich aber zumindest sagen kann: Meine Programmierer-Kollegen waren begeistert. Und ich glaube fest daran, dass es Redaktionsteams gibt, in denen das funktionieren kann.

Und mit oder ohne Gummibändel: Nach meiner Wahrnehmung kommt in vielen Redaktionsteams der Austausch der Redakteure untereinander, was Redaktions-Themen angeht, deutlich zu kurz. Und ich begrüße jede Idee, die das verbessert. Vielleicht bringt uns das ja den Kulturwandel.