Als Requirements Engineer werden Sie nicht nur darum angeheuert, weil sie die UML und das eine oder andere Tool beherrschen, sondern auch, um professionell und objektiv Anforderungen zu erheben, ohne selbst ein Stakeholder zu sein. Denn jeder Projekt-Stakeholder verfolgt außer den Projektzielen – oder manchmal sogar anstatt ihrer – seine persönlichen Ziele. So hat er nicht nur das Projektwohl im Sinne, sondern vertritt auch die Interessen seiner Abteilung, seiner Karriere oder anderer Projekte.
Im ersten Artikel dieser Serie verwiesen wir bereits auf Leitsätze für den Requirements Engineer. Insbesondere müssen Sie akzeptieren, dass das Requirements Engineering stets innerhalb eines Umfelds von Macht und Politik stattfindet, diese Randbedingungen kennen und für Ihre Arbeit nutzen.
In diesem Artikel geben wir aufgrund unserer Erfahrung Tipps, was ein Requirements Engineer in Meetings, beim Mailen, bei der Vorbereitung des Requirements Engineering und bei Entscheidungen beachten sollte.
Die Macht des Requirements Engineers
Als Requirements Engineer haben Sie meist keine formale Macht, sondern stehen in der Hierarchie des Unternehmens und des Projektes nicht sehr weit oben. Gerade deshalb hilft es ihnen bei der Arbeit, informelle Macht zu erlangen, beispielsweise durch Ihre Kompetenz. Im Requirements Engineering sollte Sie darum keiner übertreffen und am besten kennen Sie sich zusätzlich noch bestens aus mit der Fachdomäne und der verwendeten Technologie.
Best Practices für Meetings
Meetings vorbereiten: Sich auf eine Besprechung nicht oder schlecht vorzubereiten, ist gefährlich. Recherchieren Sie vorher fachliche Fakten und führen Vorgespräche mit wichtigen Beteiligten, um deren Position zu erfahren und vielleicht sogar zu beeinflussen.
Einladungen versenden: Es ist weniger schlimm, zu viele als zu wenige Personen einzuladen. Lassen Sie jemanden aus, dann fühlt er sich übergangen und vermutet schlimmstenfalls eine Verschwörung. Wird er zu einer für ihn unnötigen Besprechung eingeladen, kann er selbst entscheiden, fort zu bleiben.
Sichtbarkeit: Als Requirements Engineer präsentieren Sie sich und Ihre Arbeit oft und gut, auf möglichst vielen Meetings.
Aufstehen und handeln: Wer agiert, steuert Mehrheiten und fachliche Diskussionen. Der beste Weg in Besprechungen zu agieren ist jedoch nicht das gesprochene Wort, sondern eine Zeichnung auf den Flip-Chart, Whiteboard oder Ähnlichem. Zeichnungen können als Basis gemeinsamer Diskussion fungieren und später die Meeting-Ergebnisse dokumentieren.
Revier verteidigen: Zeichnungen sind Eigentum des Zeichners. Greift eine weitere Person in Ihre Zeichnung ein und ergänzt sie, so eignet er sich Ihr Eigentum mit an. Dies zuzulassen oder abzuwehren sollte eine bewusste Entscheidung sein. Genauso gehören auch der Platz auf dem Tisch zu Ihrem Review sowie Ihr Sitzplatz und Ihre Kaffeetasse.
Nachbereitung: Besprechungen müssen immer nachbereitet werden, um Ergebnisse zu sichern und zu verifizieren. Daher werden Protokolle erstellt, die Ergebnisse und Entscheidungen dokumentieren. Anschließend müssen diese Dokumente allen Betroffenen bekannt gemacht werden, mit der Bitte um Korrektur, falls dies notwendig ist. So können Sie später argumentieren, dass ein Schweigen Zustimmung bedeutet. Wenn Sie das Protokoll schreiben, gestalten Sie auch die bleibende Erinnerung an die Besprechung.
Best Practices für E-Mails
Wo E-Mails Sinn machen und wo nicht: E-Mails eignen sich hervorragend, um Ergebnisse zu dokumentieren. Schwierige Themen verdienen jedoch einen persönlichen Besuch und klären Sie am besten im Gespräch. Wieder gilt, dass aktives Agieren besser ist als passiv abzuwarten.
Die CC-Falle: Erscheint in E-Mails plötzlich ein Vorgesetzter im CC-Feld, signalisiert dies: Ab diesem Moment ist besondere Vorsicht angeraten, denn nun ist die Sache politisch.
Nachverfolgen: Verfolgen Sie wichtige Themen nach. Hierzu eignen sich entsprechende Funktionen in MS Outlook.
Best Practices für die RE-Vorbereitung
Je mehr der Requirements Engineer weiß, umso besser. Insbesondere sind folgende beiden Aktivitäten strategisch wichtig:
Scoping: Damit definieren Sie nicht nur den Projektumfang, sondern grenzen auch die Stakeholdern ein und steckt die relevante politische Landschaft ab.
Stakeholder-Analyse: Ermitteln Sie bei der Stakeholder-Analyse auch deren Macht und Einfluss auf den Projekterfolg.
Aktualisieren Sie beides regelmäßig.
Die weiteren Artikel
In weiteren Artikeln diskutieren wir spezielle Best Practices für die Erhebung, Dokumentation, Validierung und Verwaltung von Anforderungen ein. Wir freuen uns über Ihre Kommentare und Ideen. Zu Teil 3.