Erst kämpften wir technischen Redakteure um ein einheitliches Berufsfeld und einheitliche Bezeichnungen
wie "technischer Redakteur" und "technische Dokumentation". Warum soll jetzt mit Gewalt ein neuer Begriff
her? Ganz einfach: Wir technischen Redakteure schreiben heute nicht nur Bedienungsanleitungen, sondern
unterstützen die Kommunikation auf vielen technischen Gebieten.
Mein spezieller Arbeitsbereich ist, die Kommunikation zwischen technischem Spezialisten wie Entwicklern
zu erleichtern. Gerade bei komplexen Investitionsgütern werden die Detailprobleme immer mehr und immer
komplexer. Moderne Entwicklungswerkzeuge ermöglichen dem Einzelnen Projekte abzuwickeln, die früher nur in
enger Arbeitsteilung möglich gewesen wären. Die Beschleunigung der Entwicklung, charkterisiert durch
Schlagwörter wie Time to Market lässt diesen Spezialisten immer weniger Zeit zum Durchatmen und zum
Dokumentieren. Oft genug gibt es für die einzelnen Spezialthemen in den Firmen nur noch jeweils einen
einzigen Know-How-Träger, der den größten Teil seines Wissens ausschließlich in seinem Kopf herumträgt.
Dies ist ein höchst gefährlicher Zustand – was soll passieren, wenn so ein Entwickler längerfristig krank
wird oder die Firma verlässt? Schon ein Urlaub kann kräftig Steine ins Getriebe werfen.
Technischer Redakteur zum Aufbereiten von Entwicklungsdokumentation
Dokumentation ist in vielen Entwicklungsprojekten ein Stiefkind. Die Entwickler haben dafür weder Zeit
noch Lust. Aber wer sonst soll Algorithmen oder Entwicklungsentscheidungen dokumentieren? Das können
technische Redakteure mit einschlägiger Ausbildung und Erfahrung übernehmen.
Zwischen einem Entwickler und einem in das Entwicklerteam eingebetteten technischen Redakteur gibt es einige
Gemeinsamkeiten, aber auch eine Reihe von Unterschieden:
- Ein Entwickler ist mit seinen Aufgabenstellungen intim vertraut. Wenn er darüber redet, dann auf einem
sehr abstrakten Niveau. Vor allem an die ganzen alltäglichen Detailprobleme denkt er überhaupt nicht
mehr. Den ganzen Standardkram hat er schon längst im Kopf oder in seiner Workstation automatisiert.
- Ein Entwickler sieht seine Aufgabenstellung von innen. Er denkt in Entwicklungsgeschichte,
Detailentscheidungen und Fehlerumgehung. All das hat mit der von außen sichtbaren Funktion
seines Projektes bestenfalls am Rande zu tun.
- Beide, Entwickler und technischer Redakteur, sind nach einiger Zeit mit der Problematik vertraut.
So können sie bei ihren Gesprächen vergleichsweise schnell zur Sache kommen.
- Der technische Redakteur ist häufig genug der erste, der ein Projekt von außen betrachten kann.
So kann er zwischen "zum Verständnis wichtig" und "für Andere irrelevant" unterscheiden,
wozu der Entwickler häufig genug keine Chance hat.
- Der technische Redakteur muss weit weniger tief in die Entwicklung einsteigen. Er kann sich deshalb schneller
und in mehr Themen einarbeiten. Sehr schnell kommt er deshalb in die Position des Kommunikators innerhalb
des Entwicklerteams. Oft genug wäre es deshalb sinnvoller, statt noch eines Entwicklers einen technischen
Redakteur in das Projektteam zu entsenden. Ein neuer Entwickler verursacht erst mal nur
Kommunikationsprobleme. Ein geeigneter technische Redakteur fängt sehr schnell an,
Kommunikationshindernisse
zu beseitigen.
- Ein technischer Redakteur wird die Arbeit seiner Entwicklerkollegen oft nicht bis in die Details hinein
nachvollziehen können. Das ist auch nicht seine Aufgabe. Aber mit dem nötigen fachlichen Hintergrund wird
er die Aussagen der Entwickler auf Plausibilität und Vollständigkeit überprüfen können und sie mit
eigenen Worten so wiedergeben, dass sie innerhalb der Arbeitsgruppe für jeden nachvollziehbar werden.
Regelmäßig werden Entwickler und technischer Redakteur mehrere Iterationsschritte brauchen, bis sie sich auf
eine Beschreibung einigen können. Die entsprechenden Verständnisprobleme gibt es so aber nur einmal.
Wenn der aufbereitete Text dann für die Kollegen vergleichsweise trivial klingt, hat der technische
Redakteur einen guten Job gemacht.
- Der technische Redakteur innerhalb eines Entwicklerteams kann Zeitpläne entzerren helfen. Gegen Ende
einer Entwicklung gibt es regelmäßig Stress, den dann auch noch die Kollegen von Marketing, technischer
Dokumentation usw. erhöhen. Für alle diese externen Informationssenken kann der eingebettete
technische Redakteur die erste Anlaufstelle sein. Die zentralen Nervenstränge der Entwicklung
werden dabei nicht behelligt. Die Anwenderdokumentation kann weitgehend ohne Befragung der Entwickler
entstehen, die Marketingleute verstehen die Entwickler in den meisten Fällen sowieso nicht.
Wie das mit einem eingebetteten technischen Redakteur funktioniert
Zwei Effekte sind ganz entscheidend: Der technische Redakteur muss von den Entwicklern als Gleicher
akzeptiert werden und eine offene Kommunikationsstruktur verhindert, dass Wissen als Herrschaftsmittel gehortet
wird. Der technische Redakteur soll ganz bewusst keine Entwicklerfunktion haben – das würde ihm die
Perspektive von außen verderben, die zu seinen Alleinstellungsmerkmalen gehört. Aber er muss von
Ausbildung und Erfahrung nahe genug dran sein, damit die Kommunikation laufen kann. Wenn jeder Entwickler
erst mal stöhnt "jetzt muss ich schon wieder bei Adam und Eva anfangen", kommt es zu keiner Akzeptanz. Auf
mittlere Sicht muss es für den Entwickler einfacher und angenehmer sein, den technischen Redakteur schlau zu
machen, als selber die Dokumentation zu schreiben.
Bei meinem Arbeitsbereich, Investitionsgütern mit hohem Elektronik- und Softwareanteil, erfordert das
eigene Entwicklererfahrung und zumindest eine Techniker-Ausbildung. Bei einem externen Dienstleister wie mir
schadet es sicher nicht, wenn seine Ausbildung noch 1-2 Ebenen höher und seine Erfahrung extrem breit ist.
Ziemlich daneben ist die häufige Erwartung, der technische Redakteur müsse die jeweils benutzten
Entwicklerwerkzeuge beherrschen. Das Erstellen guter technischer Texte erfordert eine
andere Qualifikation und einen anderen Blickwinkel, als sie ein Entwickler hat. Beide Funktionen sind
bestenfalls ausnahmsweise in einer Person zu vereinigen. Ausnahmen gelten höchstens dann, wenn Entwickler und
Anwender eines Produktes mehr oder weniger identisch sind – etwa beim Entwickeln eines Programmiererwerkzeuges.
|