Wie identifiziere ich Anforderungen?

Mir wird immer mal wieder die Frage gestellt: "Wie finde ich eigentlich die Anforderung heraus?" Und meistens ist meine Antwort auf die Frage: "Gar nicht. Du stellst die falsche Frage."

Lass uns mal einen Schritt zurückgehen. Warum machen wir diesen Scheiß eigentlich? Ganz einfach: Wir wollen die Probleme unserer Anwender lösen. Es dreht sich um Anwender. Es dreht sich um Probleme. Und es dreht sich um Lösungen. Das sind die drei Punkte, die wirklich wichtig sind. Und du merkst schon, das Wort „Anforderung“ taucht da gar nicht auf.

Was du stattdessen tun kannst, erfährst du in diesem Video.

Transkript des Videos (automatisch erzeugt, bitte entschuldige mögliche Fehler)

Hallo! Mir wird immer mal wieder die Frage gestellt: "Hey Nico, wie finde ich eigentlich die Anforderung heraus?" Und meistens ist meine Antwort auf die Frage: "Gar nicht. Du stellst die falsche Frage."

Überrascht? Naja, dann lass mich das mal ein bisschen erläutern. Was passiert denn oft, wenn irgendwie so ein neues Projekt initiiert wird? Da kommen dann irgendwie Leute zusammen und machen sich Gedanken. Was will man eigentlich erreichen und wen brauchen wir dafür alles und so weiter und so fort. Und relativ schnell kommt dann meistens auch der Punkt hoch: ja, wir brauchen Anforderungen. Irgendeiner muss jetzt mal losgehen und Anforderungen definieren oder irgendjemand muss Anforderungen analysieren oder irgendjemand muss Anforderungsworkshops durchführen. Wie auch immer genau das Wording ist, aber relativ schnell kommt man dahin, dass gesagt wird: Wir brauchen Anforderungen.

So... und bevor wir über Anforderung sprechen, würde ich gerne mal einen Schritt zurückgehen. Warum machen wir diesen Scheiß eigentlich? Aus meiner Sicht ist die Antwort relativ simpel. Wir wollen nämlich die Probleme unserer Anwender lösen. Ganz einfach: Wir wollen die Probleme unserer Anwender lösen. Das heißt, es dreht sich um Anwender. Es dreht sich um Probleme und es dreht sich um Lösungen. Das sind die drei Punkte, die wirklich wichtig sind. Und du merkst schon, das Wort „Anforderung“ taucht da gar nicht auf.

Was ist denn aus meiner Sicht eigentlich so ein bisschen das Problem mit Anforderungen? Da ist eine ganze Reihe von Problemen. Fangen wir mal an. Das eine ist: Anforderungen adressieren nicht - oder sie adressieren manchmal den falschen - Anwender. Anforderungen adressieren manchmal das falsche Problem. Anforderungen lösen manchmal gar nicht das Problem. Manchmal sind sie nur eine Scheinlösung. Und Anforderungen sind meistens auch nur eine mögliche Lösung des Problems, aber nicht die einzige. Und insofern, wenn wir jetzt mal zurück gucken, was wollen wir eigentlich? Wir wollen die Probleme unserer Anwender lösen. Und zweitens, wenn wir uns jetzt klar ist: o.k. Anforderungen sind vielleicht nicht das Mittel der Wahl - was ist es denn dann?

Deine Aufgabe ist es, Klarheit über Anwender und Probleme zu schaffen. An welchen Anwender richtet ihr euch denn jetzt konkret und welche Probleme wollt ihr konkret lösen? Meistens gibt es ja ganz viele potentielle Anwender mit ganz vielen potentiellen Problemen und es ist selten eine gute Idee, alle Anwender und alle Probleme gleichzeitig zu lösen. Geschickter ist es also, Schritt für Schritt vorzugehen. Und wenn ihr darüber Klarheit habt, dann ist es deine Aufgabe - oder besser gesagt die Aufgabe von euch als Produktentwicklungsteam - Lösungsideen herauszufinden. Ja, die Anwender und Stakeholder und wer auch immer können wertvollen Input geben. Sie können euch wertvolle Hinweise geben, worüber ihr mal nachdenken könnt. Aber es ist eure Aufgabe als Produktentwicklungsteam, potentielle Lösungsideen zu entwickeln und zu bewerten. Und dann ist es auch wieder deine Aufgabe, diese Lösungsideen zu validieren. Wenn du einen Blumenstrauß von 5 Lösungsideen hast, welche funktioniert denn? Welche ist günstig umzusetzen? Welche macht deine Anwender am glücklichsten? Es gibt ja eine ganze Reihe von Kriterien, wie du deine Lösungsideen überprüfen kannst, um dann am Ende eine davon auszuwählen. Und danach setzt ihr sie natürlich um.

Was will ich damit sagen? Du merkst schon, dahinter steckt ein anderes Mindset. Es geht also an der Stelle nicht darum, der Erfüllungsgehilfe - ich nenne das jetzt mal so - Also du bist nicht der Erfüllungsgehilfe von Anwendern oder von Stakeholdern, sondern du bist der Problemlöser. Du machst dir die Probleme deiner Anwender zu eigen und versuchst, die bestmögliche Lösung zu finden. Das ist ein ganz anderes Mindset. Deswegen ist mir das so wichtig, dass dir das bewusst ist.

Ja und wenn du jetzt sagst alles klar, hab ich verstanden, würd ich ja gerne machen. Aber wie? Na, dann empfehle ich dir einfach meinen kostenlosen Online-Kurs Agiles Anforderungsmanagement. Da gehe ich nämlich genau Schritt für Schritt über diese Punkte. Wer sind meine Anwender? Wie finde ich die Probleme raus? Wie generiere ich Lösungsideen? Wie validiere ich Lösungsideen? All das kannst du dir dort kostenlos anschauen. Ich verlinke den Kurs hier.

Ich hoffe, du hast jetzt die eine oder andere Inspiration mitgenommen. Denk bitte immer daran: Das Leben ist zu kurz, um in beschissenen Projekten zu arbeiten. Bis bald.