Die zwei Fehler beim Dokumentieren

Image for post
Image for post

Egal ob beim Dokumentieren von Design oder Architektur von Software, beim Dokumentieren interner Prozesse oder, ganz Allgemein, beim Dokumentieren von Entscheidungen, meistens werden gravierende Fehler gemacht.

Zwei davon stechen besonders hervor:

1. Die Frage nach dem Adressaten der Dokumentation wird nicht gestellt.
2. Es wird nur das Endergebnis festgehalten.

Der erste Fehler führt potentiell dazu, dass die Dokumentation nie ernsthaft herangezogen wird: Für den Einen fehlen wichtige Details, der Andere vermisst die Einführung bzw. das Gesamtbild, für den Einen ist die Sprache zu technisch, dem Anderen nicht technisch genug, der Entwickler hat weiterhin noch viele offenen Fragen, als Endkundendokumentation taugt sie aber auch nicht. Im schlimmsten Fall ist es eine „Eierlegendewollmilchsau-Doku”, die irrsinnig viel Zeit erfordert hat, um sie zu erstellen, und die nun so fett ist, dass sie niemand ansehen möchte. In allen Fällen ist nutzlos Zeit investiert worden. Sehr gut erkennen kann man Fehler 1, wenn die Dokumentation mit den Worten „natürlich braucht man eine Doku, ist doch klar” eingefordert wird.

Der Fehler Nummer zwei ist aus meiner Erfahrung oft völlig unentdeckt. Jeder denkt, dass das Festhalten des Endergebnisses das einzig relevante ist. Niemand stellt dies in Frage. In meinen Augen ist das aber komplett falsch: es ist viel wichtiger alle Ideen zu dokumentieren, die entstanden sind, und auch zu dokumentieren, warum welche Idee verworfen wurde. So kann zu einem späteren Zeitpunkt, wenn ein Problem wieder auf der Tagesordnung ist, einfach und schnell analysiert werden, ob eine vormals ersonnene und verworfene Lösung nun doch eine Chance bekommt. Z.B. weil einer der verhindernden Faktoren sich geändert hat. Weiterhin ist es für die Motivation und dadurch für die Umsetzung einer Lösung sehr hilfreich, wenn alle Mitarbeiter durch die Kommunikation der Details der Entscheidung mitgenommen werden.

Unbedingt neben der gewählten Lösung auch alle anderen Ideen festhalten; inklusive der Gründe dafür und der Gründe dagegen.

Written by

Software Developer, Scrum Master und Product Owner.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store