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