Ein Jahr Anforderungsmanagement, oder: Warum sich Planung ändern muss.

Ein Jahr Anforderungsmanagement …

Avatar von Björn Schotte

Der Zeitpunkt ist gekommen, feierlich stehen wir da. Das Anforderungsmanagement. Das Produktmanagement. Die UX-Agentur ist stolz auf die Ergebnisse der Designs und Wireframes. Die Abteilungsleitung freut sich: Jetzt haben wir alle Anforderungen zusammen! Die, die wichtig sind. Unzählige Abstimmungsrunden und ein paar Anwender-Interviews sind vergangen. Der Vorstand ist auch einverstanden. Das Budget ist freigegeben, nach Präsentation des Steuerungsgremiums. Endlich können wir in die agile Softwareentwicklung starten. Wäre da nicht schon wieder dieses Missverständnis …

Mit der Zeit gehen

Die Softwareentwicklung und die BWL, die stehen bekanntlich auf Kriegsfuß: Irgendwie möchte man vorher wissen, was nachher rauskommt. Mit spitzem Bleistift müssen wir rechnen, schon klar. Doch erinnern wir uns zurück: Warum wollen, ja müssen wir agil arbeiten?

Weil die Welt sich schneller dreht und Überraschungen drohen. Die kleine, wendige Konkurrenz, die schon sechs Monate früher mit der Entwicklung begonnen hat, während der große Tanker also noch damit beschäftigt war, möglichst vollständig die Anforderungen zu durchdenken.

In einer Welt, die immer komplexer wird, in der das Verhalten von Kunden nicht mehr so gut vorherzusagen sind und sich die Wünsche der Anwender beständig ändern, ist solch ein Vorgehen nicht mehr zeitgemäß. Und das ist genau der Grund, warum agile Frameworks wie Scrum oder Kanban verwendet werden. Im Sinne eines Frameworks zur empirischen Prozess-Kontrolle, das in kleinen Iterationen arbeitet und regelmäßige Lieferung von funktionsfähigen Inkrementen vorsieht. Aber auch im Sinne eines veränderten Zusammenarbeitsmodells, das auf Werten und Prinzipien fußt.

Dem Wettbewerb voraus!

Wie wir es also drehen und wenden: Kein Stein bleibt mehr auf dem anderen. Wollen Unternehmen wettbewerbsfähig bleiben oder sogar dem Wettbewerb voraus sein, müssen sie anders an die Arbeit heran gehen.

[smartblock id=“7912″]

Das bedeutet letztlich, dass eine Vertikalisierung der Arbeit stattfindet. Das, was früher in nacheinander stattfindenden Phasen unterteilt wurde, findet also nahezu gleichzeitig statt. Damit verkürzt sich die Wartezeit für den Start in die Entwicklung von Software. Wir fangen also deutlich früher damit an. Wir verzichten auf die konzeptionelle Ausarbeitung von Anforderungen, die erst viel später entwickelt werden und von denen wir heute noch gar nicht wissen, ob wir sie später überhaupt benötigen werden.

Schneller Erkenntnisse gewinnen

Das verschafft uns (finanzielle) Luft für das, was eigentlich wichtig ist: Möglichst frühzeitig mit dem Produkt zum Endanwender zu kommen. Um auf Basis des Feedbacks der Anwender viel früher als bisher Erkenntnisse zu gewinnen. Damit wir genau die richtigen Funktionen entwickeln, die die Anwender benötigen werden.

Und damit frühzeitiger in den Genuss von Wettbewerbsvorteilen kommen – die es bei herkömmlichem Herangehen zu späteren Zeitpunkten nicht mehr geben wird.

Und das geht nur, wenn wir unsere Arbeitsweise verändern.

Avatar von Björn Schotte

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.