Co to jest Priorytetyzacja MoSCoW?

Priorytetyzacja MoSCoW, znana również jako metoda MoSCoW lub analiza MoSCoW, jest popularną techniką ustalania priorytetów w zarządzaniu wymaganiami. Metodę MoSCoW tę powszechnie stosuje się, aby pomóc kluczowym interesariuszom zrozumieć znaczenie inicjatyw w konkretnej wersji. Osobiście często korzystam z tej metody przy mniejszych projektach wykorzystując kanban board.  Akronim, MoSCoW, oznacza 4 […]
moscow

Priorytetyzacja MoSCoW, znana również jako metoda MoSCoW lub analiza MoSCoW, jest popularną techniką ustalania priorytetów w zarządzaniu wymaganiami.

Metodę MoSCoW tę powszechnie stosuje się, aby pomóc kluczowym interesariuszom zrozumieć znaczenie inicjatyw w konkretnej wersji. Osobiście często korzystam z tej metody przy mniejszych projektach wykorzystując kanban board. 


Akronim, MoSCoW, oznacza 4 różne kategorie inicjatyw: Must Have, Should be, Could be i  oraz Won’t be.

Metoda MoSCoW, Priorytetyzacja MoSCoW
Priorytetyzacja MoSCoW / Metoda MoSCow

M – Must Have (musi być)

Jak sama nazwa wskazuje, ta kategoria składa się z inicjatyw, które są „obowiązkowe” dla Twojego zespołu. Reprezentują one niezbywalne potrzeby dotyczące projektu, produktu lub wydania. Na przykład, jeśli wypuszczasz aplikację opieki zdrowotnej, konieczną inicjatywą mogą być funkcje bezpieczeństwa, które pomagają zachować zgodność.


Wszystko w kategorii „must have” jest uważane za obowiązkowe dla zespołu. Jeśli nie masz pewności, czy coś należy do tej kategorii, zadaj sobie następujące pytania.

  • Co się stanie, jeśli wydamy bez tego?
  • Czy istnieje obejście lub prostszy sposób na osiągnięcie tego?
  • Czy wydanie / projekt / produkt będzie działać bez tej inicjatywy?
  • Jeśli produkt nie będzie działał bez inicjatywy lub wydanie stanie się bez niego bezużyteczne, inicjatywa jest najprawdopodobniej „obowiązkowa”.

S – Should be (powinien być)

Inicjatywy, które należy mieć, to tylko krok poniżej tych, które należy mieć. Są ważne dla produktu, projektu lub wydania, ale nie są niezbędne. W przypadku pominięcia produkt lub projekt nadal działa. Jeśli jednak zostaną uwzględnione, stanowią znaczną wartość dodaną.


Inicjatywy „Should be” różnią się od inicjatyw „must have”, ponieważ można je zaplanować na przyszłe wydanie aplikacji, bez wpływu na obecną. Na przykład ulepszenia wydajności, drobne poprawki błędów lub nowa funkcjonalność mogą być inicjatywami, które powinny mieć. Bez nich produkt nadal działa.
 

C – Could be (może być)

Could be to wymagania, które nie są krytyczne, ani bardzo ważne. Często postrzegano jako takie, które fajnie, gdyby się pojawiły, natomiast jeżeli ich nie będzie, nie spowoduje to większego impaktu na projekt.
 

W – Won’t be (Nie będzie tym razem)

Won’t be to inicjatywy, których nie chcemy wdrażać w najbliższym wydaniu, ale mogą zostać wdrożone w nieokreślonej przyszłości.
 
Źródła:
https://www.productplan.com/glossary/moscow-prioritization/
https://www.kecg.co/blog/2018/7/22/task-prioritisation-hack-using-moscow-method

Jak oceniasz ten artykuł?

Średnia ocena 0 / 5. Oceniło: 0

No votes so far! Be the first to rate this post.