17. Juni 2021

Mit Systematik zum Erfolg – Businessanalyse als kritischer Erfolgsfaktor

Blog-Beitrag-Businessanalyse

Auf was es bei der Spezifikation von Anforderungen ankommt, wann welche Methode am sinnvollsten ist, welchen Rucksack ein erfolgreicher Anforderungsaufnehmer mitbringen soll und wie Agilität damit zusammenhängt.

Für den Projekterfolg braucht es die richtigen Werkzeuge. Als kritischen Erfolgsfaktor sehe ich die Aufnahme und Bewertung der Anforderungen – in Persona eine Verschmelzung der Rollen Business Analyst und Requirements Engineer. Mit den richtigen Methoden und Techniken werden die Wünsche und Bedürfnisse des Auftraggebers identifiziert, bewertet und dokumentiert. Auf Basis dieser Erkenntnisse können die Entwickler und Architekten das System konzipieren und entwickeln. Zur Qualitätssicherung trägt ebenfalls der Business Analyst bei, welcher das entwickelte System fachlich testet.

Was macht den Business Analyst unverzichtbar in der agilen Projektwelt?
Scrum, Hermes 5.1 oder SAFe sind zukunftsträchtige Projektführungsmethoden und den Business Analyst sehe ich klar in der Rolle als Product Owner in der agilen Gegenwart. Auch bei wasserfallähnlichen Methoden wie Hermes hat der Business Analyst eine offizielle Rolle inne und agiert als Koordinator oder Koordinatorin mit dem Auftraggebenden, den Developern und Designern.

 

 

Was der Business Analyst nebst seinen Erfahrungen und seinem Methodenrucksack auch noch mitbringen muss, habe ich in meiner Top 5 der wichtigsten Key Soft Skills zusammengestellt:

  • Zuhören: Menschen reden gerne, Auftraggebende reden gerne, Endanwender reden gerne. Der Business Analyst muss die Fähigkeit haben, relevante Informationen zu filtern und aufzunehmen. In Kombination mit dem Verstehen des «grossen Ganzen», den Anforderungen und den Möglichkeiten ist das eine sehr wirksame Methode, um rasch und fokussiert Entscheidungs- und Diskussionsgrundlagen zu erarbeiten.
  • Hartnäckigkeit: Ob beim beschriebenen Zuhören oder bei der Analyse der Unterlagen, eines Prototyps oder der aktuellen Webseite – es bedarf der Hartnäckigkeit, Dinge anzusprechen und auf Herausforderungen aufmerksam zu machen, welche zwar klar ersichtlich sind, über die aber niemand sprechen möchte. Natürlich immer mit der nötigen Eloquenz und Fingerspitzengefühl: «Wieso ist das so?», «Warum machen Sie es so?», «Auf welche Fakten stützen Sie Ihre Annahmen?».
  • Strukturen: Sei es in der Dokumentation oder in Meetings; Strukturen sind das A und O und diese zu bewältigen, ist zentral. Gerade zu Beginn muss der Business Analyst der Agilität trotzen und zwei Fundamente legen: die Vision und den Backlog.
  • Fokus: Gerade in der agilen Gegenwart und in der Kreativitätsphase ist es oft schwierig, den Fokus zu behalten. Die Rahmenbedingungen zu kennen und anzuwenden und die Schranken aufzuzeigen und auch einzugreifen, wenn diese aufzubrechen drohen, ist essentiell für meine Arbeit.
  • Kommunikation: Nebst dem Projektleitenden oder dem Scrum Master ist gerade in der Kommunikation mit dem Kunden, dem Auftraggebenden und den Stakeholdern der Business Analyst eine wichtige Drehscheibe in der Vermittlung von Informationen. Kommunikation heisst nicht Mails schicken, Stories erstellen oder Umfrage senden, sondern gezielt und klar kommunizieren. Wann soll eine Frage offen sein? Wann ist ein Interview sinnvoll, und wann eine Onlineumfrage? An wen wenden wir uns in welchem Fall? All das sind Fragen, die vor jeder Kommunikation im Kopf durchgegangen werden müssen, um die Kommunikation aufrechtzuerhalten und zu vereinfachen.

Entwirrung schaffen
Eine systematische und disziplinierte Vorgehensweise bei der Spezifikation und Bewertung der Anforderungen sehe ich als Erfolgsfaktor für Projekte:

  • Verstehen der Wünsche und Bedürfnisse der Stakeholder und Endanwender durch Design Sprints, Workshops und Usability Tests
  • Kenntnis der relevanten Anforderungen durch die gemeinsame Priorisierung des Backlogs mit dem Auftraggebenden
  • Erreichen eines Konsenses unter den Stakeholdern – Stichwort «Betroffene zu Beteiligten machen»
  • Anforderungen nach vorgegebenen Standards dokumentieren – aber nur so viel wie nötig
  • Den Backlog systematisch Wünschen und Anforderungen anpassen

Durch diese Massnahmen und Tipps wird das Risiko minimiert, ein System zu liefern, welches nicht den Wünschen und Bedürfnissen des Auftraggebers und der Endanwender entspricht.

 

 

Je nach Komplexität, Fortschritt und Projektvorgehen sind die Zeit und der Druck unterschiedlich, um die Anforderungen zu definieren und in Form von User Stories zu erstellen, um schliesslich ein System nach dem Gusto des Auftraggebenden zu entwickeln.

Gute Erfahrungen haben wir mit der Story Map gemacht; für mich auch eine gute Grundlage im Konflikt Wasserfall vs. Scrum. In der Konzeptphase resultieren als Lieferergebnis unter anderem ein Konzept, Grobanforderungen oder gar ein Systementwurf. Es ist die Aufgabe des Business Analyst, diese Informationen zu verwerten und herunterzubrechen. Bedarf es einer grösseren Spezifikationsphase, ist die Story Map zu empfehlen. Durch dieses Werkzeug werden gemeinsam mit dem Projekt- respektive Fachteam des Kunden die Grobanforderungen aufgeteilt und in Bereiche gegliedert. Anschliessend dient die Verfeinerung der Detailspezifikation in Form von User Stories der Klarheit und auch als erforderliche Abnahmekriterien für Developer, um diese zu schätzen und das System in den Sprints zu realisieren. In Bezug auf die Qualitätssicherung wird das System ebenfalls durch den Business Analyst mit Fokus auf die fachlichen Anforderungen getestet. Dies geschieht mittels einmaliger Testfälle und zusätzlicher Regressionstests, die unter der Berücksichtigung der Releaseplanung durchgeführt werden.

Fazit
Der Business Analyst ist ein Teil wie jeder andere im Projektteam. Durch seine Softskills und den Einsatz geeigneter Methoden ist auch er ein relevanter Erfolgsfaktor für jedes Vorhaben und trägt zu dessen Qualität und schlussendlich zum Erfolg bei. Die systematische Annäherung an die Produktvision und das Herunterbrechen in User Stories und Testfälle sind ein wichtiger Bestandteil und aus meiner Sicht die Hauptaufgabe eines Business Analyst.


Patrick Joder
Patrick Joder

Seit Oktober 2020 ist Patrick Joder als Agile Business Analyst im Agile Projects Team in Bern tätig. Als eidg. dipl. Business Analyst wandelt er Visionen in Anforderungen um und agiert zudem als Product Owner und Testmanager in agilen sowie Wasserfall-Projekten.