Wenn man sich anschaut, wie die Relevanz von Technischer Dokumentation begründet wird, gibt es ganz gegensätzliche Aussagen. (Hier etwas zugespitzt dargestellt.)
Maschinenbau: Haftungsrisiko und Kostenfaktor
Auf der einen Seite die typische Sichtweise des Maschinenbaus. Hier wird klassischerweise aus der Produkthaftung heraus argumentiert. Man muss (bzw. sollte) den entsprechenden Normen genügen. Technische Dokumentation ist daher etwas, was ich machen muss, weil ich gesetzlich dazu gezwungen bin. Die Anforderungen in den diversen Normenwerken (z.B. Maschinenrichtlinie und ISO IEC 82079) sind zum Teil recht detailliert geregelt. Und all diesen Anforderungen muss man sich nun unterwerfen.
Genau so betrachten viele Maschinenbauer dann auch die Dokumentation: Wir müssen das machen. Das kostet nur Geld. Es ist eine Pflicht. Es ist lästig. Mit geradezu fürchterlichen Konsequenzen für den Stellenwert im Unternehmen. Es ist ein reiner Kostenfaktor, und muss irgendwie, aber möglichst günstig erledigt werden. Qualität oder die Chance guter Dokumentation sind eher zweitrangig. Das Image der Technischen Dokumentation als Stiefkind kommt nicht von ungefähr.
Natürlich gibt es auch Hersteller, die hier eine ganz andere Sicht auf die Dokumente haben – ich fürchte aber, dass sie nicht in der Mehrheit sind.
Software: Integraler Produktbestandteil
Ganz anders dagegen die Betrachtungsweise bei Software. Natürlich gibt es auch hier durchaus rechtliche Verpflichtungen. Aber eigentlich ist die Dokumentation ein wesentlicher Bestandteil der Software selbst, denn ohne Anleitung ist sie nicht verwendbar. Sicher ist ein Teil einer Benutzeroberfläche auch mehr oder weniger intuitiv nutzbar, aber bei komplexeren Funktionen braucht man Hilfe. Oder stell dir eine API ohne zugehörige Dokumentation vor: Sie ist völlig nutzlos. Wie viel angenehmer für den Stellenwert der Dokumentation im Unternehmen ist diese Sicht! Hier besteht dann durchaus ein Interesse für Qualität, sowohl inhaltlich als auch bei der Bereitstellung der Dokumentation.
Zudem birgt die Dokumentation in dieser Konstellation sogar Chancen über den eigentlichen Arbeitsbereich hinaus. Die Technischen Redakteure gehören zu den ersten Testern der Software. Wenn sie beim Erstellen von Anleitungen auf Schwierigkeiten in der Bedienung stoßen, können sie Einfluss auf die Benutzeroberfläche oder die User-Workflows nehmen. Außerdem können sie während der Software-Entwicklung die Terminologie mitgestalten, also v.a. für Einheitlichkeit und Verständlichkeit sorgen.
Voneinander lernen
Nun ist die Welt nicht schwarzweiß, und natürlich sind nicht alle Maschinenhandbücher schlecht und alle Software-Dokus toll. Ganz im Gegenteil. Aber immer wenn ich die total einseitige Haftungsrisiko-Brille in der maschinenbau-nahen Dokumentation sehe, finde ich diese Sichtweise doch etwas einseitig. Technische Dokumentation kann mehr sein als ein Kostenfaktor! Sie hilft dem Kunden, kann Supportkosten verringern und die Kundenzufriedenheit erhöhen. Wenn man sie richtig macht.
Und in der Software-Welt: Hier kann man durchaus von den Normen lernen. Indem man sie als Empfehlung oder Best Practice betrachtet. Nicht um sich sklavisch daran zu halten, sondern damit man das Rad nicht immer neu erfinden muss.