Selbst kleinere IT Projekte können schnell Kosten im Bereich von sechsstelligen Eurobeträgen erreichen. Die Entwicklungszeit beträgt mit zwei bis drei Entwicklern dann mehrere Monate. Mangelnde Vorbereitung oder unzureichende fachliche und methodische Betreuung führen dazu, dass Kundenwünsche nicht ausreichend erkannt und kein Mehrwert geschaffen werden kann. In einer solchen Situation nehmen alle Projektpartner Schaden. Der Auftraggeber ist unzufrieden, weil er Geld für Software ausgegeben hat, die zu spät geliefert wurde oder seine Bedürfnisse nicht erfüllt. Das Entwicklungsteam ist angeschlagen, da man ihm direkt oder indirekt die Verantwortung für die Probleme zuschiebt. Dabei hätten sie wahrscheinlich ein besseres Ergebnis abliefern können. Die Motivation geht runter und die Frustration steigt.
Warum auch kleinere Projekte Unterstützung im Requirements Engineering haben sollten
Zur Entwicklung von passender Software ist die Unterstützung durch eine Requirements Engineering (RE) oder Business Analysten (BA) Rolle hilfreich. Fehlen diese Rollen für ein Projekt, so steigt das Projektrisiko. Die Rollen können häufig auch nicht ausreichend gut von einem Projektleiter oder von Mitarbeitern (Subject Matter Experts – SME) der Fachabteilung ausgefüllt werden, wie ich in einem früheren Blogbeitrag bereits beschrieben habe. Denn es fehlen Kenntnisse von RE-Methoden sowie die notwendige Praxiserfahrung. Dieser Zustand wird meist noch dadurch verschärft, dass die Personen die RE-Betreuung des IT-Projektes „nebenbei“ leisten oder sich nicht für den Gesamtprozess verantwortlich fühlen.
Die RE-Tätigkeiten auf das Entwicklungsteam zu verlagern, ist ebenfalls eine potenziell riskante Entscheidung. Das hat Josef Falk hier bereits in einem Blogbeitrag skizziert. Natürlich kann auch ein Softwareentwickler Kundenwünsche aufnehmen, die nötigen Anforderungen mit den Projektpartnern abstimmen und Testfälle schreiben. Dezidierte RE-Unterstützung ist auch schon sinnvoll, wenn es nur einen oder zwei Entwickler für ein Projekt gibt. Die Kosten für eine RE-Betreuung können auch in diesem Fall durch eine bessere Entwicklungsleistung aufgewogen werden. Spätestens wenn die Anzahl der Entwicklungskollegen aber steigt, wird die Zusatzrolle RE für einen Entwickler zumindest temporär zu einer hohen Aus- und Belastung führen. Wenn verschiedene Stakeholder betreut und abgestimmt werden müssen oder sich das Projektteam in ein neues Thema einarbeiten muss, ist an eine Kombination der Rollen kaum mehr zu denken. Hinzu kommt, dass die Arbeitsweise eines Requirements Engineers nicht wirklich der eines Software-Entwicklers entspricht.
Für den Software-Entwickler sind folgende Faktoren wichtig für ein gutes Resultat:
- lange Konzentrationsphasen
- wenig Kontextwechsel
- klare Fachlichkeit
Für den Requirements Engineer gehört Folgendes zum Alltag:
- teilweise fremdbestimmt bei der Zeiteinteilung durch spontane Rückfragen, Meeting-Einladungen etc.
- häufiger Kontextwechsel
- Abstimmungsmeetings mit verschiedenen Ansprechpartnern der Fachseite oder anderer Technikteams
- Diskussionen zur Klärung der Fachlichkeit
Was kann ein erfahrener Requirements Engineer leisten?
Auch wenn die Resultate des Requirements Engineerings nicht immer direkt in Euro und Cent zu messen sind, so bringt der effiziente Einsatz eines Requirements Engineers bei diesen Projektaufgaben einen deutlichen Mehrwert:
- Abstimmung der Projekttätigkeiten mit den Geschäftszielen
- Durchführung von Refinements- oder Anforderungsworkshops
- Koordination der Wünsche/ Anforderungen der Projektteilnehmer
- Vorbereitung der Fachlichkeit für die Entwicklungsteams
Ein erfahrener Requirements Engineer kann in Vollzeit etwa fünf bis acht Entwickler und Tester fachlich betreuen und ihnen zuarbeiten. Hier spielt es eine untergeordnete Rolle, ob die Entwickler auf ein oder mehrere Teams verteilt sind. Die fachliche Betreuung beläuft sich dabei auf die vier Haupttätigkeiten eines Requirements Engineers (nach Rupp et al. – Basiswissen RE):
- Anforderungsanalyse
- Anforderungsvalidierung
- Anforderungskonsolidierung
- Anforderungsdokumentation
Die Arbeitsergebnisse eines Requirements Engineers können durchaus projektspezifisch unterschiedlich sein und beinhalten diese Informationen:
- Schnittstellenbeschreibungen (GUI Wireframes/Mockups oder die fachliche Beschreibung von technischen Schnittstellen, Systemgrenzen etc.)
- Informationen zu Daten (Input, Output und deren Verarbeitung)
- auszuführende Aktionen der Nutzer oder des Systems
- Geschäftsregeln, fachliche Logik und deren Auswirkung auf die Aktionen und Daten
- Nicht-funktionale Eigenschaften
- Testfälle
- Dokumentationen für verschiedene Stakeholder
Einsatztypen und Auslastung eines Requirements Engineers
In den verschiedenen Phasen eines Projektes nimmt ein Requirements Engineer unterschiedliche Aufgaben wahr. Zu Beginn eines Projektes liegt der Fokus darauf, in Workshops und Diskussionen ein gemeinsames Verständnis für die Geschäfts- und Projektziele, die Nutzer und die Systeme und deren Zusammenwirken zu entwickeln. In dieser Phase sammeln sich viele, teils widersprüchliche Informationen an. Diese müssen validiert, aktualisiert und neu bzw. projektpartnergerecht (z.B. per UML, BPMN oder Mockups) strukturiert werden. Erfahrungsgemäß reduziert sich im Projektverlauf das Arbeitsvolumen und steigt ggf. zum Ende von einzelnen Meilensteinen oder zum Projektende wieder an. Die Auslastung des Requirements Engineers hängt außerdem davon ab, wie seine Rolle innerhalb des Projektteams definiert ist. Hier ergeben sich folgende mögliche (und vielleicht noch weitere) Szenarien:
Unterstützung des Product Owners (PO)
Fehlt dem Product Owner die Zeit oder das nötige Requirements Engineering-Know-How, um Anforderungen rechtzeitig und ausreichend präzise zu definieren, dann sollte er durch einen Requirements Engineer unterstützt werden. Denn der PO-Kurs liefert lediglich das Rüstzeug, um die Abläufe und die Verantwortlichkeiten der PO Rolle in einem IT-Projekt nach Scrum zu verstehen und anzuwenden. Hierfür muss der Requirements Engineer nicht dauerhaft zur Verfügung stehen und an allen Daily Scrums oder der Sprintplanung teilnehmen. Es reicht bei diesem Modell häufig aus, wenn der Requirements Engineer mit seinen Methodenkenntnissen unterstützt, z.B. bei der Moderation von RE-Workshops, bei Refinements oder der Dokumentation.
Wird die Rolle des Product Owners in dem Sinne verstanden, dass er neben der Scrum-Rolle auch die Verantwortung für den kommerziellen Erfolg (durch Marktanalysen, Vertriebstätigkeiten etc.) übernimmt, dann ist die Auslastung des Product Owners per se bereits sehr hoch. Im Team mit einem Requirements Engineer kann der Product Owner zum einen auf dessen erzielte Arbeitsergebnisse (z.B. für die Sprint- und Releaseplanung) aufbauen, zum anderen kann er sich auf strategische Aufgaben wie z.B. Stakeholder-Management, Vertrieb oder Budgetmanagement konzentrieren.
Initiale Analyse von Themen
Ist eine Investition in neue Software nötig, dann ist es hilfreich, die aktuellen Prozesse initial zu analysieren und den nötigen Bedarf festzustellen. Als Ergebnis dieser initialen Analyse sollte in jedem Fall ein gemeinsames Verständnis vom groben Rahmen des Projektes definiert werden, welches im Rahmen eines Lastenheftes oder Backlogs flankiert mit Diagrammen, Wireframes etc. festgehalten wird. Auch hierbei kann ein Requirements Engineer unterstützen, z.B. indem er Workshops mit den Projektpartnern sowie den Nutzern des zukünftigen Systems moderiert, die Ergebnisse abstimmt und dokumentiert. In diesem Szenario ist die Einsatzdauer ggf. auf wenige Wochen oder Monate begrenzt. Hierbei wird die eigentliche Auslastung stark variieren, da es durch Wartezeiten, beispielsweise die Erreichbarkeit von SME´s oder Entscheidungen durch Gremien zu „Leerlaufphasen“ kommen kann.
Requirements Engineering und Product Owner in Personalunion
Je nach Erfahrung, Rollenauslegung oder Projektgröße kann die Rolle des Requirements Engineer und die PO-Rolle von einer Person übernommen werden. Dann sollte die Größe des Projektteams eher vier bis sechs Entwickler/Tester umfassen. Ist das Projektteam zu groß, ist die Auslastung zumindest phasenweise sehr hoch.
Requirements Engineering als Betreuung für ein Bestandssystem
Neben einem Projekt mit einem definierten Anfang und Ende gibt es zusätzlich die Option der Betreuung eines bestehenden Systems. Hierbei geht es im Tagesgeschäft z.B. um die Aufnahme und Analyse von Bugs sowie die Vorbereitung und Begleitung von kleineren oder mittelgroßen Änderungen. Bei der Betreuung von Bestandssystemen ist die Arbeitsauslastung für einen Requirements Engineer eher gleichmäßig verteilt – im Gegensatz zu Projekten, in denen es besonders in der Anfangsphase zu einem hohen Arbeitsaufkommen für den Requirements Engineer kommen kann. Auch hier sollte ein sinnvolles Verhältnis zwischen Entwicklern und dem RE-Anteil angestrebt werden.
Wie kann der Personalbedarf für eine RE-Funktion ermittelt werden?
Die Beantwortung der folgenden vier Fragen ermöglicht eine erste Abschätzung des Bedarfs:
1. Wie vielen Entwicklern arbeitet der Requirements Engineer zu?
Wie oben beschrieben kann eine Vollzeit RE-Stelle zwischen fünf und acht Entwickler mit Input versorgen und die Projektpartner bzgl. der RE-Aspekte betreuen. Ist das Verhältnis kleiner, so reicht ggf. eine Teilzeitkraft.
2. Wie schnell ist die Projekt- und Gesamtorganisation?
Besonders in großen Unternehmen sind die Prozesse langsamer als für eine schnelle und effiziente Abarbeitung in IT-Projekten nötig. Folgende Punkte können Hinweise geben, dass eine Vollzeitauslastung für einen Requirements Engineer nicht gegeben ist.
- Vorlaufzeiten für die Koordination von Workshop-Terminen mit mehreren Projektpartnern beträgt mehrere Wochen
- Feedback von Projektpartnern erfolgt verzögert
- Entscheidungsgremien kommen nur monatlich oder quartalsweise zusammen
Hier ist häufig keine gleichmäßige Auslastung der RE-Rolle gegeben und der Fortschritt bei der Konzeption und der Entwicklungsvorbereitung erfolgt eher schubweise. Der Requirements Engineer muss hier recht schnell ein gutes Verständnis für die Materie entwickeln und mit etwas Mut zur Lücke die Zeiten überbrücken, in denen er auf wichtige Entscheidungen wartet. Diese Situation ist besonders unangenehm, wenn ein verhältnismäßig großes Entwicklungsteam bereitsteht, das kontinuierlich mit neuen Anforderungen versorgt werden möchte. Durch fehlende Anforderungen gehen Fokus und Motivation schnell in den Keller und es ist schwer, diese wieder zurückzugewinnen.
3. Wie ist die RE-Rolle im Projektteam definiert?
Unterstützt der Requirements Engineer einen PO mit RE-Methoden oder übernimmt er die volle fachliche Führung (Product Owner Rolle)? Unterstützt der Requirements Engineer punktuell mit Methodenkompetenz, Workshop-Moderation, Coaching und Vermittlung von Best Practice, dann ist eine Vollauslastung meist nicht gegeben.
4. In welchem Projektabschnitt befindet sich das Projekt?
In Phasen erhöhten Wissens- und Klärungsbedarfs steigt das Arbeitspensum eines Requirements Engineers. Es finden oft zahlreiche Termine oder Workshops in kurzer Zeit statt, die eine Vielzahl an Informationen generieren. Diese müssen dann sortiert, bewertet und weiterverarbeitet werden. Im Anschluss an diese Phase folgt die Abarbeitung der Anforderungen durch das Projektteam und das Arbeitspensum sinkt. Natürlich gibt es auch hier weiterhin Klärungsbedarf. Meist ist der jedoch geringer und die Dichte der Arbeit für den Requirements Engineer verringert sich entsprechend.
Arbeitsorganisation – wird das Richtige getan?
Neben den Fähigkeiten und der Erfahrung des Requirements Engineers, die ich hier schon einmal beschrieben habe, spielt auch die Arbeitsorganisation eine Rolle. Werden die RE-Artefakte im richtigen Detailierungsgrad zum richtigen Zeitpunkt geliefert? Die Erstellung von vermeintlich detailreichen Dokumenten, die nicht mit den Betroffenen auf Fach- oder Technikseite abgestimmt sind und deren Umsetzung in ferner Zukunft liegt, gehört eher nicht dazu. Solche Dokumente werden meist nicht wieder herangezogen, weil sie schnell veraltet sind und die Projektpartner sich erneut Gedanken machen müssen.
Die Zeit zur gemeinsamen Abstimmung und Klärung von Problemfeldern ist besser investiert, wenn Zeitpunkt und Detailtiefe genau stimmen. So hat man als Projektteam die Möglichkeit, die Geschehnisse zu steuern, ohne sich mit unnötigen Dingen beschäftigen zu müssen. Hier ist die richtige Balance zu finden. Treten hingegen aufgrund von mangelnder Vorbereitung/Betreuung grundsätzliche Probleme erst zum Meilensteinende oder zum Release ein, dann ist das Projektteam nicht mehr Herr seiner Zeit und wird durch „Management-Attention“ getrieben, d.h. es muss mehr Zeit für das Erstellen von managementtauglichen Statusberichten oder für die Teilnahme an Eskalationsmeetings etc. aufbringen. Des Weiteren gibt es in einigen Organisationen die Tendenz zu vermeintlich “wichtigen“ stundenlangen Regeltermin-Meetings mit mehr als 5-7 Teilnehmern. Diese blocken dann den Kalender und führen wie oben beschrieben zu einer Verknappung von Terminoptionen für RE-Workshops etc.
Fazit
Nicht immer muss eine Requirements Engineering-Rolle mit einer Person in Vollzeit besetzt werden. Berücksichtigt man zum einen die Auslastung je nach Einsatztyp und zu betreuender Entwicklerzahl, so ergeben sich Möglichkeiten einer gezielten Nutzung von RE-Ressourcen. Zum anderen trägt auch die Arbeitsorganisation zu einem effizienten Arbeiten und zu einem besseren Ergebnis bei. Grob lassen sich folgende Einsatztypen umreißen:
- Kurzfristiger Auftrag, z.B. für die Erstellung von Grobkonzepten oder initialen Backlogs
- Langfristige Unterstützung, z.B. für die punktuelle Projektunterstützung eines PO während der Projektlaufzeit
- Langfristiger Auftrag, z.B. als Systembetreuung oder als RE/PO in Personalunion
Hierbei ergeben sich wie oben beschrieben verschiedenen Auslassungen. Wenn diese in der Personalplanung berücksichtigt werden, kann der Einsatz von Requirements Engineers bedarfsorientiert gestaltet werden. Die so gewonnene Flexibilität bietet einen Mehrwert für alle Betroffenen. Requirements Engineers bekommen Einblicke in verschiedene Systeme und können mit ihrem team- oder abteilungsübergreifenden Arbeiten Synergieeffekte erzielen, beispielsweise durch das Lernen/Vermitteln von Best Practices. Prozess- und systemübergreifendes Wissen unterstützt außerdem das Finden von ganzheitlichen, systemübergreifenden Lösungen.
Unternehmen könnten so mehr IT-Projekte mit Requirements Engineers betreuen und die Vorteile dieser Rolle auch für kleinere Vorhaben nutzen. Personalbeschaffung und -organisation, Controlling und Personalführung müssten sich allerdings mit diesen Ideen vertraut machen und sich mehr Gedanken bzgl. der projektübergreifenden Nutzung machen, anstatt pauschal über einzelne RE-Besetzungen zu entscheiden. Zudem muss das Management Vertrauen in die Mitarbeiterfähigkeit haben, situativ für die verschiedenen Projekte zu arbeiten. Das bedeutet aber auch eine Bereitschaft, die Kalkulation der Arbeitszeit in starren Controlling-Rastern aufzugeben.
Happy Engineering!
Mehr zu René Busch finden Sie auf http://www.requireminds.de/. 