LET’S DO IT IN #MoSCoW!

Co to jest MoSCoW?

MoSCoW  to technika priorytetyzacji jednak na wstępie zaznaczę, że priorytety MoSCoW nie pochodzą z Rosji. Nie mają też nic wspólnego z komunistyczną utopią. Jest to skuteczna, zwinna technika zarządzania projektami, która jest częścią Agile Project Management. Moskwa w projektach Agile jest niczym zegarek dla Szwajcarów. To symbol dostarczenia projektu na czas.

Jest to kolejny z moich ulubionych akronimów (na równi z TIMWOOD oraz RACI).  MoSCoW to skrót od „Must have (musi być), Should have (powinno być), Could have (może być), Won’t have (nie będzie tym razem)”.

Do czego służy MoSCoW?

MoSCoW to nie tylko zabawny skrót, ale także najlepszy sposób na określenie, które wymagania powinny zostać uwzględnione w projekcie. Wymagania to tzw. historyjki użytkownika (user stories).

Korzystanie z MoSCoW  daje szczególnie dobre efekty w projektach, które mają sztywnie ustalony termin. Ta technika zyskuje na wartości w połączeniu ze stosowaniem timeboxu projektu. Timebox i priorytetyzacja MoSCoW zostały zaprojektowane po to, aby umożliwić terminowe dostarczanie projektów w sposób konsekwentny i przewidywalny.

Jaka jest idea MoSCoW?

Mniej znaczy więcej – Czy słyszałeś powiedzenie, że „80% rozwiązania pochodzi z 20% wymagań?” Oboje wiemy, że to prawda; istnieje niewielka liczba wymagań, często określanych jako Minimalny Użyteczny Podzbiór (ang. Minimum Usable Subset), które sprawiają, że produkt/rozwiązanie dostarczane w ramach projektu będzie działało. Reszta wymagań jest „nice to have”. MoSCoW pozwala zidentyfikować w pierwszej kolejności, jaki jest minimalny użyteczny podzbiór, a pozostałe wymagania można zaklasyfikować jako ważne, ale nie krytyczne.

Odroczenia są dozwolone – wydawać by się mogło, że przesuwanie wymagań na późniejszy etap będzie bolesne dla projektu. Ale czy lepszym pomysłem jest wdrażanie rozwiązania, które nie spełnia oczekiwań użytkowników? Zdecydowanie nie. Podczas korzystania z priorytetyzacji MoSCoW, wymagania, które nie są częścią minimalnego użytecznego podzbioru, można odroczyć, chyba że na jakimś etapie projektu okażą się one niezbędne.

Wczesne dostarczenie wartości – wszystkie wymagania w projekcie są ważne. Zasługują one na uwagę w trakcie realizacji projektu, ale najpierw trzeba się skupić na tych, które dostarczą korzyści biznesowe na wczesnym etapie projektu. Mając to na uwadze, priorytetyzacja MoSCoW wymusza kolejność pracy w projekcie z perspektywy biznesu.

Prosta klasyfikacja – klasyfikacja MoSCoW daje jasne wytyczne co do wymagań i ustanawia realistyczne oczekiwania co do ich zakończenia.

Jak zapewnić efektywną realizację wymagań?

Wszystko, co jest oznaczone jako „musi być”, musi zostać dostarczone w danym timebox’ie projektu, aby rozwiązanie mogło być użyteczne. Są nawet tacy, którzy twierdzą, że ​​„Must” w rzeczywistości jest akronimem od „Minimum Usable SubseT”. Minimalny użyteczny podzbiór to minimalna ilość wymagań, które rozwiązują problem biznesowy. Projekty, które odnoszą sukcesy to te, które kończą się o czasie oraz w których wszystkie wymagania „musi byc” zostały wykonane.

Wymagania „powinno być” są prawie tak samo ważne jak „musi być” i powinny być zrealizowane, jeśli tylko jest to możliwe (w praktyce, jeśli czas na to pozwala). Dozwolone jest, w przypadku tego typu wymagań zastosowanie obejść, które w inny sposób spełnią te wymogi.

Wymagania „może być” są mniej krytyczne niż „powinno być” i są to tzw. „nice to have”. Jednak dowiezienie ich w projekcie może znacznie zwiększyć zadowolenie klienta.

Wymagania „nie będzie” to te, które w bieżących ramach czasowych nie zostaną dostarczone, mogą być jednak ważne w przyszłości i należy je rozpatrzeć z perspektywy tzw. big picture.

Agile radzi, aby wymagania „musi być” obejmowały max 60% całkowitego nakładu pracy w projekcie. Na wymagania „powinno być” oraz „może być” należy przewidzieć około 20% nakładu pracy. Takie rozłożenie priorytetów daje wystarczającą rezerwę, by mieć przekonanie co do udanego rezultatu projektu. W przypadku projektów o wyższym ryzyku, w których przykładowo jest bardzo napięty harmonogram, proponuję przeznaczyć na wymagania „musi być” max 50% przedziału czasowego.

Kiedy nadawać priorytety?

Każdy element pracy w projekcie powinien mieć swój priorytet. Priorytety powinny być nadawane przed rozpoczęciem pracy. Jeżeli wprowadzane jest nowe wymaganie – stosując reguły MoSCoW, należy podjąć decyzję, w jakim stopniu jest ona krytyczna dla sukcesu bieżącej pracy. Wprowadzając nowe wymagania, należy uważać, żeby nie zwiększyć procentowego nakładu pracy powiązanej z priorytetami.

Wskazówka dotyczące nadawania priorytetów „musi być”

Przy każdym wymaganiu proponowanym jako „musi być” warto zadać pytanie: „Co się stanie, jeśli to wymaganie nie zostanie spełnione?”. Jeżeli odpowiedź brzmi: „wdrażanie rozwiązania nie ma sensu”, wtedy rzeczywiście jest to must.

Jeśli chcesz poznać więcej narzędzi tego typu zapraszam do zakładki Narzędziownik.

Image source: Esther Gons, thecorporatestartupbook.com