Macht und Politik sind eng mit dem Requirements Engineering verknüpft: Während des Requirements Engineerings werden unter anderem die zukünftigen Machtverhältnisse ausgehandelt. Deshalb agieren die Stakeholder auch strategisch und richten ihre Entscheidungen an ihrer persönlichen Strategie aus.
Im vorigen Artikel dieser Serie empfahlen wir, was Sie als Requirements Engineer in Ihrer täglichen Arbeit bei der Kommunikation mit den Stakeholdern beachten sollten. In diesem Artikel diskutieren wir, wie Sie während der Requirements Engineering Tätigkeiten selbst strategisch vorgehen.
Natürlich verfolgen Sie als Requirements Engineer ebenfalls strategische Ziele: Sie wollen das Projekt zum Erfolg führen. Dazu möchten Sie, dass die Anforderungen so vereinbart werden, dass am Projektende die erfolgskritischen Stakeholder möglichst zufrieden sind.
Wissen ist Macht
Domänenwissen ist keine kritische Fähigkeit für einen Requirements Engineer. Dennoch kann es helfen im Ringen um die richtige Anforderungsgestaltung den Überblick zu behalten. Kennen Sie daher alle Requirements-Quellen: Machen Sie sich mit den Stakeholdern, aber auch dem Altsystem und den relevanten Dokumenten vertraut.
Da die Stakeholder zwangsläufig einander widersprechen werden, sollten Sie außerdem frühzeitig deren Macht und Einfluss auf den Projekterfolg ermitteln. Wer könnte das Projekt stoppen oder später zum Misserfolg erklären? Wem muss ich also besonders genau zuhören und darauf achten, dessen Meinung zu wichtigen Entscheidungen einzuholen?
Erheben von Anforderungen
Bei der Erhebung der Anforderungen geht es – strategisch gesehen – darum, dass Sie die Stakeholder und Anforderungen kennen lernen und dass die Stakeholder Sie und das Projekt kennen lernen. Sie bauen eine konstruktive Beziehung auf und steuern die Einstellung der Stakeholder zum Projekt („Expectation Management“). Außerdem finden Sie heraus, wie die Stakeholder sich zu Parteien zusammengeschlossen haben. Sie sollten alle Stakeholder befragen, die Einfluss auf den Projekterfolg haben (könnten). Wenn Sie jemanden übergehen oder einzubeziehen vergessen, wird er verärgert sein. Sie erheben nicht nur die Anforderungen an die Software, sondern auch die an das Projekt.
Die Strategien der Stakeholder können das Erheben der Anforderungen erschweren. Beispielsweise könnten Beteiligte nötige Informationen verweigern. „Keine Zeit“ ist hierbei eine beliebte und schwierig zu widerlegende Ausrede. Gelingt es Ihnen nicht, die Stakeholder selbst zu motivieren, so holen Sie sich „Management Support“. Das kann bedeuten, dass der Vorgesetzte seine Mitarbeiter motiviert und dazu von der täglichen Arbeit freistellt.
Für den Fall, dass jemand unvollständige oder nicht repräsentative Informationen liefert, verlassen Sie sich nicht nur auf eine einzige Quelle. Da Sie ohnehin möglichst viele (wichtige) Stakeholder befragen, stellen Sie ruhig dieselbe Frage mehreren Personen, idealerweise solchen, die zu verschiedenen Parteien gehören.
Wenn Sie eine Gruppe von Personen zugleich befragen, spart Ihnen das zwar Zeit, und unterschiedliche Vorstellungen können sofort ausdiskutiert werden. Die Gruppendynamik kann jedoch die Ergebnisse verfälschen. Dann hilft eine Umfrage, ein repräsentatives Gesamtbild zu erhalten.
Priorisieren von Anforderungen
Das Priorisieren von Anforderungen ist hoch politisch! Alleine die Wahl der Methode kann die Macht mancher Gruppen bestärken oder schwächen. Zudem wird jeder Stakeholder versuchen, seine eigenen Lieblingsanforderungen hoch zu bewerten oder Einfluss auf die Reihenfolge der Umsetzung zu nehmen. Da Sie inzwischen den Überblick über die Anforderungen gewonnen haben, können Sie selbst einen Priorisierungsvorschlag (als „Anker“) ausarbeiten, der aus Ihrer Sicht den Projekterfolg am besten unterstützt. Ein solcher Vorschlag hilft Ihnen, den Entscheidungsprozess zu steuern, so dass das Ergebnis möglichst nahe an dieser objektiv besten Lösung liegen wird. Obwohl Sie selbst fachliche Argumente dazu bewogen haben, genau diesen Vorschlag vorzubringen, müssen diese die Stakeholder nicht unbedingt überzeugen. Versetzen Sie sich darum in deren Lage und argumentieren Sie aus der politischen Sicht des jeweiligen Stakeholders und binden Sie sie frühzeitig ein.
Validieren von Anforderungen
Bei der Validierung der Anforderungen sollen die Stakeholder bewerten, ob die Anforderungen für sie richtig sind. Dies bedeutet für die Stakeholder die letzte Gelegenheit vor der Implementierung, noch steuernd einzugreifen. Hier gilt alles zuvor gesagte: Auch hier befragen Sie alle erfolgskritischen Stakeholder, beugen falscher oder fehlender Information vor und versetzen sich bei Ihrer Argumentation in den Stakeholder. Achtung: Personen, die das Projekt sabotieren möchten, können durch die Verweigerung der Abnahme der Anforderungen das Projekt verzögern. Dies müssen Sie verhindern durch Management Support oder indem Sie eine Frist setzen nach dem Motto: „Schweigen bedeutet Zustimmung“.
Damit sind wir am Ende der Artikelserie „Requirements im Sog der Macht“. Wir freuen uns über Ihre Kommentare und Ideen.