Ich habe das MoSCoW-Modell verwendet (aber ich bin kein Projektmanager, ich bin Entwickler) und ich denke, es ist gut. Aber ich denke auch, dass Sie mir mehr erzählen und vielleicht einen Nachteil finden können, an den ich nicht gedacht habe, während ich Freunden und Kollegen sage, dass das MoSCoW-Modell ein gutes Projektmanagementmodell ist. Können Sie mir etwas über mögliche Fallstricke bei dieser Methode sagen? Ich identifiziere die Aufgaben und identifiziere, ob die Aufgabe ein Muss ist („M“), was wir tun sollten („S“), was wir tun könnten („C“) und was wir nicht tun („W“). Vielleicht besteht ein potenzieller Fallstrick darin, dass ich am Ende fast immer nur mit dem arbeite, was das Projekt tun muss, und die Sollen und Könnten nur aufgelistet und fast nie umgesetzt werden.
Hier sind einige Fallstricke, die ich beim Moskauer Modell gesehen habe.
Manager sind besorgt, dass ihre Anforderungen in "sollte" oder "könnte" fallen und nicht erledigt werden, also erfinden sie Gründe, warum ihre Anforderung ein "Muss" ist. Dadurch werden geschäftskritische Funktionen verzögert. (Dies wird normalerweise durch schlechte KPIs auf Organisationsebene verursacht oder verschlimmert. Ich bin mir nicht sicher, ob es gute KPIs gibt, wenn sie an die Bezahlung gebunden sind. Tatsächlich bin ich mir ziemlich sicher, dass es keine gibt.)
Es wird Zeit damit verbracht, über Dinge zu diskutieren, die passieren „sollten“, „könnten“ oder „würden“, wodurch der Fortschritt bei Dingen verzögert wird, die absolut wesentlich sind. Dies wird durch Manager verschärft, die sich Sorgen über die Elemente des Projekts machen, die ihnen helfen würden, ihre Ziele zu erreichen, die aber nicht unmittelbar wesentlich sind (wiederum KPIs).
Manager nutzen die Anforderungen „sollte“, „könnte“ und „würde“, um zusätzliches Budget zu erhalten, das sie dann als Puffer für das „Muss“ ausgeben. (Ich liebe auch Beyond Budgeting ).
Architekten und Verantwortliche für andere gemeinsame Abhängigkeiten verbringen Zeit damit, Unterstützung für alle Möglichkeiten zu schaffen, anstatt sich auf das zu konzentrieren, was getan werden "muss". Da es länger dauert, alle „könnte“, „sollte“ und „würde“ zu erstellen, dauert es länger, die Architektur zu beweisen, sodass die Rückmeldung, ob die Architektur angemessen ist, auch ewig dauert. Dies ist einer der Gründe, warum Architekten als so strenge Torwächter fungieren und Ewigkeiten damit verbringen, Architekturen überhaupt erst zu entwerfen.
Was getan werden „muss“, sind oft Ideen, die nicht bewiesen sind, die niemand nutzt und die am Ende doch verworfen werden. Wenn sie früher veröffentlicht würden, würden sie auch früher verworfen, aber zu dem Zeitpunkt, an dem sie zusammen mit dem „sollten“ und „könnten“ veröffentlicht werden, sind sie in die Struktur der Anwendung oder des Systems eingewoben, und der Ruhestand ist viel schwieriger . Pivoting (a la Lean Start-Up) wird unmöglich.
Aus diesem Grund neige ich dazu, die Leute dazu zu ermutigen, zwischen „Muss, jetzt sofort“ zu unterscheiden, sich darauf zu konzentrieren, ein möglichst kleines MVP zu entwickeln und Feedback zu erhalten , und sich dann Gedanken darüber zu machen, was das nächste „Muss, jetzt sofort“ ist. Bewusst und vorausschauend durchgeführt, führt dies dazu, dass Architekturen, Kommunikationsmuster, Organisationsbeziehungen usw. eher leicht zu ändern als richtig sind (siehe auch Real Options ).
Der größte Vorteil ist, wenn Sie eine Vielzahl von Interessengruppen einbeziehen und ihre unterschiedlichen Meinungen darüber besprechen, was getan werden muss. Behandeln Sie Moskau als Instrument, um die Diskussion zu erleichtern und den Konsens zu dokumentieren. Dies wird dazu beitragen, eine breite Akzeptanz für die Zusammensetzung des Produkts zu erreichen, wodurch hoffentlich nachgelagerte Nacharbeiten vermieden werden.
Im Gegensatz zu @Jonathan Miles würde ich die Behauptung in Frage stellen, dass es einfach ist. Ich bin auf Probleme gestoßen, wenn sich Interessenvertreter zu viele Gedanken über die Semantik von „Hätte haben“ und „Hätte haben können“ gemacht haben. Das mag meinerseits einfach nur Pech sein, aber normalerweise habe ich MoSCoW auf ein Must-Have-Nice-To-Have-Paradigma reduziert, bei dem ersteres im Rahmen des Projekts liegt und letzteres ins Regal gestellt wird.
Ehrlich gesagt sehe ich die Arbeit an den "Must Haves" nicht unbedingt als Fallstrick an, da die Bereitstellung von "Should Have"- und "Could Have"-Funktionalität normalerweise den Gesetzen des abnehmenden Ertrags folgt.
Ein klarer Vorteil ist die Einfachheit, Sie sollten keine Vorkenntnisse oder Schulungen benötigen, um das Konzept zu verstehen. Es verwendet die menschliche Sprache, um Anforderungen zu priorisieren und zu definieren, anstatt eine bestimmte Skala oder Messung.
Obwohl das offensichtliche Gegenargument ist, dass es zu einfach sein kann und nicht genügend Informationen darüber liefert, was zuerst getan werden sollte. Sie sind sich vielleicht einig darüber, was geliefert werden MUSS, und haben eine Liste mit einem halben Dutzend Aufgaben, aber welche werden Sie zuerst erledigen? Welche Aufgaben hängen von anderen Aufgaben ab? Wo ist Ihr kritischer Pfad? Aus Sicht des Projektmanagements werden viele Fragen offen bleiben.
Meiner Meinung nach ist es ein einfaches, aber leistungsstarkes Werkzeug für die anfängliche Priorisierung von Anforderungen auf hoher Ebene. Es ist ein großartiger Ausgangspunkt für ein Projekt, denn zu wissen, was geliefert werden muss und was zunächst verschoben werden kann, hilft sehr bei der Entscheidungsfindung.
Obwohl als Nebensache nicht, und mir ist klar, dass dies kein spezieller Nachteil der Methode selbst ist, sondern ihrer Implementierung. Sich zu sehr auf die Anforderungsliste einer Person/eines Teams zu verlassen, kann verheerend sein. Angenommen, Sie haben alle Ihre Entwickler zusammengebracht und eine MoSCoW-Priorisierungsliste erstellt, was sagt Ihnen das ... hier ist eine Liste dessen, was die Entwickler denken, was wir tun sollten. Aber was ist mit dem Geschäft, den Kunden, anderen Stakeholdern usw., die sie vertreten? Gutes Projektmanagement bedeutet, die Anforderungen aller Projektbeteiligten zu verstehen. Wenn Sie sich also für die Verwendung des MoSCoW-Systems entscheiden, stellen Sie sicher, dass Sie eine Vertretung (und nach Möglichkeit einen Konsens) aller Beteiligten haben.