Welche sind die notwendigen Eigenschaften eine Requirements Engineers? Wer IREB CPRE zertifiziert ist, das Buch [1] gelesen oder an einem HOOD Training zur Vorbereitung auf die CPRE Zertifizierung teilgenommen hat, kann diese Frage mit Leichtigkeit beantworten.
Heute möchte ich mit diesem Beitrag anhand der Eigenschaft „Konfliktlösungsfähigkeit“ demonstrieren, wie praxisrelevant diese geforderten Eigenschaften an einen Requirements Engineer sind.

In [1] heißt es: „Der Requirements Engineer muss Konflikte erkennen, zwischen den Parteien vermitteln und schließlich durch den Einsatz geeigneter Techniken den Konflikt auflösen.

Ist Konfliktlösungsfähigkeit wirklich eine wichtige Eigenschaft eines Requirements Engineers?

Der Requirements Engineer löst auch Konflikte auf

Der Requirements Engineer löst auch Konflikte auf.

Ich gebe zu, dass ich bei meiner damaligen Prüfungsvorbereitung in Frage gestellt habe, ob „Konfliktlösungsfähigkeit“ wirklich eine Eigenschaft eines Requirements Engineers ist, bzw. sein muss. Schließlich gibt es ja fachliche und disziplinarische Vorgesetzte, die Konflikte zwischen betroffenen Parteien mit einem Machtwort auflösen können. Warum sollte das die Aufgabe eines Requirements Engineers sein? Und warum gibt es unternehmensintern überhaupt Konflikte, wenn doch alle das gemeinsame Ziel haben, dem Kunden ein qualitativ hochwertiges Produkt zu liefern?

In einem Systementwicklungsprojekt, in welchem ich über einen längeren Zeitraum als Requirements Engineer eingesetzt war, erlebte ich erstmalig, wie ein Konflikt zwischen zwei Teammitgliedern mehrmals eskalierte. Ich erinnerte mich an den in [1] erklärten „Beziehungskonflikt“: „Ein Beziehungskonflikt ist durch starke Emotionen, stereotype Beziehungskonzepte, schlechte Kommunikation oder negatives zwischenmenschliches Verhalten von Stakeholdern untereinander (z.B. Missachtung, Beleidigung) gekennzeichnet.“ So ziemlich alle beschriebenen Aspekte trafen auf die Konfliktsituation zu:

  • Zwischen Teammitglied A (A) und Teammitglied B (B) wurde es in den Diskussionen sehr laut.
  • A akzeptierte die Vorschläge von B nicht.
  • B stellte, aufgrund A’s Vorgängerprojekt, voreilig die Kompetenz von A in Frage.
  • Schnittstellen zwischen Implementierungen von A und B wurden nicht mehr gegenseitig auf direktem Wege kommuniziert.
  • A und B wollten, aufgrund ihrer schlechten zwischenmenschlichen Beziehung, nicht gemeinsam zu wichtigen Kundenterminen.
  • A und B konnten sich nicht mehr vorstellen, in zukünftigen Projekten zusammenzuarbeiten.

Der Requirements Engineer kann zwischen den betroffenen Parteien vermitteln

Obwohl Gespräche mit dem Vorgesetzten nicht ausblieben, verspürte ich als Requirements Engineer instinktiv das Bedürfnis, zwischen den beiden Teammitgliedern zu vermitteln.

Im ersten Schritt konnten Sie in Vieraugengesprächen mit dem Requirements Engineer Dampf ablassen und fühlten sich danach wieder motivierter, so dass diese Gespräche auch zum Teil als Stakeholderinterviews genutzt werden konnten. Hier versuchte ich insbesondere herauszufinden, ob es bei den Systemfunktionen im Hoheitsgebiet des jeweiligen Teammitglieds nicht doch noch Schnittstellen zu den Funktionen des anderen Teammitglieds gab, die eventuell durch die stark emotionalen Diskussionen in Vergessenheit geraten waren.
Anschließend habe ich immer wieder deutlich gemacht, wie wichtig es ist, sich trotz Streitigkeiten professionell zu verhalten und an gemeinsamen Meetings teilzunehmen. Ich lud zu diesen Meetings ein, verließ mich jedoch nicht auf die Pop-up-Erinnerung der Kalender, sondern holte die Teammitglieder persönlich an deren Schreibtischen ab um gemeinsam zum Besprechungszimmer zu laufen.
Das Beharren meinerseits darauf, die entsprechenden Teammitglieder gemeinsam im Meeting sitzen zu haben, war notwendig, um die Wichtigkeit für die Erreichung des gemeinsamen Ziels – für die Zufriedenheit des  Kunden zu sorgen – zu verdeutlichen.

A und B werden mit Sicherheit keine besten Freunde mehr, jedoch ist die Einsicht, auf professioneller Basis zu kommunizieren, wieder vorhanden.

 

[1] Klaus Pohl, Chris Rupp, Basiswissen Requirements Engineering, 4. Überarbeitete Auflage, dpunkt.verlag, 2015