in Anforderungsanalyse, Engpassorientierung, Erfolgskriterien, Requirement-Engineering, Software-Engineering

Soviel wie nötig, oder so viel wie möglich?

Ein erfahrener Springreiter springt nicht höher, als es das aktuelle Hindernis erfordert. Das ist zweifellos vernünftig, es schont die Kräfte für die nächste Herausforderung. Ist das auch die richtige Einstellung wenn es um die Entwicklung einer Anwendung geht? Ich meine: Nein!

Bühne frei für ein Wunschkonzert?

Heißt das, dass ich dafür bin, „gold plating“ zu betreiben, jedes Usability Feature umzusetzen und Automatismen zu implementieren, wo immer jemand eine Idee hat, was man noch automatisieren könnte? Nein, bin ich nicht. Aber ich lehne es auch ab, eine Anforderung nur deshalb zu verwerfen, weil sie nicht zwingend notwendig ist. Ich finde es seltsam, wenn Top-Manager massiv darauf drängen, alle Anforderungen abzublocken, die nicht unbedingt notwendig für den Betrieb der Anwendung sind. Man müsste sie fragen, wozu sie als Dienstwagen einen großen BMW, Audi oder Mercedes fahren, obwohl man mit einem Dacia auch von A nach B kommt. Und man muss nicht beim Meinl am Graben oder beim Käfer einkaufen, es gibt alles, was ein Mensch zum Essen und Trinken braucht auch beim Lidl. Polemischer Vergleich? Naja, ein wenig schon, aber nicht völlig aus der Luft gegriffen. Denn so wie man bei Autos Komfort, Sicherheit, Zuverlässigkeit und auch „Freude am Fahren“ als Entscheidungskriterien akzeptieren muss, sollte man auch bei IT-Anwendungen akzeptieren, dass diese auch Freude machen dürfen, wenn man mit ihnen arbeitet.

Ja oder nein – wie soll man entscheiden?

Natürlich ist es eine Frage der Möglichkeiten und damit der Priorisierung, wie weit man hier gehen kann. Aber Usability und Effizienz ist nicht nur eine Frage des Aufwandes. Es ist mindestens im gleichen Ausmaß auch eine Frage der Kreativität. Und es ist zum allergrößten Teil eine Frage der Fähigkeit und Bereitschaft, den Anwendern genau zuzuhören und ihre Wünsche ernst zu nehmen.

Die Wünsche ernst nehmen heißt aber nicht, diese 1:1 umzusetzen. Damit soll nicht einer überheblichen Einstellung im Sinne von „Wir wissen besser, was der Kunde will als der Kunde selbst“ das Wort geredet werden. Aber ein Designer entwickelt Lösungen, die Kunden überraschen. Lösungen, die eine bessere Erfüllung der Kundenbedürfnisse bieten, als wenn man genau die Vorstellung des Kunden umgesetzt hätte. Ein guter Architekt analysiert die Kundenwünsche sehr genau, leitet daraus Kriterien für gute Lösungen ab. Dann entwickelt er mit seiner speziellen Expertise eine Lösung, die diese Kriterien erfüllt. Ich möchte in keinem Haus wohnen, das genau nach meinen Vorgaben gebaut wurde! Und klassisch Henry Ford: „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt: schnellere Pferde.“

Priorisierung bei IT-Projekten

Was bedeutet das für IT-Projekte? Wenn man User-Stories sammelt, ist das ein guter Weg, um Wünsche der Anwender möglichst unverfälscht zu erfahren. „Dann hat er die Teile in seiner Hand. Fehlt, leider! nur das geistige Band“, so sagt treffend Goethes Mephisto. Ein Design, eine Architektur entsteht nicht durch Addition von Einzelanforderungen. Sie ist ein eigenständiger kreativer Akt, dessen Ergebnis mit den einzelnen Anforderungen abgeglichen wird, wodurch sich sowohl das Design als auch die Anforderungsdetails verändern. Dieser Prozess wird meist mehrfach durchlaufen. Die Anforderungen bleiben weitgehend konstant, der Architekturentwurf kann sich mehrmals völlig verändern.

Wo macht Architektur den entscheidenden Unterschied?

Nun konkretere Beispiele aus der IT: Ob ich die Geschäftsregeln hart programmiere oder in eine Business Rule Engine auslagere, ist eine Architekturentscheidung. Nur in seltenen Fällen finde ich diese als User Story eines Anwenders vor. Ob ich eine Prozess-Engine implementiere oder nicht, ist natürlich von der Variabilität der Geschäftsprozesse abhängig. Ebenso von den Möglichkeiten der Entwicklungsplattform, die ich nutze und es hat auch etwas mit Kosten zu tun. Die Gestaltung des User Interface ist in den meisten Fällen durch die technische Plattform weitgehend vorgegeben bzw. nur im Rahmen der von dieser gebotenen Möglichkeiten gestaltbar. Es gibt Rahmenbedingungen, die man auch in einem agilen Projekt nicht ändern kann und es gilt: „Gute Architektur kommt nicht von Gelegenheitsarchitekten“.

Setzen wir voraus, dass ein angemessenes Budget für das Projekt zur Verfügung steht. Das heißt keineswegs, dass Geld keine Rolle spielt. Gerade enge Vorgaben setzen oft Kreativität frei und ergeben Lösungen, die man mit mehr Budget nicht gefunden hätte, weil man nicht danach gesucht hätte. Aber wenn ein Projekt deutlich unterdotiert ist, gibt es kein Wundermittel, um es zum Erfolg zu führen. Dazu habe ich an anderer Stelle meine Meinung gesagt. Der notwendige Aufwand hängt von vielen Faktoren ab, die Anwenderanforderungen sind nur einer davon. Auch dazu hier mehr. Die Annahme, dass die Budgetvorgaben realistisch sind, ist also nicht nur notwendig, sie ist auch wahrscheinlich.

Zu bescheiden ist auch nicht gut

Wenn User-Stories gesammelt werden, wiederhole ich als Product-Owner immer wieder: Bitte keine vorauseilende Resignation! Nennen Sie alle Wünsche an die Anwendung, wir werden alle als User-Stories in den Backlog aufnehmen. Das heißt allerdings nicht, dass sie auch realisiert werden. Manche Anforderungen werden in späteren Phasen des Projektes als unzweckmäßig erkannt, manche als unnötig bis störend. Manche erweisen sich als extrem aufwändig in der Realisierung, diese werden dann nochmals hinterfragt und es wird nach Alternativen gesucht, mit denen die Anforderung mit geringerem Aufwand erfüllt werden kann.

Und ich stelle auch noch eine Frage, in späteren Phasen der Anforderungsanalyse: Was würde Sie begeistern? Was wäre ein wirklich cooles Feature? Was dann kommt, weist direkt auf den Engpass der Ist-Situation hin. Und was sich auch regelmäßig zeigt: Es sind Features, von denen die Entwickler meinen, das sei doch nichts Besonderes und kein großer Aufwand. Wenn das so ist, umso besser. Wenn es doch mehr Aufwand und nicht so einfach umzusetzen ist, dann lohnt es sich aber, mehr darüber zu diskutieren. Vielleicht kann man andere Anforderungen zurückstellen, wenn man das coole Feature bekommt. Das ist ein Vorgang, der zwar Verzicht erfordert, aber insgesamt trotzdem mit positiven Emotionen verbunden ist. Die Anwender sind ja Realisten, sie wissen, dass es Grenzen gibt, meist weniger das Budget, sondern die verfügbaren Ressourcen an Entwicklern und Testern.

Am Ende steht also: wir machen soviel wie möglich. Vorrang hat alles, was wirklich wichtig ist. Und zumindest ein Luxus-Feature sollte sich ausgehen, wenn wir sparsam mit unseren Ressourcen umgehen.

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

Schreibe einen Kommentar

Kommentar