Anforderungen oder Annahmen? Einige Gedanken und Beobachtungen
Wenn wir in irgendeiner Rolle im IT-Geschäft unterwegs sind, dann begegnen uns häufig „Anforderungen“, die in eine Anpassung / Änderung / Erweiterung eines Softwaresystems (und manchmal auch der dazugehörigen Organisation) umgesetzt werden. Organisationen auf dem Weg in die Agilität versuchen häufig, sich von der Begrifflichkeit „Anforderung“ zu lösen – damit verknüpfte Denkmuster und Rollen sind häufig eher in einer „Wasserfall-Kultur“ verwurzelt, die man doch hinter sich lassen möchte. Also versucht man gerne, die Anforderung zu ersetzten durch Hypothese oder Annahme, welche ein vermutetes Anwender- oder Geschäftsbedürfnis beschreibt. Das verändert die Perspektive deutlich – nicht ein „Anforderer“ (Projektleiter, Requirements-Engineer) formuliert eine neue Aufgabe, sondern versucht als Stellvertreter des Nutzers, ein Problem zu beschreiben.
Und damit die Möglichkeit eröffnet, das eine Hypothese sich als falsch herausstellt. Ein zentrales Element von kundenzentrierter Produktentwicklung und agiler Arbeit.
Man kann die Arbeit mit Annahmen aber auch noch weiter fassen – jeder „Anforderung“ für eine Veränderung liegen implizit zwei Annahmen zugrunde:
- Wir haben eine Annahme über ein Problem der Nutzer unseres Produkts. Oft nicht explizit formuliert, aber wir nehmen irgendeine Motivation an, warum ein Nutzender diese neue oder geänderte Funktion nutzen soll, und es für den Anwendenden einen Mehrwert darstellt.
- Wir haben die Annahme, das unser Experiment (a.k.a. die Änderung zum vorherigen Zustand) geeignet ist, zu verifizieren, dass es eine geeignete Lösung für das angenommene Problem sein könnte.
Kritik an einer geplanten oder angefangen Veränderung kann sich nun gegen zwei Dinge richten, die ursprüngliche Annahme bezüglich des Problems, oder über die Art des Experiments. Beides kann man diskutieren, und sicher auch kritische Stimmen dazu einordnen. Beides lässt sich aber am ehesten verifizieren, in dem man das Experiment zu Ende bringt, und bewusst die Ergebnisse bewertet. Neben der Interpretation der Ergebnisse, das wir die Kundenbedürfnisse vielleicht falsch eingeschätzt haben, könnte auch unsere Lösung (aka unser Experiment) einfach ungeeignet oder ungewollt sein. Und einen Impuls geben, es noch einmal mit einem anderen Lösungsansatz zu probieren.
Ein Fehlschlag kann das Experiment nur sein, wenn wir keine Erkenntnis gewinnen. Vielleicht falsifizieren wir eine oder beide der Annahmen, und dieser Erkenntnisgewinn hat sicher einen Preis – die Arbeit und Zeit, welche investiert wurde.
Vielleicht stellt sich auch heraus, das Kritik berechtigt war, und wir einen Beleg dazu erzeugt haben. Aber die Erkenntnis AN SICH, ist der wichtigste Mehrwert, oft für uns wichtiger als der Wert einer Problemlösung für ein angenommenes Problem, und Erkenntnis für ein neues Experiment, was dadurch vielleicht zielgenauer wird.
Reinald Kirchner 