Doku-Hotline

“Two hours of trial and error can save ten minutes of manual reading.”

Betrifft mich aktuell nicht, aber auch ich habe schon “fictitious documentation” verfasst:

Fictitious documentation refers to documentation that fails a lie detector test but which passes the project manager’s approval. (zum Artikel)

Idealerweise entspricht die Dokumentation dem Ist-Stand; realistischerweise ist regelmäßig ein Soll-Stand abgebildet, da z.B. nur eine unvollständige Software-Vorversion verfügbar ist. Auch das Verschweigen bestimmter Eigenschaften (besonders solcher, die potentiell Benutzer verärgern) ist nicht selten.

Der zitierte Artikel bezieht sich primär auf echte Bugs und die Frage, ob diese beschrieben werden sollen. Hier findet sich eine Stärke von Open-Source-Systemen - da für diese niemand Geld zahlt, ist es üblich, z.B. bei Modulen ausführlich zu warnen, wenn bestimmte Einschränkungen vorhanden sind. Bei Kaufsoftware dagegen, die zumindest scheinbar einen stabilen, geprüften, fehlerfreien Stand liefern soll, werden Bugs lieber nicht erwähnt, wenn es sich vermeiden lässt…

…können sich ausgiebig Gedanken darüber machen, wie man am besten Smilies in Klammern schreibt:
Emoticons and Parentheses.

Eine Bekannte war ein wenig künstlerisch tätig, und das kam dabei raus… “Tools for Technical Writing” by AnK (draufklicken fürs Original):

Mein persönlicher Favorit ist ja das Bugfixing-Verfolgen mit den Tarotkarten…aber das bin ich in der Softwareentwicklung nicht anders gewohnt ;)

Genial: jetzt gibt es ein DITA to WordPress Import Tool ! Was für ein potentiell riesengroßer Schritt für das Thema Online-Hilfe, wenn diese jetzt endlich auch interaktiver und dynamischer werden kann (Medieneinbindung, Kommentarfunktionen etcpp).

Eine Besprechung und ein Demo-Filmchen dazu gibt es hier: Merging Worlds: DITA and WordPress.

Tolle Sache. Ich bin gespannt, wann die ersten Hilfe-Projekte mit dieser Methode online gehen.

Vorab: Der Begriff “Technischer Redakteur” ist der von der Tekom präferierte und hat sich weithin durchgesetzt, auch wenn viele Leute dadurch denken, dass man “nur” die Texte anderer redaktionell bearbeitet und lektoriert. Tatsächlich betreiben meiner Erfahrung nach freiberufliche technische Redakteure immer auch Consulting rund um technische Lösungen und Design für Dokumentation, können ein wenig programmieren und Grafiken erstellen, können übersetzen und eine gewisse Qualitätssicherung für Übersetzungen, Oberflächendesigns und Benutzerfreundlichkeit durchführen. Wenn man sich abgrenzen mag - “Informationsdesign” oder “Technische Kommunikation” ist eigentlich korrekter, nur benutzt das kaum jemand in Angeboten und Suchen.

Einige typische Fragen…

Wo findet man Jobs oder Projekte in der technischen Redaktion?

Stellenangebote bei der Tekom — in diesem Spezialistenportal tragen viele Firmen ihre Stellen ein.

Monster.de und ähnliche Jobportale. Die gezielte Eingabe sollte dabei “technischer redakteur [stadt]” lauten. Für eine breitere Suche bieten sich Themenfelder wie “software [stadt]” oder “maschinenbau [stadt]” usw. an. Damit lassen sich Firmen finden, die Bedarf haben könnten.

Gulp.de ist das Portal für freiberufliche IT-Berater (und überwiegend in Männerhand). Dort suchen sich viele Projektvermittlungsagenturen ihre Mitarbeiter.

So richtig viele Angebote gibts aber nicht, oder?

Geht so. Bis zur Wirtschaftskrise hat der Markt für technische Redakteure ziemlich geboomt, allerdings eher in den Sektoren E-Technik, Maschinenbau und Flugzeugbau. Softwaredokumentation ist definitiv seltener.

Wie ist das mit Projektvermittlern?

Projektvermittler sitzen zwischen Auftraggeberfirmen und dem Freiberufler und nehmen diesen als Unterauftragnehmer unter Vertrag. Sie haben folgende Vorteile:

• Sie übernehmen die Akquise für den Freiberufler. Akquise stellt für Freiberufler oft eine Schwierigkeit dar, und so ist es tendenziell entspannter, einfach auf den nächsten Anruf mit dem Angebot zu warten (wenn er denn kommt!).
• Sie haben Kontakte zu großen Firmen (die vielfach gar keine einzelnen Freiberuflern beauftragen, sondern nur noch über Projektvermittler gehen). Wer wohlklingende Namen in der Referenzliste will, hat hier gute Chancen.
• Sie zahlen zu einem definierten Zeitpunkt (typischerweise 30-45 Tage nach Rechnungsstellung). Das klingt nach einem langen Zeitraum, doch wer einmal mit deutschen Großunternehmen zu tun hatte, weiß, dass diese schnell drei Monate bis zur Zahlung ins Land ziehen lassen. Projektvermittler überbrücken diese Zeiten. Ich kann nur davon abraten, Verträge zu unterschreiben, in denen die eigene Zahlung zeitlich an die des Oberauftraggebers gekoppelt ist. (Die Zahlung ist immer daran gekoppelt, dass die Rechnung akzeptiert wird.)

Dafür gibt es folgende Nachteile/Besonderheiten:

• Projektvermittler verdienen an jeder Stunde mit, daher ist der Stundensatz tendenziell (aber nicht immer!) geringer als bei direktem Kundenkontakt.
• Verträge mit Projektvermittlern sind meist umfangreich und beinhalten bedrohliche Vertragsstrafen bei Verletzung der Schweigepflicht oder vorzeitigem Ausstieg, vermitteln also leicht das Gefühl, seine Seele dem Teufel zu verschreiben :) Arbeitsverträge sind vergleichsweise brav dagegen.
• Das Projektvermittlerbusiness ist primär im Süden von Deutschland beheimatet. Die überwiegende Zahl von Angeboten kommt aus Frankfurt, Stuttgart, München und sonstwo in Bayern. Ruhrgebiet, Berlin und Norddeutschland sind ziemlich unterrepräsentiert.
• Projektvermittler vermitteln üblicherweise Vollzeitprojekte. Dies führt zu einer Ganz-oder-Gar-Nicht-Zeitaufteilung: Entweder man steckt in einem Projekt, oder man hat nichts zu tun. Es ist schwierig, kleinere Kunden und ihre Projekte neben einem Vollzeitprojekt zu betreuen.

Mehr Infos gibts bei Gulp und im Gulp-Forum. Ein Basis-Profil bei Gulp ist kostenlos und für alle Freiberufler im IT-Bereich unbedingt empfehlenswert!

Übrigens vermitteln einige Projektvermittler inzwischen auch feste Stellen. Allerdings ebenfalls überwiegend im Süden.

Was ist mit Agenturen?

Klassisches Agenturgeschäft gibt es mehr im Grafik- und Übersetzungsbereich. In der technischen Dokumentation kann man als Freiberufler prinzipiell auch mit größeren Dokumentationsfirmen zusammenarbeiten, typischerweise als Unterauftragnehmer. Allerdings bevorzugen diese Firmen meiner Erfahrung nach eher Festangestellte (die auch in 2 Jahren noch fürs Projekt greifbar sind) anstelle von Freiberuflern, die nach 3 Monaten weg sein können.

Wie ist es mit Referenzen?

Für Freiberufler sind Referenzen sehr wichtig. Schriftliche Referenzen sind bereits hilfreich, allerdings habe ich in den letzten Monaten auch erlebt, dass bis zu 3 Telefon-Referenzen gewünscht wurden, d.h. Personen, deren Daten man dem Projektvermittler gibt und die dann als Referenz vom Kunden ausgefragt werden können. In USA ist dies für Stellen meines Wissens üblich, in Deutschland eher neu. Achtung: Nie Telefonnummern weitergeben, ohne dass der potentielle Referenzgeber zugestimmt hat! Sonst kann man diesen Kunden sicherlich für die Zukunft vergessen.

Zur Lage bei Angestellten kann ich weniger sagen; Referenzen zu haben ist aber vermutlich immer hilfreich.

Was tun, wenn man keine Referenzen hat?

a) Referenzen schaffen, z.B. indem man einige kurzzeitige Projekte durchführt, ggf. auch für wenig Geld, dafür aber mit dem Ziel der Referenz vor Augen (und vertraglich mit dem Kunden im Vorfeld geklärt).

b) Mehr mit direkten Kunden als z.B. über Agenturen arbeiten, da letztere oft kein Interesse haben, dass der eigentliche Auftraggeber erfährt, wer da unten die Arbeit gemacht hat.

c) Eigene Projekte schaffen, z.B. im Internet. Das verhindert Leerzeiten im Lebenslauf und demonstriert technisches Know-How in Kombination mit interessanten Texten. Dabei darauf achten, dass die Projekte wirklich vorzeigbar sind.

Brauche ich denn eine Webseite?

Als jobsuchender Redakteur braucht man keine Webseite. Auch für Freiberufler ist eine eigene Webseite nicht notwendig, allerdings ist es im Hinblick auf das Thema Scheinselbstständigkeit hilfreich, wenn man durch eigene, sichtbare Aktivität im Markt vertreten ist, und dazu kann eine Webseite gehören.

Wenn man allerdings sowieso im Internet aktiv ist, ist dem Selbstmarketing keine Grenze gesetzt :)

Wie ist das mit der Scheinselbstständigkeit?

Eigentlich war das Gesetz 1999 dazu gedacht, die Ausbeutung von z.B. Auslieferungsfahrern und Blumenverkäufern zu limitieren — dass es plötzlich die gutverdienenden, sehr freiwillig freien IT-Berater traf, kam eher überraschend. Das Gesetz wurde alsbald korrigiert, doch auch heute gilt eine zu lange Tätigkeit für nur einen Kunden als auffällig. Ausführliche Infos dazu gibts bei E-Lance, einem allgemein sehr empfehlenswerten Ratgeber für Selbstständige und solche, die es werden wollen.

Welche Firmengrößen arbeiten denn überhaupt mit freien technischen Redakteuren?

Prinzipiell alle Größen:

• Kleine Firmen, bei denen sich ein festangestellter Redakteur noch nicht lohnt.
• Mittelgroße Firmen, die bereits ein Team in der Technischen Redaktion haben, aber punktuell Verstärkung brauchen.
• Große Firmen, die bereits wieder in viele Unterabteilungen zerfallen, die eigenständige Projekte durchführen. Diese Firmen haben oft eine Redaktion, aber die ist eher fürs Intranet oder andere übergeordnete Arbeiten zuständig. Fürs Projekt wird dann temporär jemand eingekauft.

Und wie ist das mit der Wirtschaftslage?

Meine Erfahrung ist, dass bei zunehmender Krise der Markt relativ schlecht ist. Gut ist die Phase, wenn die Wirtschaft wieder anzieht, aber noch sehr zögerlich Personal eingestellt wird. Für Freiberuflichkeit eher schlecht ist eine sehr gute Wirtschaft, da die Firmen dann lieber fest einstellen.

Und die Stundensätze…?

Es gibt zwei Hauptansätze, Stundensätze zu berechnen: nach dem eigenen Bedarf (z.B. hier), oder nach dem, was der Markt bietet (z.B. hier). Da Dokumentation eine tendenziell geringe Priorität hat, wird sie gerne auch schlechter bezahlt als Entwicklung/Programmierung (wobei dort die Sätze auch schwanken, wenn nicht grad die magischen Buchstaben SAP im Profil stehen). Es hilft, wenn man sich als Spezialist profiliert, sei es über das Fachgebiet (E-Technik, Automatisierung…) oder die Dokumentationstechnik (Framemaker, DITA, SGML…).

Soviel zum Thema für heute. Ich wünsche allen, die gerade am Suchen sind, viel Erfolg! Ergänzungen und Kritik gerne in den Kommentaren.

Pünktlich zum Jahresende gab es für tekom-Mitglieder wieder ein Buch der “Schriften zur Technischen Kommunikation” als Goodie. Dieses Jahr den nagelneuen Band Nr. 13 mit dem etwas unhandlichen Titel “Arbeits- und Gestaltungsempfehlungen für Technische Dokumentation. Eine kritische Bestandsaufnahme”. 12 Autoren schreiben darin über den aktuellen Erkenntnis- und Umsetzungsstand von Redaktionsleitfäden, Lasten- und Pflichtenheften, Übersetzungsmanagement, Checklisten, Typografie und Layout, Grafikgestaltung, Multimedia und Kreativität in der technischen Dokumentation.

The Intro

Die Einleitung liest sich sehr interessant, beleuchtet die Entwicklung in der Literatur zum Thema Dokumentation - früher ging es schwerpunktsmäßig um Qualität, heute um Standardisierung - und zeigt auf, dass einige gängige Regeln, wie die Verwendung von Aktiv/Passiv-Formulierungen, eher dem Reich der Glaubenssätze als der wissenschaftlich bewiesenen Regeln zuzuordnen sind. Dies nutzen die beiden Herausgeber als Aufhänger für die “kritische Bestandsaufnahme”. Ziel des Buches soll sein, aktuelle rechtliche Vorgaben und aktuelle Forschungsergebnisse zu beleuchten, und gängige Irrtümer oder Verunsicherungen zu beseitigen.

Den ganzen Beitrag lesen »

Eddie VanArsdall veröffentlicht in seinem InfoDesign-Blog ausführliche Tutorials zu Madcap Flare. Das aktuelle Thema ist Flare Print Publishing: Creating Print–Only Topics.

Gerade beim Printoutput von Flare 3 nach Flare 4 hat sich einiges geändert (Stichwort: Page Layout statt Masterpage, hier gibts den Bericht eines anderen technical writer zu dem Thema). Es lohnt sich daher, auch bei Erfahrung mit Flare noch mal die Print-Formatierungen im Detail anzuschauen.

Tendenziell habe ich in der Vergangenheit wenig mit diesem oft kritisierten Tool gearbeitet, doch für ein Projekt bot sich das Erstellen der Unterlagen in Powerpoint an. Es ging darum, Schulungsunterlagen für Trainer und Teilnehmer aus derselben Quelle zu gestalten. Basis dafür war die Möglichkeit, die Folien und Notizen aus Powerpoint nach Word auszugeben (siehe auch Unterlagen im Dualen System).

Die Unterlagen

Die eigentliche Schulungsunterlage war in klassischem Folienformat (von meiner Grafikerin optisch ansprechend aufbereitet) und enthielt das Nötigste - was immer noch recht viel Information war. Hier ein Auszug:

Alle zusätzlichen Informationen, die nicht auf die Folie passten, wurden als Notizen ergänzt. Mit Ausgabe nach Word / PDF konnten die Teilnehmer so eine Unterlage mit Zusatzbemerkungen und Tipps erhalten.

Wo lagen die Herausforderungen?

Technisch ist das genaue Ausrichten von Folieninhalten und Notizen in Powerpoint ein wenig gewöhnungsbedürftig. Für die gelungene Ausgabe nach Word muss der Notizenmaster analog zu den Folien ans Corporate Design angepasst werden. Dennoch traten manchmal Nebeneffekte auf, da z.B. die Textausrichtung der Notizen in Word nicht immer sauber funktionierte.

Inhaltlich musste der Einstieg in eine komplexe Webanwendung so erklärt werden, dass die Teilnehmer nach der Schulung selbstständig Formulare erstellen können sollten. Dabei sollten die Inhalte mit viel Grafik schmackhaft gemacht werden. Dies führte zu starkem Kürzen oder Verteilen eines Vorgangs auf mehrere Folien. Die im Feinkonzept veranschlagte Folienanzahl wurde um 10% überschritten.

Resonanz der Teilnehmer

Die Unterlagen wurden gut angenommen, aber einige Folien enthielten immer noch zuviel Inhalte auf zuwenig Raum. Auch über thematische Erweiterungen wird noch nachgedacht. Vielleicht mehr dazu nächstes Jahr.

Fazit

Nicht unbedingt das stabilste aller Arbeitsmittel, bietet Powerpoint im Zusammenspiel mit Word doch einen Weg, um Inhalte für zwei Zielgruppen gleichzeitig zu verpacken. Da beide Programme zu den Bordmitteln der meisten Firmen gehören, ein praktischer Ansatz, wenn die Unterlagen nicht sehr oft angepasst werden müssen.