Die Redaktion ist gefragt

Wie dem auch sei: Ganz in der Nähe der klassischen Technischen Redaktion, die sich um Informationen und Dokumente zur Produktanwendung kümmert, entstehen in Industrieunternehmen Dokumente, die Ihren sehr ähnlich sind. Zwar fokussieren sie nicht die Phase „Anwendung“ im Produktlebenszyklus, sondern die frühere Phase der „Entwicklung“. Auch enthalten sie keine Handlungsanweisungen oder ANSI-konformen Warnhinweise. Aber es geht um die Dokumentation von Leistungsmerkmalen und Eigenschaften von Produkten. Dokumentiert wird – vielleicht sollte ich schon einschränken „sollte werden“ – mit ganz ähnlichen Verfahren und technischen Standards, wie wir sie aus der Technischen Redaktion kennen.

Diese Nähe ist Grund genug, diese Dokumente genauer anzusehen: Wo liegen die Gemeinsamkeiten zur klassischen Technischen Dokumentation? Wo die Besonderheiten? Was sind die speziellen Fallstricke, wenn man es mit Lasten- und Pflichtenheften zu tun bekommt?

Festlegen, was werden soll

Schauen wir uns zunächst die Funktion von Lasten- und Pflichtenheften ein bisschen genauer an. Es handelt sich um so genannte Spezifikationsdokumente. Darin wird festgehalten, was ein noch zu entwickelndes Produkt leisten soll, wie es funktioniert und wie der Entwicklungsprozess dazu aussehen soll. „Noch zu entwickelnd“ deutet es schon an: Lasten- und Pflichtenhefte entstehen vor der Produktentwicklung. Sie dokumentieren aus einer Vorab-Perspektive den gewünschten Soll-Zustand des fertigen Produkts am Ende des Entwicklungsprozesses.

Lassen Sie uns das Mit- und Nebeneinander von Lasten- und Pflichtenheften an einem Beispiel beleuchten. Ein Autobauer möchte von einem Zulieferer eine neue Klimaanlage entwickeln lassen. Der Autobauer ist hier der Auftraggeber und erstellt deshalb das Lastenheft. Darin legt er seine Anforderungen an die Klimaanlage fest: die Klimatisierungsleistung, die Baugröße, die Schnittstellen und was sonst aus seiner Perspektive als Auftraggeber das Produkt unbedingt leisten und bereitstellen muss.

Der Auftragnehmer – der Automobilzulieferer – beantwortet die Anforderungen in einem Pflichtenheft. Darin legt er nieder, wie er die Anforderungen seines Auftraggebers umsetzen wird. Welches Material setzt er ein, um die Gewichtsvorgaben zu erreichen? Welche Stellmotoren für Klappen kommen zum Einsatz, um die geforderte Reaktionsschnelligkeit zu gewährleisten?

Komplexes erfolgreich meistern

Was unser Beispiel schon zeigt: Lasten- und Pflichtenheft nutzt man vor allem dann für die Produktspezifikation, wenn es sich um Entwicklungsprojekte mit einem erhöhten Erfolgsrisiko handelt. Für die Beschaffung einer PC-Maus würde wohl niemand ein umfangreiches Lastenheft erstellen. Da dürfte der sprichwörtliche Bierdeckel reichen, um die Wünsche des Auftraggebers festzuhalten. Wenn es aber um umfangreiche oder komplexe Produktentwicklungen geht, in denen viele Details erfolgsentscheidend sind, wenn es noch gar keine Standardlösung auf dem Markt gibt, dann schlägt die Stunde der Lasten- und Pflichtenhefte.

Häufig ist damit ein Missverständnis verbunden, nämlich dass diese nur der rechtlichen Absicherung dienen würden. Es geht aber um viel mehr, nämlich Vertrauen und Transparenz: Das Wissen, was der andere erwartet oder leisten wird. Und die Zuversicht, dass man als Partner das erfolgreich umsetzen kann, was nach intensiver Beratung und Diskussion schriftlich niedergelegt wurde. Denn das ist ja das Ziel: ein neues, vielleicht noch nie da gewesenes Produkt. Das natürlich dem entsprechen muss, was in Lasten- und Pflichtenheft vereinbart wurde.

Oft werden Lasten- und Pflichtenhefte auch dann eingesetzt, wenn Auftraggeber und Auftragnehmer aus demselben Unternehmen kommen. Ein typischer Fall ist ihre Anwendung in Innovationsprojekten: Da möchte der Vertrieb für seine Kunden ein neues Produkt auf den Markt bringen. Seine Wünsche an dieses Produkt dokumentiert er in einem Lastenheft. In diesem Szenario ist der Vertrieb der Auftraggeber. Und die Entwicklungsabteilung als unternehmensinterner Auftragnehmer erstellt das Pflichtenheft, das inhaltsreicher und technischer ausfallen wird als das Lastenheft.

Von der Redaktion lernen

So weit ein kurzer Abriss zur Funktion von Lasten- und Pflichtenheften. Auch wenn diese Funktion ganz anders gelagert ist als die der Anwenderdokumentation, die wir als Technische Redaktionen täglich erstellen: Was wir aus unserem Umgang mit Dokumentation und Dokumenten aus dem Effeff beherrschen und oftmals wahrscheinlich blind anwenden, ist auch für Spezifikationsdokumente wichtig. Die Erfahrung aus der Beratung zeigt, dass die Entwicklungsabteilungen viel von der Technischen Redaktion lernen können, um die Qualität und damit den Erfolg ihrer Lasten- und Pflichtenhefte zu steigern.

Wo also hakt es häufig bei Lasten- und Pflichtenheften? Was müssen diese Dokumente mitbringen, damit sie gut funktionieren?

Am Anfang steht die Gliederung

Ganz ähnlich wie in eher hemdsärmelig erstellten Handbüchern mangelt es vielen Lasten- und Pflichtenheften zunächst an einer sauberen Gliederung. In einem meiner Lieblingsbeispiele, das ich in Workshops gerne verwende, stößt man im Inhaltsverzeichnis auf eine Kapitelfolge, die aus einem Lastenheft zu einer Produktionsanlage stammt:

• 7. Technische Beschreibung der Maschinenmodule
• 8. Funktionsablauf
• 9. Inbetriebnahme der Anlage vor Ort
• 10. Bedienung und Wartung

All diese Themen sind in einem Lastenheft gut aufgehoben. Aber sicher juckt es Ihnen wie mir in den Fingern, in die Gliederung eine logische Ordnung zu bringen. Der „Funktionsablauf“ gehört nach vorne – es geht um eine grundlegende Information zum Produktionsprozess der spezifizierten Anlage. Dann folgt der Blick auf die Komponentenstruktur der Anlage („Technische Beschreibung der Maschinenmodule“), dem logisch nachgeordnet ist der Punkt „Bedienung und Wartung“. Das Thema „Inbetriebnahme“ gehört an den Schluss nach dem Motto: „Nachdem ich jetzt klargemacht habe, was ich technisch-inhaltlich fordere, widme ich mich den Details zum Ablauf des Entwicklungsprojektes – im konkreten Fall dem Verfahren der Inbetriebnahme“.

Das Beispiel zeigt, wie ein Mangel an Logik die Gliederung eines Lasten- oder Pflichtenhefts im Grunde unbrauchbar macht. Auch wenn alle Inhalte innerhalb der Kapitel zu 100 Prozent korrekt sind: Wenn ich nicht weiß, was ich wo finde, kann ich mit einem Dokument nicht arbeiten – und Lasten- und Pflichtenhefte sind in hohem Maß Arbeitsdokumente. Oft liest man sie einmalig ganz, um danach gezielt auf ausgewählte Detailinformationen zurückzugreifen. Und das funktioniert nur, wenn klar geregelt ist, was wo steht. Je umfangreicher ein Dokument wird, desto wichtiger ist diese strukturelle Sicherheit (Abb. 01).

Das gilt im Übrigen nicht nur für die Leser der Dokumente. Auch wer Lasten- und Pflichtenhefte erstellt, braucht Klarheit, was er an welcher Stelle dokumentiert. Sonst kann es leicht passieren, dass Themen mehrfach behandelt werden oder gar nicht. Das ist nicht nur unpraktisch und lästig, sondern kann bei der Produktspezifikation richtig problematisch werden. Ich erinnere mich gut an ein Lastenheft, in dem die zulässige Toleranz für dieselbe Produkteigenschaft an einer Stelle mit 0,2 mm und an anderer Stelle mit 0,4 mm festgelegt war. Die Dopplung und die abweichende Spezifikation waren vorher niemandem aufgefallen, einfach deswegen, weil es keine standardisierte Gliederung für das Lastenheft gab.

Abb. 01 Absolutes Muss: Eine logisch geordnete Gliederung, die wachsen kann. Hier die Gliederung für ein Lastenheft zur Anlagenbeschaffung. Quelle Johannes Dreikorn

Keine Lösungen von der Stange

Entwicklungsabteilungen ist der Bedarf an Standardisierung in der Regel bewusst. Aber gerade bei der Standardisierung der Gliederung sind viele schon auf die Nase gefallen. Kurzerhand wurde eine Vorlage aus dem Internet heruntergeladen oder aus einer Norm kopiert, was im Ergebnis die Verzweiflung eher noch gesteigert hat. Versucht man zum Beispiel, ein Spezifikationsdokument für Produktionsanlagen (Schwerpunkt auf Mechanik, Komponenten, Produktionsprozesse) auf Basis einer Mustergliederung für ein Software-Lastenheft zu erstellen, wird das Vorhaben zwangsläufig scheitern.

Wenn Sie als Technische Redakteurin oder Redakteur mit der Konzeption von Dokumenten zu tun haben, werden Ihnen diese Fragestellungen nicht fremd sein. Man kann trotz aller sinnvollen Standardisierungsvorgaben nicht von vornherein sagen, wie ein Dokument richtig aufgebaut ist. Das gilt für die Anwenderdokumentation wie für Spezifikationsdokumente in der Produktentwicklung. Und so überrascht es mich mittlerweile nicht mehr, dass in meinen Beratungs-Workshops je nach Unternehmen und Kontextfaktoren wie der Produktart oder der beteiligten Partner ganz unterschiedliche Dokumente entstehen – aber alle sind funktionierende Lasten- oder Pflichtenhefte.

Da bekommt zum Beispiel ein Unternehmen von seinem Auftraggeber ein 300-seitiges Lastenheft in Vollprosa vorgelegt. Es spezifiziert in 1.200 einzelnen Anforderungen, welche Vorgaben der Kunde für einzelne Produkteigenschaften erfüllt sehen möchte. Die Lösung für das Pflichtenheft kann kaum darin bestehen, ein noch längeres Dokument als „Antwort“ zu erstellen. Niemand hätte die Zeit dafür. Zudem würde ein solches „Monster“-Dokument im weiteren Entwicklungsprozess nicht weiterhelfen.Und so etablieren wir für dieses Unternehmen ein Pflichtenheft, das aus zwei Dokumenten besteht:

• Inhaltliches Herzstück ist eine Excel-Tabelle, die jede Anforderung des Auftraggebers in einer eigenen Zeile listet. Die Antwort des Auftragnehmers steht maximal prägnant „hinter“ der dazugehörigen Anforderung des Auftraggebers in der zweiten Spalte der Excel-Tabelle. So ist einem ganz grundlegenden Anspruch an Pflichtenhefte Genüge getan, nämlich dass ein Pflichtenheft jede Anforderung aus dem Lastenheft explizit berücksichtigt. Aber eben in einer Form, die maximal prägnant ist und sich mit wenig Aufwand pflegen lässt.
• Neben der Excel-Tabelle erstellt der Auftragnehmer ein kurzes Rahmen­dokument. Es enthält die Zusagen, Hinweise und Einschränkungen, die konzeptionell in der Excel-Tabelle keinen Platz finden, die dem Auftragnehmer aber wichtig sind. Im Gegensatz zu einem „klassischen“ Pflichtenheft ist dieses Dokument sehr kurz gehalten – denn die Details für die technische Spezifikation sind ja in der Excel-Tabelle dokumentiert.

Erfolge durch eine saubere Konzeption

Das Beispiel zeigt: Wie in der uns vertrauten Anwenderdokumentation kommt man nur dann zu funktionierenden Spezifikationsdokumenten, wenn man sich erst einmal planerisch mit diesem speziellen Dokumenttyp auseinandersetzt. Dabei stellen sich genau dieselben Fragen, die wir uns als Technische Redakteure vornehmen müssen, zum Beispiel bei der (Neu-)Konzeption einer Online-Hilfe.

• Was sind meine Ziele als „Produzent“ des Dokuments? Umgemünzt auf ein Lastenheft bedeutet das zum Beispiel: Möchte ich als Auftraggeber meinem Auftragnehmer viel oder wenig Lösungsspielraum einräumen? Entsprechend lösungsoffen oder restriktiv werde ich mein Lastenheft auslegen. Entsprechend unterschiedlich fallen Art und Umfang der Inhalte aus. Entsprechend unterschiedlich sind die Anforderungen an die Gliederung (Abb. 02).
• An wen richtet sich mein Dokument? Wer sind die Konsumenten und Stakeholder, die das Dokument bejahen und freigeben müssen? Wenn ein Auftragnehmer zum ersten Mal für einen Kunden (Auftraggeber) arbeiten möchte, wird er mit seinem Pflichtenheft wahrscheinlich nicht nur die „Techniker“-Fraktion des Kunden überzeugen müssen, sondern auch Entscheider. Wie kann ich deren Informationsbedürfnisse systematisch mit berücksichtigen?
• Welchen Lebenszyklus wird das Dokument durchlaufen? Handelt es sich um ein Lastenheft, das nur am Anfang des Produktspezifikations­prozesses benötigt wird? Oder soll das Konzept für ein Dokument entstehen, das über mehrere Stationen und Spezifikationsphasen wachsen kann? (Abb. 03)

Abb. 02 Bei wem liegt die Design-Verantwortung für ein neues Produkt? (1) Beim Auftraggeber: Dann gibt er fast alles vor und erstellt ein entsprechend lösungsorientiertes Lastenheft, dem der Auftragnehmer im Pflichtenheft fast nichts mehr hinzufügen kann. (2) Beim Auftragnehmer: Dann hält sich der Auftraggeber bewusst zurück. Und der Auftragnehmer kann seine ganze Innovationskraft zeigen. Quelle Johannes Dreikorn

Abb. 03 Konzeption für ein Pflichtenheft, das über den Spezifikationsprozess hinweg wachsen kann. Version 1 dient der noch unverbindlichen Abstimmung mit dem Auftraggeber. Version 2 ist Grundlage für das Angebot. Und Version 3 adressiert nicht mehr den Kunden, sondern die Umsetzer der in Version 2 zugesagten Lösung. Quelle Johannes Dreikorn

Raum für Details

In Lasten- und Pflichtenheften wimmelt es normalerweise von Details. Kein Wunder, es soll ja ein neu zu entwickelndes Produkt spezifiziert werden. Und zwar in allen Dimensionen und mit allen Eigenschaften, die aus der Vorab-Perspektive heraus erfolgsentscheidend sind. Sehen wir uns eine Produktionsanlage an. Neben Eigenschaften wie Größe und Gewicht geht es um die Spezifikation des Produktionsprozesses, den Aufbau in Arbeitsstationen mit jeweils Anforderungen an Mechanik, Pneumatik, Elektrik, Steuerung und Bedienung. Dazu kommen die gewünschten Leistungswerte und natürlich die grundsätzlichen Rahmenbedingungen wie Normkonformität und Energieeffizienz – und das sind noch nicht einmal alle relevanten Themen.

Schnell entstehen so Dokumente mit einem Umfang von 30 bis 100 Seiten. Fast jede Seite ist gespickt mit Detailinformationen. Sie alle sind wichtig und dürfen nicht übersehen werden.

Sieht man als Technischer Redakteur typische Lasten- und Pflichtenhefte durch, entdeckt man oft einen Fehler, den wir auch aus der klassischen Anwenderdokumentation gut kennen: Inhaltlich mag jede Information korrekt sein, aber die Details stehen undifferenziert nebeneinander. Wie schon bei der besprochenen Gliederung mangelt es an Struktur – auch unterhalb der Kapitelebene bei der Aufbereitung der konkreten Inhalte.

Dazu ein Beispiel, das diesen strukturellen Mangel schön illustriert. Es geht um das Lastenheft zu einem Outdoor-Notebook, speziell um die Anforderungen an das Display:

„Das Display muss mindestens 13 Zoll groß sein. Im Bereich der Leuchtstärke ist ein Wert von 1000 cd/m² zu erreichen. Außerdem wird für das Display eine Ausführung als Touchscreen zur mauslosen Bedienung gefordert.“

Lege ich in einem Workshop Entwicklern dieses Beispiel vor, ist das Urteil meist einhellig: Zu viel Prosa, zu umständlich formuliert. Obwohl es sich nur um drei Sätze handelt, weiß man am Ende des letzten Satzes nicht mehr, was im ersten stand.

Lasse ich die Runde dann eine bessere Lösung erarbeiten, bekomme ich in über 90 Prozent der Fälle eine Tabelle vorgelegt. Meist ganz einfach mit zwei Spalten – Spalte 1 ist zum Beispiel mit „Merkmal“ betitelt, Spalte 2 mit „Spezifikation“. Die Tabellenzeilen sind ebenso einfach ausgeführt und bestehen meist nur aus Schlagwörtern, zum Beispiel „Größe – min. 13 Zoll“.

Klassifiziert und strukturiert

Intuitiv machen Ingenieure und Entwickler als tendenziell ungeübte Schreiber das, was wir Technischen Redakteure als Textprofis auch tun würden. So wie wir in einer Handlungsanweisung Informationen klassifizieren als „Handlungsschritt“, „Anweisung“ und „Resultat“ und diese entsprechend strukturieren und darstellen, so benötigen Entwickler in Spezifikationsdokumenten eine für den Verwendungszweck passende Klassifikation für Produkteigenschaften.

Was in der Theorie klar ist, wird in der Praxis aber oft nicht gemacht. Und so sehe ich in der Vorbereitung zu Workshops ganz oft Lastenhefte und Pflichtenhefte durch, die fast nur aus Fließtext bestehen. Im Workshop ist dann spannend zu sehen, wie sich die Autoren in ihren eigenen Dokumenten nicht mehr zurechtfinden. Auch dann nicht, wenn sie zuletzt am Vortag daran gearbeitet haben.

Stellen wir wie im Beispiel unserer Outdoor-Notebooks die Inhalte um auf eine strukturierte Darstellung, ändert sich das sofort. Man kann endlich selbst nachvollziehen, was man dokumentiert hat. Obwohl man Wörter spart, wird das Ergebnis klarer. Auch wird über die strukturelle Standardisierung erst greifbar, wo sich noch Lücken in der Spezifikation befinden. Ist eine wesentliche Anforderung vergessen? Oder gibt es Anforderungen, die zu unspezifisch gefasst sind nach dem Motto „Das Display sollte über eine hohe Kratzfestigkeit verfügen“? In einem Fließtext geht das unspezifische „sollte“ schnell unter. In einer Tabelle sieht man hingegen auf einen Blick, dass keine konkrete Größe genannt ist. Die leere oder mit der Floskel „sollte“ bestückte Tabellenzelle schreit förmlich nach mehr Eindeutigkeit.Letztlich sorgt eine strukturierte Informationsaufbereitung in der Anwenderdokumentation wie auch in Lasten- und Pflichtenheften dafür, dass Dokumente

• leichter erstellt werden können, auch im Team und über längere Zeiträume.
• ergänzt und gepflegt werden können; das vermittle ich Ingenieuren gerne als „Wartungsfähigkeit“ von Dokumenten, die sie für ihre Maschinen ganz selbstverständlich fordern.
• ein einheitliches Gesicht bekommen, man das Rad nicht immer neu erfinden muss und Inhalte wiederverwendbar werden; an dieser Stelle stehen Entwicklungsabteilungen vor den gleichen Hürden wie Technische Redaktionen.
• ihre Funktion erfüllen, indem sie von den Adressaten verstanden und zielgerichtet verwendet werden können. Wie schon gesagt: Lasten- und Pflichtenhefte sind in hohem Maße Arbeitsdokumente.

Das Ganze hat das Ziel, dass der Entwicklungsprozess optimal unterstützt wird und am Ende hinter jeder erfüllten Anforderung (Lastenheft) oder jeder umgesetzten Leistungszusage (Pflichtenheft) ein Häkchen gesetzt werden kann. Auch das setzt natürlich voraus, dass die Inhalte klassifiziert, strukturiert und unterscheidbar sind.

Es gibt viel zu tun

Zurück zum Anfang: Haben Sie als Technische Redakteurin oder Redakteur schon einmal ein Lastenheft oder ein Pflichtenheft in der Hand gehabt? Es vielleicht auch schnell wieder verzweifelt weggelegt?

Wie dem auch sei, die Erfahrung zeigt, dass auch Spezifikationsdokumente in die Hände von Textprofis gehören. Vielleicht nicht immer in der konkreten Erstellung – das müssen wohl oft die Ingenieure und Entwickler selbst erledigen –, zumindest aber mit Blick auf Konzeption und Standardisierung. Und wo, wenn nicht in den Technischen Redaktionen, ist diese Kompetenz zu finden?

Der Bedarf an standardisierten Entwicklungsprozessen und damit auch der Bedarf an Lasten- und Pflichtenheften in Unternehmen steigt. Die Erfahrung macht deutlich: Wo Entwicklungsabteilungen analog zu Technischen Redaktionen zielgerichtet und maßvoll in die Standardisierung investieren, entstehen die gleichen positiven Effekte wie in den Technischen Redaktionen: schnellere Reaktionszeiten, mehr Zeit für die erfolgsentscheidenden Aufgaben und eine viel bessere Kosten-Nutzen-Struktur.