Wer hat eigentlich diese Software verbrochen?


 

Umfangreiche Software wird oft aus "Einkäufer-Perspektive" entwickelt.

Was heißt das? - Nun, bei der Sammlung funktionaler Anforderungen, im Oberflächen-Design und der gewählten Technologie, stehen nicht selten die Begeisterungsanforderungen der Geldgeber im Fokus. Das sind Führungskräfte und Einkäufer, Projektsponsoren, Investoren etc. Doch sind diese Stakeholder nachher auch die Hauptbenutzer der Lösung? In der Regel nicht. 

 

Es ist völlig verständlich und zu einem gewissen Grad auch erfolgskritisch, die Budgetgeber mit einer "coolen Lösung" für sich zu begeistern. Hier geht es aber häufig primär darum, auf sich aufmerksam zu machen, in den Dialog zu treten und dann die passende Geschichte zu erzählen. 

Das Hauptaugenmerk muss dann aber auf die zukünftigen Benutzer gerichtet werden. Menschen, die täglich mit der Lösung ihre Arbeit erledigen müssen. Entsteht dort Frust, landet dieser irgendwann wieder beim "Einkäufer". Und dieser geht dann i.d.R. ein Häuschen weiter zum Hersteller und lädt dort den gesammelten Frust ab. 

 

Viel schöner wäre doch, wenn die Benutzer zufrieden mit der Lösung sind (und diese daher ggf. gar nicht kommentieren) oder sogar begeistert (und die Lösung vielleicht sogar loben). Noch viel schöner wäre es dann, wenn bei der aktiven Benutzung weitere Ideen oder Verbesserungspotentiale entstehen, die von den Benutzern eingesammelt und flexibel umgesetzt werden können. Eine wunderbare Welt. 

 

Klingt unrealistisch?

 

Das alles ist überhaupt so utopisch wie es klingt, wenn man sich frühzeitig mit den zukünftigen Benutzern einer Lösung beschäftigt und sie sogar in den Entwicklungsprozess involviert. Bevor wir eine Software entwickeln, erarbeiten wir zu Beginn in Workshops oder Interviews mit zukünftigen Benutzern deren Anforderungen und Bedürfnisse. Einen Teil davon (ca. 20 %) können wir in der Regel zügig in z. B. Prototypen umsetzen, die durch besondere Funktionalitäten oder einen neuartigen Oberflächenentwurf auch die "Einkäufer" begeistern, während sich die Hauptentwicklungskapazität mit der langfristigen Zukunft der Lösung beschäftigt (80 %). Auf dieser Basis lassen sich zukunftsfähige Software-Architekturen aufbauen, die eine ständige Weiterentwicklung und Anpassung erlauben und so den Benutzern die notwendige Prozessflexibilität liefern.

 

Interessanter Ansatz? Dann lassen Sie uns drüber sprechen. 

Kontakt