Schlüssel für bessere Anforderungsermittlung

by | 06.11.2017 | Requirements Engineering

Probleme bei der Ermittlung von Anforderungen

Die meisten IT-Projekte fangen immer gleich an: mit einem Berg von Dokumenten, die nur mit einem Gabelstapler von einem Büro zum anderen transportiert werden könnten und von dem man schon beim ersten Anblick weiß: „Das wird mich eine Weile beschäftigen“. ITler stehen vor einem Wust an Informationen in Form von Dokumentationen, Prozessbeschreibungen und Trainingsmaterial, aus denen sie die Anforderungen ableiten sollen. Doch dabei wird oft das Wichtigste außen vor gelassen: der Mensch. Der Nutzer, der am Ende mit dem neuen System arbeiten soll, taucht in diesen Dokumenten in der Regel nicht auf.

Was dann passiert, wiederholt sich in hunderten Projekten jeden Tag: Nutzer fühlen sich unverstanden, lehnen das System oder gar das ganze Projekt ab und das Projektziel rückt in weite Ferne. Dabei wäre es so einfach, die Anforderungen dort herauszufinden und aufzunehmen, wo sie entstehen. Nämlich beim Nutzer. Nur muss man dafür zum Äußersten greifen und miteinander reden.

2012 begleitete ich als Teilprojektleiterin ein IT-Projekt bei einem Werkzeughersteller. Mein Kunde hatte einige Jahre zuvor ein IT-Projekt durchgeführt, das nur mit Qualitätseinbußen und einem höheren Budget abgeschlossen werden konnte. Die Geschäftsleiter und ITler hatten später in Lessons Learned Workshops die Anforderungen als einen Knackpunkt herausgearbeitet. Ab einem gewissen Zeitpunkt fehlte allen der Überblick über das Gesamtbild und niemandem war es bewusst, dass Anforderungen fehlten, zu denen später teuer nachgebessert werden musste.

Für dieses neue Projekt hatte das Unternehmen sogar in eine Software investiert, in der die IT die Anforderungen aufnehmen, priorisieren und tracken konnte.

Doch die beste Software und der beste Projektmanagement-Ansatz sind nur so gut, wie die Qualität der Gespräche, die für die Informationen sorgen, welche im Projekt verarbeitet werden sollen. Wird die Tracking-Software lediglich mit einem Teil der Anforderungen gefüttert, wird eine lange Zeit nur mit einem Teil der Anforderungen gearbeitet. Auch agile Projektmanagement-Ansätze sind in ihren Möglichkeiten begrenzt, denn sie geben den Beteiligten zwar die Möglichkeit, schnell auf Veränderungen einzugehen, aber nicht, um implizites Wissen aus einem System heraus zu kitzeln.

Ich war erschüttert über das Ausmaß, mit dem in der Entwicklungsphase Anforderungen übersehen wurden. Es fehlte der Austausch zwischen den Menschen. Wieder stand das Unternehmen an dem Punkt, an dem fehlende Anforderungen Nacharbeit mit sich brachten.

Mehr und mehr stieg ich in die Vermittlerrolle zwischen IT und Fachbereich ein, um weitere Verluste zu verhindern. Und ich erkannte, an welchen Stellschrauben gedreht werden müsste, um den Austausch zwischen den Beteiligten zu ermöglichen.

Kollegen werden zu Anforderungshelden

Auch heute ist es noch Gang und Gäbe, dass die IT die Anforderungen erstellt, meist als Essenz endlos scheinender Dokumentenberge.

Doch es hat sich gezeigt, dass es gleich in mehreren Punkten sinnvoll ist, die Fachbereiche nicht nur früh mit einzubinden und eng mit der IT arbeiten zu lassen, sondern eine dauerhafte Zusammenarbeit anzustreben. Beide Bereiche können voneinander lernen, verstehen also auch besser die Restriktionen, denen die Arbeit des jeweils Anderen unterliegt. Mitarbeiter aus dem Fachbereich können Informationen aus erster Hand direkt an ihre Kollegen weiterleiten und Feedback aufnehmen, wobei sie Sachverhalte besser verstehen und verständlich kommunizieren können. Damit können alle Parteien die Change Management-Aktivitäten unterstützen, für die klare und bidirektionale Kommunikation eine Basis ist.

Schnell fanden sich zwei Kollegen aus dem Fachbereich, die mit der IT enger zusammenarbeiten wollten. Im Laufe der ersten Tage war die Überraschung oft groß, wenn vorgefertigte Meinungen und Bilder bestätigt oder revidiert werden mussten.

Der Name ‚Anforderungshelden‘ entstand während des Entwicklungsprozesses und war eine Erfindung eines IT-Kollegen. Er gefiel dem Team so gut, dass sie ihn für sich übernahmen.

Der Nutzer, das unbekannte Wesen

Als erste Quelle für Anforderungen dienen heute noch immer Dokumentationen, Prozessbeschreibungen oder Trainingsmaterial alter Systeme.

Werden die Anforderungen dagegen von Nutzern erfragt, die schließlich die Prozesse kennen und, was in wirklich jeder Organisation passiert, sie an ihre Arbeitsweise angepasst haben, ist der Umfang der Anforderungen nicht nur vollständiger, die Nutzer können auch direkt in den Prozess eingebunden werden. Übernehmen sie die Verantwortung für ‚ihre‘ Anforderungen, sind sie selbst schneller bereit, sich mit dem neuen System als Gesamtes auseinander zu setzen.

Die befragten Kollegen waren schnell Feuer und Flamme, weil sie merkten, dass ihre Mitarbeit wirklich einen Sinn machte. Sie wurden zu exklusiven Stakeholdern für ihre eigenen Anforderungen, wurden über Änderungen informiert und konnten den aktuellen Stand in einer offen verfügbaren Version des Lasten- und später Pflichtenheftes einsehen.

Mein Kunde ging sogar dazu über, einzelne Schlüsselfunktionen des neuen Systems von den Nutzern testen zu lassen, die die Anforderungen dafür gegeben hatten.

Anforderungsermittlung - Sketchnote

Drei Schlüssel zur Anforderungsermittlung: Wissen zusammenfügen, Verantwortung abgeben, Begeisterung wecken.

Präsentationen, Meetings und Workshops

Ein Meeting ist schnell aufgesetzt, doch die Stakeholder werden noch viel zu oft mit Präsentationen gequält, die aus der PowerPoint-Hölle kommen und in der sich Screenshots und Textwüsten abwechseln.

Damit Teilnehmer von Meetings und Workshops nicht nur körperlich anwesend sind, sondern auch geistig mitmachen, braucht es weit mehr als betreutes Vorlesen. Einen Anfang macht eine Aufteilung der Meetings in verschiedene Klassen, wie beispielsweise Informations- und Diskussionsmeetings. Informationsmeetings finden immer dann statt, wenn eine Gruppe von Stakeholdern über einen Sachverhalt informiert werden soll, eine einfache Email aber nicht mehr ausreicht. Diskussionsmeetings gehen da einen Schritt weiter und erlauben den Austausch über den Sachverhalt. Je nach Art des Meetings ist auch der Teilnehmerkreis genau einzugrenzen.

Generell gilt es, Informationen so ansprechend wie möglich zu transportieren, denn nur dann kommen sie wirklich in den Köpfen der Teilnehmer an. Das kann alles von einem vorbereiteten Flipchart bis zu einem Rollenspiel mit dem neuen System sein.

Einmal in der Woche hielten wir eine Videokonferenz mit allen interessierten Stakeholdern ab. Sie wurde aufgezeichnet und konnte später als Video im Intranet angesehen werden. Die Anforderungshelden und das gesamte Entwicklerteam ging auf vorab gestellte Fragen ein und erklärte Änderungen. Sobald es möglich war, wurden alle Fragen und Änderungen live im System gezeigt.

Nach den ersten Meetings, in denen sie Live-Präsentationen abgehalten hatten, wurden die Anforderungshelden vertrauter damit und hielten zu wichtigen Meilensteinen wie einem Jahrestreffen Rollenspiele, die sie bei der Nutzung des Systems zeigten. Die Stakeholder waren begeistert.

Fazit

Wer Anforderungen umfassend finden möchte, darf sich nicht auf Dokumente beschränken. Jede Organisation hat ihre ganz eigenen Regeln und Prozesse, und um die zu finden, muss man mit den Menschen dort sprechen. Damit das gelingt, braucht es manchmal ein wenig Übersetzung zwischen den doch sehr unterschiedlichen Welten der IT und der Fachbereiche.