Community Management und technische Kommunikation

In den letzten Monaten ist das Thema “Die Zukunft des Technischen Redakteurs” ziemlich präsent gewesen. Mit den trendigen Themen Crowdsourcing und Community stellt man sich als technischer Redakteur so langsam die Frage: “Verlier ich meinen Job an die Crowd in der Cloud?”.

Ein mögliches Betätigungsfeld, oder besser gesagt: ein Feld bei dem wir Redakteure uns was abschauen können, ist das Community-Management. Ich kannte den Begriff Community-Manager eigentlich nur von Spiele-Foren und habe das nicht besonders ernst genommen – in meinem Kopf waren das “nur” Forenadministratoren (Asche auf mein Haupt, jaja). Wie ich mich jetzt mit dem Begriff “Community” im Umkreis technischer Kommunikation auseinandergesetzt habe, ist mir der Begriff “Community Manager” wieder eingefallen. Ich suchte, ich fand – und war erstaunt. Da ist ja richtig was los! Das ganze ist gar keine Randerscheinung irgendwelcher Nerd-Foren, sondern ein immer stärker werdender Berufszweig, in Deutschland sogar mit einem eigenen Verband, dem Bundesverband Community Managament (BVCM).

Und was ist Community-Management?

Community Management ist die Bezeichnung für alle Methoden und Tätigkeiten rund um Konzeption, Aufbau, Leitung, Betrieb, Betreuung und Optimierung von virtuellen Gemeinschaften sowie deren Entsprechung außerhalb des virtuellen Raumes. Unterschieden wird dabei zwischen operativen, den direkten Kontakt mit den Mitgliedern betreffenden, und strategischen, den übergeordneten Rahmen betreffenden, Aufgaben und Fragestellungen. (Quelle: BVCM)

Der Begriff “Community” ist also sehr weit gefasst: darunter fällt ein Forum, wie auch der Kreis an Twitter-Followern oder Facebook-Fans. Wenn man sich Stellenanzeigen anschaut, merkt man allerdings, dass es da noch kunterbunt zugeht. Community Manager, Social Media Manager – so ein richtiger Unterschied ist da häufig noch nicht zu bemerken.

Und was hat das mit technischer Kommunikation zu tun?

Ich denke, wir Redakteure können von Community Managern einiges lernen. Der Trend Hilfe-Communities heißt einerseits, dass wir Redakteure nicht mehr alles schreiben, was an den Kunden geht. Das ist der Punkt, der uns ein wenig Zukunftsangst verschafft. Andererseits bietet er eben auch neue Möglichkeiten. Das “Entstehen” von Community Managern zeigt, dass man eine Community eben nicht einfach so sich selbst überlassen kann. Es muss immer ein paar geben, die ein wenig lenken, hier und da Leute zur Ordnung rufen und die grobe Richtung im Auge behalten, ganz egal ob es sich um ein Spieleforum, eine Facebook-Seite oder ein Hilfeportal handelt.

Und da kommen wir Redakteure dann doch noch ins Spiel.

Von den Community-Managern können wir  lernen, wie man eine Community aufbaut, wie wir die Nutzer so miteinbeziehen, dass sie sich engagieren, wie wir mit Konflikten (oder wie man heute auch sagt: Shitstorms) umgeht etc.

Zusammen mit den Fähigkeiten eines Redakteurs könnten sich außerdem die folgenden Aufgaben ergeben: eine gewisse Grundstruktur vorgeben, einen Grundstock an Content ausäen, Redaktionsleitfäden konzipieren, Hilfe-Artikel aus der Community lektorieren, Feedback einarbeiten, Übersetzungen anstoßen und auch weiter selbst Artikel schreiben, bloß eben nicht mehr alleine :)

Wie kann so eine Hilfe-Community aussehen?

Ein interessantes Beispiel ist  die ubuntu-Community. ubuntu ist eine sehr populäre Linux-Distribution, die von der Firma Canonical gesponsert wird. Einer der Community Manager ist der Canonical-Mitarbeiter Jono Bacon, der auch das sehr lesenswerte Buch The Art of Community: Building, Managing, and Supporting Cooperation Over the Internet geschrieben hat.

Ich habe diese Community als Beispiel genommen, weil sie verschiedene Arten der Beteiligung ermöglicht: Entwickler können entwickeln, Grafiker mitdesignen und Schreibwütige eben auch dokumentieren.

Der Doku-Bereich gliedert sich dabei in 2 Teile: die offizielle System-Dokumentation, die mit der Distribution ausgliefert wird und bei der nur bestimmte Mitglieder mitwirken dürfen und die Community-Doku bei der jeder mitmachen kann. Es gab wohl auch schon Überlegungen, diese 2 Doku-Bereiche zu einem zu verschmelzen, aber ich vermute, über die “offizielle” Doku wollen sie doch noch mehr Kontrolle haben, damit auch wirklich kein Mist drinsteht, und das ist im Community-Bereich dann doch etwas schwieriger zu überblicken.

Sind Hilfe-Communities die Zukunft?

In einigen Bereichen sicherlich. Was Open-Source angeht, sind sie sogar schon Realität. Im Firmenumfeld wird es in einigen Bereichen sicherlich immer mehr kommen. Für manche wird aber sicherlich die folgende Frage immer ein Showstopper sein: wer ist denn eigentlich haftbar, wenn in einem Community-Hilfe-Artikel etwas Falsches steht und daraus Schaden entsteht? Und auch die Frage der Übersetzung ist da meiner Meinung nach ziemlich schwierig. Klar, kann man das auch die Community machen lassen, aber wenn man Ende ein Produkt mit Doku ausliefern muss, kann man sich evtl. doch nicht drauf verlassen. Um eine Community zu schaffen, muss man ein Stück Kontrolle aufgeben, aber die Frage ist, ob es nicht ein gewisses Maß an Kontrolle gibt, das man als Firma einfach behalten muss, um nicht in die Bredouille zu geraten.

Ich glaube, dass der Community-Trend uns Redakteure nicht die Jobs kosten wird. Zum einen, weil manche Dokus aus rechtlichen Gründen einfach nicht in die Community gegeben werden können ;) Zum anderen sehe ich eher einfach nur die Entstehung einer neuen Facette für Leute mit TR-Fähigkeiten – und zwar eine sehr spannende :)

Geschrieben in Beruf,Erweiterter Horizont,Social Media | 4 Kommentare

Die Redakteuse schreibt auch für dich!

Hier und da konnte man es schon von Twitter ahnen und der eine oder andere wusste es: ich arbeite ab sofort freiberuflich als Technische Redakteurin.

Ich werde weiterhin hier als Redakteuse schreiben, aber wer nun auch mit mir zusammenarbeiten will, darf gerne zu mp dokumentation rübergehen.

Heute mache ich mich auch auf den Weg zur tekom-Jahrestagung – also vielleicht sieht man sich ja :-)

Logo mp dokumentation

Geschrieben in Beruf,Nice to know | 4 Kommentare

Jeder kann schreiben

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? :-)

Geschrieben in Beruf,Erweiterter Horizont,Redakteurs Alltag | 7 Kommentare

tekom 2010: Documentation for Software Engineers

In meinem ersten Job wurde ich zur Betreuung der internen Dokumentation und des Firmen-Wikis eingestellt. Die Vision damals war, dass ich mal tüchtig aufräume und danach alle Abteilungen in der Firma tolle Dokumentation haben. Nun, das wäre super gewesen :) Aber ich musste feststellen, dass das so einfach nicht ist. Es kommt zum einen darauf an, um was es sich für eine Abteilung handelt ( PR? Marketing?Personal? Entwicklung? Wenn ja, welche Richtung? etc), denn die Anforderungen sind dann natürlich unterschiedlich. Dazu hätte ich mich im Detail mit jeder Abteilung und ihrer Dokumentation auseinander setzen müssen. Eine Person alleine kann das für eine große Firma nicht schaffen – und: die Abteilungen müssen am Ende trotzdem auch immer noch selbst Dokumentation schreiben. Das war für die meisten die größte Überraschung damals ;)

In dem Vortrag “Documentation for Software Engineers” von Ulrike Parson habe ich nun einiges erfahren, wie man das Thema interne Dokumentation angehen kann. Und es hat meine oben erwähnten Erfahrungen bestätigt.

Zielgruppen
Auch bei interner Dokumentation ist es wichtig sich über die Zielgruppe Gedanken zu machen. Das wird bei diesem Thema oft vergessen – es ist ja “nur” für intern. Die Zielgruppe ist hier der Software-Entwickler und seine verschiedenenen Ausprägungen. Frei übersetzt teilte Ulrike Parson sie wie folgt auf:

  • Den Praktiker:
    • will loslegen
    • benötigt Code-Kommentare, Code-Beispiele
  • Den Gründlichen:
    • liest zuerst einmal die Grundlagen
    • benötigt Hintergrundinfo zu API/Framework, Beschreibung allgemeiner Programmieraufgaben (Error handling, Lokalisierung &Co.)
  • Bedarfsleser
    • Liest bei konkreten Fragen nach
    • Benötigt Code-Kommentare, Hintergrundinformationen und Code-Beispiele

Anhand dieser Zielgruppenanalyse schlüsselt sie dann auf, welche Dokumenttyen geliefert werden müssen, um diesen Anforderungen gerecht zu werden. Und auch wie sie geliefert werden müssen, z.B. als PDF oder Wiki mit Feedback-Funktion, Index etc.

Die Rolle des technischen Redakteurs
Ich habe von Entwicklern schon so oft gehört, dass sie endlich mal dokumentieren müssten oder endlich mal “gescheit dokumentieren” müssten. Gleichzeitig hab ich mich immer gefragt: wie könnte ich dabei helfen? Immerhin heißt es doch auch “technische Dokumentation”, was ich studiert habe ;)

Inwieweit der technische Redakteur die Entwickler beim tatsächlichen Dokumentieren unterstützen kann, hängt natürlich stark davon ab, wieviel Programmierwissen und -erfahrung er selbst hat. Aber es ist ununmgänglich, dass die Entwickler auch selbst dokumentieren – wer etwas selbst macht, weiß einfach am besten darüber Bescheid. Frau Parson hat sehr schön gezeigt, dass der Redakteur auch ohne selbst viel zu schreiben, doch sehr viel hier mitarbeiten kann.

So können die Aufgaben des Redakteurs aussehen:

  • Zielgruppen- und Bedarfsanalyse
  • Dokumentationsworkflows erstellen
  • Terminologie erarbeiten, pflegen und bereitstellen
    • gerade in der Entwicklung lebt so manch uralter produktname ewig weiter
    • Missverständnisse untereinander werden vermieden
  • Neue Texte redigieren/korrigieren
  • Neue Texte evtl. schreiben
  • Strukur der Dokumentation entwickeln und überwachen
  • Dokumentvorlagen bereitstellen

Und wenn man sich das mal genau anschaut, sieht man wieder, dass das ganz klassische Redakteursaufgaben sind. Nur ist der Fokus nicht so sehr darauf alles auch selbst zu schreiben, sondern viel mehr zu recherchieren, strukturieren, den Entwicklern eine Basis zu geben.

Als praktisches Beispiel wurde abschließend noch ein Wiki gezeigt, das vor allem von den Entwicklern befüllt wird. Von der Redakteursseite wurde eine Grundstruktur angelegt und auch verschiedene Templates, damit die Entwickler nicht vor einer weißen Seite stehen und nicht wissen wo sie anfangen sollen. Der Redakteur überwachte nun die Entwicklung der Dokumentation und greift hier und da korrigierend ein. Zudem gibt es einen Freigabeprozess, so dass man auch wirklich nur qualitativ hochwertige Dokumentation publiziert.

Für den einen oder anderen Software-Entwickler klingt das ganze vielleicht nach zu viel Reglement, aber ich habe schon zuviel schlechte und veraltete SW-Dokumentation gesehen und das klingt für mich nach einem plausiblen Weg aus der Misere.

Fazit

Ein hochinteressanter Vortrag (als PDF), der auch mal neue Wege für Redakteure aufgezeigt hat, die nicht in der klassischen Schiene liegen, aber am Ende doch perfekt auf das Skillset passen. Vielen Dank dafür! :)

Geschrieben in Beruf,Erweiterter Horizont,Softwaredokumentation | Keine Kommentare

tekom Jahrestagung 2010 – Rückblick

So, es ist geschafft :)

Ich habe den Beinahe-Laptopausfall und die Vor-Vortrags-Nervosität halbwegs überstanden und ich denke, mein Vortrag ist ganz gut angekommen. Aber Genaueres weiß ich erst, wenn die Feedback-Bögen eintreffen. Und da bin ich äußerst gespannt! Meine Folien werde ich demnächst hier veröffentlichen sind nun unter Downloads erhältlich.

Nun, wie sah es mit dem Rest der Tagung aus?

Das Zielgruppen-Problem

Bei mir und bei vielen anderen (u.a. auch im neuentdeckten Blog von Jason A. Nichols), herrschte ein wenig Unmut darüber, dass man in vielen Fortgeschrittenen- oder Experten-Vorträgen dann doch wieder mit sehr vielen Basics konfrontiert wurde. Ich weiß schon gar nicht mehr in welchem Vortrag das war, aber als man anfing uns zu erklären, dass Standards gut sind, da kam ich mir etwas veräppelt vor (das gehört für mich zur Grundausstattung des Redakteurs!). Vielen fiel es sichtlich schwer, den Vortrag zielgruppengerecht aufzubereiten. Vielleicht fehlt aber auch ein genaue Beschreibung der Klassifikationen “Einsteiger – Fortgeschrittene -Experten”? Ich habe mir rückblickend nämlich überlegt, dass ich meinen Vortrag wohl besser als “Für Experten” eingestuft hätte, aber so richtig sicher bin ich mir nicht. Daher mein Vorschlag an die tekom, da vielleicht mal den Versuch einer detaillierten Klassifikation zu starten. Als Zuhörer ist es wirklich sehr ärgerlich, wenn man sich in einem Vortrag wiederfindet, der einfach gar nicht passt. Ich kann mir gut vorstellen, dass sich viele die Investition in die nächste Tagung nochmal gut überlegen.

Die Idee von Urs Klenke nicht mehr so viele verschiedene Vorträge anzubieten, aber dafür ausgewähltere und diese auch zu wiederholen, finde ich prinzipiell auch ganz gut, wobei es organistorisch bestimmt ziemlich kompliziert wäre…

iPad, iPhone, ePub

Das war definitiv der Hype in diesem Jahr. Vieles war hier noch recht theoretisch – ich hoffe im nächsten Jahr auf erste richtige echte Beispiele!

User assistance

Der Hype dauert immer noch an, wobei ich da weiterhin hoffe, dass es auch hier noch mehr echte Beispiele geben wird. Die Theorie ist so langsam bekannt – jetzt will ich sehen was andere machen :)

… und der Rest

Es war einfach mal wieder nett so komplett unter “seinesgleichen” zu sein und sich über das Fach austauschen zu können – und auch so einige Leute mal “in echt” zu treffen ;) Zielgruppen hin oder her – es waren immer noch Vorträge dabei, die einem hier und da wieder einen neuen Denkanstoß gegeben haben. Ich werde mir zum Beispiel in nächster Zeit einige Gedanken dazu machen, wie ich eventuell eine Verknüpfung meiner Hilfedateien mit den Textdateien unserer Applikationen hinbekommen kann, so wie in dem Vortrag “User Interface-Texte in der Dokumentation“.

Und last but not least: endlich ist mir bei einem von Tony Selfs Vorträgen eine Frage eingefallen! Dafür wird man nämlich mit einem echten Aussie-Koala belohnt ;-)

Tony-Self-Koala

EDIT: einen interessanten Rückblick bietet auch Sarah.

Geschrieben in Beruf,Erweiterter Horizont,Nice to know | Keine Kommentare