Ein wichtiger Punkt für Dokumentationen von komplexen Inhalten möchte ich einleitend noch erwähnen. Mir wurde vor einigen Jahren immer wieder vorgehalten, dass ich zu viel dokumentiere und in Konzepten schreibe. Früher dachte ich, es muss ja alles ganz genau dokumentiert sein, daher braucht es viel Text.
Heute weiss ich, was alle damals damit gemeint haben. Lange Texte in Dokumentationen werden selten gelesen und noch seltener genau so verstanden. Daher versuche ich in letzter Zeit meine Dokumentationen mehr auf Visualisierungen mit kurzen Beschreibungen zu beschränken. „Ein Bild sagt mehr als 1000 Worte“ wird umgangssprachlich oft gesagt. Das kann ich voll bestätigen. In der Regel werden Bilder öfter genauer angesehen und konstruktiv kommentiert als lange Texte.
Es kommt aber auch auf die Anforderungen, den Auftraggeber und die Teilnehmenden an. Es gibt Projekte, in denen ein Ablaufdiagramm ausreicht, um den Prozess zu formulieren und die Umsetzung hangelt sich an dem Prozess entlang. Andere Projekte benötigen mehr Detail-Beschreibungen oder sogar MocUps (Skizzierung der zukünftigen Software-Oberfläche) von dem Zielbild.
Je weiter weg von einer Standard Software, um so mehr muss beschrieben und visualisiert werden.
Die Detailtiefe einer Konzeption oder Dokumentation sollte im Vorfeld besprochen und bestimmt werden.
Hier sollten die Fragestellungen als Grundlage genommen werden:
Kann eine Standard Software genutzt werden?
Wenn eine Software nah am Standard genutzt werden kann, ist schon was vorhanden, das als Beispiel verwendet werden kann. Dann muss nur noch ein geneinsames Verständnis der Nutzung der Software in einem Ablaufdiagramm aufgeschrieben und deren Konfiguration und eventuelle Anpassungen in einem Konzept vermerkt werden, und es kann sehr schnell in die Umsetzung am System gestartet werden.
Kann eine Standard Software nicht genutzt werden, oder muss sie stark angepasst werden, sollte ein Konzept für die neue Software anhand von Prozessen und Use Cases / Test Cases erstellt werden, um eine Idee der neuen Lösung erstmal durchzudenken, bevor mit der Umsetzung begonnen wird.
Wie kompliziert / Komplex ist die neue Lösung?
Kurz zur Erklärung:
- Kompliziert: ist eine Vielzahl von Anforderungen, die aber in sich klar und abgeschlossen sind.
- Komplex: Verschachtelte und abhängige Anforderungen die wiederum Auswirkungen aufeinander haben können.
Sind die Prozesse einfach und hat keine komplexere oder kompliziertere funktionale Anforderung, reicht eine einfach Ablaufbeschreibung zu Beginn und die wenigen Details können bei der Umsetzung erarbeitet und direkt angepasst werden.
Sind die Prozesse oder deren Anforderungen kompliziert oder gar komplex müssen sie vor der Umsetzung genau analysiert und in ein Zielbild überführt werden, Hier braucht es eine genaue Dokumentation der Vielzahl der Anforderungen und wenn sie Auswirkungen aufeinander haben, um so mehr um Klarheit im Detail zu schaffen, bevor mit der Umsetzung begonnen wird.
Wie viel System- und Prozess-Wissen haben die Teilnehmenden?
Das Fachwissen der Teilnehmenden ist ein wichtiger Schlüsselfaktor für eine neue Lösung, das Wissen über die neue Software ist aber genauso wichtig. Ist eine Standard Software geplant zu nutzen oder geht es in dem Projekt um eine Erweiterung der Software, kann die neue Anforderung recht konkret identifiziert und grob aufgeschrieben werden.
Ist die neue Software noch nicht bekannt bei den Teilnehmenden, sollten die Prozesse mit Bezug zu der neuen Software genauer dokumentiert werden. Hier können entweder funktionale Anforderungen zu den Ablaufdiagrammen erfasst, oder Use Cases und deren Test Cases vor Beginn der Umsetzung formuliert werden, dass ein Lösungs-Design auf der Grundlage erstellt werden kann, bevor mit der Umsetzung begonnen wird.
Wie weit können die Teilnehmenden abstrahieren, sich also eine noch nicht vorhandene Lösungen vorstellen?
Kurz zur Erklärung: Abstraktionsvermögen ist die Vorstellungskraft eines Menschen für etwas, dass noch nicht vorhanden ist.
Bei einer vorhandenen Software, ob sie neu eingeführt wird, oder schon vorhanden ist, und erweitert wird, benötigt es nicht viel Abstraktionsvermögen von den Teilnehmenden. Hier kann konkret anhand eines Ablaufdiagramms am System die Anpassung besprochen werden und bedarf keiner genaueren Dokumentation.
Ist keine Software vorhanden oder die Anpassung sehr weit weg von der aktuellen Softwarelösung oder gar komplett neu, braucht es das Abstraktionsvermögen der teilnehmenden. Ist dies nicht vorhanden, sollte gemeinsam genau dokumentiert werden, was als Anforderungen in dem neunen System umgesetzt werden soll. Hier hilft oft auch ein einfaches Bild der Lösung zu malen oder in Screenshot der Lösung die neuen geplanten Anpassungen einfügen, dass alle ein Bild der Lösung vor Augen haben.
Und nicht zu vergessen ist wie die Unternehmenskultur des Unternehmens ist. Unternehmen, die Umgangssprachlich „Hemdsärmelig unterwegs sind“ gehen eher das Risiko ein, weniger im Vorfeld zu erarbeiten und mehr „Agil“ in der Umsetzung auch mal in eine falsch Richtig zu gehen und dies während der Umsetzung zu korrigieren. Diese Unternehmen habe ich in meiner Laufzeit sehr wenig gesehen. Es ist viel mehr die Planbarkeit, die Unternehmen vorgeben, und je nach den Fragestellungen zuvor, ergibt sich dann eine mehr oder weniger ausgeprägte Dokumentation der Konzeption.
Die weitere Dokumentation im Projektverlauf ist aber genauso wichtig und wird sehr oft vernachlässigt. Hier sollten neben der Dokumentation der Zusammenarbeit von Terminen und User Stories mit allem was dazu gehört zumindest fachliche und technische Entscheidungen und Anpassungen an den zuvor definierten Prozessen festgehalten werden.
Zusammengefasst kommt es auf das Projekt und ihre Eigenschaften an, ob es eine genauere Dokumentation der geplanten Lösung braucht oder nicht. Dies sollte zu Beginn des Projekts geklärt werden, da eine umfangreichere Dokumentation mehr Zeit und mehr Menschen benötigt, die wiederum Auswirkungen auf den Projektplan haben.