Früher war alles besser. Naja, nicht besser, aber einfacher. Früher war alles einfacher. Da gab es Projekte einfacher und komplizierter Natur, die Wünsche des Anforderers waren klar und die Herausforderung lag lediglich darin, in Form von Dokumenten für ein gemeinsames Verständnis durch klare Spezifikationen von Anforderungen zu sorgen. So konnten Missverständnisse vermieden und ein gemeinsames Verständnis hergestellt werden. Mehr oder weniger. Naja. Eher weniger.
Der Requirements Engineer
Früher, also viel früher, da war alles einfacher. Da gab es klare Abläufe, Prozesse und zugehörige Rollen. Eine dieser Rollen war die des Requirements Engineers.
Die Aufgabe: gewünschte, beziehungsweise relevante, funktionale Anforderungen und Qualitätsanforderungen ebenso wie technologische, organisatorische, rechtliche und ethische Rahmenbedingungen über den gesamten Lebenszyklus einer Anwendung zu ermitteln, zu spezifizieren und zu prüfen. Letztendlich konnte durch eine ausreichende Analyse, Spezifikation und Validierung der Anforderungen das Zielbild und der Weg dahin beschrieben werden.
Die Aufgabe war vielfältig, spannend, herausfordernd und machbar. Der Projekterfolg war maßgeblich eine Frage einer besonders guten und genauen Anforderungsanalyse mit einer anschließenden der Analyse entsprechenden sauberen Abarbeitung.
Heute bewegen wir uns zunehmend im Nebel. Das grobe Ziel kann häufig noch formuliert werden, ist aber im Gegensatz zu früher meist nicht mehr in Stein gemeißelt. Und der Weg zum grob definierten Ziel wird zunehmend beeinflusst durch nicht absehbare Faktoren und kurzfristige Änderungen, die antizipiert werden wollen und auf die reagiert werden muss. Um es mit Bjarte Bogsnes zu sagen: Das Einzige, das in der heutigen Zeit sicherer geworden ist, ist das Wissen, dass unsere Vorhersagen über die Zukunft sehr wahrscheinlich falsch sind. Viel Klärung muss im Dialog stattfinden, und wenn schon alleine Sprache nur noch ein grobes Abbild dessen ist, was wir eigentlich sagen wollen, sind aufwändige, durch dedizierte Rollen formulierte Anforderungsdokumente kurzlebiger als eine Eintagsfliege. Wir brauchen also – frei nach Jeff Patton – keine präziseren Dokumente, sondern ein gemeinsames Verständnis.
Schon allein Sprache ist nur noch ein grobes Abbild dessen, was wir eigentlich sagen wollten.
Conny Dethloff
Klassisches Vorgehen
In einem klassischen Vorgehen – also in einem typischen Projektphasenplan – gab es eine serielle Abarbeitung von Arbeitspaketen, bei der das Ergebnis jeder Phase im weitesten Sinne ein Dokument war. Ein Teil dieser Kette war die klar spezifizierte Liste der Anforderungen – ein präzises Dokument, mit dem das zu erstellende Produkt bereits vor Beginn der Umsetzung in allen Details beschrieben werden sollte. Leider führt nicht nur die Weiterreichung von Wünschen des Auftraggebers über zahlreiche Menschen und Stationen zu Missverständnissen und Informationsverlust, sondern auch das Grundproblem, dass sich ein gemeinsames Verständnis nicht endgültig und lückenlos besprechen und formulieren lässt. Schon gar nicht viele Monate oder gar Jahre im voraus. Dieses Vorgehen sorgte immer wieder zu mehrfach auszuführenden Arbeiten und suboptimalen Ergebnissen, also zu Verschwendung und wenig erfolgreichen Projekten.
Aktuelles Vorgehen
Wir haben aus der Vergangenheit gelernt, dass wir im Nebel der heutigen Komplexität oft nur auf Sicht navigieren können. Also wissen wir, dass umfassende Spezifikationen für den gesamten Lebenszyklus von Anwendungen nicht vorab formuliert werden können. Die aktuelle Antwort auf das Problem sind crossfunktionale Teams aus Experten, in denen auch die Verantwortung für das Formulieren von klar spezifizierten Anforderungen liegt. Diese werden von Product Ownern oder User Experience Designern, Business oder Requirements Engineers nun in Form von User Stories geschrieben, als kleinteilige, möglichst genau beschriebene Vorgabe für die Umsetzung.
Das ist besser als ein klassisches Vorgehen, weil wir schneller reagieren können. Jeder, der aber schon einmal Streitigkeiten mitbekommen hat, wer nun die Verantwortung für ungenaue Formulierungen oder eine nicht ausreichende Liste von Akzeptanzkriterien zu tragen habe, kann sich vorstellen, dass auch dieses Vorgehen nicht der Weisheit letzter Schluss ist. Auch wenn wir mit User Stories stark am Nutzer orientiert, kleinteiliger und damit flexibler versuchen zu arbeiten, bleiben User Stories im Kern ein Versuch, Details zu spezifizieren und auszuformulieren, die wir gar nicht im Detail kennen und wissen können. Denn viele übersehen in dieser Form der Zusammenarbeit, dass auch eine User Story eigentlich die “Einladung zu einem Gespräch” ist (Ron Jeffries). Eine lange Liste genau ausformulierter Akzeptanzkriterien für ein – im besten Fall – gemeinsames Verständnis und – im häufigen Fall – zur Absicherung in Schuldfragen hat das gleiche Grundproblem, wie das früher formulierte umfassende Anforderungsdokument – nur eben in klein und direkter an der Umsetzung. Immerhin.
Zukünftiges Vorgehen – was wir wirklich brauchen
Was brauchen wir also wirklich? Der einfachste und beste Weg, zwischen Anwendern, Auftraggebern und Umsetzern ein gemeinsames Verständnis zu schaffen, sind interdisziplinäre Teams, in denen die Fachexperten selbst Requirements Engineering betreiben – also das ermitteln, spezifizieren und prüfen von Anforderungen, für ihr Expertengebiet selbst in kurzen Zyklen erarbeiten, verstehen und direkt umsetzen, im ständigen Dialog mit Nutzern und Stakeholdern.
Ein interdisziplinäres Team zu Ende gedacht bedeutet auch, dass die Aufgabe, fachliche und technische Anforderungen sowie unterschiedliche Rahmenbedingungen zu kennen und zu berücksichtigen die Aufgabe jedes Teammitglieds ist. Die technischen Rahmenbedingungen müssen die Techniker kennen, für rechtliche Rahmenbedingungen sollte ein Rechtsexperte hinzugezogen werden und die Verantwortlichen für die Umsetzung sollten die fachlichen Anforderungen selbst kennen und verstehen. Kennen bedeutet dabei, im Nebel der Komplexität ein Grundverständnis zu haben und im direkten Dialog mit dem Anwender die Anforderungen heraus zu bekommen und umzusetzen.
Jeder aus dem Team ist ein eigener Requirements Engineer und formuliert dabei nur gerade so viel in Spezifikations-Dokumenten – zum Beispiel in User Stories – wie nötig. Denn erst wenn die spezifizierte Anforderung in der Anwendung beim Nutzer ist, wird sich zeigen, ob die vorher getroffenen Annahmen wirklich zutreffend waren.
Veränderungen für die Rolle
Wenn ein interdisziplinäres Team aus Experten nun selbst im Dialog mit dem Anwender ermitteln, spezifizieren und prüfen, wozu braucht es dann noch Requirements Engineers?
Die Rolle an sich wird mittelfristig wohl nicht mehr gebraucht. Die Einführung oder Beibehaltung von Experten-Rollen wie Requirement Engineer, Business Engineer, User Experience Designer, Konzepter und Ähnliche verlängert die Kette der Kommunikation. Das verlangsamt die Umsetzung und erhöht die Wahrscheinlichkeit, dass Kommunikation nicht funktioniert. Der direkte Austausch zwischen den Nutzenden und den Umsetzenden muss gewährleistet sein. Das schnelle Verständnis der Umsetzenden von den Bedarfen der Nutzenden wird immer wichtiger.
Was ein solches Team von direkt mit den Nutzern im Dialog stehenden Umsetzungsteams stattdessen benötigen wird, ist Unterstützung und Gestaltung des kontinuierlichen Austauschs mit Nutzern und Anforderern. Das Feld an möglichen Aufgaben ist hier groß und vielfältig, von Kreativitätsmethoden wie etwa Design Thinking oder Lego Serious Play bis hin zur Facilitation von Anwenderworkshops oder der Organisation von Nutzerbefragungen. Hinzu kommt, dass es ein weiter Weg zu diesem interdisziplinären Team ist, in dem jeder Experte auch Requirements Engineering Skills hat mit einem entsprechenden Methodenkoffer. Dieser Weg braucht die Begleitung, das Coaching und Training durch die aktuellen Experten auf dem Gebiet des Requirements Engineering.
Der ehemalige Requirements Engineer wird mehr und mehr zum Gestalter des Rahmens für einen kontinuierlichen Anforderungsdialog, damit das ganze interdisziplinäre Team möglichst kurzfristig und schnell agieren und reagieren kann. Die Weiterentwicklung des Produkts wird im direkten Gespräch zwischen fachlichen und technischen Experten, Anforderern und Anwendern erarbeitet. Dabei den Fachexperten weiterhin den Fokus auf ihr Spezialgebiet inklusive des dazu gehörenden Requirements Engineerings zu ermöglichen und sie nicht mit Moderation, Organisation oder Ausgestaltung dieser Dialogformate zusätzlich zu beanspruchen: hier können die Requirements Engineers von heute auch in Zukunft einen wertvollen Beitrag zu einer gelungenen Produktentwicklung leisten.
Ergänzung
Der Blog-Beitrag ist eine gemeinsame Ausformulierung der kontrovers diskutierten Keynote, die Kai Pukall und ich auf der ModernRE Konferenz 2019 gehalten haben. Die im Nachgang noch leicht überarbeiteten Slides können hier abgerufen werden. Vielleicht können wir die kontroverse Diskussion der Konferenz ja über diesen Kanal weiterführen?