Hartelijk welkom zum ersten Teil des Interviews
Im letzten Jahr war unsere Chris Keynotespeakerin auf dem DREAM event in Nijkerk, Holland. DREAM = Dutch Requirements and management conference. Aber traumhaft war es auch. Und zwar so traumhaft, dass die Veranstalter Chris noch um ein Interview zu ihrer Keynote gebeten haben. Das Interview wird demnächst auf Englisch im DREAMmagazine erscheinen. In unserem Blog können Sie den ersten Teil des Interviews schon heute lesen. Der erste Teil fokussiert das Thema Stakeholderanalyse – oder im kriminalistischen Kontext: Zeugensuche!
Hallo Frau Rupp, vielen Dank noch einmal für Ihre inspirierende und originelle Keynote im letzten September. Wir freuen uns, dass wir im Rahmen dieses Interviews die Gelegenheit haben, Ihnen noch einige weiterführende Fragen zu stellen.
Stakeholderliste: Sie hatten das Konzept einer Stakeholderliste erklärt. Wir finden das sehr interessant und können uns vorstellen, dass diese sogar noch nützlicher ist, wenn man weitere Informationen über die Stakeholder hinzufügt, z.B. die Einstellung zum Projekt und die Entscheidungsbefugnis, die der jeweilige Stakeholder in diesem Projekt hat. Sehen Sie das auch so, oder halten Sie diese Informationen separiert von der Stakeholderliste? Falls Letzteres zutrifft, warum trennen Sie diese Informationen?
Eine Stakeholderliste sollte öffentlich zugänglich sein, so dass jede Person, die etwa mit dem Projekt zu tun hat diese kommentieren kann. Auf diesem Weg findet man häufig noch weitere wichtige Stakeholder, die einem empfohlen werden, da sie irgendjemand auf der Liste vermisst. Da die Stakeholderliste öffentlich ist, sollte man sich natürlich auch sehr gut überlegen, welche Informationen man da reinpackt. Informationen, wie die Einstellung einer Person zum Projekt, oder deren Entscheidungsmacht in diesem Projekt könnten da schon kritisch sein. Genau diese Informationen sind aber für uns als Requirements-Engineers sehr interessant. Deshalb kenne ich Projekte, in denen zwei Stakeholderlisten geführt werden. Eine öffentliche Version mit den eher unkritischen und für alle Beteiligten wichtigen Informationen. Eine weitere vertrauliche Stakeholderliste steht nur den Requirements-Engineers zur Verfügung. In dieser Liste finden sich dann teilweise Informationen darüber, wie entscheidend die Meinung dieser Person im Projekt ist, ob sie eher zugänglich oder schwierig in Interviews ist, wie ihre Einstellung zum Projekt ist, oder mit welchem Analytiker sie gut kann und vieles mehr.
Personas: Sie haben uns einiges über Personas erzählt und wie nützlich diese sind. Können Sie uns auch einige Nachteile bei der Benutzung von Personas nennen? Verwendest du Personas auch in Projekten in denen es eine begrenzte Anzahl an Stakeholdern gibt und diese alle gut erreichbar sind?
Personas haben natürlich auch Nachteile. Es kostet z.B. Zeit sie fundiert zu erstellen. Diese Zeit könnten Sie auch nutzen um bei einem späteren Nutzer des Systems direkt zu erfragen, was er vom System erwartet.
Sobald ich es mit einer sehr limitierten Gruppe an Stakeholdern zu tun habe, deren Anforderungen ich direkt ermitteln kann, unterlasse ich das Erstellen einer Persona. Eine Persona ist für mich immer nur ein Repräsentant für eine Gruppe von Personen über deren Wünsche und Verhalten ich mir möglichst konkret Gedanken mache, da ich sie nicht so konkret abfragen kann (weil die Gruppe zu groß oder nicht erreichbar ist). Bei einer Persona handelt es sich immer um einen Kompromiss, da ich in diese Persona die Wünsche einer gesamten Zielgruppe hineindichte. Dabei treffe ich schon eine Menge Entscheidungen, denn eine Persona ist ein Stereotyp, der angeblich eine ganze Gruppe repräsentiert. Eine Persona ist dann gut, wenn sich die Mitglieder der repräsentierten Gruppe zu 80% darin wiederfinden. Jede reale Person der Gruppe wird in gewissen Bedürfnissen entscheidend von der Persona abweichen.
Wenn ich allerdings die Wünsche aller konkreten Personen direkt erhebe, dann muss ich beim Gestalten des Systems auch Kompromisse schließen, denn im zukünftigen System lassen sich auch nicht alle Wüschen gleichzeitig umsetzen. Nur schließe ich hier explizit Kompromisse zwischen geäußerten Wünschen einzelner Stakeholder. D.h. ich weiß genau, wem ich mit welcher Entscheidung auf die Füße trete, weil ich seine Anforderung zurückweise.
Personas: Was ist Ihr Tipp, wie man eine gute Persona erstellen kann? Wie verhindern Sie, dass Sie zu viele Annahmen treffen?
Der sicherste Weg eine gute Persona zu gestalten, ist eine fundierte Marktforschung. Sie müssten eine empirisch signifikante Menge an Personen aus ihrer Zielgruppe befragen, diese Menge an Personen in die richtigen Unterzielgruppen unterteilen, deren Bedürfnisse und Eigenschaften statistisch auswerten und mit diesen Ergebnissen dann die Persona kreieren. Wenn Sie sich jetzt denken „das ist ja ein riesiger Aufwand“, dann liegen Sie absolut richtig. Das wird im Consumer Markt gemacht, wenn hochwertige Produkte erzeugt werden sollten, die für einen hart umkämpften Massenmarkt konzipiert werden. Ich schlage Personas immer als Ergänzung zu realen Stakeholdern vor, wenn entweder eine bestimmte Stakeholdergruppe nicht zugänglich ist oder zu groß ist um eine repräsentative Anzahl an Personen dieser Stakeholdergruppe zu befragen.
Im ersten Fall (reale Stakeholder aus dieser Gruppe nicht zugänglich) ist eine Persona, die die Stakeholdergruppe auch nur annähernd wiedergibt besser als gar keine Idee davon zu haben, wie die entsprechenden Stakeholder ticken. Ich hatte mal ein Projekt, in dem wir keinen Zugang zu den Wartungstechnikern hatten. Da haben wir uns etwas in das Berufsbild der in diesem Konzern arbeitenden Wartungstechniker eingearbeitet und darauf basierend einen Entwurf einer Persona erstellt. Die haben wird dann mit anderen Stakeholdern diskutiert, die Wartungstechniker im Unternehmen kannten, und Feedback eingesammelt. Am Ende haben wir dann doch einen Wartungstechniker gefunden, der zumindest die Persona reviewen konnte, sich sehr gut wiedergegeben fand und uns ein paar wichtige Anforderungen erzählen konnte.
Im Fall einer zu großen Stakeholdergruppe kombinieren wir Ermittlungstechniken mit realen Stakeholdern mit der Erfindung von Anforderungen auf der Basis von Personas. Die auf der Basis von Personas erfundenen Anforderungen legen wir den realen Stakeholdern zur Kommentierung vor und gleichen sie natürlich mit den Anforderungen der realen Stakeholder ab.
Sherlock Holmes: Wir fanden Ihren Vergleich mit Sherlock Holmes toll. Glauben Sie, dass gute Requirements-Engineers auch gute Detektive, so wie Sherlock Holmes, sind?
Ja, die Ähnlichkeit des Berufsbildes ist definitiv da. Man sucht bewusstes, unbewusstes und unterbewusstes Wissen. Man spricht mit willigen und unwilligen Befragungspartnern. Nicht jeder verrät einem die wirkliche Intention, …. Mit der Zeit gewinnt man als Requirements-Engineer immer mehr Einblick, kann konkretere Fragen stellen und Fakten abgleichen. Eben wie ein guter Detektiv ;-)).
Teil 2 des Interviews wird demnächst am gleichen Tatort (dem SOPHIST Blog!) folgen. Der Fokus: Detektivische Ermittlungstechniken und welche Eigenschaften einen guten Requirements-Engineer – also einen Sherlock – ausmachen.