Arten von Softwaredokumentation

Softwaredokumentation im weitesten Sinne umfasst teilweise sehr unterschiedliche Bereiche. Dies führt oft zu Missverständnissen.


Unterteilung nach der Nutzung der Softwaredokumentation



Grob unterteilen lässt sich Softwaredokumentation allgemein in Dokumentationstypen für den internen Gebrauch beim Hersteller und in Dokumentationstypen zur Weitergabe an Kunden.


Für den internen Gebrauch zählen zur Softwaredokumentation insbesondere:

  interne Projektdokumentation

  Dokumentation im Quellcode


Für den externen Gebrauch, also zur Weitergabe an Kunden, zählen zur Softwaredokumentation insbesondere:

  Benutzerdokumentation

  Schnittstellendokumentation (API-Dokumentation)


Unterteilung nach dem Informationstyp

der Softwaredokumentation

Typischerweise sind in einer Benutzerdokumentation mindestens drei grundlegend verschiedene Informationstypen enthalten:

  Grundlagenwissen zu den allgemeinen Konzepten hinter der Software sowie gegebenenfalls ergänzendes Fachwissen (Domänenwissen), das der Zielgruppe noch fehlt

  schrittweise Handlungsanleitungen

  Referenzinformationen zum Nachschlagen, z. B. zu einzelnen Parametern


Nur selten ist eine Vermischung dieser Informationstypen sinnvoll, denn sie werden zu ganz unterschiedlichen Zeitpunkten aber fast nie gleichzeitig benötigt. Oft werden diese Informationstypen daher sogar in unterschiedliche Dokumente oder Dokumentationsteile aufgeteilt, z. B. in ein „Benutzerhandbuch“ und in ein „Referenzhandbuch“.


Unterteilung nach dem Medium

der Softwaredokumentation



Neben der inhaltlichen Ebene gibt es auch vom Medium her grundlegend unterschiedliche Typen von Softwaredokumentation:

  gedruckte oder druckbare Handbücher mit einer festen Seitenfolge (einschließlich PDF)

  Online-Dokumentationen (Online-Hilfen) als echter Hypertext, meist HTML

Eine Softwaredokumentation sollte Teil einer ganzheitlichen Software-User-Assistance sein



Eine Softwaredokumentation für Benutzer sollte im Idealfall immer in einem globalen Kontext stehen: dem Kontext einer ganzheitlichen Software-User-Assistance. Dies sind alle Maßnahmen, die die Benutzer bei ihrer Nutzung der Software unterstützen. Neben der klassischen Dokumentation, bestehend aus Handbüchern und Online-Hilfen, gehören zu einer ganzheitlichen User-Assistance insbesondere auch:

  kleine, bereits in die Benutzeroberfläche integrierte Infotexte

  Screencasts (Software-Videos)

  interaktive Lernprogramme

  Beispiel-Projekte

  Benutzerforen und Communities

Anforderungen an Softwaredokumentation

Grundlegende Anforderungen


Die wichtigste und zugleich die am häufigsten vernachlässigte Anforderung an Softwaredokumentation ist: Eine Softwaredokumentation muss die Fragen der Kunden beantworten und sie befähigen, das Produkt vollständig und effizient zu nutzen. Mehr nicht! Es geht nicht darum, was wir in der Softwaredokumentation sagen möchten, sondern ausschließlich darum, was der Leser wissen will. Technische Details, auf die wir zurecht stolz sind, die die Leser aber nicht kennen müssen, haben in einer Softwareokumentation ebenso wenig verloren wie hochtrabende Phrasen und „
Buzzwords“ aus der Marketing-Abteilung.

Die Kunst beim Erstellen von Softwaredokumentation besteht darin, mit der Softwaredokumentation genau die Wissenslücke zu schließen zwischen dem, was der Leser schon weiß, und dem, was er noch nicht weiß aber wissen muss. Weniger Information ist zu wenig, mehr Information ist zu viel.

Machen wir uns nichts vor: Niemand liest eine Dokumentation zum Spaß. Technische Dokumentation, und damit auch Softwaredokumentation, wird meist nur als lästiges Übel empfunden. Sie wird nur dann gelesen, wenn der Schmerz, eine Funktion nicht nutzen zu können, größer ist als der Schmerz, die Dokumentation lesen zu müssen. Es geht beim Erstellen von Softwaredokumentation also immer darum, den Schmerz beim Lesen möglichst gering zu halten.

Der Schmerz ist dann gering, wenn:

  die Information schnell und ohne Umwege gefunden wird

  genau die passende Information gefunden wird, also nichts Irrelevantes mitgelesen werden muss

  die Information einfach verständlich ist, also möglichst wenig Denkarbeit geleistet werden muss

  die Information auf die eigene Problemstellung angewandt und praxisnah nachvollzogen werden kann

  das Lesen schnell geht


Gesetzliche und vertragliche Anforderungen



Anders als bei anderen Formen Technischer Dokumentation gibt es bei Softwaredokumentation kaum gesetzliche und aus bestimmten Normen resultierende Anforderungen. In den meisten Fällen gilt lediglich die generelle Grundanforderung an Dokumentation, dass sie die Kunden dazu befähigen muss, das Produkt vollständig und erfolgreich zu nutzen.

Zusätzlich können sich spezielle Erfordernisse basierend auf vertraglichen Vereinbarungen mit Kunden ergeben, oder aus besonders zugesicherten Eigenschaften. Wird zum Beispiel damit geworben, dass eine Software über eine spezielle Schnittstelle verfügt, dann muss diese Schnittstelle auch so dokumentiert sein, dass die Kunden sie erfolgreich verwenden können.

Steuert eine Software Maschinen oder Geräte, können die für diese Maschinen und Geräte maßgeblichen Normen auch für die Softwaredokumentation relevant sein. Insbesondere betrifft dies die Gestaltung von Warnhinweisen.

Wer erstellt Softwaredokumentation?

Entwickler oder Technischer Redakteur?



Das Erstellen von Softwaredokumentation wird von Entwicklern oft als lästiges Übel empfunden und zählt nicht unbedingt zu den Aufgaben, um die sich alle reißen. Und trotzdem: Ein großer Teil aller Softwaredokumentation wird von den Entwicklern einer Software selbst geschrieben. Neben dem persönlichen Mangel an Motivation hat das Schreiben durch Entwickler vor allem den Nachteil, dass die Entwickler selbst viel zu tief in der Materie stecken, um einem Außenstehenden die benötigten Informationen in allgemeinverständlicher Form liefern zu können. Ganz besonders gilt dies für Benutzerdokumentation. Wer eine Software selbst programmiert, hat ganz automatisch eine ganz andere Sicht auf das Produkt als ein Benutzer. Die Benutzersicht einzunehmen, ist beim Schreiben von Benutzerdokumentation aber eine unbedingte Voraussetzung, wenn die Dokumentation wirklich gut werden und die Fragen der Benutzer widerspiegeln soll. Sich als Entwickler aus der primär technischen Sichtweise zu lösen, ist unglaublich schwierig und gelingt nur in den seltensten Fällen.

Technische Dokumentation, und damit auch Softwaredokumentation, professionell erstellen zu können, erfordert eine spezielle Ausbildung und auch ein gewisses Talent. Hierfür gibt es heute eigenständige, mehrjährige Studiengänge. Zwar kann jeder schreiben, aber nicht jeder kann automatisch so schreiben, dass ihn jeder versteht!

Andererseits haben Entwickler den großen Vorteil, unmittelbar an der Quelle der Informationen zu sitzen und daher (zumindest theoretisch) auch Dinge beschreiben zu können, die einem nicht unmittelbar an der Entwicklung beteiligten Autor möglicherweise entgehen.


Fazit


Als Know-how-Lieferanten sind Entwickler unersetzlich. Allgemein lässt sich sagen: Je näher eine Dokumentation „am Code“ ist, desto eher sollte sie von Entwicklern selbst verfasst werden – z. B. eine API-Referenz. Je stärker eine Dokumentation auf die Benutzer der Software eingehen muss, desto eher sollte die Dokumentation NICHT von Entwicklern konzipiert und geschrieben werden, sondern von einem erfahrenen Technischen Redakteur.

Besonders effizient kann auch ein kombinierter Workflow zur Erstellung von Softwaredokumentation sein: Entwickler und Know-how-Träger stellen die wichtigen Fakten zusammen und schreiben eine erste Rohfassung der Dokumentation. Sie konzentrieren sich dabei ausschließlich auf die Inhalte und „verschwenden“ keine Zeit damit, schön zu formulieren und zu formatieren. In einem zweiten Schritt bereitet ein erfahrener Technischer Redakteur die Inhalte so auf, dass daraus eine auch für Kunden verständliche Softwaredokumentation entsteht. Besonders effizient ist dieses Modell deswegen, weil hierbei jeder genau das tut, was er am besten kann.

Best Practices für Softwaredokumentation

Wenn eine hochwertige, professionelle Softwaredokumentation entstehen soll, können Sie nicht erwarten, dass diese Dokumentation ein Entwickler ohne entsprechende Vorbildung mal eben nebenbei aus dem Ärmel schüttelt.

Wenn Sie keinen Technischen Redakteur einstellen können und keinen auf die Erstellung von Softwaredokumentation spezialisierten Dienstleister beauftragen möchten, bleibt nur eine Lösung: Sie müssen den mit der Dokumentationserstellung betrauten Mitarbeitern das erforderliche Grundlagenwissen vermitteln, damit diese Miarbeiter selbst verständliche, benutzerfreundliche Dokumentation erstellen können.

Wesentliche Verbesserungen können Sie erstaunlich schnell erzielen. Wie in vielen Bereichen gilt auch für Technische Dokumentation die bekannte 80-zu-20-Regel (Paretoprinzip): 80 Prozent einer möglichen Qualitätssteigerung lassen sich bereits mit 20 Prozent der Mittel erreichen. Zwischen
einer planlos erstellten Softwaredokumentation und dem 80-Prozent-Niveau liegen bereits Welten!

Die Schlüsselbereiche, für die Sie die wichtigsten Best-Practices kennen sollten, sind:
Best-Practices zum Strukturieren
von Softwaredokumentation

Welche Dokumente sollten Sie überhaupt erstellen? Gedruckt oder online oder beides? Wie bauen Sie diese Dokumente auf? Wie führen Sie den Leser schnell und erfolgreich zu den für genau diesen Leser relevanten Inhalten?
Best-Practices zum Gestalten von Softwaredokumentation

Wie gestalten Sie Ihre Dokumente, so dass diese Dokumente nicht nur gut aussehen, sondern gleichzeitig auch den Lesern das Aufnehmen und Behalten der Informationen einfach machen?
Best-Practices zum Schreiben von Softwaredokumentation

Wie schreiben Sie einfach und verständlich, so dass die Leser die Informationen so mühelos wie möglich verstehen? Die Inhalte sind meist schon komplex genug, da sollte wenigstens die Sprache einfach sein!

Beispielsweise vermitteln Ihnen meine Schulungen zum Thema Technische Dokumentation für Software und meine Bücher zum Thema Technische Dokumentation in kompakter Form genau diese wichtigsten Best-Practices.

Tools zum Erstellen von Softwaredokumentation

Welches die optimalen Werkzeuge zum Erstellen von Softwaredokumentation sind, hängt in erster Linie davon ab, welcher Typ von Softwaredokumentation entstehen soll. Grob lassen sich die Tools zum Erstellen von Softwaredokumentation in folgende Gruppen einteilen:

  Standard-Help-Authoring-Tools
Erzeugen allgemeine Online-Hilfen und oft auch druckbare Dokumente (PDF-Handbücher) in unterschiedlich guter Qualität. Eignen sich primär für Benutzerdokumentation. Beispiele: Flare, RoboHelp, Help & Manual, Help Studio, HelpNDoc

  Web-basierte Help-Authoring-Tools
Von der Funktion her ähnlich den Standard-Help-Authoring-Tools, jedoch installationsfrei im Browser aufrufbar und außerdem unabhängig vom Betriebssystem. Mit den typischen Vor- und Nachteilen einer Web-Anwendung. Beispiele: Paligo, ClickHelp

  DITA-basierte Tools
Tools basierend auf der standardisierten XML-Struktur DITA, die speziell für Softwaredokumentation entwickelt wurde. Leistungsfähig für umfangreiche Dokumentationsprojekte. Für kleinere Projekte unter mehreren Hundert Seiten meist zu komplex und zu aufwendig. Beispiele: <oxygen/> xml Editor, DITA Open Toolkit

  Content-Component-Management-Systeme (CCMS)
Entweder DITA-basiert oder mit eigenen Strukturen. Leistungsfähig für sehr große Dokumentationsprojekte. Zu teuer für Projekte unter mehreren Tausend Seiten. Beispiele: easyDITA, DITAToo, Vasont CMS, Schema ST4

  Konverter für bestehende Handbücher
Wandeln ein mit Word- oder FrameMaker erstelltes Handbuch in eine HTML-basierte Online-Hilfe um. Können eine kostengünstige Lösung für eine erste Version einer Online-Hilfe sein. Auf Dauer wenig effizient. Außerdem besteht die Gefahr, dass die Dokumente in Wahrheit Handbücher bleiben, auch wenn sie auf den ersten Blick wie Online-Hilfen aussehen. Beispiel: WebWorks ePublisher

  Teilautomatisierte Dokumentationslösungen für kurze schrittweise Anleitungen
Erstellen automatisch eine Serie von Screenshots, während Sie eine Handlung in der Software durchführen. Basierend auf den Screenshots und den von Ihnen in der Software durchgeführten Aktionen, erstellt das Tool dann automatisch eine Rohfassung der Dokumentation. Für eine umfassende Dokumentation nicht geeignet, jedoch eine schnelle Lösung insbesondere für kleine Handlungsanleitungen und für den Benutzer-Support. Beispiele: SnagIt, FlowShare, ScreenSteps

  Teilautomatisierte Dokumentationslösungen für GUI-Referenzen
Scannen automatisch die Ressource-Daten eines Programms und erstellen daraus Hilfe-Topics mit beschrifteten Screenshots der Benutzeroberfläche (GUI). Weitere Informationen können Sie später manuell ergänzen. Die Tools können äußerst schnell eine gewisse Grunddokumentation erstellen, wenn dafür nur minimale Zeit oder ein sehr kleines Budget zur Verfügung steht. Inhaltlich fehlen einer so generierten Dokumentation allerdings fast immer entscheidende Teile, insbesondere fehlen schrittweise Handlungsanleitungen mit einem klaren Aufgabenbezug. Beispiel: Dr. Explain

  Teilautomatisierte Dokumentationslösungen für API-Dokumentation
Scannen den Quellcode nach dort enthaltenen Kommentaren und bauen automatisch aus dem Quellcode plus den Kommentaren eine API-Dokumentation ‒ in der Regel im HTML-Format. Der große Vorteil bei diesem Ansatz ist, dass sich bei einem neuen Release der Software jederzeit mit wenig Aufwand sofort auch ein aktueller Stand der Dokumentation generieren lässt. Anders als bei den anderen Toolgruppen gibt es in diesem Bereich sehr viele gute Open-Source-Lösungen. Hauptnachteil dieser Lösungen ist jedoch, dass sich zusätzliche Inhalte meist nur schwer oder gar nicht hinzufügen lassen. Nicht selten werden teilautomatisierte Dokumentationslösungen für API-Dokumentation daher kombiniert mit Standard-Help-Authoring-Tools eingesetzt. Beispiele: Doc-O-Matic, Document! X, Sphinx, Slate

  Eigenentwicklungen
Nicht wenige Unternehmen „basteln“ sich selbst eine Lösung, um ihre Dokumentation zu generieren. Jedoch sind solche Lösungen in den wenigsten Fällen auf Dauer wirtschaftlich. In den kommerziellen Help-Authoring-Tools stecken heute so viele Jahre an Entwicklungszeit, dass sich ein solches Tool nicht nebenbei nachbauen lässt. Auch wenn anfangs manches vielleicht einfach erscheint: am Ende fehlen selbstgestrickten Lösungen fast immer entscheidende Funktionen, die die Arbeit mit einem solchen System in der Praxis erst wirklich effizient machen. Wenn Sie dann berücksichtigen, wie viel Zeit Sie gegenüber einer kommerziellen Lösung verlieren, wird eine Eigenlösung verdammt teuer! Nicht selten verlassen auch die Mitarbeiter, die eine eigene Lösung entwickelt haben, nach einiger Zeit das Unternehmen. Mit den Mitarbeitern verschwindet das Know-how zur Pflege der Lösung. Diese dümpelt dann mehrere Jahre vor sich hin, bis am Ende doch ein kommerzielles Autorenwerkzeug angeschafft wird …


Übrigens: Ist Ihnen etwas aufgefallen? Word ist nicht unter den aufgeführten Erstellungswerkzeugen. Zwar wird immer noch ein erheblicher Anteil an Softwaredokumentation mit Word geschrieben, das optimale Werkzeug hierfür ist Word jedoch nur in den seltensten Fällen.

Eine sehr umfassende Übersicht mit nahezu allen auf dem Markt verfügbaren Tools zum Erstellen von Softwaredokumentation finden Sie im Tool- und Web-Guide auf www.indoition.com. Ergänzend biete ich außerdem auch Workshops an, in denen wir gemeinsam Ihre projektspezifischen Anforderungen analysieren und dann eine Vorauswahl der auf Ihre spezielle Situation am besten passenden Tools treffen. Ich berate Sie dabei vollkommen neutral und frei von jedem Interesse, Ihnen eine bestimmte Software zu verkaufen.

Single-Source-Publishing


Viele der Erstellungswerkzeuge für Softwaredokumentation unterstützen sogenanntes Single-Source-Publishing. Darunter versteht man, dass aus derselben Textquelle (Single-Source) mehrere Zieldokumente generiert werden können: einerseits mehrere Medien ‒ z. B. ein druckbares Handbuch (PDF) und eine Online-Hilfe (HTML) ‒ andererseits und gleichzeitig auch unterschiedliche Varianten der Dokumentation ‒ z. B. die Dokumentation für eine Standard-Version und für eine Professional-Version derselben Software. In diesem einfachen Beispiel entstünden aus einer gemeinsamen Textquelle am Ende also vier Dokumente: Handbuch zur Standard-Version, Online-Hilfe zur Standard-Version, Handbuch zur Professional-Version, Online-Hilfe zur Professional-Version. In der Praxis sind es oft noch deutlich mehr Dokumente.

Bei der Ersterstellung einer Softwaredokumentation ist der
Effizienzgewinn durch das Single-Source-Publishing noch klein, denn hier könnten Sie fast ebenso schnell die Texte einfach auch kopieren. Bedenken Sie aber, dass Sie eine Softwaredokumentation in der Regel auch weiterpflegen möchten. Wenn Sie Texte kopiert haben, müssen Sie später jede Änderung an mehreren Stellen nachpflegen. Mit Single-Source-Publishing machen Sie jede Aktualisierung oder Ergänzung nur an einer einzigen Stelle: der Single-Source. Die Änderung oder Ergänzung wird dann automatisch beim nächsten Generiervorgang in alle Zieldokumente übernommen. Bei größeren Projekten kann das schnell mehrere Tage oder sogar Wochen an Aufwand sparen.

Wichtige Anforderungen an Ihr Help-Authoring-Tool


Wenn Sie die Werbeversprechen der Hersteller lesen, erscheint jedes Help-Authoring-Tool das universell beste Erstellungswerkzeug zu sein. Das ist natürlich Quatsch. Ein pauschal für alle Zwecke bestes Tool kann es gar nicht geben. Welches Tool genau für Ihren speziellen Einsatzzweck am besten geeignet ist, bedarf einer individuellen Analyse
unter Abwägung aller spezifischen Vor- und Nachteile. Folgende Punkte sollten Sie dabei unbedingt bedenken und prüfen:

  Zielformat und Qualitätsanspruch: Welche Formate muss das Tool generieren können? Wie hoch sind Ihre Anforderungen an die jeweilige Layoutqualität? Können Sie diese Qualität mit dem jeweiligen Tool mit vertretbarem Aufwand erreichen?

  Spezielle Funktionen: Benötigen Sie besondere Funktionen für Darstellung und Navigation innerhalb einer erzeugten Online-Hilfe? Können Sie diese Funktionen mit dem jeweiligen Tool umsetzen? Sind generierte Online-Hilfen auch kontextsensitiv aus Ihrer Software heraus aufrufbar?

  Menge der Inhalte: Ist das Tool in der Lage, Ihre Inhalte in der anfallenden Menge effizient und zuverlässig zu verwalten und zu verarbeiten?

  Varianten: Wie viele Varianten Ihrer Dokumentation werden Sie in absehbarer Zukunft erstellen müssen? Wie groß wird der Überschneidungs- und Verzahnungsgrad zwischen diesen Varianten sein? Wie effizient unterstützt das Tool Single-Source-Publishing einer derart aufgebauten Dokumentation? (Beachten Sie, dass die Tools hier teils erhebliche Unterschiede aufweisen, die nicht immer auf Anhieb erkennbar sind!)

  Änderungshäufigkeit: Wie häufig werden Sie Ihre Dokumente später aktualisieren müssen? Wie viel manuellen Aufwand bedeutet es, eine neue Version aller Dokumente zu generieren? Wie weitgehend sind die Layout- und Produktionsprozesse automatisierbar? Lässt sich das Generieren der Dokumente in den Build-Prozess Ihrer Software integrieren?

  Sprachen: Unterstützt das Tool alle Sprachen, in denen Sie Ihre Dokumente publizieren möchten ‒ gegebenenfalls z. B. auch asiatische Sprachen oder Sprachen, die von rechts nach links geschrieben werden? Lassen sich die Texte auch außerhalb des Tools extern übersetzen, so dass ein Übersetzer nicht selbst im Autorentool arbeiten muss? Können Übersetzer mithilfe eines Translation-Memory-Systems arbeiten, so dass bei späteren Aktualisierungen der Dokumentation nur noch die jeweils tatsächlich geänderten Textteile neu übersetzt werden müssen?

  Autoren: Passt das Tool zu den Autoren, die später damit arbeiten sollen, oder könnte das Tool auf Ablehnung stoßen? Ist das Tool einfach genug zu bedienen auch für Autoren, die nur gelegentlich Inhalte zur Dokumentation beisteuern? Können ggf. auch mehrere Personen gleichzeitig an derselben Dokumentation arbeiten?

  Prozesse: Passt das Tool zu Ihren internen Erstellungsprozessen? Bietet das Tool Unterstützung für einen Review-Prozess? Gibt es eine Versionskontrolle? Passt das Tool vom Betriebssystem und von seiner Architektur in Ihre Systemlandschaft?

  Schutz: Benötigen Sie autorenseitig oder leserseitig einen Zugriffsschutz? Lässt sich ein solcher Zugriffsschutz mit dem gewählten Tool realisieren?

  Altdaten: Müssen Sie Inhalte in das neue Tool übernehmen, die bereits mit einem anderen System erfasst wurden? Lohnt sich hierfür ein Automatismus, und wenn ja, wie gut und mit welchem Aufwand können Sie einen solchen Automatismus umsetzen?

Ergänzende Werkzeuge


Ergänzend zu den Help-Authoring-Tools gibt es noch eine Reihe weiterer Werkzeige, die Ihre redaktionelle Arbeit erheblich vereinfachen und beschleunigen können:

  Ein gutes Screencapture-Utility erstellt nicht nur Bildschirmfotos („Screenshots“ oder „Screen Captures“), es hilft Ihnen auch, diese Screenshots wesentlich effizienter zu bearbeiten, als dies mit einem Standard-Grafikprogramm möglich ist. Beispiele: SnagIt, FullShot, H@rdcopy, Greenshot

  Ein Makro-Utility hilft Ihnen beim Automatisieren wiederkehrender Aufgaben und beim schnellen Einfügen häufig benötigter Wörter und anderer Inhalte. Beispiele: AutoHotkey, AutoIt, WinAutomation, UI.Vision, PhraseExpress

  Ein gutes Search-and-Replace-Utility kann automatisiert den Output eines Help-Authoring-Tools nachbearbeiten und auf diese Weise auch Funktionen einbauen, die Ihr Help-Authoring-Tool selbst nicht unterstützt. Beispiele: Text Workbench, TextPipe, PowerGREP, TextCrawler

  Styleguides und Wörterbücher helfen Ihnen dabei, sprachlich einheitliche und richtige Texte zu erstellen. Beispiele: Knowledge Base Technische Dokumentation, WordWeb, Babylon

  Falls Sie Ihre Texte übersetzen: Ein Translation-Memory-System (TMS-System, CAT-Tool) vereinfacht die Übersetzung. Sie können die zu übersetzenden Texte nicht nur besonders bequem editieren ‒ wenn ein Teil des Texts bereits früher einmal übersetzt wurde, fügt das System diese Übersetzung sogar automatisch ein. Beispiele: SDL Trados, Transit, MadCap Lingo

Über mich und meine Leistungen

Mein Name ist Marc Achtelig. Ich erstelle seit mehr als 25 Jahren hauptberuflich Softwaredokumentation.

Als Berater für Softwaredokumentation und freiberuflicher Technischer Redakteur biete ich Ihnen unter anderem folgende Dienstleistungen:

  Optimieren bestehender Dokumentation

  Konzipieren neuer Dokumentation

  Schreiben von Handbüchern und Online-Hilfen

  Erstellen von Formatvorlagen (Templates) für Handbücher und Online-Hilfen

  Beratung bei der Auswahl von Redaktionssystemen

  Schulungen


Ausführlichere Informationen zu meinen Leistungen finden Sie bei Interesse auf meiner Hauptwebsite www.indoition.com.

Gerne helfe ich Ihnen persönlich weiter. Meine Kontaktdaten finden Sie unten. Ich würde mich freuen, von Ihnen zu hören!


Ihr
Marc Achtelig
Diese Seite ist ein Service von indoition, Ingenieurbüro für Technische Kommunikation Marc Achtelig.

Ich freue mich auf Ihre Nachricht!

Marc Achtelig
Dipl.-Ing.(FH), Dipl.-Wirtschaftsing.(FH)

Ingenieurbüro für Technische Kommunikation

Goethestr. 24
90513 Zirndorf bei Nürnberg
Deutschland

E-Mail:  info@indoition.com
Tel.:  +49 (0)911/60046-659