Wissenslücken und Komplexität – ein einfacher aber meist ignorierter Zusammenhang

In jedem anspruchsvollen Projekt haben die Projektbeteiligten am Anfang nicht das komplette Wissen über alle notwendigen Wissensgebiete zur Verfügung. Wenn dies der Fall wäre, könnte das Team die Lösung nahezu aus dem Gedächtnis abrufen und umsetzen. In Softwareprojekten aber auch in vielen anderen Arten von Projekten gehen wir mit vier Wissensgebieten um, die alle nicht völlig unabhängig voneinander sind, sondern sich gegenseitig beeinflussen (siehe Grafik unten, aus dem Buch Softwareentwickeln mit Verstand).

Zu Beginn des Projektes bringt das Team einen Teil des Wissens schon mit (dunkel eingefärbter Teil in jedem der vier Wissensgebiete), meist aus Ausbildung und anderen Projekten, die von den Mitarbeitern zuvor durchgeführt wurden. Das fehlende Wissen, das hier durch die helleren Farben symbolisiert ist,  ist oft projektspezifisch und muss dann im Projekt erarbeitet werden.

Die vier abgebildeten Wissensgebiete im Detail:

• Markt: Konkurrenzprodukte, Alternativen, Markttrends, Positionierung auf dem Markt und in der Wertschöpfungskette. Bei firmeninternen Projekten ist hier der  interne Markt mit allen Stakeholdern und deren Ansprüche zu berücksichtigen. Das Wissen über diese Gegebenheiten erlaubt ein Produkt erfolgreich zu positionieren und zu verkaufen.
• Prozess / Experience: Geschäftsprozesse, Benutzungsszenarien, Benutzer, kulturelles und soziales Umfeld. Nur das Wissen über Nutzer und die tatsächliche Nutzung eines Produkts erlaubt es, ein nützliches und benutzbares Produkt zu erstellen.
• Domäne: Finanzmathematik, Ophthalmologie, Schachwissen und wie die Anwendungsgebiete alle heißen. Das Wissen über die fachlichen Zusammenhänge, Vorschriften und Modelle ist notwendig, um überhaupt ein sinnvolles Produkt zu erstellen.
• Technologie: IT Infrastruktur, Programmiersprachen, Entwicklungsumgebungen, Software Architektur, Algorithmen – die ganze Palette des zur Entwicklung notwendigen Informatikwissen.

Wie man aus dem Diagramm auch erkennt, gibt es Abhängigkeiten zwischen den vier Gebieten. Die Bedürfnisse des Marktes beeinflussen z.B. welcher Teil der fachlichen Domäne in der Applikation abgebildet werden soll oder welche Technologie eingesetzt werden soll. Die Technologie wiederum beeinflusst zum Beispiel die User Experience usw. Je grösser nun die Wissenslücken zu Beginn sind, desto unklarer sind die Abhängigkeiten untereinander. Im Extremfall, wenn nicht einmal ein Mindestverständnis eines Wissensgebietes da ist, sind die wahren Wissenslücken kaum erkennbar und das Projekt ist dann besonders stark gefährdet. Hier schlägt die durch Wissenslücken erzeugte Komplexität dann mit voller Kraft zu.

Komplexität haben wir auch in userem Buch Softwareentwickeln mit Verstand betrachtet und folgende Eigenschaften komplexer Problemstellungen festgehalten:

• Große Anzahl von Variablen, die die Problemsituation beschreiben
• Starke Vernetztheit der beteiligten Variablen – also gegenseitige Abhängigkeiten
• Hohe Dynamik der Problemsituation – also unvorhersehbare Änderungen
• Intransparenz im Hinblick auf die beteiligten Variablen sowie die Zielstellung
• Polytelie, d.h. viele sich gegenseitig beeinflussende und sogar widersprechende Ziele – viele Stakeholder, viele Wünsche

Wenn man sich nun vorstellt, man wüsste praktisch bei Projektbeginn über nahezu alle wichtigen Aspekte und Details, wie das zum Beispiel beim Bau einer einfachen Garage für ein Auto der Fall wäre, dann sieht man, dass die obigen Parameter für Komplexität praktisch alle nicht zutreffen. Eine einfache Garage aus Fundament, Mauern, Dach und Garagentor hat nicht viele Variablen und sie sind auch kaum vernetzt. Auch Dynamik, Intransparenz und Polytelie sollten für eine normale Garage keine Rolle spielen, da man ein solch einfaches Gebilde sehr gut vorausplanen kann.

Wenn man nun das Gedankenspiel fortsetzt und sich vorstellt, die Entwicklung eines Hörgerätes zu starten, dann spielen viele der genannten Parameter für Komplexität ein grosse Rolle, zumindest wenn man kein ausgewiesener Experte für Hörgeräte ist. Zum Beispiel kennen wir den Markt kaum, die Fachdömäne für Hörgeräteakkustik wahrscheinlich auch nicht und die Technologie, um solche miniaturisierten Hochleistungsgeräte zu bauen und alle erforderlichen Normen einzuhalten, auch nicht. Das Problem wird dann sehr komplex und vielleicht sogar chaotisch, wenn wir aufgrund des Nichtwissen die eigenen Wissenslücken gar nicht erkennen.

Ich möchte hier die Verbindung zum Cynefin Framework von Dave Snowden machen. Gemäss Wikipedia ist das Cynefin Framework wie folgt beschrieben:

Das Cynefin-Framework ist ein Modell, das verwendet wird, um Probleme, Situationen und Systeme zu beschreiben. Das Modell liefert eine Typologie von Kontexten, die einen Anhaltspunkt bieten, welche Art von Erklärungen und / oder Lösungen zutreffen können.

Die untenstehende Grafik zeigt die vier bzw. fünf Bereiche (Grafik von Cynthia F. Kurz, Attribution-NonCommercial-NoDerivs 3.0 Unported)

Die nachfolgende Beschreibung von Simple, Complicated, Complex und Chaotic ist aus Wikipedia übernommen:

Simple, in der die Beziehung zwischen Ursache und Wirkung für alle offensichtlich ist. Die Heransgehensweise ist hier Sense – Categorise – Respond, und wir können bewährte Praktiken (best practice) anwenden.

Complicated, in der die Beziehung zwischen Ursache und Wirkung Analyse oder eine andere Form der Prüfung erfordert und/oder die Anwendung von Fachwissen. Hier geht man mittels Sense – Analyze – Respond heran, und man kann gute Praktiken (good practice) anwenden.

Complex, in der die Beziehung zwischen Ursache und Wirkung nur im Nachhinein wahrgenommen werden kann, aber nicht im Voraus. Hier ist der Ansatz Probe – Sense – Respond, und wir können emergente Praktiken (emergent practice) feststellen.

Chaotic, in der es keine Beziehung zwischen Ursache und Wirkung auf Systemebene gibt. Hier ist der Ansatz Act – Sense – Respond, und wir können innovative Praktiken entdecken.

Nun möchte ich beide Betrachtungsweisen – Wissenslücken und das Cynefin Framework – verbinden.

Wenn wir praktisch alles über Problem, Lösungsalternativen und Vorgehensweise wissen, befinden wir uns im Bereich known / simple. Auf diese Stufe müssen wir eine Problemstellung vereinfachen, wenn wir für ein Managementteam oder ein Steering Committee eine Entscheidung vorbereiten müssen.

Sind zwar Wissenslücken vorhanden aber das vorhandene Wissen reicht aus um Ursache -Wirkungsbeziehungen noch zu erkennen, dann handelt es sich um die Kategorie knowable / complicated.

Wenn entscheidendes Wissen zu Beginn fehlt und wir dadurch in bestimmten Gebieten auch die Ursache – Wirkungsbeziehungen nicht mehr ohne ausreichende Experimente erkennen können um daraus gewisse Muster abzuleiten, dann haben wir es mit der Kategorie interconnected / complex zu tun. Die fünf Eigenschaften von komplexen Problemstellungen von oben (Variablen, Abhängigkeiten, Dynamik, Intransparenz, Polytelie) treffen hier fast alle zu.

Und wenn wir viel zu wenig wissen um unser Nichtwissen zu erkennen, dann sind wir im Bereich unavailable / chaotic. Wenn wir solche Projekte mit so wenig Expertise starten, können auch erzielte Resultate nie richtig beurteilt oder eingeordnet werden. Das Team stochert buchstäblich im Nebel und typischerweise bieten Projektumgebungen nicht das Experimentierfeld um sich grundlegendes Wissen anzueignen.

Projekte der Kategorien simple, complicated oder complex sind alle managebar. Allerdings sind hierfür die geeignetsten Methoden nicht die selben. Ein komplexes Projekt (complex) braucht zum Erfolg ein agiles Vorgehen, siehe auch den Beitrag von Jocham/Botta. Ein Projekt der Sorte knowable / complicated kann man gut mit den typischen iterativen und inkrementellen Phasenmodellen wie RUP bearbeiten. Der Typ simple, wie am Beispiel der Garage erläutert, verträgt ohne Probleme einen klassischen Wasserfallprozess. Hier agil zu arbeiten würde zumindest bei den Nachbarn, die beim Bau der Garage zuschauen, ein Kopfschütteln verursachen.

Entscheidend für das Vorgehen ist also die Komplexität, die wiederum die Ursache in den Wissenslücken hat. Wenn Wissenslücken nicht erkannt werden, dann ist die Wahrscheinlichkeit hoch, dass ein Team mit dem falschen Vorgehen sich einer unüberwindbaren Komplexität gegenübersteht. Solche Projekte scheitern immer – ohne Ausnahme!