Aufgeschriebene Anforderungen sind oft schlecht formulierte Wünsche!
Die Szenarien
Schauen wir uns die drei Szenarien aus dem Schaubild einmal genauer an: Das Szenario 1 setzt sehr viel Wissen des Stakeholders darüber voraus, was er haben will! Der Stakeholder muss eindeutig und vollständig seine Anforderungen dokumentieren. Das ist in der Praxis unmöglich. Selbst wenn der Stakholder seine Anforderungen stehts den Veränderungen seines Kontextes anpassen würde, kann er keine Gewissheit darüber erlangen, wie der Leser seiner Anforderungen diese interpretiert.
In Szenario 2 gibt es Feedback vom Auftragnehmer, sodass in der direkten Kommunikation ein Erwartungsabgleich erfolgt und im Gegensatz zu Szenario 1 eine gemeinsame Vorstellung bzw. Hypothese über die Anforderungsumsetzung möglich ist. einen positive Veränderung tritt ein.
Szenario 3 setzt auf dem vorhergehenden auf und verifiziert die gemeinsame Hypothese von Stakeholder und Auftragnehmer in zeitlich kurz folgenden Lieferinkrementen. Dadurch wird zum einen die schnelle Lieferfähigkeit des Auftragnehmers transparent. Und die Stakeholder können zeitnah Feedback geben, ob sich ihre beabsichtigen Intentionen und Wünsche in den Liefer-Inkrementen abbilden. Ist das der Fall können weitere neue Themen in die Realisierung gegeben werden. Oder wenn Erwartungen nicht erfüllt wurden, können andere Lösungen in die Entwicklung einfließen, die den gemeinsamen Hypothesen besser entsprechen. Die Wünsche und Anforderungen des Stakeholders werden realisiert.
Das Kano-Modell (kleiner Exkurs)
Aus der Analyse von Kundenwünschen leitete Noriaki Kano, Professor an der Universität Tokio, 1978 ab, dass Kundenanforderungen unterschiedlicher Art sein können. Das nach ihm benannte Kano-Modell erlaubt es, die Wünsche (Erwartungen) von Kunden zu erfassen und bei der Produktentwicklung zu berücksichtigen. Dabei wird zwischen drei unterschiedlichen „Klassen“ von Faktoren unterschieden: Basis-, Leistungs- und Begeisterungsfaktoren.
Basisfaktoren werden als selbstverständlich angenommen. Deren Erfüllung und Berücksichtigung wird vorausgesetzt. Basisfaktoren werden oft nicht (mehr) explizit genannt. Die Erfüllung der Basisfaktoren trägt nicht zu einer gestiegenen Kundenzufriedenheit bei, die Nichterfüllung hat allerdings stark negative Auswirkungen auf die Kundenzufriedenheit. Die Erfüllung von Basisfaktoren alleine reicht nicht aus, um die Kunden zufrieden zu stellen.
Leistungsfaktoren werden hingegen in der Regel explizit genannt. Sie dienen den Stakeholdern oft zum Vergleich mit anderen Produkten. Je besser die Leistungsfaktoren erfüllt sind, desto größer ist die Kundenzufriedenheit. Dabei besteht ein annähernd linearer Zusammenhang.
Begeisterungsfaktoren sind neue, visionäre Anforderungen, die das Produkt von anderen Produkten differenzieren. Die Kundenzufriedenheit steigt stark (überproportional) mit diesen Begeisterungsfaktoren, der Kunde ist vom Produkt begeistert. Eine Nichterfüllung dieser Begeisterungsfaktoren führt zwar nicht zu einer Abnahme der Kundenzufriedenheit, allerdings vernachlässigt man dann ein eventuell wichtiges Differenzierungsmerkmal. Begeisterungsfaktoren sind oft den Kunden selbst nicht bewusst. Innovation bedeutet Erfüllung der Begeisterungsfaktoren. Prioritäten ändern sich im Laufe der Zeit. Was heute noch ein Begeisterungsfaktor ist, kann morgen bereits ein Basisfaktor sein. Zum Beispiel wenn Wettbewerber die Begeisterungsfaktoren auch erfüllen und später die Kunden nur noch implizit deren Erfüllung voraussetzen.
Zurück zu den Szenarien
Weshalb Szenario 1 oft scheitert und Szenario 2 meist nur mittelmäßige Ergebnisse liefert, kann sehr anschaulich am Kano-Modell erklärt werden.
Über was erfahrene Stakeholder gerne und gut sprechen können sind die Leistungsfaktoren einer Lösung, die sie sich vorstellen. Meist wird nicht über Basisfaktoren gesprochen. Die werden einfach stillschweigend vorausgesetzt. Wenn der Auftragnehmer viel Erfahrung hat kompensiert er diese Lücke im Allgemeinen. In Szenario 1 sorgen eher die Interpretationen, unerfahrene Stakeholder und die unterschiedlichen Hypothense über das was gemeint war zum „an einander vorbei entwickeln und liefern“.
Im Szenario 2 kann der Auftragnehmer diese Basis- und Leistungsfaktoren zu einer vermeindlich gemeinsamen Sicht konsolidieren. Da das „Wie“ aber auch hier weiter offenbleibt, wird zu Spät erkannt, dass die Vortsellungen über mögliche Lösungen doch weit auseinander lagen.
Mit Szenario 3 stehen die Chancen sehr gut, dass die von Stakeholder gewünschen Leistungs- und Basisfaktoren in erwarteter Qualität geliefert werden. Abweichungen werden zeitnah erkannt und korrigiert, sei es im Lösungsdesign oder den Stakeholder Anforderungen.
Ein sehr innovativer Auftragnehmer kann in eigeninitiative im Szenaio 3 auch Begeisterungsfaktoren liefern und durch die Stakeholder validieren lassen. Damit der Auftragnehmer solche Begeisterungsfaktoren systematischer erzeugen kann, soll im Folgenden eine (von vielen) und sehr innovative Methode beschrieben werden, mit der Stakeholder und Auftragnehmer eine Ende-zu Ende (E2E) -Sicht erzeugen, Leistungs- und Basisfaktoren für ein MVP (Minimal Viable Product) definieren und gemeinsam überlegen, was für Dinge zur Begeisterung der Stakeholder beitragen. Es handelt sich um das Format Story-Mapping.
Story Mapping
Jeff Patton, Keynote Speaker auf der REConf 2019, beschrieb dieses Format als einer der Ersten im Jahr 2008. Mit der folgenden Bilderserie (11) aus den Slides von Jeff Patton, wird das Format sehr gut beschrieben und visualisiert:
Fazit
Stakeholder sollten ein Bewußtsein darüber haben, welche „Gefahren“ im Beschreiben von Anforderungen liegen. Etwas zu beschreiben, was es noch nicht gibt, also keine Referenz hat, führt ohne direkte Kommunikation in den allermeisten Fällen zu mehrdeutigen Interpretationen. Damit zu unerwarteten Lösungen, die nur selten mit Begeisterung durch den Stakeholder akzepiert werden.
Der zur Zeit einzige Ausweg ist die direkte Kommunikation! Unterstützt durch Visualisierung, schnelle und kontinuierliche Lieferung sowie wiederkehrendes Feedback der Stakeholder, gelingt es deutlich mehr, akzeptabel Lösungen auszuliefern.
Gemeinsam besprochene, visualisierte und schnell realisierte Anforderungen sind oft erfüllte Wünsche!
Jens Donig
Kontaktieren Sie Jens DonigJens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.
Wissen, das bewegt!
Verpasse keinen der spannenden Artikel mehr auf blog.hood-group.com und melde dich für unseren Newsletter an! Erfahre alle 2 Wochen als Erster von den neuesten Branchentrends, erhalte exklusive Experten-Tipps und bleib über unsere Veranstaltungen immer auf dem Laufenden. Alles direkt in dein Postfach.
Jetzt abonnieren und keine wichtigen Insights mehr verpassen!
Diskussion