Ohne UML in die Word-Falle
Über das Management in der UML-Falle habe ich bereits geschrieben. In dem Artikel habe ich darzustellen versucht, dass es eine große Gefahr birgt, wenn man sich in großen Projekten im Rahmen einer Spezifikation auf die Erstellung von UML-Diagrammen beschränkt und auf detaillierte textliche Erklärungen verzichtet. Man hat zwar schöne Fachklassen- und Use Case Diagramme, die gute Übersichten liefern. Die fachlichen Details – und die sind spätestens für die Entwickler unverzichtbar – gehen aber verloren.
Das andere Extrem
Doch es gibt auch das andere Extrem: den Versuch einer kompletten Fachspezifikationen in einem einzigen Dokument. Und das auch noch ohne grafische Übersichten.
Ich hatte diese Möglichkeit bisher noch nicht ernsthaft in Erwägung gezogen. Leider muss ich aber nun damit selbst in einem Projekt zurecht kommen. Es handelt sich um ein Projekt, welches ich fachlich konzeptionell begleite. Meine Aufgabe ist es, ein Fachkonzept zu entwickeln, auf dessen Basis die bestehende Software um weitere Funktionalität ergänzt werden soll. Also mache ich mich auf die Suche nach hilfreicher Dokumentation zu erforderlichen Klassen, Attributen und den dahinterstehenden Zusammenhängen. Doch überraschenderweise finde ich nichts als sehr umfangreiche Word-Dokumente und genauso schwer zu durchschauende Excel-Tabellen.
In einem solchen Word-Dokument (ebenfalls Fachkonzept genannt) ist die gesamte Beschreibung des gewünschten Systems abgelegt. Da werden alle Aspekte drin beschrieben.
Einführung in den fachlichen Zusammenhang
Fachklassen und Attribute inklusive Kardinalitäten (1:n-, 1:1-, n:n-Beziehungen)
Dialogbeschreibungen inklusive Screenshots
Anforderungen
Geschäftsregeln (Ausnahmen, Gültigkeiten)
Fehlermeldungen
Fachanalyse, Systemdesign und Oberflächenspezifikation sind da lustig miteinander vermischt. Wie soll man daraus die wesentlichen Informationen extrahieren und sich ein schlüssiges Bild erstellen. Welches fachliche Problem (Was?) wurde mit welchen technischen Mitteln (Wie?) gelöst? Mir will es nicht gelingen. Ich stelle mir auch immer wieder die Frage, für wen diese Art von Dokumenten eigentlich geschrieben werden. Doch dazu später…
Ein Erklärungsversuch
Ich denke das Problem liegt in zwei Ursachen begründet. Ein Grund ist der eingeschränkte Werkzeugkasten. Ich bewege mich hier in einer Fachabteilung, deren Mitglieder rein fachlich orientiert sind. Nun, das mag bei einer Fachabteilung auch nicht überraschen. Jedes Werkzeug jenseits von Textverarbeitung und Tabellenkalkulation stößt auf prinzipielle Ablehnung. Da wird gesagt, man beherrsche das nicht. Und überhaupt, das sei doch nur was für Techniker. Das möchte ich so nicht gelten lassen. Die Zergliederung der fachlichen Realität in ein übersichtliches Modell ist kein Hexenwerk und kann gelernt werden. Wohl gemerkt, ich spreche nicht von Use Case-Modellierung, welche wirklich etwas schwieriger ist. Ich meine einfach nur die grafische Beschreibung des Zusammenspiels von bspw. Person, Kunde, Vertrag, Bankverbindung, Ort, Anschrift etc. Das ist nicht so kompliziert. Versuchen Sie das aber mal rein textlich zu beschreiben. Da kommen schon für diese paar Klassen zehn Seiten und mehr zusammen. Wenn man also nur Textverarbeitung und Tabellenkalkulation zur Hand hat / beherrscht, bleibt einem nichts anderes übrig, als eben diese zig-Seiten-Dokumente zu schreiben. Da macht das Schreiben keinen Spaß. Und auf die Pflege solcher Dokumente möchte ich nicht weiter eingehen.
Der andere Grund mag in der Verquickung unterschiedlicher Projektperspektiven liegen. Nicht erst seit dem Rational Unified Process (Erklärung bei Wiki) sind die unterschiedlichen Aufgaben im Rahmen des Gesamtprozesses von der Idee bis zum fertigen Produkt beschrieben. Um zu einer innovativen Problemlösung zu kommen, müssen die Perspektiven des Was (fachliche Aufgabe) und des Wie (die Lösung) klar getrennt sein. Das wird ja auch in vielen großen Unternehmen dadurch abgebildet, dass es auf der einen Seite reine Fachabteilungen und auf der anderen Seite die Entwicklungsabteilungen gibt. Nur häufig ist es eben so, dass erstens Designabteilungen fehlen und sich zweitens die Fachabteilungen zu weit in die Umsetzung hinein wagen. Dann kommt es zwangsläufig zu solch überlasteten Dokumenten, wie ich es oben beschrieben habe. Dieses Problem kann man aber nicht mit Werkzeugschulungen in den Griff bekommen. Das ist ein Problem der Unternehmensorganisation und muss strukturell gelöst werden. Kleine Anmerkung: Das hat mit Projektmanagement-Methoden, ob nun Wasserfall oder Scrum nichts zu tun. Es geht vielmehr um das prinzipielle Verständnis verschiedener Rollen und ihrer Lösungskompetenzen.
Ein Konzept – ungelesen
Nun zurück zum Dokument auf meinem Tisch. Was soll ich also damit anfangen? Und weiter: Wenn ich das nicht verstehe, verstehen es die Entwickler? Denn für die Entwickler werden ja solche Dokumente geschrieben. Die traurige Antwort wird natürlich nur unter vorgehaltener Hand gegeben: Nein! Die Entwickler machen das so, wie sie es sich denken, spielen den Code ein, und die Fachabteilung stellt dann Tickets mit den Fehlern ein. Und so geht das weiter bis das Klagen leiser wird oder das nächste Release ansteht… Unter iterativer Entwicklung stelle ich mir etwas anderes vor.
Das bedeutet auf den Punkt gebracht: Derart umfangreiche Fachkonzepte, die versuchen in einem Dokument die Vielfalt des Fachuniversums zu erklären, werden de facto nicht gelesen. Das frustriert nicht nur die Autoren sondern bereitet auch dem Auditorium ein schlechtes Gewissen. Wie viel Geld ließe sich da einsparen und an anderer Stelle sinnvoller einsetzen?
Lösungsansatz
Der Lösungsansatz ist mehrschichtig. Zuerst muss in dem Unternehmen ein Bewusstsein für die verschiedenen Projektperspektiven und deren Verantwortlichkeiten gebildet werden. Dann gilt es diese Rollen mit kreativen Köpfen zu besetzen. Dabei muss jeder Mitspieler die Aufgaben voran treiben und verantworten, die seiner Kernkompetenz entsprechen. Es hilft nicht, die Ente zum Klettern zu zwingen und dem Eichhörnchen das Schwimmen beizubringen. Alle Beteiligten müssen aber die Fähigkeiten des anderen kennen und richtig einschätzen können.
Hat man die Verantwortlichkeiten klarer strukturiert – und vielleicht sogar neue entdeckt -, kann man auch die Projektspezifikation in geeignetere Ergebnistypen (unterschiedliche Arbeitsergebnisse) aufteilen. Ich versuche das für die obige Liste:
Einführung in den fachlichen Zusammenhang –> Ein Textdokument pro Themenbereich
Fachklassen und Attribute inklusive Kardinalitäten –> UML Domain Class Model (Das ist noch kein Design Model!)
Dialogbeschreibungen inklusive Screenshots –> Storyboards und Mockups
Anforderungen –> Datenbank mit Tagging
Geschäftsregeln (Ausnahmen, Gültigkeiten) –> Datenbank mit Tagging, referenziert Anforderungen
Fehlermeldungen –> Datenbank mit Tagging, referenziert Geschäftsregeln
Die Datenbanken sollten die Möglichkeit bieten, unterschiedliche Berichte zu erzeugen. So kann man sich themenorientiert bzw. komponentenbezogen zusammen stellen lassen, was das zukünftige System zu leisten hat. Die obige Liste ist nicht vollständig. Es fehlen weitere Ergebnistypen wie Prozess- und Aktivitätsdiagramme. Auch die Use Cases sind hier noch nicht berücksichtigt. Das sind übrigens Aspekte, die in dem Dokument auf meinem Tisch gar nicht berücksichtigt wurden.
Fazit
Riesige Spezifikationsdokumente, die versuchen das gesamte Fachuniversum auf einmal zu beschreiben, sind unverständlich. Die Informationen mögen da zwar drinstecken, können aber nicht extrahiert werden. Sie sind also de facto verloren. Die “Word-Falle” hat zugeschnappt!
Statt viel Energie (und Geld) in Dokumente zu stecken, die keiner liest, sollte man besser kleinere, passende Ergebnistypen erstellen. Das müssen nicht immer Texte sein. Häufig sind mit Erläuterungen angereicherte Diagramme und Skizzen viel verständlicher. Um das jeweils passende Mittel wählen zu können, müssen sich auch Fachexperten (sprich Fachabteilung) mit Darstellungsmitteln jenseits von Word / Excel auseinander setzen.
Wenn ich das Management in der UML-Falle mit dem “Unternehmen in der Word-Falle” vergleiche, kann ich nicht entscheiden, wer schlimmer dran ist. In beiden Situationen fehlen wichtige Informationen, die ein erfolgreiches Projektergebnis gewährleisten.
#Fachspezifikation #Projektrollen #Projektmanagement #Entwicklungskosten #EnterpriseApplication