Guest Post by

Torn out of Context in Reverse at 50 mph

Vor einigen Jahre wurde mir bei einem Automobilhersteller eine Anekdote erzählt, die sich selbstverständlich bei einem Konkurrenten abgespielt haben soll: Bei einem neuen Sportwagen-Cabrio gab es immer wieder Reklamationen aufgrund von Undichtigkeiten der Heckscheibe. Obwohl diese für eine Geschwindigkeit von 80 km/h ausgelegt war, wurde bei einigen Neuwagen gemeldet, die Scheibenabdichtung sei eingedrückt. Wer fährt schon rückwärts schneller als 80 km/h? Die Ingenieure rauften sich die Haare, überprüften mit Labortests die Einhaltung der Anforderung, konnten aber keinen Fehler entdecken. Schließlich stellte sich heraus, dass Fahrzeuge beim Transport mit dem Güterzug manchmal auch rückwärts zur Fahrtrichtung auf den Wagons stehen. Da Güterzüge teilweise schneller als 80 km/h fahren war somit die Ursache gefunden.

Den Wahrheitsgehalt dieser kleinen Geschichte kann ich nicht garantieren. Vielleicht handelt es sich um eine der modernen Sagen, wie die berühmte Spinne aus der Yucca Palme. Als Anstoß darüber nachzudenken, wie fehlerhafte Anforderungen entstehen, ist sie dennoch gut geeignet.

Natürlich hätte die Anforderung so nicht in die Spezifikation des Fahrzeugs aufgenommen und umgesetzt werden dürfen. Aber ist sie deshalb auch falsch? Ich denke nicht. Die Anforderung ist korrekt. Aber nur unter einer Bedingung: sie muss im richtigen Kontext gesehen werden (Kontext im Sinne von: Gedanken- und Sinnzusammenhang, in dem ein Phänomen oder eine Äußerung verstanden werden muss).  Dieser Kontext ist in unserem Beispiel das Szenario, in dem das Cabrio seinen eigentlichen Zweck erfüllt: von einer Person gefahren zu werden.

Der Mangel an dem Produkt Fahrzeug entstand dadurch, dass ein weiterer wichtiger Kontext nicht beachtet wurde: der Transport des Fahrzeugs mit der Bahn zum Händler. Dort ist dann auch der Fehler aufgetreten. Einen Schritt weiter gedacht muss natürlich neben dem Transport zum Händler auch jeder andere Transport des Cabrio berücksichtigt werden, wie z.B. auf einem Reisezug. Und vielleicht gibt es noch weitere relevante Kontexte, die Einfluss auf die Heckscheibe haben. In den letzten Jahren hat die Häufigkeit von Stürmen mit hohen Windgeschwindigkeiten zugenommen. Mir ist nicht bekannt, ob die Autobauer dies schon in ihre Spezifikationen aufgenommen haben.

Der Weg zur Spezifikation

Der Weg zur Spezifikation

Aus unterschiedlichen Kontexten heraus können unterschiedliche Anforderungen an ein und dieselbe Eigenschaft eines spezifizierten Produktes resultieren. Es ist dann die Aufgabe des Produktmanagements, diese Anforderungen zu priorisieren und zu aggregieren. Oft müssen dabei Kompromisse geschlossen werden. So kommen beispielsweise vom Controlling auch immer wieder Anforderungen, welche von den Ingenieuren nicht gerne gesehen sind. Automobilhersteller sind in der Regel jedoch sehr gut darin, unterschiedliche Anforderungskontexte zu managen. So wird zum Beispiel beim Entwurf eines Autos immer auch darauf geachtet, dass Werkstätten die Fahrzeuge später auch reparieren können. Einige Hersteller geben sich dabei viel Mühe, andere weniger.

In der kleinen Anekdote wurde ein Nutzungsszenario schlichtweg vergessen. Man könnte auch sagen: der Systemkontext wurde zu klein gewählt. In der Folge wurde eine Anforderung umgesetzt, die in einem einzelnen Kontext zwar richtig, sich im Kontext der gesamten zu unterstützenden Nutzungsszenarien aber als Mangel herausgestellt hat. Ich schätze, dies ist eine der häufigsten Ursachen von Fehlern bei der Erfassung von Anforderungen ist: man hat etwas schlichtweg vergessen.

Der Kontext bestimmt, wie eine Anforderung zu verstehen ist

Etwas schwieriger gestalten sich die Fälle, in denen der Kontext der Anforderung unterschiedlich verstanden wird. Bei abstrakten Dingen, wie Geschäftsprozessen oder komplexen IT-Lösungen, passiert dies ganz schnell. Diese „Dinge“ zeichnen sich durch Strukturen aus, die man nicht anschauen kann, man kann sie nicht in die Hand nehmen. Sie sind nicht greifbar und damit schwer begreifbar. Die Folge: jeder macht sich sein eigenes Bild im Kopf. Die Betonung liegt dabei auf „jeder“ und „sein eigenes“. Alles Gesprochene und Aufgeschriebene – somit auch die Anforderungen – wird in diesem individuellen Kontext verstanden. Selbst wenn die Anforderungen präzise und eindeutig formuliert sind, versteht jeder sie vor seinem persönlichen Verständnishintergrund.

Wie unterschiedlich dieser sein kann, zeigt sich häufig an der Schnittstelle zwischen den Fachbereichen und der IT. Wenn man genauer hinschaut erkennt man, dass die beiden Gruppen selbst auch kein homogenes Weltbild haben. Wie läuft ein bestimmter Geschäftsprozess genau ab? Wo fängt er an? Wo hört er auf? Sogar Kollegen, die schon lange zusammenarbeiten, haben da unterschiedliche Ansichten. Ganz deutlich wird dieses Problem, wenn unterschiedliche Disziplinen zusammen kommen. Man denke an die Abteilungen Vertrieb und Produktion, oder den Datenschutz und den Betriebsrat.

Den Standpunkt verstehen

Den Standpunkt verstehen

Wenn es aufgrund von Missverständnissen zu Streit über Anforderungen kommt, so ist dies lästig, aber nicht unbedingt schädlich. Diese Situationen lassen sich ja aufklären. Kritischer sind die Fälle, in denen ein Konflikt nicht erkannt wird. Jeder interpretiert die Anforderungen  im eigenen Kontext und versteht sie so, wie sie den eigenen Interessen entsprechen. Solche Konflikte werden in der Regel erst sehr spät entdeckt. Eine Lösung bringt enorm hohe Kosten mit sich und ist mit viel Streit und Stress verbunden. Häufig sind nur noch faule Kompromisse möglich, die keine Seite wirklich zufrieden stellen. Da die Umsetzung schon zu weit fortgeschritten ist, lässt sich mit vertretbarem Aufwand nicht mehr erreichen.

Die Wahrscheinlichkeit für Missverständnisse reduzieren

Einen Königsweg zur gänzlichen Vermeidung solcher Missverständnisse habe ich noch nirgends entdeckt. Zumindest keinen, der in der betrieblichen Praxis umsetzbar ist. Ich denke, diese Art Fehler wird nie zu 100% vermeidbar sein. Die Wahrscheinlichkeit für solche Fehlentwicklungen lässt sich jedoch reduzieren.

Bei der Erhebung von Anforderungen ist es enorm wichtig, immer den Kontext zu verstehen und im Auge zu behalten, aus dem heraus Personen Anforderungen stellen. Stellt man fest, dass das Kontextverständnis unterschiedlich ist, ist dies noch nicht weiter schlimm. Im Gegenteil: unterschiedliches Wissen und Verständnis können sich schließlich auch ergänzen. Stellt man jedoch fest, dass Kontextwissen widersprüchlich zueinander ist oder dass Anforderungen für Einzelne garnicht nachvollziehbar sind, obwohl sie mit darüber entscheiden müssen, so ist es nach meiner Meinung eine wichtige Aufgabe des Anforderungsmanagers, für ein gemeinsames Verständnis zu sorgen.

Ich erlebe solche Missverständnisse gehäuft bei abstrakten und komplexen Projekt-Themen. In solchen Fällen setze ich auf grafischen Darstellungen. Dinge und Zusammenhänge, die  jeder für sich im Kopf hatte, werden dadurch für alle sichtbar gemacht. Man kann plötzlich mit dem Finger auf etwas zeigen, was vorher nur ein schwammiger Begriff war. Es ist allerdings nicht leicht, wirklich gute und nutzbare Visualisierung zu erstellen. Auf der einen Seite muss eine solche Grafik einfach sein, sonst macht sich keiner die Mühe sie zu verstehen. Auf der anderen Seite muss sie präzise sein. Sie darf nicht trivial werden und damit jede Aussagekraft verlieren. Dies erfordert gutes Abstraktionsvermögen und viel Übung. Am wichtigsten aber ist eine Fähigkeit, die jeder gute Anforderungsanalyst mitbringen muss: das ehrliche Interesse an seinem Gegenüber und den Wunsch wirklich zu verstehen, aus welchem Kontext heraus sein Gegenüber spricht und agiert.

 

Hinweis:
In seinem Blog http://www.bungert.berlin/blog/ schreibt Dr. Andreas Bungert regelmäßig zu diesem Thema.

 

Dr.-Ing. Andreas Bungert is a freelance consultant and systemic coach. He facilitates complex processes of change in medium-sized enterprises, e.g. digital transformations by improving communication about business processes, IT and requirements. He is a co-founder of ARCWAY AG, the Hasso-Platter-Institute's first spin-off and has been a manager for the institute for seven years. Andreas Bungert relies on visualizations to manage complexity in projects and to integrate all parties involved. Find his blog at www.bungert.berlin/blog.

Tags:
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *