Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03603.jsonl.gz/54

Anforderungsmanagement
In Entwicklungsprojekten mag es stimmen, dass sie am Anforderungsmanagement scheitern. Migrations- und Integrationsprojekte (MIP) ticken anders. Die Zielsetzung kann meist erst während der Projektabwicklung konkretisiert werden. Wer dann endlose Diskussionen über kostenpflichtige Change Requests vom Zaun bricht, hat schon verloren. MIP werden im allgemeinen von lokalen Handelsgesellschaften eines Herstellers durchgeführt. Bei der Handelsgesellschaft arbeiten Integrationsspezialisten, die die Produkte des Mutterhauses beim lokalen Kunden installieren sollen.
Implizite Anforderungen
Es gibt selbstverständliche Anforderungen, die nicht einmal implizit auftauchen und andererseits Anforderungen, die aus den geschriebenen abgeleitet werden können. Aus einem (idealen) vollständigen Anforderungskatalog lassen sich damit alle, aber wirklich alle Anforderungen herauslesen, auch wenn sie nicht explizit drin stehen. Ein Anforderungskatalog muss also nicht alle «wichtigen» Anforderungen enthalten, sondern nur diejenigen, die es erlauben, alle anderen daraus abzuleiten, auch die «unwichtigen». Das würde aber bedeuten, dass der Auftraggeber im Voraus seine Bedürfnisse bis in das letzte Detail aufzählen kann. Man weiss aber schon lange, dass dies nicht möglich ist. Beispielsweise haben Fischhoff et al. Versuchspersonen verschiedene Versionen eines Diagramms gezeigt, das beschreibt, wie ein Auto funktioniert. Die verschiedenen Versionen unterschieden sich in der Vollständigkeit. Die Versuchspersonen wurden gefragt, ob ein Auto, das gemäss diesem Diagramm aufgebaut ist, anspringen würde. Die Versuchspersonen bemerkten fehlende Teile kaum. Selbst das Weglassen so wichtiger und allgemein bekannter Teile wie Zündung und Benzinversorgung wurden kaum bemerkt1). Die Versuchpersonen waren daher nicht in der Lage, lückenhafte Diagramme zu komplettieren. Wenn es also für ein im Betrieb stehendes und weitverbreitetes System nicht möglich ist, auch nur die primitivsten Anforderungen zu notieren, so ist es für ein noch zu entwickelndes und zu bauendes System erst recht nicht möglich.
Erwähnt wird nur, was besser werden und nicht, was gut bleiben soll
Haben Sie schon einmal ein technisches Gerät erneuern müssen? Ein Auto, einen PC oder auch nur einen Drucker? Sie betreiben bereits ein solches Gerät, aber es ist ein wenig in die Jahre gekommen oder hat sogar den Geist aufgegeben. Sie haben gelernt, einige Funktionen ganz besonders zu schätzen. So habe ich gerade einen Farblaser ersetzt, an dem ich die Möglichkeit des Duplexdrucks geschätzt und oft gebraucht hatte. Beim neunen Drucker fehlte diese Funktion, weil ich auf andere Dinge achtete, vor allem darauf, die Fehler zu vermeiden, die der alte Drucker hatte. Die guten Charakteristiken, die das alte System hatte sind einem selbstverständlich. Man ärgert sich jedoch über die schlechten Charakteristiken und denkt nur an sie, wenn man das System migriert.
Gerade darin besteht die Schwierigkeit, in Anforderungskatalogen und Pflichtenhefter Vollständigkeit zu erreichen. Zum einen weil der Kunde Selbstverständliches nicht zu formulieren braucht und die Grenze zwischen Selbstverständlichem und formulierungspflichtigen verschwimmt, zum anderen weil Handelsgesellschaften die Produkte ihres Mutterhauses nie einem Qualitätstest unterwerfen können, bevor sie sie auf ihrem lokalen Markt anbieten.
Die Anatomie von Migrations- und Integrationsprojekten
Ein MIP hat drei Bestände: Work in Progress (WIP), relevantes Wissen und eine Issuelist. Mit der Projektarbeit wird der Projektgegenstand entfaltet, wie eine Statue, die durch die Arbeit des Bildhauers immer mehr aus dem Steinblock heraus tritt. Indem der Projektgegenstand immer handfester wird, lernen sowohl Kunde/Auftraggeber als auch Lieferant/Projektteam, was möglich ist. Ihr Wissen nimmt zu. Dadurch können sie die Anforderungen immer konkreter spezifizieren. Sie tun dies, indem sie Fragen, Aufträge, Tasks, Ergänzungen in eine Issuelist schreiben. Jedes Issue in der Liste verursacht aber natürlich wiederum neue Arbeit. Dadurch, dass das Wissen einer Halbwertszeit unterworfen ist, nimmt es nach dem Erreichen eines Maximums wieder ab. Das hat zur Folge, dass auch die Issuelist nicht ins Unendliche anwächst, sondern sich auf einem Minimum einpendelt. Wenn das passiert ist, kann das Projekt abgeschlossen werden. Verzögerungen im Projekt sind die Ursache, dass die Länge der Issuelist ein wenig oszilliert. Die Entwicklung der drei Bestände zeigt die folgende Grafik.
Quintessenz
Es geht also nicht darum, bessere Anforderungskataloge und Spezifikationen anzustreben. Vielmehr geht es darum, die Tatsache zu verstehen und zu akzeptieren, dass die Anforderungen erst währen der Projektausführung endgültig formuliert werden können und die Projektplanung darauf auszulegen. Lassen Sie es geschehen! Erklären Sie als Lieferant bei den Vertragsverhandlungen dem Kunden, dass er das Recht hat, während des Projekts seine Anforderungen zu konkretisieren. Versuchen Sie als Kunde vom Lieferanten zuerst ein „Proof of Concept“ liefern zu lassen. Das ist eine Art Testsystem, das probehalber in Ihre Umgebung integriert wird. Oder strukturieren Sie das Projekt klar nach den Phasen
- Pilot
- Formulierung der Anforderungen
- Restart des Projekts
1)B. Fischhoff et al. Fault trees: Sensitivity of estimated failure probabilitiesto problem representation. Journal of Experimental Psychology: Human Perception and Performance, 1978, 4, 330-334