Früher war alles besser, äh, gewisser
Das Problem mit dem Begriff „Anforderung“ ist, dass er eine Gewissheit suggeriert, die in den meisten Fällen nicht mehr gegeben ist. Für die moderne Form der Anforderung, die User-Story, gibt es die Empfehlung, sie in der Form zu schreiben: „Als <Rolle> will ich <Verhalten>, weil/damit <Begründung>“. Das Problem mit dieser Form ist, dass wir in der Regel nicht mehr wissen, was <Rolle> will. Insbesondere, wenn es sich dabei um unsere Kundinnen und Kunden handelt, können wir eigentlich nur raten, denn letztlich wissen auch unsere Kund:innen nicht, was sie wollen, bis sie es vor sich sehen. Und wenn sie es vor sich sehen, dann wollen sie es meistens nicht (eine Daumenregel besagt, dass nur eines von 10 Features auch positiven Geschäftswert erzeugt). Anforderungen sind in den meisten Kontexten also mehr raten, denn wissen.
Aber warum halten wir dann so hartnäckig daran fest, dass wir wüssten, was unsere Nutzer wollen? Das hat aus meiner Erfahrung viel mit der Veränderungsträgheit von Unternehmen zu tun. Insbesondere die Unternehmen, die schon länger am Markt sind, kommen aus einer Zeit relativer Gewissheit. Die Märkte waren langsamer und als Anbieter konnte man häufig bestimmen, wohin die Reise geht. Und wenn man nicht zu weit danebengegriffen hat (wobei einem z. B. Mittel wie Marktforschung geholfen haben), dann war die Erfolgswahrscheinlichkeit ziemlich hoch. Man konnte also weitestgehend vorhersagen, was die Nutzerinnen und Nutzer wollen und in einen solchen Kontext passt die klassische Anforderung auch.
Moderne Zeiten und das Ende der Gewissheit
Die Zeiten sind aber fast überall vorbei. Die Märkte sind „VUCA“ (das englische Akronym für volatil, ungewiss, komplex und mehrdeutig, engl.: ambiguous). Es herrscht Verdrängungswettbewerb allerorten und die Unternehmen, die am schnellsten den sich stets ändernden Anforderungen und Wünschen der Kunden hinterherspüren und diese erfüllen, treiben die Wettbewerber vor sich her. Die begeisternde Neuerung von heute ist die wertgeschätzte Produkteigenschaft von morgen, ist die erwartete Selbstverständlichkeit von übermorgen.
Und was ist die begeisternde Neuerung von morgen? Das wissen die Kunden selber nicht. Die große Mehrheit der Menschen extrapoliert bei der Frage nach morgen immer nur den Status quo. Echte Neuerungen können wir uns in der Regel nicht vorstellen, bis wir sie sehen. So finden wir in vielen Science-Fiction-Bildern aus dem 1950ern weiterhin Röhrenfernseher und kabelgebundene Telefone. Und gemäß Marktforschung aus der jeweiligen Zeit braucht praktisch kein Mensch Computer zu Hause, Digitalkameras, das Internet oder Handys ohne Tasten. Entsprechend hilft uns auch die Marktforschung nur sehr eingeschränkt.
Ähnlich sieht das bei Software aus, die in Unternehmen genutzt wird. Modernisiert man dort einmal ein altes System, über das die Fachbereiche seit Langem klagen, und erfragt dann die Anforderungen, erhält man meistens: „Genauso wie das alte System bis auf <5 Dinge, die die User beim bestehenden System stören>“. Es wird der Status quo extrapoliert. Echte Neuerungen kann man sich nicht wirklich vorstellen.
Mit Scheuklappen durch die (ungewisse) Welt
Anforderungen gaukeln uns eine Gewissheit vor, die es in der Regel also nicht mehr gibt. Letztlich sind sie ein Relikt aus den Zeiten, als die Märkte noch langsamer waren und die Anbieter noch das Zepter in der Hand hatten. Aufgrund der Veränderungsträgheit halten die meisten Unternehmen noch an diesem veralteten Weltbild fest. Das Handeln im Glauben an die Gewissheit hat sich fest in das Unternehmensgedächtnis eingebrannt und ist da nur extrem schwer wieder herauszubekommen.
Erschwerend kommt dazu, dass die meisten Menschen Ungewissheit hassen. Sie wollen Gewissheit, bis hin in die oberen Führungsetagen, wo man als „führungsstarker“ Manager stets klar vorhersagen können muss, was in der Zukunft passieren wird – Gewissheit muss sein, egal ob sie in Wirklichkeit existiert oder nicht. Da werden dann gerne einmal die Scheuklappen aufgesetzt und störende Dinge wie VUCA im kollektiven Unternehmensgedächtnis einfach ausgeblendet.
Aus Anforderungen werden Hypothesen
Wenn man aber die Scheuklappen ablegt, dann kann man nicht mehr verleugnen, dass Gewissheit heute an den meisten Stellen eine Illusion ist. Die Ungewissheit dominiert und wir müssen raten, was unsere Nutzer:innen, insbesondere die Kund:innen wollen. Um sich in einem solchen Umfeld sinnvoll bewegen zu können, benötigt man keine Anforderungen, sondern Hypothesen. Wir behaupten nicht mehr, zu wissen, was unsere Nutzer wollen. Stattdessen formulieren wir eine Idee, was sie wollen könnten, und ein Messkriterium, mit dessen Hilfe wir überprüfen können, ob wir auf dem richtigen Weg sind oder ob wir gerade dabei sind, ein totes Pferd zu reiten.
Damit verändert sich die oben zitierte User-Story zu einer Hypothese der Form: „Wir glauben, dass <Rolle> <Verhalten> will. Ob wir auf dem richtigen Weg sind, überprüfen wir mit <Messkriterium>“. Damit wird schon über die Formulierung klar, dass wir nicht genau wissen, ob wir richtig geraten haben. Wir haben aber eine Möglichkeit, es zu überprüfen.
Prinzipiell könnte man an der Stelle auch noch die Begründung aus der User-Story einfügen. Persönlich bin ich aber kein Freund davon: Wenn ich eine Annahme unter Ungewissheit treffe, dann ist normalerweise auch die Begründung unklar. Dadurch, dass ich eine Begründung angebe, suggeriere ich aber wieder eine Gewissheit, die ich in der Regel nicht habe.
Von Epics zu kleinstmöglichen Fragen
Ein Problem haben wir an der Stelle noch. Was haben wir davon, wenn wir ein Epic umsetzen, das richtig viel Zeit und Geld kostet, um dann hinterher beim Messen festzustellen, dass es eine Fehlinvestition war? Das ist doch eine Art Hornberger Schießen: Via Hypothese holen wir uns einfach nur im Nachhinein die Bestätigung, dass wir falschgelegen haben. Auch wenn wir dadurch möglicherweise etwas für die Zukunft gelernt haben, ist das mit Blick auf das verlorene Geld ein geringer Trost.
An der Stelle kommt ein Effekt zum Tragen, der sich in der Regel einstellt, wenn man von Anforderungen zu Hypothesen wechselt: Gute Product Manager werden zögern, große Epics am Stück umzusetzen, insbesondere wenn ihnen bewusst ist, dass die meisten Ideen keinen Mehrwert stiften (wie zuvor geschrieben: Gemäß Daumenregel stiften 9 von 10 Features keinen Mehrwert). Entsprechend werden die Product Manager in der Regel beginnen, ihre Epics in eine Reihe kleinerer Teil-Features zu zerlegen, über die man sich wiederholtes Feedback von den Nutzern holen kann. So kann man über eine Reihe von Teilschritten immer wieder validieren, ob man (noch) auf dem richtigen Weg ist. Auf diese Weise kann man die Richtung anpassen, wenn das Feedback nicht wie erhofft ist, beziehungsweise bei mehreren negativen Messungen das Epic komplett verwerfen – und zwar, bevor ein großer Teil des geplanten Budgets verbraucht ist.
Der erste Schritt ist immer der schwerste
Auf diese Weise kann man mit Hypothesen viel effektiver und auch deutlich effizienter unter Ungewissheit navigieren. Man muss „nur“ akzeptieren, dass die Welt VUCA geworden ist. Der Rest ergibt sich dann eigentlich schon fast von alleine. Aber wie so häufig ist der erste Schritt der schwerste ...
Uwe Friedrichsen
Herausgeber
