Dokumentieren, aber was und wann?

Veröffentlicht auf 6. Januar 2015

Auch wenn die aktuelle Entwicklung hin zu eher weniger Dokumentation geht, wird immer noch fleißig dokumentiert. Vorgehen, Regeln, Prozesse, Software, Frameworks, Methoden, Handbücher usw.

Oft wird dabei von Vorgesetzten gefordert, dass z.B. Regeln eines neuen Frameworks erst dokumentiert und dann umgesetzt werden. Schliesslich muss man ja festlegen, was wie geschehen soll. Oder ein neuer Prozess muss erst beschrieben werden, bevor er eingeführt werden kann.

Wirklich?

Von Vorteil ist sicherlich die Einheitlichkeit und das man sich schon einmal mit der Materie befasst hat. Aber eben leider nur gedanklich. Ausnahmen bestätigen die Regel, vielleicht ist eine Regel in der Praxis aber weniger sinnvoll? Meistens stellt sich auch ein definiertes Vorgehen bei der Umsetzung als vollkommen unpraktisch heraus, eine Alternative aber als brauchbar. Dann muss undokumentiert werden. Eingewendet wird dann oft, dass man doch monatelang sich auf Regeln geeinigt hat, da kann man doch nicht einfach alles ändern ...

Kennen Sie das, wenn sich Dokumentation und Beschriebenes großteils unterscheiden?

Aus meiner Erfahrung tendiere ich zu folgenden Grundsätzen:

Dokumentation wird während der Entstehung oder nach einem Feature Freeze erstellt und ständig angepasst.
Dokumentation wird von einer Person erstellt, die nur sich selbst und dem eigenen Gewissen verpflichtet ist.
Dokumentation soll den Lesenden leiten, aber nicht einengen. Man hat es selten mit Idioten zu tun!

Die Vorteile liegen auf der Hand, die Dokumentation beschreibt nur, was auch umgesetzt wurde und das nur so detailliert wie nötig, auf keinen Fall mehr. Das erleichtert dem Schreibenden die Arbeit enorm. Endlose, unnütze Abstimmungsrunden im 2 Wochen Rhythmus können ebenso entfallen. Ein kurzes Review gegen Ende genügt für jede Normerfüllung.