Management von Fehlern oder Vorfällen in einem lösungsbasierten Projektmodell

Wir haben eine Produktsuite, die vier Produkte und eine zugrunde liegende Datenstruktur umfasst. In der Vergangenheit haben wir die Arbeit jedes Produkts einzeln gemanagt, vom Backlog bis zur Veröffentlichung (z. B. „XYZ-Produkt-Juli-Veröffentlichung“) und die gesamte Arbeit unter einem einzigen Projektmanager in dieses Projekt integriert. So haben wir das Minimum Viable Product geliefert.

Jetzt, wo Minimum Viable Products geliefert werden, bringen wir Lösungen auf den Markt, die die Fähigkeiten mehrerer Produkte nutzen. Zum Beispiel veröffentlichen wir die "Retail Market Solution", die eine Änderung der Produkte XYZ, ABC und 123 beinhalten kann. Um Konsistenz und Interoperabilität zu fördern, verwalten wir die Lösung als ein einziges Projekt, das Design und Entwicklung für die Lösung als Ganzes für alle Produkte umfasst. Aufgrund dieser Vorgehensweise erfolgt eine Priorisierung eine Ebene über den einzelnen Product Backlogs (meist durch strategische Planung). Also weisen wir dieser Lösung für den Einzelhandelsmarkt einen Projektmanager zu und diese Person arbeitet mit den Produktmanagern und Produktbesitzern zusammen, um Backlog-Elemente zu identifizieren, die diese Lösung unterstützen ... und von dort aus,

Meine Frage ist folgende: In einem Modell, in dem Sie Produktrückstände verwalten, die Dinge außerhalb der Lösungsliste erfassen, die klein, aber dennoch von hoher Priorität sind (denken Sie an Defekte oder Vorfälle ... oder sogar sehr, sehr kleine Verbesserungen, wie eine Änderung der Feldbezeichnung) , wie arbeiten Sie diese in den Projektmanagement-Arbeitsvorrat ein? Wenn ich 7 Projektmanager habe und jedem ein Projekt zugewiesen wird, das mehrere Produkte (dh eine Lösung) umfasst, wo passen die kleineren Elemente in den Zyklus? Wie verhindern wir, dass sie durchs Raster fallen?

Vielen Dank!

Klingt so, als bräuchten Sie ein wöchentliches Meeting mit allen PMs – und jeder sollte mit seiner Liste kleiner Dinge kommen, die priorisiert werden können. Ich würde dies als 7 Projekte belassen, die parallel arbeiten. (Bauchgefühl, also keine Antwort.)

Antworten (1)

Ein Projektmanager ist für ALLE zu erledigenden Aufgaben verantwortlich, unabhängig von ihrer "Größe". Es gibt also wirklich keine „Mindestschwelle an Arbeit“, bevor ein Problem verfolgt werden sollte. Die einfache Antwort ist, diese kleinen Elemente in Ihre Issue-Tracking-Datenbank einzugeben.

Ich gehe davon aus, dass Ihre "Projektmanagement-Arbeitsliste" Ihre Problemverfolgungsdatenbank ist. (Dies kann eine Excel-Tabelle oder ein Tool wie Jira oder DevTrack sein.) Es wäre einfacher für Sie, wenn Sie eine einzige Problemdatenbank für alle Produkte hätten, insbesondere wenn Sie die Aufgabenlisten mehrerer Produktmanager verwalten/überprüfen müssen . Komplizierter wird es, wenn jeder Produktmanager eine eigene Problemdatenbank hat. (Noch komplizierter, wenn einer Excel, ein anderer Jira und ein dritter handgeschriebene Notizkarten verwendet.)

Unabhängig davon, ob es sich um Datenbanken mit mehreren Problemen handelt oder nicht, stellen Sie sicher, dass jedes Element aufgelistet ist und ein zugewiesenes Opfer, äh ... verantwortliche Person hat.

Das Verfolgen all dieser Details sollte Ihren Teams und Managern sehr bewusst machen, dass Sie alles im Griff haben. Außerdem inspiriert es fast immer andere dazu, ähnliche kleine Probleme zu erstellen, die sonst nie aufgelistet würden.