Teambuilding im Requirements Engineering

Nicht alle, die in einem IT-Projekt arbeiten (müssen), verfolgen den Projekterfolg als oberstes Ziel. Natürlich freut sich niemand, wenn sein Team, einzelne Kollegen oder sogar er selbst wegrationalisiert werden, sich seine Aufgaben ändern oder die Arbeit komplizierter wird. Das ist vorhersehbar. Gelangt man als externer Berater in das Macht- und Intrigengespinst eines Kundenunternehmens und versucht, dort vollständige und korrekte Anforderungen zu sammeln, dann muss man Freund und Feind voneinander unterscheiden können und den Flohzirkus dazu bringen, ein Team zu werden oder zumindest ausnahmsweise wie ein Team zusammenzuarbeiten.

Sie kennen vermutlich die Redewendung „einen Sack Flöhe hüten“. Darin steckt das Bild, dass jeder Floh unkontrollierbar in eine andere Richtung davon springt. Ein Team arbeitet eher wie ein Gespann, das die schwerste Kutsche in dieselbe Richtung zieht, aufeinander abgestimmt im selben Takt.

Nun können wir leider als Requirements Engineer oder Berater unsere Ansprechpartner nicht physisch festbinden oder gar eine Peitsche schwingen. Hierarchisch gesehen sind wir oft nicht der Kutscher, sondern auch nur ein Pferd. Wir müssen sie eher mit unsichtbaren Fäden binden und auf ein gemeinsames Ziel ausrichten.

Wie funktioniert das? Folgende Prinzipien sind zu beachten:

• Deeskalation und Zuversicht: Der Kutscher ist verantwortlich.
• Die Situation verstehen, Verständnis zeigen und dann auf der Sachebene weitermachen.
• Gemeinsame Ziele finden und ausrufen.
• Die Zügel werden straff geführt.
• Zuckerbrot und Peitsche.

 

Deeskalation und Zuversicht: Der Kutscher ist verantwortlich

Auf jedem Kutschbock sitzt mit gutem Grund nur ein einziger Kutscher. Griffen mehrere Personen gleichzeitig in die Zügel, würden die Projektmitglieder durch widersprüchliche Aussagen verwirrt. Die Uneinigkeit von zwei Requirements Engineers oder Konflikte zwischen Requirements Engineer und Projektleiter kosten unnötig Kraft und können durch übelmeinende Stakeholder ausgenutzt werden, indem sie beide gegeneinander ausspielen. Darum ist für das Requirements Engineering und damit für den Projektumfang und die Change Requests genau eine Person verantwortlich. Dies gilt insbesondere in schwierigen Projekten bzw. einem schwierigen Umfeld. Diese Person will nur eines, nämlich mit dem Requirements Engineering voran zu kommen.

Idealerweise ist der Requirements Engineer nicht nur inhaltlich für das Arbeitspaket des Requirements Engineering verantwortlich, sondern leitet dieses Arbeitspaket eigenverantwortlich. Da er eine klare Vorstellung vom Vorgehen und den zu erzielenden Ergebnissen hat, kann er sich – schlimmstenfalls im Schneckentempo – hartnäckig und konsequent an seinem geplanten Vorgehen entlang hangeln. Alle Nebenkriegsschauplätze können den Fortschritt zwar verlangsamen, aber das Projekt nicht ganz vom Weg abbringen. Eine saubere Requirements-Engineering-Vorgehensweise ist darum gerade hier eine Überlebensstrategie.

Der Requirements Engineer benötigt in schwierigen Projekten besonders viel Charakterstärke. Jede Schwäche würde sofort ausgenutzt. Ist er leicht verletzlich, dann werden ihn die Projektsaboteure verletzen. Mir hat es immer geholfen, daran zu denken, dass die Aggressionen, auch persönliche Beleidigungen gegen mich gar nicht wirklich mich meinen, sondern es ganze Zeit nur um eine ungewollte Software, eine unwillkommene Prozessänderung oder interne Streitigkeiten geht, die schon das Klima vergifteten, bevor ich kam. So hält man sich selbst emotional heraus.

Zum Glück kann man als externer Berater die internen Spielchen beim Kunden aus der Distanz betrachten. Sie sind nicht existenzbedrohend für mich, wohl aber für mein Projekt. Und darum gilt es zu kämpfen. Vertrauen Sie darauf, dass selbst der schlimmste Gegner des Projekts es sich nicht wirklich leisten kann, es ganz alleine zu kippen und damit dem Arbeitgeber enormen finanziellen Schaden zuzufügen. Verlieren Sie nie den Glauben, dass es für alles eine Lösung gibt. Darum gibt es für Sie auch keinen Grund, emotional zu werden, Konflikte weiter anzuheizen oder sich auf die eine oder andere Seite ziehen zu lassen. Deeskalieren Sie, das heißt, Sie versuchen, projektbezogene Konflikte zu glätten oder aus dem Projekt draußen zu halten. Eigene Fehler zuzugeben und aufzuzeigen, wie man ihn auszubügeln gedenkt, gehört auch dazu. Sie wissen, wohin Sie wollen und richten alles danach aus.

Die Situation verstehen, Verständnis zeigen und dann …

Um zu deeskalieren und nicht versehentlich etwas Falsches zu sagen, müssen Sie ganz genau verstehen, was hier gespielt wird, wer mit wem paktiert und gegen wen konkurriert, wer was befürchtet. Ein Kollege von mir sagte mal ganz fröhlich: „Dank der neuen Arbeitsweise wird alles hier viel schneller gehen. Dann können Sie nachmittags früher heim gehen und haben mehr frei.“ Das sollte den Mitarbeiter zum Beitrag im Projekt motivieren, aber zu dem Zeitpunkt wussten wir nicht, dass die Mitarbeiter eine derartige Effizienzsteigerung befürchteten, dass manche Kollegen zukünftig ganz zu Hause bleiben müssten. Die wirkungsvollen Argumente hängen von der Situation ab. Und die müssen Sie so gut wie möglich kennen.

Die wichtigste Quelle für Informationen über die Interessen und Aversionen der Mitarbeiter ist eine Person (oder auch mehrere), die vom Projekterfolg profitiert und schon lange im Unternehmen arbeitet. Das sollte der beim Kunden verantwortliche Projektleiter sein, der bei einem Projektmisserfolg verantwortlich gemacht würde. Aber auch der Projektsponsor, Anwender oder eine Sekretärin, die von den ganzen Intrigen die Nase voll hat, kann wertvolle Informationen liefern. Die wichtigsten Quellen haben sich mir bisher unerwartet erschlossen. Oft war es nicht die Person, die mir als Ansprechpartner genannt worden war oder das Meeting, bei dem „Stakeholdermanagement“ auf der Agenda stand. Eine wichtige Rolle spielten informelle Kommunikationsgelegenheiten wie gemeinsame Mittagessen, ein Flurgespräch nach Feierabend, ein Vieraugengespräch mit einem eher stillen, aber aufmerksamen Teammitglied. Oft haben sich diejenigen von selbst an mich gewandt, um mir zu helfen. Vermutlich brachte mir das oben genannte (systematische Arbeit, Zuversicht und Deeskalation) Sympathien und Vertrauen ein. Beides ist nötig, denn es ist für einen Mitarbeiter nicht einfach, einen Kollegen bei mir als Projektsaboteur anzuschwärzen oder mich vor jemandem zu warnen. Absolute Vertraulichkeit ist die Voraussetzung dafür.

Schon manches Mal habe ich durch eine gezielte Nachfrage Schleusen geöffnet. Ich sage etwas, sehe den Unwillen im Blick des anderen und sage: „Ja, ich verstehe, dass Ihnen das nicht gefällt. Schließlich folgt für Sie daraus…“ Und dann sagt er mir schon, ob ich richtig geraten habe oder nicht. Unzufriedene Stakeholder machen sich gerne Luft. Seien Sie als der Requirements Engineer doch derjenige, der diesen Leuten zuhört. Gerade die Besorgten und die Projektgegner sind wertvolle Quellen für inoffizielle Informationen, historische Fakten und mögliche Projektrisiken. Und was auch immer Sie zu hören bekommen, es sind keine unlösbaren Probleme, sondern die Informationen lassen sich konstruktiv in Software-Anforderungen umformulieren.

Die Situation zu verstehen ist die eine Sache. Aber was macht man nun mit diesem Wissen? Verständnis und Empathie zu zeigen, ist eine gute Strategie. Die Existenzängste anderer Leute kann man nicht einfach ignorieren. Die meisten Sorgen sind berechtigt. Manche kann man zum Glück ehrlich zerstreuen.

Knifflig wird es manchmal, vertrauliches Wissen zu nutzen, ohne zu verraten, dass man es besitzt und woher. Wie soll man beispielsweise begründen, dass man Informationen anhand einer zweiten Quelle überprüfen will, wenn doch der ach so engagierte Key User schon stundenlang geplaudert hat? Da muss man diskret vorgehen.

Natürlich können Sie es nicht allen recht machen. Der eine will grün, der andere rot. Dann bringen Sie das Thema auf den Tisch, und die Verantwortlichen beim Kunden sollen das entscheiden. Schlagen Sie am besten schon Lösungen und Kompromisse vor. Es ist nicht Aufgabe des Requirements Engineers, Entscheidungen über die Anforderungen zu treffen, sehr wohl aber, solche Entscheidungen vorzubereiten, zu moderieren und zu unterstützen. Bleiben Sie am besten immer auf der Sachebene. Ziehen Sie aus allem, was Sie hören und erleben, Schlussfolgerungen für das Requirements Engineering heraus. Nicht mehr und nicht weniger.

Gemeinsame Ziele finden und ausrufen

Ja, verschiedene Stakeholder verfolgen unterschiedliche Ziele. Einige davon sind nicht miteinander vereinbar. Aber auf einer abstrakten, allgemeinen Ebene lassen sich jedoch trotzdem gemeinsame Ziele finden, auf die Sie den Flohzirkus einschwören können. Erinnern Sie gerne regelmäßig daran: „Wir alle wollen doch, dass das XY erfolgreich eingeführt wird. Dann lassen Sie uns nun gemeinsam herausfinden, wie wir das am besten schaffen.“

Die Zügel werden straff geführt

Behalten Sie möglichst die Kontrolle über alles. Mischen Sie sich in alles ein, stellen Sie viele Fragen, teilen Sie anderen mit, was Sie planen und wollen. Die anderen müssen ständig spüren, dass Sie da sind und sich kümmern. Ihnen sollte nichts entgehen, kein Meeting, kein Gerücht, keine Unzufriedenheit. Kommentieren Sie alles. Notfalls fügen Sie passende Klauseln in Verträge ein oder vereinbaren mit den Stakeholdern Regeln wie z. B. „jeder Change Request muss offiziell beantragt und von mir genehmigt werden“. Je engmaschiger Ihre Kontrolle, umso früher und konkreter entdecken Sie versuchte Sabotageakte.

Zuckerbrot und Peitsche

Natürlich sind Sie immer nett und freundlich zu allen. Gute Arbeit wird gelobt. Aber wenn es mal nicht gut läuft, dann sagen Sie das auch. Die Konsequenzen von schlampiger Arbeit zeigen Sie deutlich auf und rechnen das gerne auch in Personentagen und Euro vor.

Bei einem Kunden, wo Entscheidungsprozesse nicht voran kamen und Verantwortung gerne wie ein schwarzer Peter herumgeschoben wurde, stand ausdrücklich im Vertrag, dass Entscheidungen innerhalb von 48 Stunden zu treffen sind. Andernfalls verschiebe sich der Liefertermin entsprechend. Das war letztlich nur eine leere Drohung, aber ich konnte die Klausel wenn nötig zitieren, um Tempo zu machen.

Fazit

Teambuilding im Requirements Engineering ist nicht einfach. Natürlich gibt es keine Blaupause oder einen 10-Punkte-Plan, mit dem jeder gut funktionierende Teams zaubern kann. Auch die genannten Prinzipien machen nicht aus jedem Sack Flöhe ein Team. Aber Sie schaffen es zumindest, die Flöhe mehr oder weniger vor Ihren Karren zu spannen und voran zu kommen! Alles was Sie dafür benötigen sind

• klare Verantwortlichkeiten und Vereinbarungen,
• systematische Arbeit und Interesse an Lösungen,
• Vertrauen, Verschwiegenheit, Sympathie und Zuversicht,
• Empathie und Neutralität.

Und ein bisschen Erfahrung schadet vermutlich auch nicht.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Unter http://www.herrmann-ehrlich.de/ bloggt Frau Dr. Andrea Herrmann regelmäßig über Requirements Engineering und Software Engineering.

Alles Wichtige über Requirements Engineering auf 37 Seiten jetzt als Download zum Mitnehmen.

Dr. Andrea Herrmann hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.