Jegliches Qualitätsmanagement wird oft mit Dokumentation gleich gesetzt. Letzt wurde mir gegenüber sogar die Meinung geäußert, die NASA würde hohe Qualität erzielen, weil sie soviel dokumentiert. Nun, die NASA erreicht sicherlich beeindruckend hohe Qualität. Wann wird schon mal ein hochkomplexes Stück Software ausgeliefert, dass in der ersten Version über Jahre ohne wesentliche Fehler läuft? Für die Weltraumtechnik ist dies eine Standardanforderung, den auf dem Weg an den Rand des Universums ist es schwierig mal einen USB Stick mit einer neuen Version einzuspielen.

Aber ist das wesentliche an dem QM-System der NASA wirklich die Dokumentation? Ich denke nicht. Eine der großartigsten Leistungen der NASA, die Landung auf dem Mond ist so schlecht dokumentiert, dass sie dieses Projekt nicht einfach wiederholen könnten, selbst wenn sie jemanden finden würden, der sich in eine Rakete auf dem technischen Stand der späten 60ern setzen würde. (Das würden die wahrscheinlich noch hinbekommen).

Eine Softwarearchitektur wird nicht besser, dadurch dass ich sie dokumentiere. Das gleiche gilt für Testkonzepte, Designentscheidungen, Projektpläne und was sonst noch gerne in digitale oder analoge Dokumente gegossen wird. Wichtig ist bei all diesen Konzepten und Plänen, dass sie

1. Selbst hohe Qualität haben
2. Jeder, dessen Arbeit darauf basiert, sie in der aktuellen Form kennt.
3. von allen Betroffenen berücksichtigt werden.

Beim ersten Punkt hilft die Dokumentation kein bisschen. Was hilft sind hochqualifiziert, motivierte Mitarbeiter, die die entsprechenden Konzepte erstellen, und eben solche Mitarbeiter, die die Arbeitsergebnisse Reviewen um Fehler und Lücken zu erkennen und zu vermeiden. Es helfen auch Vorgaben, wie solche Arbeitsergebnisse aussehen sollen, damit der Ausführende nicht aus versehen ein Softwaredesign erstellt, wenn er mit einer Systemarchitektur beauftragt wird.

Beim 2. Punkt KANN Dokumentation helfen. Wenn es aber die Teamstruktur (Verteilung und Größe) erlaubt ist es oft besser einfach mit einander zu sprechen und das Arbeitsergebnis direkt verbal zu kommunizieren. Sprich: redet miteinander! Wenn ich meinem Team sage, dass das Pflichtenheft in Verzeichnis X liegt werden 80% der Mitarbeiter das Dokument allenfalls überfliegen. Wenn ich will, dass es jedes Teammitglied kennt, muss ich es mit dem Team durchsprechen. Ja, das wird ein langes Meeting und es kostet eine Menge Geld. Wenn aber alle das Dokument lesen und verstehen sollen müssen, sie diese Zeit ebenfalls aufwenden.

Beim 3. Punkt hilft die Dokumentation wieder überhaupt nicht. Was hilft sind Reviews und die Ãœberzeugung aller Beteiligten, dass die getroffenen Entscheidungen sinnvoll und richtig sind. Und dies erreicht man, wenn die Beteiligten miteinander sprechen.

Die Dokumentation eines Projektes hilft jedoch im Nachgang, wenn Projekte analysiert werden sollen, um daraus Lehren für die Zukunft zu ziehen, und auf diese Weise kann Dokumentation wirklich einmal zur langfristigen Qualitätsverbesserung beitragen.

Also, wenn ihr dokumentiert oder Dokumentation fordert oder vorschreibt, stellt euch immer erst die Fragn

1. Kann ich es auch in direkter mündlicher Kommunikation erledigen?
2. Kann ich die Dokumentation kürzer fassen, ohne wesentliches zu verlieren
3. Wer wird die Dokumentation, mit welchem Ziel lesen?

"Aber die Norm XY verlangt doch, dass ich dies oder jenes dokumentiere!" höre ich da vor allem von Bekannten, die in großen Konzernen arbeiten. Dies ist in 95% der Fälle ein Irrtum. Prozesse sollten wohl sinnvoller Weise dokumentiert sein. Ansonsten wird recht wenig Dokumentation explizit gefordert. Was gefordert wird, ist typischer Weise dass bestimmte Dinge geplant werden, bevor sie durchgeführt werden, und das dies  NACHVOLLZIEHBAR ist. Aber gerade in der Softwarebranche lassen sich viele Dinge implizit dokumentieren:

• Architekturentscheidungen können durch Tests dokumentiert werden (keine Zyklen, nur bestimmte Abhängigkeiten zwischen Schichten ...). In der Tat würde ich in den meisten Fällen Architekturentscheidungen, die nicht durch Tests abgedeckt sind anzweifeln, denn hat wirklich die Möglichkeit sämtlichen Code intensiv zu reviewen.
• Ein Testplan und Testkonzept kann durch zunächst noch leere Testsuites dokumentiert werden.

und ich bin mir sicher mit ein bischen nachdenken lassen sich noch viel mehr Dinge finden.

Für den Rest, macht es so einfach wie möglich. Wenn zum Beispiel die verwendeten Komponenten von Drittanbietern separat dokumentiert werden, können die Standardkomponenten schon in der Liste stehen, so dass dort nur nicht zutreffendes gestrichen und exotisches ergänzt werden muss.

Dokumentation ist ein notwendiges Ãœbel, nicht Sinn und Zweck des Qualitätsmanagements.