Pareto: Der Yoda der Anforderungen
Yoda sagte nicht „Schreibe einen 50-seitigen Plan, bevor du loslegst.“, sondern „Tu es oder tu es nicht, es gibt kein Versuchen.“
Vilfredo Pareto lehrte uns, dass wir mit 20 % Aufwand bereits 80 % der Ergebnisse erzielen können. Doch was ist konkret damit gemeint?
Wenn wir Anforderungen erheben, also noch ganz am Anfang in der Entwicklung stehen, ist es wichtig, diese Anforderung zu den Stakeholdern zu tragen und konstruktive Diskussionen loszutreten. Es ist tatsächlich besser geeignet, grob formulierte Anforderungen als Gesprächsgrundlage zu verwenden, als Ressourcen dafür zu verschwenden, diese bis ins kleinste Detail zu spezifizieren. Und dies nicht nur aus dem Grund, dass u. U. gewisse Spezifikationen sowieso nur von den wenigsten Stakeholdern verstanden werden.
Möge die Kommunikation mit dir sein
Versteht mich bitte nicht falsch. Für die Implementierung einer Anforderung ist ein gewisser Granularitätsstandard definitiv wichtig und sogar essenziell! Es geht aber zu Beginn einer Entwicklung nicht darum, diese direkt zu implementieren, sondern diese zu validieren und zu diskutieren.
Diskussionen sorgen dafür, dass wir neue Sichtweisen auf diese Anforderungen erlangen und ggfs. gewisse Teilaspekte aus einem anderen Blickwinkel hinterfragen. Der Schlüssel dafür lautet: Kommunikation auf Augenhöhe!
Es ist wichtig, dass wir alle dieselbe Sprache sprechen, wenn wir über Anforderungen diskutieren. Es bringt nichts, wenn ich einem Sales Mitarbeiter erkläre: „Wir überlegen das Framework auf die Version XY zu updaten, so dass die Interaktion des Benutzers erhöht wird.“ Das potenzielle Feedback, welches ich an der Stelle erhalten würde, würde sich höchstwahrscheinlich in Grenzen halten. Das viel bessere Ergebnis erhalte ich, wenn ich sage: „Wir überlegen dem Benutzer die Möglichkeit zu geben, die UI Elemente selbst anordnen zu können.“ Hier würde ich in dem konkreten Fall wahrscheinlich konstruktiveres Feedback erhalten.
Doch wie können wir dieses Prinzip nun konkret im Arbeitsalltag anwenden?
Die Rückkehr der User Stories
Die grobe Form der User Story eignet sich perfekt, um erste Diskussionen über Anforderungen loszutreten!
Hilfreich kann dabei folgendes sein:
- Orientierung geben, aber Spielraum für Diskussionen zulassen.
- Klare Intention, keine starren Vorgaben.
- „Als [Rolle] möchte ich [Funktion], um [Nutzen] zu erzielen.„
- Erste Akzeptanzkriterien definieren.
- Nicht zu technisch, sondern nutzerorientiert formulieren.
User Stories sorgen dafür, dass wir flexibel bleiben, effizient arbeiten und uns nicht in detaillierten Dokumentationen (zu Beginn der Entwicklung) verlieren.
Also, einfach mal machen!
