Dlaczego zwykła lista priorytetów często nie działa?
W wielu projektach wymagania są numerowane od najważniejszych do najmniej ważnych. Na pierwszy rzut oka wydaje się to logiczne, ale szybko pojawia się kilka problemów.
Po pierwsze, numer nie wyjaśnia, co właściwie oznacza dany poziom. Czy funkcja oznaczona jako priorytet 2 może zostać usunięta? Czy priorytet 3 powinien wejść do pierwszej wersji? Czy różnica pomiędzy pozycją 4 i 5 ma rzeczywiste znaczenie?
Po drugie, interesariusze często walczą o najwyższy numer dla własnych potrzeb. W efekcie większość pozycji otrzymuje oznaczenie „1”, a system przestaje pomagać w podejmowaniu decyzji.
Po trzecie, lista rankingowa sugeruje, że wymagania można ułożyć w prostą kolejność. W praktyce niektóre z nich są konieczne ze względów prawnych, inne blokują uruchomienie produktu, a jeszcze inne są ważne dla wygody użytkowników. Nie zawsze da się je porównać jedną liczbą.
Czym jest metoda MoSCoW?
MoSCoW to technika priorytetyzacji wymagań, celów i elementów zakresu projektu. Nazwa pochodzi od pierwszych liter czterech kategorii:
- Must have – musi znaleźć się w rozwiązaniu,
- Should have – powinno znaleźć się w rozwiązaniu,
- Could have – może znaleźć się w rozwiązaniu,
- Won't have this time – nie zostanie zrealizowane w tym wydaniu.
Litery „o” w nazwie nie oznaczają osobnych kategorii. Zostały dodane po to, aby skrót był łatwy do zapamiętania.
MoSCoW nie tworzy idealnego porządku od pierwszej do ostatniej pozycji. Zamiast tego pomaga uzgodnić poziom konieczności i przygotować zakres, który można realnie zrealizować w określonym czasie i budżecie.
Must have – wymagania bezwzględnie konieczne
Kategoria Must obejmuje elementy, bez których projekt nie może osiągnąć swojego podstawowego celu. Brak takiego wymagania oznacza, że rozwiązanie nie może zostać uruchomione, nie spełnia obowiązków prawnych albo nie dostarcza minimalnej wartości użytkownikowi.
Do kategorii Must mogą należeć na przykład:
- możliwość zalogowania się do systemu, jeśli bez konta nie można korzystać z usługi,
- obsługa płatności w sklepie internetowym,
- funkcja wymagana przez przepisy,
- zabezpieczenie krytycznych danych,
- integracja niezbędna do wykonania głównego procesu,
- możliwość zapisania i odczytania kluczowych informacji.
Dobre pytanie kontrolne brzmi: czy projekt nadal ma sens, jeżeli tego elementu zabraknie? Jeżeli odpowiedź brzmi „tak, choć będzie mniej wygodny”, prawdopodobnie nie jest to Must.
Jak rozpoznać fałszywe Must?
Najczęstszym błędem jest przypisywanie kategorii Must wymaganiom, które są po prostu ważne dla konkretnej osoby. Sformułowania „zawsze tak robiliśmy”, „klient tego oczekuje” albo „zarząd bardzo to lubi” nie wystarczają, aby uznać funkcję za konieczną.
Warto sprawdzić konsekwencje braku wymagania:
- Czy rozwiązanie będzie niezgodne z prawem?
- Czy nie da się wykonać głównego zadania?
- Czy uruchomienie będzie niemożliwe technicznie?
- Czy ryzyko biznesowe stanie się nieakceptowalne?
- Czy zniknie podstawowa wartość produktu?
Jeżeli konsekwencją jest głównie mniejszy komfort, dodatkowa praca ręczna albo konieczność zastosowania tymczasowego obejścia, wymaganie może należeć do Should zamiast Must.
Should have – bardzo ważne, ale możliwe do odroczenia
Wymagania Should mają dużą wartość i powinny zostać zrealizowane, jeżeli pozwalają na to czas oraz zasoby. Ich brak jest odczuwalny, ale nie powoduje całkowitej porażki projektu.
Przykładem może być:
- automatyczne generowanie raportu, który tymczasowo można przygotować ręcznie,
- dodatkowa metoda płatności przy działającej metodzie podstawowej,
- integracja przyspieszająca proces, ale nieblokująca jego ręcznej realizacji,
- rozbudowane filtry wyszukiwania przy działającej wyszukiwarce podstawowej,
- funkcja ułatwiająca obsługę dużej liczby użytkowników.
Should nie oznacza „nieważne”. Oznacza, że istnieje akceptowalne rozwiązanie zastępcze albo możliwość przesunięcia funkcji bez zniszczenia celu bieżącego wydania.
Could have – wartościowe dodatki
Kategoria Could obejmuje elementy pożądane, ale niekonieczne. Ich realizacja poprawia wygodę, estetykę lub atrakcyjność rozwiązania, jednak brak nie wpływa znacząco na podstawowe działanie projektu.
Przykłady to:
- dodatkowe warianty wyglądu,
- rozszerzone opcje personalizacji,
- alternatywne sposoby prezentacji danych,
- drobne automatyzacje,
- funkcje przydatne niewielkiej grupie użytkowników,
- ulepszenia, które można łatwo dodać w kolejnej iteracji.
Could pełni ważną rolę w planowaniu. Pozwala przygotować listę zadań, które zespół może podjąć, gdy najważniejsze prace zakończą się wcześniej albo pojawią się dodatkowe zasoby.
Won't have this time – świadome odłożenie wymagania
Kategoria Won't jest często błędnie rozumiana jako miejsce dla pomysłów odrzuconych i nieważnych. W rzeczywistości oznacza: nie realizujemy tego teraz, ale świadomie zachowujemy temat na przyszłość.
Takie wymaganie może być wartościowe, lecz nie mieścić się w aktualnym budżecie, terminie lub celu wydania. Jego zapisanie zapobiega sytuacji, w której przyszłe potrzeby znikają z dokumentacji i muszą zostać odkryte ponownie.
Warto zapisywać również powód decyzji, na przykład:
- zbyt wysoki koszt w obecnym etapie,
- brak gotowej integracji,
- niewystarczająca liczba użytkowników,
- konieczność wcześniejszego zebrania danych,
- brak potwierdzonej potrzeby,
- planowana realizacja w kolejnym wydaniu.
To właśnie kategoria Won't sprawia, że MoSCoW nie jest wyłącznie metodą cięcia zakresu. Jest również sposobem ochrony wartościowych pomysłów przed całkowitym zagubieniem.
Won't nie oznacza „nigdy”
Pełne określenie tej kategorii powinno brzmieć „Won't have this time”. Dodatek „this time” ma duże znaczenie, ponieważ ogranicza decyzję do konkretnego wydania, sprintu, etapu lub okresu.
Bez tego doprecyzowania interesariusze mogą obawiać się, że przypisanie wymagania do Won't oznacza trwałe usunięcie. Wtedy zaczną bronić każdej funkcji i próbować przenosić ją do Should albo Must.
Dobrą praktyką jest ustalenie terminu ponownego przeglądu wymagań Won't. Mogą zostać ocenione przed planowaniem następnej wersji, po zebraniu danych od użytkowników albo po zakończeniu kluczowych integracji.
Jak przeprowadzić warsztat MoSCoW?
Najlepsze rezultaty daje wspólna sesja z udziałem osób reprezentujących różne perspektywy. W zależności od projektu mogą to być:
- właściciel produktu,
- przedstawiciel biznesu,
- analityk,
- projektant UX,
- programista lub architekt,
- przedstawiciel sprzedaży,
- pracownik operacyjny,
- osoba odpowiedzialna za prawo lub bezpieczeństwo.
Warsztat może przebiegać w kilku krokach:
- Uzgodnienie celu bieżącego wydania.
- Przegląd pełnej listy wymagań.
- Wstępne przypisanie kategorii.
- Omówienie pozycji spornych.
- Sprawdzenie, czy liczba Must jest realistyczna.
- Zapisanie powodów najważniejszych decyzji.
- Potwierdzenie zakresu przez osoby odpowiedzialne.
Bez wspólnego celu MoSCoW może zmienić się w kolejną walkę o własne wymagania. Uczestnicy muszą oceniać funkcje z perspektywy sukcesu projektu, a nie wyłącznie własnego działu.
Najpierw cel projektu, potem priorytety
Nie da się poprawnie ustalić kategorii bez wiedzy, jaki rezultat ma przynieść dany etap. Ta sama funkcja może być Must w jednym wydaniu i Could w innym.
Przykładowo, jeżeli celem pierwszej wersji jest sprawdzenie, czy użytkownicy chcą kupować produkt, rozbudowany panel raportowy może być Won't. Jeżeli jednak projekt dotyczy systemu do raportowania danych regulacyjnych, raporty mogą być najważniejszym Must.
Przed warsztatem warto zdefiniować:
- cel wydania,
- główną grupę użytkowników,
- najważniejszy proces,
- termin,
- budżet i dostępne zasoby,
- największe ryzyka,
- kryteria uznania projektu za udany.
Ile wymagań może znaleźć się w Must?
Nie istnieje uniwersalny procent odpowiedni dla każdego projektu, ale lista Must nie powinna zajmować całego dostępnego czasu. Jeżeli wszystko jest konieczne, zespół nie posiada żadnego marginesu na problemy techniczne, błędy, nieobecności i nieprzewidziane zależności.
Rozsądny zakres powinien pozostawiać przestrzeń na zmianę i niepewność. Jeżeli realizacja wszystkich Must wymaga stu procent dostępnych zasobów, plan jest bardzo podatny na opóźnienia.
Warto również sprawdzić, czy niektóre wymagania można uprościć. Zamiast rozbudowanej automatyzacji w pierwszej wersji może wystarczyć proces częściowo ręczny. Zamiast pełnej integracji można zastosować prosty import danych.
Jak rozstrzygać spory o priorytet?
Spory są naturalną częścią priorytetyzacji. Oznaczają, że uczestnicy widzą różne ryzyka i wartości. Problem zaczyna się wtedy, gdy dyskusja opiera się wyłącznie na stanowiskach i hierarchii.
Pomocne pytania to:
- Jaką wartość użytkownik straci bez tej funkcji?
- Jakie jest ryzyko prawne lub finansowe?
- Czy istnieje obejście tymczasowe?
- Ilu użytkowników potrzebuje tej funkcji?
- Jak często będzie używana?
- Jaki jest koszt realizacji?
- Czy funkcja blokuje inne prace?
- Jakie dane potwierdzają jej znaczenie?
Decyzje powinny być oparte na konsekwencjach, a nie na tym, kto mówi najgłośniej.
MoSCoW a zależności techniczne
Priorytet biznesowy nie zawsze odpowiada kolejności technicznej. Funkcja należąca do Could może wymagać przygotowania architektury wcześniej, aby w przyszłości nie przebudowywać całego systemu.
Z drugiej strony wymaganie Must może zależeć od kilku mniej widocznych zadań technicznych. Dlatego klasyfikacja powinna obejmować nie tylko funkcje widoczne dla użytkownika, lecz również:
- bezpieczeństwo,
- migrację danych,
- monitoring,
- wydajność,
- kopie zapasowe,
- integracje,
- infrastrukturę.
Analityk i zespół techniczny powinni wspólnie pokazać, które zadania są konieczne do dostarczenia deklarowanych Must.
MoSCoW w projektach Agile i sprintach
Metoda MoSCoW może być stosowana na poziomie całego produktu, wydania, sprintu albo pojedynczego procesu. Ważne jest jednak, aby zawsze określić zakres czasu, którego dotyczy klasyfikacja.
W projekcie Agile kategorie nie są przypisane raz na zawsze. Wymagania mogą zmieniać priorytet po:
- testach z użytkownikami,
- zmianie warunków rynkowych,
- pojawieniu się nowego ryzyka,
- analizie danych,
- zmianie terminu,
- odkryciu zależności technicznych.
MoSCoW nie powinno zastępować regularnego zarządzania backlogiem. Jest narzędziem wspierającym decyzje, a nie jednorazową etykietą.
Przykład zastosowania MoSCoW w sklepie internetowym
Załóżmy, że zespół przygotowuje pierwszą wersję sklepu internetowego.
Must have
- przeglądanie produktów,
- koszyk,
- złożenie zamówienia,
- podstawowa płatność,
- potwierdzenie zakupu,
- ochrona danych użytkownika.
Should have
- kilka metod płatności,
- śledzenie przesyłki,
- konto klienta,
- automatyczne faktury.
Could have
- lista ulubionych produktów,
- porównywarka,
- zaawansowane rekomendacje,
- rozbudowana personalizacja.
Won't have this time
- program lojalnościowy,
- aplikacja mobilna,
- sprzedaż w wielu krajach,
- integracja z rozbudowanym marketplace'em.
Taki podział nie oznacza, że program lojalnościowy jest nieważny. Oznacza, że nie jest potrzebny do sprawdzenia podstawowego modelu sprzedaży w pierwszej wersji.
Najczęstsze błędy podczas stosowania MoSCoW
Wszystko jest Must
Jeżeli większość wymagań otrzymuje najwyższą kategorię, metoda nie została zastosowana prawidłowo. Należy ponownie zdefiniować minimalny zakres sukcesu.
Brak jasnego „this time”
Bez określenia konkretnego wydania kategoria Won't będzie odbierana jako trwałe odrzucenie.
Klasyfikacja bez udziału zespołu technicznego
Biznes może nie znać kosztów, zależności i ryzyk implementacyjnych.
Brak uzasadnienia decyzji
Po kilku tygodniach uczestnicy mogą nie pamiętać, dlaczego wymaganie zostało przesunięte. Krótkie uzasadnienie ogranicza powracające spory.
Brak ponownego przeglądu
Priorytety mogą się zmieniać. Lista powinna być aktualizowana po zdobyciu nowych informacji.
Mylenie priorytetu z kolejnością realizacji
Must nie zawsze musi być wykonane jako pierwsze. Kolejność może zależeć od architektury, dostępności osób i zależności pomiędzy zadaniami.
Jak dokumentować decyzje?
Przy każdym wymaganiu warto zapisać:
- kategorię MoSCoW,
- krótkie uzasadnienie,
- osobę odpowiedzialną za decyzję,
- datę klasyfikacji,
- warunki zmiany priorytetu,
- planowany termin ponownego przeglądu.
Dokumentacja nie musi być rozbudowana. Jedno lub dwa zdania często wystarczą, aby uniknąć późniejszych nieporozumień.
Jak MoSCoW pomaga osiągnąć porozumienie?
Metoda nie usuwa różnic interesów, ale tworzy wspólny język. Zamiast dyskutować, czy dana funkcja jest „bardzo ważna”, zespół analizuje konsekwencje jej braku i możliwość przesunięcia.
Najważniejsze korzyści to:
- czytelniejsze granice zakresu,
- łatwiejsze planowanie wydania,
- mniejsza liczba niejawnych oczekiwań,
- zachowanie pomysłów na przyszłość,
- większa przejrzystość decyzji,
- ograniczenie sporów pod koniec projektu.
Porozumienie nie oznacza, że każdy otrzyma wszystkie oczekiwane funkcje. Oznacza, że wszyscy rozumieją, co zostanie wykonane, co może zostać wykonane i co świadomie przesunięto.
MoSCoW nie zastępuje oceny wartości i kosztu
Sama kategoria nie mówi, ile kosztuje realizacja ani jak dużą wartość przynosi funkcja. Dwa wymagania Should mogą różnić się czasem wykonania dziesięciokrotnie.
Dlatego MoSCoW warto łączyć z:
- estymacją pracochłonności,
- oceną wartości biznesowej,
- analizą ryzyka,
- danymi od użytkowników,
- mapą zależności,
- planem wydania.
Metoda daje ramę do rozmowy, ale nie zwalnia zespołu z analizy.
Kiedy MoSCoW sprawdzi się najlepiej?
Technika jest szczególnie użyteczna, gdy:
- zakres jest większy niż dostępny czas,
- w projekcie uczestniczy wielu interesariuszy,
- trzeba przygotować minimalną wersję produktu,
- konieczne jest uzgodnienie zakresu wydania,
- zespół chce zachować pomysły odłożone na później,
- potrzebny jest prosty język do rozmowy o kompromisach.
Może być mniej skuteczna, jeżeli kategorie są przydzielane przez jedną osobę bez dyskusji albo gdy decyzje nie są powiązane z konkretnym celem i terminem.
Podsumowanie
MoSCoW jest prostą, ale skuteczną metodą ustalania priorytetów w projekcie. Pozwala rozdzielić wymagania konieczne, bardzo ważne, opcjonalne oraz świadomie odłożone na później.
Największą zaletą tej techniki jest to, że nie usuwa z listy przyszłych potrzeb. Kategoria Won't pozwala zachować wartościowe wymagania, jednocześnie chroniąc bieżący zakres przed przeciążeniem.
Skuteczne zastosowanie MoSCoW wymaga jasnego celu wydania, udziału biznesu i zespołu technicznego, ograniczenia liczby Must oraz regularnego przeglądu decyzji.
Dobrze przeprowadzona priorytetyzacja nie polega na oznaczeniu wszystkiego jako ważne. Polega na świadomym wyborze tego, co musi zostać wykonane teraz, oraz uczciwym nazwaniu tego, co może poczekać.
