Prioritäten in der Technischen Dokumentation: Von Hasen und Igeln

Natürlich sind zunächst einmal alle Projekte in der Technischen Dokumentation dringend. Ganz dringend. So zumindest nach Kundenaussage. Und falls sie nicht sehr dringend sind, dann liegen sie durch Verschleppung und mangels Berücksichtigung so lange herum, bis sie ganz dringend werden. Das ist das Schicksal aller selbstständigen Redakteure: Sie haben keinen Einfluss auf die Terminplanung der Kunden. Andererseits ist das auch meist gar nicht nötig. Denn in der Technischen Dokumentation sollte nach Wichtigkeit und nicht nach Dringlichkeit priorisiert werden.Dringlichkeit ist eine Reihenfolge nach Terminen. Und je näher ein Termin rückt, desto dringlicher werden die Aufgaben, die bis zu diesem Zeitpunkt erledigt werden müssen. Aber nicht alle Aufgaben sind gleich wichtig, denn manche Aufgaben erledigen sich von selbst, andere sind Voraussetzungen für nachfolgende Schritte. So kann beispielsweise die Abgabe einer Dokumentation auf Englisch nicht vor der Freigabe der Dokumentation auf Deutsch erfolgen – außer der Übersetzer arbeitet gerne doppelt.

Was aber ist wichtig? Welche Tätigkeiten müssen unbedingt erfolgen, um andere Tätigkeiten überhaupt erst auszulösen? Welche Tätigkeiten können zu einem beliebigen Zeitpunkt erfolgen, weil sie keine Schritte voraussetzen oder keine bedingen?

Hier kann sich ein Technischer Redakteur das Leben erstaunlich einfach machen: Technische Dokumentationen haben nämlich eine innere, eine quasi systemimmanente Abfolge aus Handlungsblöcken, die in einer bestimmten Reihenfolge aufeinander folgen müssen:

1. Aufwandsabschätzung. Angenommen, die Akquise ist erfolgreich gewesen oder es handelt sich um einen Folgeauftrag, muss zuerst für die Zeitplanung eine Aufwandsabschätzung erfolgen, die man dem Kunden auch mitteilt. Nicht nur, weil sich daraus der Preis der Dokumentation ermitteln lässt, sondern auch der ungefähre Zeithorizont der Fertigstellung.
   Für eine Aufwandsabschätzung, die in der Technischen Dokumentation nicht besonders einfach ist, weil meist viel zu viele Unsicherheiten bestehen, zerlegt man am Besten den Dokumentationsprozess in kleinere Schritte. Beispielsweise nach Kapiteln, zusätzlicher Recherche, Ortstermine, Vorlagenerstellung und was sonst noch zum Projekt gehört. Diese Schritte werden dann mit einem ungefähren Stundenaufwand versehen und addiert.
2. Bestellung. Jetzt kommt es zum Schwur: akzeptiert der Kunde die Aufwandsabschätzung, kann daraus eine Bestellung werden. Diese sollte so detailliert sein, dass wie in einem Pflichtenheft eine Festlegung des Umfangs möglich ist, auf den man sich im Zweifelsfall immer zurückziehen kann („Das war nicht bestellt. Da müssen wir noch ein paar Stunden draufpacken …“), um nicht bei Rechnungsstellung böse Überraschungen zu erleben. Und auch, weil darin der voraussichtliche Liefertermin erkennbar ist, der von beiden Seiten angenommen wird.
   Nun gibt es immer wieder Projekte, die so dringend sind, dass das kundenseitige Bestellwesen nicht nachkommt, weil es zwar beim Projektleiter brennt, die Buchhaltung aber nach einem anderen Zeitplan arbeitet. Da ist Abwägung gefragt: bei großen Unternehmen sollte man bis zur Bestellung keine weitere Zeit investieren, ohne Gefahr zu laufen, dass man seinem Geld hinterherläuft. Bei mittelständischen Unternehmen lässt sich über eine Zusage per E-Mail schon reden.
3. Recherche und Erstellung. Der Technische Redakteur ist kein Märchenonkel, der sich die Inhalte einer Dokumentation bei Kerzenschein aus den Fingern saugt. Er braucht kompetente und verlässliche Ansprechpartner beim Kunden. Ein Programmierer, der aus reiner Hilfsbereitschaft schon mal 80 Screenshots schickt, ohne dass diese so überhaupt im Programm verwendet werden, ist genauso unsinnig wie die kommentarlose Überlassung von CAD-Modellen oder Bauteilzeichnungen. Der Redakteur ist nicht der Konstrukteur, selbst wenn er Ingenieur sein sollte. Der Redakteur kennt das Produkt nicht – das ist sein Stärke, nicht sein Manko. Er muss fragen. Und er muss sich darauf verlassen können, dass die Antworten korrekt sind.
   Manchmal fragt er sogar mehrmals das Gleiche, weil es dazu in einem anderen Zusammenhang Gesichtspunkte gibt, die für die Dokumentation an anderer Stelle wichtig sein können. Das ist keine Dummheit, das ist sein Job.
4. Korrekturläufe. Gerne vernachlässigt, aber immens wichtig. Selbst wenn während der Erstellung eigentlich schon alles gesagt wurde, dient die Korrekturfassung der beiderseitigen Kontrolle, ob alles so verstanden wie kommuniziert wurde. Auch ist die Korrekturfassung eine Übersicht der kompletten Dokumentation. Eine Kontrolle, ob die „innere Logik“ schlüssig ist, ob der Benutzer der Dokumentation auch die Informationen finden kann. Nichts ist schlimmer, als wenn wenn sich beispielsweise wichtige Informationen zu Anziehdrehmomenten an drei Stellen in der Dokumentation wiederfinden – und dann noch einander widersprechen.
5. Freigabe. Ohne Freigabe keine Übersetzung und keine Rechnung. Jetzt kann es natürlich sein, dass der Kunde bereits mit der letzten Korrekturfassung zufrieden ist und sie quasi implizit freigibt, indem er sich nicht weiter meldet. So ehrenvoll das sein mag, für den Redakteur bedeutet das, dass er auf einer unvollständigen Lieferung sitzen bleibt, weil er sich nicht auf eine Fertigstellung berufen kann. Um dem Auftraggeber die Angst zu nehmen, er müsse bei späteren kleinen Änderungen nochmals tief in die Tasche greifen, bleibt auch für den Redakteur die Gewährleistungspflicht: Er hat sich verpflichtet, nach bestem Wissen und Gewissen eine Dokumentation zu erstellen, die den aktuellen Normen entspricht. Wenn dabei Fehler entstehen (und das ist nur menschlich), dann kann er in geringem Umfang zur Nachbesserung verdonnert werden – ohne dies in Rechnung stellen zu können. Selbst wenn also die Dokumentation freigegeben und die Rechnung gestellt (und hoffentlich) auch bezahlt wurde, ist der Redakteur als Dienstleister noch nicht aus dem Schneider.

Diese fünf Eckpunkte legen die Priorisierung der dahinter stehenden Tätigkeiten fest. Aus ihnen ergibt sich dann auch die Terminierung der Aufgaben – und damit die Dringlichkeit.

Für ein Projekt mag sich das noch banal anhören, wirklich komplex wird es bei 10–15 gleichzeitigen Projekten, die natürlich alle dringend sind. Hier entsteht noch ein zusätzlicher Punkt: Wo und wie bedingen sich diese Projekte gegenseitig? Gibt es Projekte, die ab einem gewissen Stadium (beispielsweise den Korrekturläufen) schon das nächste möglich machen? Oder verdoppelt eine solche Überlappung den Korrekturaufwand? Lassen sich Tätigkeiten zusammenfassen, die für alle Projekte wichtig sind, wie beispielsweise die Erstellung eines Impressums oder die Festlegung der Kapitelreihenfolge?

Zusammengefasst

Bei allen Überlegungen sollte man nicht übersehen, dass wir Redakteure Menschen sind, keine Maschinen. Wir sind selbst bei hochgradiger Effizienz nur von beschränkter Einsicht in die Produkte des Auftraggebers. Und wir sind mehr oder weniger anfällig für Überlastung und Irrtümer. Das sollten wir uns eingestehen und – wie es ein guter Projektplaner auch macht – Puffer einplanen. Entweder, indem wir Zeitfenster öffnen, oder indem wir unsere Kapazitäten nach unten rechnen (75% ist da ein annehmbarer Wert). Von jeder Stunde, die wir verplanen, sind 15 Minuten nicht unmittelbar auf das Projekt anrechenbar. Das ist die Zeit, die wir brauchen, um eine Telefonnummer zu suchen, einen Kaffee zu holen, eine neu eintreffende Mail zu lesen und abzulegen, die nächsten Tätigkeiten zu planen oder einfach nur mal das Getane zu revidieren.

Dies muss in die Priorisierung mit einfließen, denn es sind wichtige Schritte. Sonst werden sie nämlich dringend.