Was ist das Problem?

Projektleitungen und das zugehörige Projektteam stehen zu Beginn des Projekts ohne irgendein Wissen da. Das wird in wirtschaftliche und technologische Unwissenheit unterschieden. Dazu gibt es auch ein Modell von McConnel aus dem Jahr 2006, was den schicken Namen „Cone of Uncertainty“ trägt.

Technologische Unwissenheit ergibt sich immer dann, wenn man noch nicht wissen kann, wie eine Software später aussieht, funktioniert, mit welchen Subsystemen diese kommuniziert und vieles mehr. Jetzt wirst du vielleicht antworten, dass du das nicht vorstellen kannst. Du gehst sicher davon aus, wenn ich eine Software A weiterentwickle, dass ich dann deren Schnittstellen etc. kennen werde. Das wird bis zu einem gewissen Grad eine vertretbare These sein. Es ist jedoch so, dass ein Auftraggeber das in der Regel nicht weiß. Hat dieser nun eine Anforderung, kommt es nicht selten vor, dass sich diese im Laufe des Softwareentwicklungsprojekts ändert – manchmal sogar mehrfach. Dabei ist es schon ausreichend, wenn die ursprüngliche Anforderung ein Datenpaket in einem bestimmten Format übertragen sollte und sich später durch eine gesetzliche Regelung herausstellt, dass die Daten aber aus zwei Zeichen mehr bestehen. Dieses Beispiel ist schon eine kleine Unwissenheit. Summiert man diese kleinen Unwissenheit, so ergibt sich ein großes Problem. Da Software nicht angefasst werden kann (immateriell ist), läuft man eigentlich vollkommen blind in die Umsetzung solcher Projekte.

Sicher denkst du jetzt, dass man ja deshalb ein Projekt auch plant. Ja, in Projekten wird geplant, manchmal sogar zu wenig, manchmal auch zu viel. Dieser Umstand ändern leider nichts an dem ursprünglichen Problem, dass alle Beteiligten im Projekt blind sind – nicht abschließend bewerten können, wie sich die Unwissenheit in Wissen ändern wird.

Dadurch ergibt sich zwangsläufig der Einfluss auf die wirtschaftliche Ungewissheit:

  • Welche Leute müssen jetzt an Board sein?
  • Welche Programmiersprache müssen die Entwickler können?
  • Wie viel Zeit benötigt man jetzt?

Diese Liste mit Fragen kann wirklich lang werden.

Wo man nicht sicher sein kann, wie die Anforderungen technisch umgesetzt werden, wie soll man an der Stelle sinnvoll die Kosten schätzen? Das ist in den meisten Fällen einfach nicht möglich. In meinen Augen ist das Anfertigen eines TCO (Total Cost of Ownership / Gesamtkostenanalyse) Ressourcenverschwendung.

Wenn du dir meine Skizze anschaust, stellst du fest, dass der grüne Bereich (Unwissenheit) zu Projektstart sehr hoch ist. Aber selbst nach circa der Hälfte hat man immer noch zu wenig Wissen. Deshalb musst du dir merken, dass es auf der einen Seite niemals eine perfekte Software geben wird und auf der anderen Seite kannst du niemals eine fehlerfreie Software beweisen – egal wie viel Zeit und Geld du in Qualitätsmanagement stecken wirst.

Typen von Unsicherheit

Es gibt vier Typen von Unsicherheiten:

  • Was-Unsicherheit
  • Wie-Unsicherheit
  • Wer-Unsicherheit
  • Worin-Unsicherheit

Mit dem „Was?“ ist die technische Ungewissheit gemeint. Wir wissen eben nicht wie die fertige Lösung konkret aussehen wird. Daran schließt sich „Wie?“ an, denn wir nicht wissen, was wir umsetzen sollen, dann wissen wir auch nicht, wie wir das umsetzen sollen. Jetzt kommt aber noch „Wer?“ dazu, womit die Stakeholder gemeint sind, die eben in den Projekten fast immer die Anforderungen über den Haufen werfen – und manchmal fängt man dann wieder von vorne an. Mit „Worin?“ sind die Domänen gemeint. Also für welche Geschäftsbereiche oder Geschäftsprozesse wollen wir die Anforderungen eigentlich umsetzen.

Unsicherheitsebenen

Wem das noch nicht ausreicht, der kann sich noch mit den 5 Ebenen von Unwissenheit auseinandersetzen. Diese wären:

  • Ebene 5: Meta-Unwissenheit (man könnte es auch völlige Ahnungslosigkeit nennen)
  • Ebene 4: Fehlen eines Prozesses
  • Ebene 3: Fehlen eines Bewusstseins
  • Ebene 2: Fehlen von Wissen
  • Ebene 1: Fehlen von Unwissenheit

Die Meta-Unwissenheit kommt eigentlich nur bei ganz neuen und großen Projekten vor, wo man so gar keine Ahnung hat, wie man strukturiert vorgehen könnte. Hier macht es Sinn sich erst einmal Gedanken zu machen, wie das Software Engineering ablaufen wird, in welchem Kontext die Software entwickelt werden soll und eine sehr ausführliche Stakeholderanalyse zu machen. Ebene 4 ist in der Regel der Startpunkt bei den Projekten. Hier muss man sich für das Anforderungsmanagement konkret überlegen welche Strategien angewendet werden sollen. Es geht also darum sich Prozesse aufzubauen oder die vorhandenen zu hinterfragen. In Ebene 3 ist man angekommen, wenn man weiß, dass man eigentlich durch die viele Unwissenheit eine Menge Probleme besitzt. Hier setzt das Problem ein, dass man nicht sicher weiß, welche Fragen nun gestellt werden müssen, um Wissen zu erlangen. Selbst wenn man Fragen sammelt, man verliert nicht den Zustand von Unsicherheit etwas vergessen zu haben. Um das zu wissen, müssten wir ja wieder genau wissen, was wir eigentlich suchen – was ja nicht der Fall ist. Dadurch das man sich nun intensiv mit den Dingen beschäftigt, kristallisieren sich nach und nach neue Fragen heraus, die man wieder stellen kann. Hier ist man in Ebene 2 und in der Lage die Frage zu stellen, die noch bestehende Unwissenheit in Wissen umwandelt. Wenn die Software – oder auch nur ein Prototyp – fertiggestellt ist, erreicht man Ebene 1, denn jetzt sieht man ja das Ergebnis und mit diesem arbeiten.

Sehr oft kommt es vor, dass erst durch das Sehen der Software die Stakeholder richtig aktiv werden und Anforderungen formulieren. Und wir dachten schon, wir wären fertig 🙂

 

Tags:
0 Comments

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

* Die Checkbox für die Zustimmung zur Speicherung ist nach DSGVO zwingend.

Ich akzeptiere

Nehmen Sie Kontakt zu mir auf

Möchten Sie, dass ich in Ihrem Unternehmen Anforderungsmanagement 4.0 einführe?

Benötigen Sie allgemein Unterstützung im Thema Requirements Engineering und/oder IT Projektmanagement?

Lassen Sie uns gemeinsam herausfinden, wie ich Sie unterstützen kann oder ob ich auf einer Ihrer vakanten Stellen passe.

Sending

©2018 Pierre Holger Braun (Wirtschaftsinformatiker, Requirements Engineer, Projektmanager, Software Engineer & Blogger)

Log in with your credentials

Forgot your details?