In diesem Beitrag zum Beruf des technischen Redakteurs habe ich bereits den Punkt „Undankbarkeit“ erwähnt. Wann immer es um Text (und auch um Grafik, wie ich von befreundeten Grafik-Designern weiß) geht, hat die Allgemeinheit die Vorstellung: „Ja, das schreib ich schnell selber zusammen.“ Oft kommen dabei Texte raus, die einem textliebenden Menschen den Magen umdrehen – egal ob es um Anleitungen, E-Mail- oder Anwendungstexte geht.
Was ist „guter Text“?
Ich führe die Diskussion, warum eben nicht jeder gut schreiben kann, ziemlich oft. Sehr gerne auch mit Entwicklern, die glauben, sie könnten die kleine Fehlermeldung mal eben schnell selber schreiben. Die Sache ist die: einige wenige können sogar ganz gute Texte schreiben, aber sehr viele eben nicht.
Dabei fällt es mir teilweise schwer, überhaupt zu vermitteln, warum eben die Profis an die Texte gelassen werden sollten und warum es tatsächlich eine halbe Stunde bis Stunde dauern kann einen bestimmten Absatz zu formulieren bis er wirklich gut ist. Irgendwelche Messkriterien für guten Text will ich jetzt schon mal gar nicht beachten, denn bisher hat mich noch nichts überzeugen können.
Für solche Diskussionen lege ich mir gerade eine kleine persönliche Sammlung an, die textliche „Lowlights“ aus den Bereichen Doku oder Software-GUI enthalten soll, die mir in den letzten Jahren so untergekommen sind – und die dazugehörige Überarbeitung natürlich. Dabei geht es mir nicht um Übersetzungsfehler, sondern die Patzer, die eben schon im Quelltext entstehen (und dann vielleicht zu noch kurioseren Übersetzungen führen). Einige werde ich mit euch teilen, andere werde ich nur im Offline-Leben aus der Kiste zaubern können.
Meine Hoffnung ist, dass ich mit solchen konkreten Beispielen diese abstrakte Tätigkeit „Text schreiben“ mal irgendwie greifbarer machen kann.
Warum muss es ein technischer Redakteur sein?
Bei der DITA Europe Conference in Wien habe ich einen Partnervortrag von Tony Self gesehen, bei dem ein „Doku auf DITA umstellen“-Projekt vorgestellt wurde. In diesem Projekt wurde beschlossen, dass in der Firma gescheite Kundendokumentation benötigt wird (yay!). Da man aber keine Redakteure hatte, rekrutierte man aus der Qualitätssicherung rund um die Welt Mitarbeiter, die „nebenbei“ noch schreiben sollten. Für das „Drumherum“ und für die Organisation dessen holte man sich immerhin Tony ins Boot. Aber ehrlich gesagt hat mich dieses Vorgehen baff gemacht und es kamen mir sorgenvolle Gedanken wie „Wenn das jetzt immer mehr so machen, weil es ‚gut genug‘ ist, was ist dann meine Ausbildung noch wert?“.
Beim Thema „TR-Redaktionssystem“ bemerke ich inzwischen auch oft, dass die Leute denken, dass man da einfach jeden davor setzen können muss. Ich vermute, dass dieser Irrglaube von der unglückseligen Benennung „Redaktionssystem /CMS“ herrührt, die die meisten Leute eben doch an ein Web-CMS denken lässt. Und bei einem Web-CMS ist es ja das Wichtigste, den Leuten das Editieren piepeinfach zu machen.
Ein TR-Redaktionssystem soll das Editieren zwar auch einfach gestalten und die Leute von Technik und Layout fernhalten, aber der Punkt ist, dass hier doch sehr viel Basiswissen da sein muss, damit man so ein System effizient nutzt, z.B. in Sachen Modularisierung, Wiederverwendung, bedingtem Text, Übersetzungsmanagement, Standardisierung etc.
(Ich will damit übrigens nicht sagen, dass ein TR unbedingt studiert haben muss. Wie überall gibt es auch hier sehr gute Quereinsteiger. Aber wenn man hergeht und einfach irgendjemanden nimmt und mit der Aufgabe ein Handbuch zu schreiben vor ein Redaktionssystem setzt… Naja, lustig wird das ziemlich sicher nicht… )
Auf in den Kampf
Ich will mir in der nächsten Zeit mal Gedanken dazu machen, wie ich fachfremden Leuten besser klar machen kann, was wir TRler eigentlich machen und warum wir es machen sollten und es nicht jeder kann. Und zwar einerseits in Hinblick auf das Thema „Schreiben“, aber auch im Hinblick auf Sachen wie „CMS/Übersetzungsmanagement/Workflows“. Das wird ne recht schwierige Sache, aber hey – Informationsvermittlung sollte doch für eine/n TR kein Problem sein 😉
Und wie führt ihr diese Diskussionen? Oder müsst ihr die etwas gar nicht führen? 🙂
Hallo Marijana,
wieder mal voll aus der Seele geschrieben. Auch aus meiner.
Die Situation ist doch wirklich oft die gleiche.
Argumente meinerseits für einen TR sind z.B. der rechtliche Aspekt (kann, soll oder muss da einer was tun – ja, da gibt es Unterschiede), der finanzielle Aspekt (Wiederverwendung gleicher Inhalte und deren Übersetzung) oder auch der Blick auf Verständlichkeit oder den Umfang an Infos für die Zielgruppe (meist stecken ja die Entwickler doch zu tief drin).
Aber es ist ein Kampf, der nie aufhört. Gerade das Thema Fehlermeldungen, Oberflächenbeschriftungen und Beschriftungen auf Geräte wird meist eben schnell so gemacht – und meist mit wenig Weitblick – mit oft schwerwiegenden Folgen.
Ich freue mich auf die Beispiele von Dir für meine Argumentationsstrategie.
Grüße
Mirko
Negativ-Beispiele sind gute Beweismittel in Deinen Diskussionen. Weitere nützliche Aspekte sind Redundanz und Konsistenz der mal eben nebenher geschriebenen Doku. Wenn dieselben Dinge einerseits doppelt und dreifach beschrieben, andererseits immer wieder anders benannt sind, wird dem geneigten Benutzer im Manager schnell klar, dass das gleich doppelt am Ziel vorbei schießt.
Viele Firmen lassen auch einen Friedhof gescheiterter Projekte hinter sich, wo mal eben ein Glossar oder ein Wiki angelegt wurde. Wenn schon sowas bei Pflege und Nutzen scheitert – trotz zahlloser Stunden des Aufsetzens und Hineinklapperns – wie soll es dann erst bei der Doku funktionieren, wo’s ja auch noch im Ganzen sinnvoll sein soll…?
Und immer schön auf die vergeblichen Kosten verweisen, die dem weggeschmissenen Nutzen gegenüberstehen!!!
Hallo Marijana, Christoph Hein schrieb einmal über die DDR-Literatur: „Dem Druck des Staates konnte man ausweichen, der war so eindeutig und offensichtlich. Aber da gab es die Gefahr, dass man sich im Widerstand verkrampft und blödsinnig verbeißt; wie der Lessing in den Dummkopf Goeze, auf den er Jahre vergeudet hat.“
Ich glaube, Webseiten zu Stilblüten der Technischen Redation gibt schon einige. Und wie Kai es schon sagt: die Adressaten sind die Geschäftsführer, die an der falschen Stelle sparen. Aber die lesen nicht Dein Blog! Na, und bei uns rennst Du offene Türen ein! Also: schreib für uns! Verbeiß Dich nicht! Kein „Kampf“ und keine „Beweismittel“. Von Dir als Spezialistin erwarte ich schon mehr: wie man DITA inkl. „Reuse“ richtig einsetzt zum Beispiel.
Gruss aus Berlin – Andreas
Hallo Andreas,
nun ja… Nenne es Kampf oder nenne es Aufklärung. Ich kenn kaum einen TRler, der die geschilderten Probleme nicht immer wieder erlebt. Es ist sicherlich Einstellungssache, ob man das einfach hinnimmt oder versucht die Sicht auf diesen beruf zu verändern. Ich gehöre zu letzteren und finde das alles andere als blödsinnig. Immerhin wird mit jedem „Ist ja nur Text.“ am TR-Stuhl gesägt.
Am Ende nutzt jede Technik, sei es DITA oder sonstwas, nichts, wenn die falschen Leute davor gesetzt werden und niemand angemessen dafür zahlen will. Und ich will verhindern, dass mir sowas passiert.
Was machst du, wenn du mal wieder mit dem Satz „Das hab ich schnell selber geschrieben.“ konfrontiert wirst?
Hallo Marijana, Du sprichst mir ja ganz aus der Seele… Ich sitze noch nicht mal auf einem TR-Stuhl. Ich wurde als sogenannter Supporter eingestellt. Der Zufall wollte es, dass mein Arbeitgeber in mir auch einen Technischen Redakteur eingestellt hat. Es schreiben bei uns also weitere Supporter mal nebenbei „nur Text“ – keine Spur von verschiedenen topic-Arten, ganz zu schweigen davon, dass sie die Idee von „Wiederverwertbarkeit“ schon beim Schreibprozeß berücksichtigen.
Insofern überrascht es mich zu hören, dass es ähnliche Probleme („schreib ich schnell selbst“) auch bei größeren Firmen mit eigener Dokumentationsabteilung gibt.
Ich schreibe diverse Beiträge in unser Firmen-Confluence (Wiki). Viele Entwickler lesen dies und berücksichtigen vielleicht meine Vorschläge.
Die Geschäftsführer von KMUs werden so lange an TR sparen, wie sich die Kunden nicht beklagen. Wenn zwar im Vertrag ein „kontextsensitives Online-Hilfesystem“ fixiert wurde, sie sich aber mit mehreren PDF-Dateien abspeisen lassen.
Ich weiß jetzt aber, dass bei Dir „kein Verbeißen“ zu befüchten ist, sondern dass es Dir wirklich wichtig ist, etwas zu tun. Viel Erfolg, Du schreibst schließlich auch für mich.
Also ich finde den Artikel richtig gut und muss sagen, dass er mir gerade diese Woche beim erneuten lesen die Hoffnung zurückgegeben hat. Zumindest die Hoffnung das noch mehr Leute an dem Problem arbeiten den Status der TR zu verbessern. Ich bin gerade für ein Unternehmen tätig um hier „Topic orientierte Dokumentation“ einzuführen. Nachdem ich jetzt mal die Grundlagen geschaffen habe geht nun die Diskussion los: Ja Doku und Schulungsunterlagen haben ja schon immer die Produktmanager mal so nebenher geschrieben, warum sollen wir jetzt Leute einstellen die nur das machen? Nachdem ich die lange Liste der Gründe heruntergebetet habe kam noch der Spruch: Also von den meisten Dingen habe ich noch nie gehört, dass die wichtig sind bei Dokumentation…
Irgendwie kam ich mir dann schon komisch vor, wenn noch nicht mal die Rechtssicherheit als Argument ernst genommen wird, mit was soll man denn noch kommen? Ich glaube eine Sammlung von Praxisbeispielen wäre hier eine gute Idee um auch den letzten Menschen klar zu machen warum TR wichtig ist.
Ich für meinen Teil werde auch anfangen zu suchen und zu sammeln. Wenn es dann die Sammlung hier gibt werde ich meine Funde hinzufügen soweit möglich!
\m/(^_^)\m/ immer tapfer weiter