Cynefin Value Map

Das Cynefin-Framework ist eine Theorie zur Beschreibung komplexer Systeme und wurde von Ralph Stacey um eine Matrix-Darstellung weiterentwickelt. Auf dem Blog NOOP.NL http://www.noop.nl/2010/09/simplicity-a-new-model.html findet man alles Interessante dazu. Ich empfehle einen Besuch!

Ich nenne die Adaption von Ralph Stacey nun weiterhin Cynefin-Modell und möchte dieses Koordinatensystem um eine weitere Dimension „Value“ ergänzen.

Falls Sie oben den Link übersehen haben, noch einmal das 2D-Koordinatensystem (eigene Darstellung):

Stellen wir nun die Analyse eines Systems aus 4 Teilen dar. Tragen dazu die  Systemteile A, B, C und D repräsentiert durch blaue Punkte in das Cynefin-Koordinatensystem ein:

Zusätzlich zur Position hat die Größe des Kreises die Bedeutung „Value“. Darunter ist z.B. der geschätzte Kundenwert oder vielleicht auch eine Kundenzufriedenheit aus einer Umfrage oder Ähnliches einsetzbar. Wir sehen zwei wertvolle und zwei weniger wertvolle Teile.

Jetzt ist die Frage: Lassen wir das System so oder wollen wir etwas verändern? Riskieren wir bei der Operation einen der vorhandenen Werte zu beschädigen? Dafür sprechen zwei Hauptpotentiale: Zum einen können (durch die Vereinfachung des Systems) Maintainance-Kosten gesenkt werden, zum anderen kann eine bessere Usability auch die Kundenzufriedenheit steigern. Manchmal ist die Komplexitätsreduktion jedoch auch einfach unabdingbar, um neue Funktionen hinzuzufügen, ohne das System unter der Komplexität zusammenbrechen zu lassen, also ohne eine Hyperinflation von Bugs auszulösen.

Ich möchte 4 Prototypen von sinnvollen Beispielen von Vereinfachungen aufzählen:

Modifikationen an A (zu A’)

Für einen sehr komplexen Systemteil, der jedoch sehr wertvoll ist, sollte man zunächst versuchen, durch Nutzerdokumentation eine höhere Voraussagbarkeit zu erreichen. Das System ist dann vielleicht sehr komplex, aber zumindest nach intensiver Einarbeitung für jeden vorhersagbar. Nur wenn dies “nichts hilft”, sollte man eine risikoreiche Änderung in Betracht ziehen.

Modifikationen an B (zu B’)

Auch wenn ein Feature einen großen Wert hat, macht es Sinn ggf. auf einen Teil zu verzichten und nur den Kernnutzen beizubehalten, wenn dadurch eine starke Vereinfachung für den Nutzer oder in der Maintainance resultiert. Ein gutes Beispiel ist das Entfernen von Makro-Unterstützung in der Visual Studio-IDE (nach 2010). Mit einem geringen Wertverlust, konnte eine hohe Systemvereinfachung erreicht werden und eine Kostenreduktion in der Entwicklung.

Liquidation von C

Wenn ein Systemteil einen nur geringen Wert besitzt, jedoch sehr chaotisch ist, sollte er in der Regel liquidiert werden.

Modifikationen an D (zu D’)

Für die meisten Systeme ist eine Balance aus statischer Vereinfachung und Linearisierung sinnvoll, soweit dies ohne einen Feature-Abbau möglich ist. Beispiele sind das Ersetzen von Forms-Over-Data durch eine Task-basierte UI, das Einführen von Assistenten, internes Refactoring, das Einführen von UI-Konventionen, das Angleichen an bekannte Standards (z.B. Look & Feel, aber auch interne Programmierstruktur).

Fazit

Prinzipiell sollte es das Ziel sein, die Vorhersagbarkeit durch Linearisierung zu verbessern. Dies ist meist „einfacher“ möglich, als die statische Struktur des Systems zu vereinfachen. Wenn möglich sollte die Balance zwischen Linearisierung (bessere Vorhersagbarkeit) und Simplifizierung (statische Komplexität) angestrebt werden.

In bestimmten Grenzfällen ist auch ein Verzicht von Value zugunsten einer geringeren Komplexität sinnvoll.