Viele verbinden mit Requirements Engineering vor allem das Dokumentieren und Verwalten von Anforderungen. Für mich steht aber die Frage davor im Mittelpunkt: Wie komme ich denn überhaupt zu den richtigen Anforderungen? Ganz wesentlich dafür ist es, erst einmal einen Schritt zurückzugehen und die Bedürfnisse hinter den Anforderungen zu klären.
Niemand braucht einen Export-Button.
"Ich brauche dringend einen Button, mit dem die ganze Hauptsaldenliste in Excel exportiert werden kann!" Kennen Sie solche oder ähnliche Anforderungen? Oft landet das sofort 1:1 als Item im Backlog der Entwicklung, wird eingeplant, umgesetzt, getestet und ausgeliefert. Kunde zufrieden. Oder etwa nicht? Wozu braucht der Kunde die Liste denn überhaupt in Excel? Hm. Wissen wir nicht. Fragen wir einfach! Kunde: "Ich muss die Daten jeden Morgen für die Geschäftsführung aufbereiten. Bisher hab ich sie immer ins Excel abgetippt, das möchte ich mir sparen. Darum: Export nach Excel." Verblüffung macht sich im Raum breit. Entwickler: "Aber dafür gibts ja schon einen fertigen Bericht. Warten Sie, ich schalte Sie dafür frei."
Was braucht unser Kunde wirklich? Ich meine jetzt echt WIRKLICH?
Viel zu oft werden in der Hektik des Tagesgeschäfts Anforderungen und ganze Projekte angenommen und umgesetzt, von denen wir gar nicht genau wissen, wozu sie verwendet werden. Welches Problem hat der Kunde? Welches Ziel möchte er erreichen? Wie macht das sein Leben leichter? Was möchte er damit machen? Welche Anwendungsfälle hat er? Oder allgemeiner gefragt, was ist das Bedürfnis ("Need") hinter der Anforderung? Nur wenn wir dieses Bedürfnis kennen, können wir die wirklich beste Lösung für den Kunden liefern. Und darum geht es doch, oder?
Fragen Sie den Kunden selbst, er weiß es.
Wenn wir dann beim Produktmanager / Kundenbetreuer / Berater / Vertrieb nachfragen, wozu das gebraucht wird, kommen wir oft nicht recht weiter. Die Kollegen wissen es selbst nicht, haben die Anforderung selbst so bekommen. Die wohl naheliegendste Lösung ist, den Kunden einfach direkt zu fragen. Dass unsere Kunde ja eh nicht wissen, was sie wollen, ist ein Mythos. Unsere Kunden können meist sehr genau sagen, was sie brauchen. Man muss sie nur fragen. Aber man muss sie richtig fragen.
Fragen Sie bitte nie „Warum?“
Beim Gefragten kommt dann an: „Das ist nicht wichtig. Ich will es nicht machen.“. Nicht gut. Fragen Sie immer „Wozu?“ oder „Welches Problem willst Du damit lösen?“ Viel besser!
Ein Bedürfnis ist ein gewünschter Zustand und kein Button.
Ein Bedürfnis beschreibt einen gewünschten Zustand der Welt des Kunden oder seiner Umwelt. Anforderungen spezifizieren, mit welchen Funktionen/Eigenschaften das System dabei unterstützt, den Zielzustand zu erreichen. Das ist wichtig! Wenn sich die Formulierung jedoch um eine Systemfunktion dreht, dann sind wir noch nicht beim Bedürfnis angelangt. Beim Bedürfnis geht es immer um eine Veränderung in der Welt rund um unser System, zu der wir mit Funktionen und Eigenschaften des Systems beitragen.
Sammeln Sie Bedürfnisse in einem „Needs Backlog“.
Sie können gerne auch Bedürfnis-Sammlung oder Zieleliste dazu sagen. Bei kleineren Changes können Sie es auch direkt im „… so that“ Teil einer User Story festhalten. Egal. Schreiben Sie die Bedürfnisse der Kunden auf. So kurz es geht, aber schreiben Sie es auf. Nur so ist sichergestellt, dass sie auch in fünf Jahren noch wissen, wozu eine Funktion da ist und ob man sie noch braucht.
Priorisieren Sie Bedürfnisse und nicht Anforderungen.
Reihen Sie die Bedürfnisse nach deren Wichtigkeit. Oder noch besser: Lassen Sie Ihre Kunden reihen. Wenn Sie wissen, was die wichtigsten Bedürfnisse sind, ergibt sich die Prio der umzusetzenden Systemanforderungen fast von selbst. Begonnen wird mit dem, was zur Erfüllung der wichtigsten Bedürfnisse benötigt wird.
Needs:
- Als Kunde möchte ich Produkte, die meine Bedürfnisse erfüllen.
- Als Vertrieb möchte ich Produkte, die die Bedürfnisse der Kunden besser treffen als die Konkurrenz.
- Als Entwicklung möchte ich klare Prioritäten.
Daraus ergeben sich folgende Anforderungen ans Requirements Engineering:
- Als Requirements Engineer möchte ich Methoden, Checklisten und Trainings, die mir helfen, die Bedürfnisse meiner Kunden herausfinden.
- Als Requirements Engineer möchte ich die Bedürfnisse meiner Kunden so dokumentieren, dass ich sie verständlich an die Entwicklung weitergeben kann.
- Als Architekt möchte ich die Bedürfnisse unserer Kunden kennen, damit ich das System optimal designen kann.
- Als Product Owner möchte ich wissen, was die wichtigsten Bedürfnisse sind, damit ich die Reihenfolge meiner Backlog Items daran ausrichten kann.
- ...
Früher hat man Produkte gebaut, weil irgendjemand die Idee dazu hatte. Mit viel Marketing wurde das dann in den Markt gedrückt. Und ist immer wieder grandios gescheitert. In Zeiten von Lean und Agile werden Produkte fundamental anders gebaut. Am Beginn steht immer das Herausfinden der Bedürfnisse der Kunden. Daraus werden dann Anforderungen abgeleitet. Richtig gemacht erhält man Produkte, die für unsere Kunden tatsächlich wertvoll sind, die sie weiterbringen und ihnen helfen. Ein erster Schritt dahin wäre, einfach bei jeder Anforderung in einem Satz das dahinterliegende Kundenbedürfnis dazuzuschreiben.
Wenn Sie Ihre Produkte besser an den tatsächlichen Kundenbedürfnissen ausrichten oder die Priorisierung in Ihrer Entwicklung verbessern wollen, unterstützen wir Sie gerne. In unseren Requirements Engineering Praxistraining und in der Beratung bei der Einführung von professionellem Requirements Engineering geben wir unser Wissen und Erfahrung über Methoden und Werkzeuge an Sie weiter.
Weitere Informationen finden Sie im Themenbereich Requirements & User Experience auf unserer Website.
