it-swarm.com.de

Sammeln und Gewichten von Stakeholder-Ideen

Dokumentieren Sie bei der Befragung von Stakeholdern zur Erfassung von Geschäftsanforderungen auch Inhaltsideen wie Produktvorteile oder Ideen für Abschnitte auf der Website? Fügen Sie sie in dasselbe Anforderungsdokument ein und wie sehr folgen Sie diesen Ideen? Machst du eine Art Ausdünnung?

5
Tony Bolero

Du machst Benutzer Erlebnisdesign. Es heißt nicht Stakeholder Experience Design aus einem bestimmten Grund.

Ihr primäres Ziel ist es also, alle Stakeholder zu gewinnen, die tatsächlich etwas zu tun haben mit dem System: diejenigen, die es tatsächlich verwenden. Dies sind die Kunden, die Administratoren, was auch immer, zusammengerufen Benutzer.

Ihre Kunden sind nicht Ihre Benutzer. Normalerweise sind Ihre Kunden Leute mit zu viel Geld, die die Leute beschäftigen, die tatsächlich Ihre Benutzer sind.

Normalerweise müssen Ihre Kunden nur eines: Sie möchten, dass sich die Benutzer so verhalten, dass sie mehr Umsatz erzielen.

Das Unglückliche ist, dass Sie von Ihrem Kunden angestellt werden, nicht von Ihren Benutzern.

In der Regel sind die Programmierer auch Stakeholder: Einige möchten eine einfache Implementierung, andere eine Herausforderung, andere möchten einige neue Technologien ausprobieren.

Ihre Priorität ist zunächst einfach: Benutzer die bestmögliche Erfahrung machen.

Letzte Priorität: eliminiere alles, was die Benutzer nicht benutzen. Wenn der Kunde darauf besteht, dass er seinen Welpen auf jedem einzelnen Bildschirm einer Website haben möchte, die nichts mit Welpen zu tun hat, können Sie ihn einfach schließen. Ich sage nicht, dass Sie es nicht tun sollten, wenn es ihre Manie ist, aber es ist Ihre letzte Priorität.

Mittelweg: Wenn es einen Widerspruch zwischen Benutzern und Kunden gibt, wählen Sie eine Lösung, die den Benutzern den geringsten Schmerz und dem Kunden den größten Umsatz bringt. Die Reihenfolge ist wichtig: am wenigsten Schmerzen zuerst. Sie sind wieder ein User Experience-Designer.

Sie können ein einfaches Diagramm zeichnen, in dem Sie sagen:

mockup

bmml source herunterladen - Wireframes erstellt mit Balsamiq Mockups

Als User Experience Designer besteht Ihre Aufgabe darin, schmerzarme Lösungen für Benutzer zu erstellen. Als Mitarbeiter des Kunden müssen Sie jedoch Einnahmen erzielen. Ihre Priorität liegt bei den Nutzern - der Beruf, der sich etwas mehr auf den Umsatz konzentriert, heißt "Marketing"

Wenn es wieder ein Kostenproblem gibt, Sie sollten die beste Benutzererfahrung innerhalb der verfügbaren Ressourcen anstreben. Zu den Ressourcen gehören Kosten, Technologie, Zeit usw. Als Mitarbeiter müssen Sie das Budget einhalten, und als Kollege sollten Sie den Entwicklern nicht zu viel Ärger machen. Sie sollten dies jedoch an vernünftige Grenzen bringen: Bei Ihrem Job geht es um die Benutzererfahrung. Solange die Entwickler mit ihrem Job zufrieden sind, sollten Sie sie bitten, die Vorteile für die Benutzer zu nutzen, aber ihnen manchmal ihren kreativen Spielplatz zu lassen.

Wenn es innerhalb verschiedener Benutzergruppen ein Problem gibt, zahlende Benutzer stehen an erster Stelle: Während Sie aus dem Kundenservice keinen Albtraum machen sollten, halten Kunden (des Produkts) das Unternehmen am Leben . Wenn der Kundendienst also jeden Morgen weitere 10 Minuten benötigt, um sich eine bestimmte Funktion anzusehen, die das Bezahlen zahlender Benutzer der Software erleichtert, werden sie nicht daran sterben. Wenn Sie jedoch eine Funktion verwenden können, um dem Servicemitarbeiter weniger Schmerzen zu bereiten, tun Sie Folgendes: Der Kundendienstmitarbeiter ist immer noch Ihr Benutzer.

Ihre Abmessungen sind folgende:

  • externe Benutzer, die das Unternehmen am Leben erhalten
  • interne Benutzer, die das Produkt am Laufen halten
  • entwickler und andere Stakeholder, die das Produkt zur Verfügung stellen
  • kunden, die für Sie und für alle anderen in den beiden vorherigen Gruppen bezahlen

Ihre Prioritäten sind ähnlich. Als User Experience Designer sollten Sie sich mehr auf die ersten beiden Gruppen als auf die letzten beiden konzentrieren. Immer wenn es zu Interessenkonflikten kommt, versuchen Sie, dem Partner mit niedrigerer Priorität einen minimalen Verlust zu bringen, während Sie das Beste für den Partner mit höherer Priorität haben.

Das heißt natürlich, es ist ein hartes Gleichgewicht und es muss von Fall zu Fall entschieden werden.

1
Aadaam

Mit Stakeholder gehe ich davon aus, dass Sie den Kunden-/Produktmanager meinen, da meiner Meinung nach auch das Entwicklerteam ein Stakeholder ist. Auf jeden Fall ist es normalerweise eine gute Idee, die Anforderungen (den "Was" -Teil) von den Implementierungsdetails (den "Wie" -Teil) zu trennen. Manchmal denken die Kunden-/Geschäftsanalysten, dass sie am besten wissen, wie ein System entwickelt werden sollte, aber tatsächlich ist es nicht korrekt. Ich denke, Sie können Inhaltsideen dokumentieren, aber sie aus den Geschäftsanforderungen heraushalten.

2
Aziz Shaikh

Erstens denke ich, dass diese Frage eher zu einer Site wie Programmierer gehört.

Bei meiner Arbeit haben wir alle Fehler und Vorschläge in dieselbe Liste aufgenommen. Es liegt dann an dem Produktmanager und dem Entwicklerteam, diese zu bewerten.

Wir geben ihm eine Beschreibung, die sowohl Was als auch Warum unter dem Gesichtspunkt des Benutzerszenarios enthält. Technische Details finden Sie in einem Abschnitt mit Notizen.

Wir empfehlen allen, einschließlich Benutzern, Feature-Vorschläge zu melden. Sie sollten dokumentiert werden, um die Bedürfnisse des Benutzers zu verstehen und nicht die Details zu bestimmen, wie man dorthin kommt. Der Prozess zur Bewertung von Vorschlägen findet im Entwicklungsteam statt, und es liegt im Wesentlichen an den Entwicklern, zu entscheiden, wie er implementiert werden soll.

Und vergessen Sie nicht Ford: "Wenn ich fragen würde, was meine Kunden wollten, würden sie ein schnelleres Pferd sagen."

1
JOG