1 Einleitung

Das interdisziplinäre Zusammenspiel Requirements Management und Psychologie wurde vom Vienna Agile Requirements Circle als “mission critical” eingestuft. Es gibt allerdings kaum Literatur die sich mit diesem Zusammenspiel beschäftigt.

Dieser Beitrag führt Thesen zu psychologischen Aspekten des Requirements Management an.

Diese sollen als Grundlage für eine weitere Diskussion des Themas dienen. Wir würden uns über Eure zahlreichen Kommentare dazu freuen!

Annahmen:
In diesem Paper werden folgende Annahmen als Tatsachen gesehen:

Agile Methoden (wie z.B: Scrum) können die Software Entwicklung signifikant verbessern

Die Qualität der entwickelten Software hängt ab vom
Grad der Einbeziehung der Endbenutzer
“Qualität” der Kommunikation und Beziehung Enbenutzer/Fachbereich/Analytiker/Programmierer

2 Klassischer Wasserfallansatz

Insgesamt ergibt der Wasserfallansatz viel zu oft eine Situation wie folgt:

Fachbereichsvertreter formuliert Anforderungen unvollständig und unter zu wenig Einbeziehung der Endbenutzer
Analytiker versucht Anforderungen zu vervollständigen, allerdings nur mit dem Fachbereichsvertretern, selten mit den Endbenutzern
Konsens zwischen Fachbereichsmitarbeiter und Analytiker wird in schriftlicher Form an die Programmierer weitergeleitet
Programmierer machen kaum Rückfragen zum Analytiker und schon gar nicht zum Fachbereich
Treten dann (wie zu erwarten) Probleme beim Einsatz der Software auf (“das ist doch nicht das was ich brauche!!”), werden die “schuldigen” auf Seite des Software Lieferanten gesucht, spätestens hier verschlechtert sich die Beziehung Fachbereich-Analytiker

Wasserfallansatz Thesen:

1. IT ist meist nicht auf gleicher Augenhöhe wie Fachbereich
– “eh nur die Techniker/Programmierer die schlechte Software liefern”
– Verglichen mit “Star-Architekten” in der Bau-Branche haben IT-Analytiker einen vergleichsweise niedriges Ansehen :-)

2. Fachbereichsvertreter blockieren oftmals den direkten Kontakt Endbenutzer->Analytiker/ Entwicklungsteam Vermutung weil:
– Verlust von Einfluss und Macht
– Angst davor selbst obsolete zu werden

3. Fachbereichsvertreter ist meist zu weit weg von den Problemen im “echten Geschäft”

4. Der lange Kommunikationsweg Endbenutzer->Fachbereichsvertreter->Analytiker->Entwicklungsteam führt notwendigerweise dazu, dass Anforderungen nicht richtig erkannt und programmiert werden.

Anm. Vladimir: Die Augenhöhe Problematik ist in meinen agilen Projekten auch vorhanden, das hat meiner Ansicht nach nicht unbedingt was mit Wasserfall vs. Agil.

Die Problematik, bzw. Konflikt liegt meiner Meinung hat folgende Gründe:

IT der 80’er Jahre war in jenen Unternehmen wo IT als kein Core Business war oder betrachtet wurde, ein sog. “Rechenzentrum IT”. Für diese Art der IT waren folgende Aspekte spezifisch:
Keine Auseinandersetzung mit fachlichen Anforderungen, eher eine unidirektionale (von IT hin zu Fachbereich) Weitergabe der Tools/Software/Systeme.
Rechenzentrum-IT hat oft selbst entschieden was für Business geeignet und was nicht geegnet war, IT hat über meiste Geld selbst verfügt
Augenhöhe-Spiel war also eher umgekehrt

Sukzessive wurden die IT Organisation hin zu Dienstleister in dem Unternehmen transformiert, was an sich gut ist:
Budget für die IT Projekte kommt aus Business Projekten, Fachbereiche haben Geld, gehen dann auch teilw. An die eigene IT vorbei, kaufen selbst Lösungen auf dem Markt
Businessziele sollen mehr in Vordergrund stehen

Konflikte welche dabei entstehen sind folgende:

Nachdem Business nun Geld der IT in der Hand hat, führt es zu eine Umkehr der Augenhöge-Differenz. Die “alte IT” will sich wiederum mit der gezwungenen Transformation nicht abfinden, IT ist gemacht von den Technikern, und diese hinterfragen nicht die Businessziele, versuchen nicht neue Rolle wahrzunehmen, sondern tendieren in tiefe technische Diskussionen (WIE statt WAS).
In Fachbereichen wollen die Leute selbst auch nicht die eigenen Ziele hinterfragen, sondern denken auch gerne in Lösungen (WIE statt WAS), sehr oft ist also als Konfliktpotential ein Fachbereichslösungsansatz versus IT-Lösungsansatz, beide Gruppen sind also längst in WIE-Modus.

Ich denke es die Kommunikationsengpässe auch in Agilen Methoden durchaus gibt: daher ist z.B. die Rolle des “Product Owners” da, als der Sprachrohr der Endkunden. Agilität bietet eigentlich eher die Möglichkeit, dass man früher die Konsequenzen eigener Entscheidungen welche auch Konfliktpotential hatten, erfährt (z.B. bei Präsentation der entwickelten User Stories nach einem Sprint) und bietet einer Person/Gruppe dass sie daraus lernt und zu einem sinnvolleren Konsens für das Inhalt des nächsten Sprint kommt.

Diese Fähigkeit, die Zwischenergebnisse als Teil der Diskussions- und Entscheidungsgrundlage für die nächsten Schritte heranzunehmen, ist m.Meinung nach im Hinblick auf entstandene Gruppendynamik und soziale Verhältnisse zwischen den Parteien estentiell.

3 Scrum

Scrum bietet einen guten Lösungsansatz um einen direkten Kommunikationskanal zwischen Endbenutzer und Programmierern zu ermöglichen.
Voraussetzung: Product Owner schafft es sich zurückzunehmen und sich in einer Vermittlerrolle zu sehen.
Product Owner und Analytiker gestalten den Prozess der Anforderungserhebung und sorgen dafür dass die richtigen Leute über die richtigen Dinge reden und geeignet dokumentieren
Product Owner und Analytiker sind eher Consultants am Weg zur passenden Software

 

Abb. 2: Wünschenswerte Situation in Scrum Projekten
Thesen:
1. Scrum führt dazu, dass Fachbereich und IT “im selben Boot” rudert und somit zu einer Verbesserung in der Beziehung
2. Rolle des Product Owners ist problematisch, er formuliert Anforderungen meist unter zuwenig Einbeziehung der Endbenutzer
3. Fordert der Software-Lieferant ein frühzeitiges Einbeziehen der Endbenutzer so wird das häufig vom Product Owner abgeblockt. Vermutung weil:
– Verlust von Einfluss und Macht
– Angst davor selbst obsolete zu werden

4 Zu diskutierende Fragen:
Die vorherrschende organisatorische Trennung zwischen “Fachbereich” und “IT” wird durch Scrum aufgeweicht. Ist sie im Lichte agiler Methoden nicht eher ein Hindernis und mittelfristig abzubauen?
Wie bringt man eine Organisation dazu sich im Dienste der friktionsfreien Erstellung von Software mit Scrum neu aufzustellen?

Wie schafft man es als Software Lieferant eine Situation wie in Abbildung 2 gezeigt zu etablieren?
Vertrauen beim Kunden herstellen
“Gleiche Augenhöhe” frühzeitig etablieren (aber wie???)
Erfolge vorweisen
Aber was wenn ein “Machtmensch” als Product Owner eingesetzt wird und die Endbenutzer dennoch abschirmt?

Welche Moderations/Kommunikationstechniken brauchen wir um den breiten Kommunikationskanal zwischen Endbenutzern und Programmierern zu managen?

Psychologische Aspekte im RM – Thesen V0.2