Jeśli zapytasz klienta, które z wymagań są niezbędne, to klient bez mrugnięcia odpowie: wszystkie! I w tej sytuacji z pomocą przychodzi Ci technika MoSCoW. Przeczytaj poniższy wpis i sprawdź, jak ustalać priorytety z jej pomocą.
Co to jest MoSCoW?
Technika MoSCoW, jak wspomniałam we wstępie, pomaga ustalić priorytety. Każde wymaganie klienta można sklasyfikować jako:
- Niezbędne do tego, żeby produkt końcowy był w stanie dostarczyć oczekiwanych korzyści biznesowych – ta kategoria nosi nazwę Must have.
- Równie ważne, jak wymagania powyżej. Różnica polega na tym, że w tej drugiej kategorii mieszczą się wymagania, dla których istnieje „obejście” (również manualnie), gdyby te wymagania nie zostały dostarczone. Ta kategoria nosi nazwę Should have.
- Jak pewnie sie domyślasz, kolejną kategorię stanowią wymagania, które dobrze by było mieć. Niemniej jednak możemy z nich zrezygnować, gdyby projekt miał trwać dłużej niż to było pierwotnie zakładane. Są to wymagania Could have.
- To jeszcze nie koniec! Zawsze znajdą się takie wymagania, które odrzucimy, bo nie chcemy w nie inwestować czasu/pieniędzy (w tym projekcie lub w ogóle) – ta kategoria nosi nazwę Won’t have this time.
Celowo zaznaczyłam pierwsze litery nazw poszczególnych kategorii – nazwa MoSCoW to właśnie zlepek tych liter.
Przykład priorytetyzacji MoSCoW
Zastanówmy się na przykładzie, jak poszczególne wymagania dla produktu, jakim jest kurs online, zostałyby spriorytetyzowane.
| Priorytet | Wymaganie |
| Must have | Dostęp do kursu mają tylko osoby, które zakupiły ten kurs. – Zgodzisz się ze mną, że jeśli to wymaganie nie będzie dostarczone, klient nie uzyska oczekiwanych korzyści biznesowych (brak ograniczenia dostępu do strony spowoduje, że materiały będą udostępniane osobom, które za taki kurs nie zapłaciły). Ogólny dostęp musi być zablokowany. |
| Should have | Certyfikat ukończenia kursu jest tworzony i wysyłany automatycznie po zaliczeniu testu przez kursanta. – Klient chce, żeby taki certyfikat generował się automatycznie. Niemniej jednak klient może sobie „poradzić” eksportując listę kursantów do pliku i generując dla nich certyfikaty „ręcznie”, a następnie wysyłając je – jeden po drugim – do każdego kursanta. |
| Could have | Każda lekcja video w kursie zawiera również nagranie w wersji audio do pobrania przez kursanta. – Fajnie jest dać kursantom dodatkową wartość, którą w tym przypadku są nagrania audio do odsłuchania w formie podcastu w dowolnym momencie. Prawda jest jednak taka, że bez tych dodatkowych materiałów kursanci wyniosą dokładnie taką samą wartość z kursu. |
| Won’t have this time | Każda lekcja video w kursie zawiera PDF z podsumowaniem materiału. – Tego typu wymaganie może mieć najniższy priorytet, klient może zecydować o „przeniesieniu” prac nad tą funkcjonalnością do następnej wersji kursu (następnego projektu). |
W których metodykach wykorzystuje się MoSCow, żeby ustalić priorytety?
W metodyce PRINCE2 technika MoSCoW wykorzystywana jest do:
- klasyfikowania wymagań jakościowych (kryteriów akceptacji),
- priorytetyzacji zmian zgłaszanych do projektu w trakcie jego trwania.
Z kolei Agile Project Management wykorzystuje technikę MoSCoW do ustalania priorytetów biznesowych – zarówno na poziomie całego projektu, jak i pojedynczego timeboxa. Zwróć uwagę, że wymaganie, które na poziomie projektu jest zpriorytetyzowane jako Should have, w timeboxie, w którym jest realizowane, może mieć priorytet Must have (i odwrotnie). W danym timeboxie priorytety mogą być inne.
Kilka wskazówek praktycznych na temat tego, jak ustalać priorytety z wykorzystaniem MoSCoW
W dyskusji na temat priorytetów dla poszczególnych wymagań powinien wziąć udział biznes. Mam tu na myśli klienta/sponsora, który „przyszedł” z konkretnymi wymaganiami. W niektórych przypadkach jesteśmy w stanie zaprosić do dyskusji użytkowników (reprezentantów użytkowników), którzy z tego rozwiązania będą korzystać.
Ustalanie priorytetów zgodnie z MoSCoW będzie przebiegało w sposób iteracyjny. Tak, jak wspomniałam we wprowadzeniu, klient – w pierwszym odruchu – uzna wszystkie wymagania jako Must have. Zadawaj właściwe pytania:
- Co się stanie, jeśli nie dowieziemy tego wymagania? Jeśli biznes w takiej sytuacji będzie chciał zatrzymać projekt, wymaganie ma priorytet Must have.
- Czy istnieje manualny sposób („obejście”), które pozwala osiągnąć ten sam efekt bez inwestycji w to wymaganie teraz? Oczywiście każde „obejście” jest bolesne dla klienta, bo zwykle zajmuje jego czas. Niemniej jednak, jeśli takie rozwiązanie istnieje, wymaganie ma priorytet Could have.
- Czy wymaganie jest zależne od innych wymagań? Wymaganie Must have nie może być zależne od wymagań, które mają niższy priorytet!
Rozbijaj wymagania na mniejsze – tam, gdzie to możliwe. Jest duże prawdopodobieństwo, że pod jednym wymaganiem typu Must kryje się również kilka wymagań typu Should, a nawet Could.
Dąż do tego, żeby w projekcie poszczególne wymagania rozkładały się następująco: 60% wymagania Must have, 20% wymagania Should have i 20% wymagania Could have. Wymagania Must have muszą być dostarczone. Pozostałe wymagania stanowią rezerwę na wypadek nieprzewidzianych zdarzeń w projekcie.
