Wie sollten wir die Moskauer Priorisierung auf unsere Projektanforderungen anwenden?

TL; DR

Die MoSCoW-Methode bietet einen Rahmen für die Priorisierung basierend auf Bucket-Sortierung von Merkmalen. Es soll flexibel sein, also müssen Sie es für Ihr Projekt anpassen. Sie können die Definitionen und Kriterien für jede Ebene nach Bedarf anpassen und müssen möglicherweise zwischen Merkmalen, die vorhanden sein sollten, und Merkmalen, die vorhanden sein könnten , unterscheiden . Allerdings müssen Sie auf jeden Fall zwischen Must Have , Won't Have und allen Features unterscheiden, die bis zu einem gewissen Grad optional sind.

Priorisierung und Geltungsbereich

Die Seite, auf die Sie in Ihrer ursprünglichen Frage verlinkt haben, enthält Beispieldefinitionen und Filterkriterien für jede Ebene. Ich werde ihre vollkommen brauchbare Erklärung nicht wiederholen, aber vielleicht wird es klarer, wenn Sie es als eine Übung zum Scoping betrachten.

1. Must-Have- Features sind Teil des Minimum Viable Product und müssen innerhalb des Geltungsbereichs bleiben.
2. Funktionen, die (dieses Mal) nicht vorhanden sind, sind für das aktuelle Projekt ausdrücklich nicht im Umfang enthalten, können aber in zukünftigen Projekten erneut aufgegriffen werden.
3. Funktionen, die „ Sollen“ oder „Möchten“ haben , sind im Umfang enthalten, können jedoch während des Projektlebenszyklus geändert oder entfernt werden, da sie für das minimal realisierbare Produkt nicht wesentlich sind.

Definitionen und Filterkriterien für jede Ebene

Die Seite, auf die Sie in Ihrer ursprünglichen Frage verlinkt haben, enthält Beispieldefinitionen für jede der Ebenen. Darüber hinaus enthält Abschnitt 10.3 Anleitungen zum Definieren der einzelnen Ebenen für Ihr spezifisches Projekt und zum Festlegen der Kategorisierung. Darin heißt es auszugsweise:

Vor der Erfassung der Anforderungen müssen die Definitionen von Muss, Soll, Könnte und Wird nicht mit dem Unternehmen vereinbart werden. Einige Beispiele sind oben beschrieben. Die Must-Have-Definition ist jedoch nicht verhandelbar. Jede als „Must Have“ definierte Anforderung hat einen entscheidenden Einfluss auf den Erfolg des Projekts. Der Projektmanager oder Business Analyst sollte Anforderungen hinterfragen, wenn es sich nicht um offensichtliche Must Haves handelt; Es liegt am Business Visionary oder seinem bevollmächtigten Business Ambassador, zu beweisen, dass eine Anforderung ein Muss ist. Wenn er/sie es nicht kann, ist es bestenfalls ein Must Have.

Anders ausgedrückt, jedes Projekt muss:

1. Führen Sie die Übung durch, um jede Ebene so zu definieren, wie sie für das aktuelle Projekt gilt. Definitionen können zwischen Organisationen und sogar zwischen Projekten innerhalb einer einzelnen Organisation variieren, es sei denn, die Organisation hat einen internen Standard erstellt.
2. Lassen Sie die Stakeholder jede Kategorisierung, insbesondere die Must-Have-Kategorie, basierend auf ihren Geschäftstreibern begründen. Dies hängt von den Zielen des Projekts ab und sollte im Kontext der Projektcharta bewertet werden.

Ich glaube, Sie brauchen sie alle, um sich zu unterhalten. Zuerst kategorisieren Sie alle Anforderungen und überprüfen dann das Ergebnis und sehen, was in der Liste nach unten verschoben werden kann. Nach ein paar Iterationen haben Sie eine Anforderungspyramide: Muss oben, wird nicht müssen unten. Sie verwenden Ihre Ressourcen ganz oben und bringen den Rest in die nächste Diskussion ein.

Beachten Sie, dass die Kategorisierung kurz- und langfristig erfolgen kann. Zum Beispiel könnte etwas, das jetzt zu haben sein könnte – eine AWS-Infrastruktur anstelle einer Rack-Lösung –, aber in Kürze zu einem Must-have werden – Erhöhung des Kundenstamms, Bedarf an Skalierbarkeit.

Ich bereite mich auf AEC und CSM vor, und es wäre wahrscheinlich hilfreich, wenn Sie dies aus einer breiteren agilen Perspektive sehen würden.

Domäne Eins der agilen Praktiken ist die wertorientierte Bereitstellung. Zu den „Praktiken für wertorientierte Bereitstellung“ gehören:

• Wert einschätzen
• Planungswert
• Bereitstellung von Mehrwert
• usw...

Planungswert beinhaltet „Kundenwert-Priorisierung“ mit der Absicht, dem Kunden zuerst die Produkte oder Funktionen mit dem höchsten Wert zu liefern. Moskau ist nur eine von vielen Optionen, die Ihnen zur Verfügung stehen.

Wie jemand bereits erklärt hat, setzt es Ihre Anforderungen in Eimer, oder wie das Buch gerne "Affinitätsgruppierungen" sagt, basierend auf genau diesen Merkmalen:

• Haben müssen
• Sollte haben
• Könnte haben
• Hätte gerne (aber diesmal nicht).

Danach liegt es einfach an Ihnen!!! Andere Kundenwert-Priorisierungsschemata, die Sie verwenden könnten, umfassen:

• Einfache Schemata ("Priorität 1", "Priorität 2" usw.);
• Monopolgeld (Projektbudget wird durch Spielgeld dargestellt, und Kunden weisen einen Teil dieses festen Betrags den Funktionen zu, die sie am meisten wünschen);
• 100-Punkte-Methode (Dean Leffingwell und Don Widrig);
• Kano-Analyse (Noriaki Kanos Methode zur Gruppierung in Exciters, Satisfiers, Dissatisfiers und Indifferent).

Auch hier liegt es an Ihnen, wie Sie es ausführen, und Sie haben mehr als nur Moskau zur Auswahl. :-)