Zarządzanie priorytetami za pomocą MoSCoW

Pracując w projektach spotykamy się z ogromną ilością wątków. Każdy z nich wydaje się równie istotny i dopóki nie zastosujemy jakiegoś mechanizmu do ich priorytetyzacji będziemy odczuwali duży dyskomfort z tytułu przeciążenia informacjami. W tym artykule chcemy pokazać Wam bardzo proste narzędzie, które możecie zastosować praktycznie w każdej dziedzinie życia i to nie tylko w stosunku do elementów Waszej listy To do.
POZIOM TRUDNOŚCI: | ![]() |
Jak pracować z priorytetami MoSCoW?
MoSCoW to technika priorytetyzacji wymyślona przez Dai Clegga z Oracle UK Consulting. Została następnie włączona przez konsorcjum DSDM do podstaw metodyki Agile PM. Jest podstawą planowania prac w projektach podzielonych na tzw. timeboxy (np. SCRUMowe sprinty).
W skrócie polega na podziale listy wymagań (ale również dowolnego innego zestawu tematów – np. maili, na które musicie odpowiedzieć, czy zadań, które musicie wykonać) według następujących kryteriów:
- M – Must – Czyli coś, co się musi wydarzyć. Na liście wymagań jest to ten punkt, bez którego realizacji projekt nie może wystartować. Z mustów nie da się zrezygnować, są po prostu zbyt ważne. Nadając czemuś taki priorytet zadaj sobie pytanie – czy to naprawdę jest coś, bez czego nie możemy wystartować?
- S – Should – Shouldy to tematy bardzo pilne, których odpuszczenie będzie miało bolesne konekwencje, ale nie jest niemożliwe. Shouldami są często wymagania, które pozornie wydają się mustami, ale można je zaspokoić w jakiś inny, zastępczy sposób, jeśli będzie to konieczne.
- C – Could – Do couldów wpadają wszystkie wymagania/tematy/zadania, które mogłyby się wydarzyć, ale nie są niezbędne.
- W – Won’t – Te sprawy po prostu odpuszczamy.
W swoim pierwotnym zastosowaniu MoSCoW określał priorytety wymagań w projekcie. Z czasem narzędzie rozpowszechniło się i zaczęło być również w innych obszarach procesu produkcji oprogramowania, np. przy testach (do określania priorytetów na liście błędów).
Przyjrzyjmy się teraz przykładowi wykorzystania MoSCoW przy projekcie budowy samochodu : – ) Poniżej wypisałem kilkanaście składowych samochodu i nadałem im priorytety. Dajcie znać w komentarzach, czy się ze mną zgadzacie!
MUST (bez tego nie pojedziemy)
- Koła.
- Kierownica.
- Silnik.
- Hamulce.
- Skrzynia biegów.
SHOULD
- Siedzenia (w najgorszym wypadku wstawimy do środka 4 taborety :).
- Wycieraczki.
- Nawiew.
- Lusterka.
COULD
- Radio.
- Elektrycznie opuszczane szyby.
- Autoalarm.
WON’T
- Skórzana tapicerka.
- Automatyczne wykrywanie zmiany pasa ruchu.
- Czujnik deszczu.
- Podgrzewane siedzenia.
Praca w ramach timeboxów – Praktyczne zastosowanie
MoSCoW ma bardzo istotne praktyczne zastosowanie – pozwala w dosyć precyzyjny i skuteczny sposób planować prace zespołu projektowego. Zasada pracy z tym narzędziem jest taka, że w ramach timeboxa 60% czasu może zostać poświęcone na wymagania z priorytetem MUST, 20% na wymagania z priorytetem SHOULD i 20% na wymagania z priorytetem COULD. Zachowanie tych proporcji pozwala na dużą elastyczność w trakcie trwania prac. Jeśli pojawi się jakaś zmiana (np. poprzez zmaterializowanie się jednego z ryzyk), możemy w spokoju podjąć prace nad jej obsługą, rezygnując z wymagań Should i Could. W ten sposób uda nam się wypracować niezbędne minium w ramach zaplanowanego okresu prac i nie będziemy musieli reorganizować prac ani inicjować niepotrzebnej komunikacji.
Oczywiście w ramach timeboxa możemy poświęcić więcej czasu na zadania z priorytetem MUST. Jeśli dysponujemy doświadczonym i zgranym zespołem, albo realizujemy któryś z etapów prac z kolei, wiemy, że możemy te proporcje naginać. Zawsze jednak powinniśmy zostawić sobie przynajmniej 20% czasu trwania sprintu na nieoczekiwane wydarzenia i zadania z mniejszym priorytetem.
Zmiana priorytetów w czasie
Na koniec naszych rozważań warto wspomnieć o tym, że priorytety (nie tylko te opisywane za pomocą szablonu MoSCoW) zmieniają się w czasie. Coś, co mogło być COULDem na początku projektu w trakcie 3-ego, ostatniego sprintu, może już być MUSTem. Wyższy priorytet nadaje w tym wypadku po prostu zbliżający się deadline na daną funkcjonalność. Pamiętajcie o tym planując prace. Warto w tym kontekście nadać danej sprawie dwa priorytety – jeden pod kątem projektu jako całości, a drugi pod kątem obecnie prowadzonego sprintu.
Jarek Łojko
Myślę, że trzeba wziąć pod uwagę wymagania prawne oraz realne wymagania użytkowania produktu. Samochód bez wycieraczek i bez jednego zewnętrznego lusterka nie zostanie dopuszczony do ruchu, a poza tym byłby po prostu niebezpieczny. :) Dla mnie to są dwa wymagania są definitywnie MUST. Fajnie, że piszesz o MoSCWie :)