Wir entwickeln, betreiben und warten kontinuierlich ein Hardware-Software-System. Im letzten Jahr hat sich eine Menge komplexer Geschäftsanforderungen (100-150) angesammelt, aber leider nicht gut verarbeitet. Das aktuelle Ziel unserer BA-s ist es, diese Liste irgendwie zu priorisieren und/oder ihr einen gewissen Geschäftswert hinzuzufügen. Ich möchte eine Absicht zu den BA-s hinzufügen, wie man diese Menge an Anforderungen anordnet. Der Kunde hat den Anforderungen keinen KPI zugeordnet.
Am vielversprechendsten ist die MoSCoW-Methode, aber ich gehe davon aus, dass unser Kunde diese Menge an Anforderungen nicht effektiv bewältigen konnte. Gibt es eine bewährte Methode, um diese Situation zu lösen?
Es gibt eine Reihe von Techniken, um Ihren Rückstand zu priorisieren. Bewertungsmodelle (Wert vs. Aufwand, Wert vs. Komplexität, RICE usw.), KANO, MoSCoW, Übernahme der Delphi-Methode (Buy a feature, Cost of delay), yadayadayada.
Die erfolgreiche Anwendung des Priorisierungsframeworks hängt von Ihrer Situation ab. Wenn Sie eine engagierte Person haben, die alle geschäftlichen Anforderungen rechtfertigen kann, sollten Sie keine Probleme haben. Geben Sie dieser Person einfach den Titel „Product Owner“ und erklären Sie ihr das Geschäftswertkonzept.
Ihr Team hat ungefähr 100 Änderungsanfragen pro Jahr (2-3 pro Woche) in der Pipeline, höchstwahrscheinlich arbeiten Sie mit einer Reihe verschiedener Interessengruppen zusammen (hoffentlich gibt es keine Konflikte). Die eigentliche Herausforderung besteht darin, eine solche Anzahl von Menschen auf das Verständnis ähnlicher Prioritäten auszurichten. In meiner Praxis hat sich in solchen Situationen die „Cost of Delay“-Methode am besten bewährt. Dieses Konzept ist für die meisten Geschäftsleute ziemlich klar, da es alles in ihrer Muttersprache erklärt. Als Referenz können Sie überprüfen, wie WSJF-Matrizen in SAFe entworfen wurden, es ist sehr praktisch.
Hier ist gut zu lesen über bestehende Techniken. https://roadmunk.com/blog/product-prioritization-techniques/
Und, btw, herzlichen Glückwunsch. Wenn Ihnen jemand 2-3 Änderungswünsche pro Woche schickt, bedeutet das, dass die Geschäftsleute wirklich an Ihrem Job interessiert sind :)
Wenn wir die Anforderungsliste als Backlog bezeichnen, wäre die agile Sache meiner Meinung nach eine Reihe von Backlog-Grooming-Sitzungen, in denen sich ein geeigneter Benutzervertreter oder Unternehmensvertreter mit den BAs und dem PM trifft, um den Rückstand zu überprüfen. Während dieser Sitzungen sollten alle irrelevanten Elemente aus dem Backlog entfernt, alle Ungenauigkeiten in den Backlog-Tickets behoben und das Ganze nach bestem Wissen und Gewissen priorisiert werden. Dann ist es auch wichtig, sich regelmäßig zu treffen, um den Rückstand neu zu pflegen, wenn sich die Situation ändert. Ticketing-Software wie Jira kann bei solchen Dingen sehr hilfreich sein.
Haben Sie Product Owner für das Backlog? Die geschäftlichen Interessengruppen sollten die Verantwortung für die Priorisierung haben. Ein PO könnte vernünftigerweise einige Analysen an die BAs delegieren, aber wenn Ihre BAs für die tatsächliche Priorisierung verantwortlich sind, deutet dies darauf hin, dass das Unternehmen nicht ausreichend mit dem beschäftigt ist, was sie tun.
Die Einschränkung bei MoSCoW besteht darin, dass es Ihnen nur drei echte Prioritäten gibt, mit denen Sie spielen können. Angenommen, Sie haben mehr als drei Iterationen an Arbeit, dann müssen Sie für jede Iteration erneut priorisieren, um zu entscheiden, welche Muss, Sollte oder Könnte als nächstes erledigt werden. Dies kann als Vorteil angesehen werden - Prioritäten regelmäßig zu überprüfen ist eine gesunde Sache. Persönlich finde ich es jedoch bequemer, Prioritäten von 1-1000 zu nummerieren, was viel Spielraum gibt, um Lücken zwischen Zahlen zu lassen. Es ist dann einfach, Prioritäten nur bei Bedarf neu zu nummerieren.
Ein weiteres Problem, das ich beim MoSCoW-Ansatz festgestellt habe, besteht darin, dass er zu einigen kniffligen Diskussionen mit Interessengruppen darüber führen kann, was wirklich ein Muss oder ein Soll oder ein Könnte ist. Diese Worte sind möglicherweise zu überfrachtet mit Bedeutung, um einige Stakeholder zufrieden zu stellen. Alles, worum sie sich wirklich kümmern sollten, ist das viel abstraktere Konzept der relativen Priorität, 1 bis N ...
azendh
robbpriestley