Metoda MoSCoW – jak wykorzystać ją w projektach IT?

Priorytetyzacja zadań w projektach IT

Priorytety pozwalają określić kluczowe funkcjonalności produktu i wymagania klienta względem rozwiązania, które planuje stworzyć z software housem. Przy nadawaniu priorytetów w projektach IT głównie bierze się pod uwagę właśnie zdanie klienta, jego potrzeby i oczekiwania. Oczywiście część priorytetów jest modyfikowana przez product ownerów, ale ostateczna decyzja należy do inwestora. Jest to etap niezwykle ważny – proces, który ma za zadanie wyodrębnić najistotniejsze na dany czas wymagania. Klient musi określić, co jest dla niego najważniejsze z biznesowego punktu widzenia.

Priorytetyzacja wymagań brzmi jak jedno kluczowe spotkanie, ale nim nie jest. To płynny proces, który w zależności od etapu projektu zmienia się. Najczęściej podczas jednego ze sprintów, co jakiś czas wyodrębnia się priorytety i określa kluczowe w danym momencie wymagania. Jest wiele metod umożliwiających product ownerom ułożenie aktualnej listy zadań. Przyjrzyjmy się bliżej bardzo popularnej analizie MoSCow.

Co to jest MoSCow?

Technikę MoSCow opracował Dai Clegg, a po raz pierwszy została użyta w metodyce Dynamic Systems Development Metod (DSDM). To metoda służąca do priorytetyzacji Backlogu, ale nie tylko. Pomaga porównać ze sobą poszczególne elementy projektu. Metoda MoSCow zakłada, że każdy z nich powinien zostać skategoryzowany według określonych zasad. Analiza pomaga priorytetyzować poszczególne elementy projektu bez względu na jego etap. Technikę MoSCow można wykorzystać do zaplanowania najbliższego sprintu, kilku pod rząd lub nawet całego projektu. W każdym przypadku przyda się lista wymagań z nadanym priorytetem.

Metoda MoSCow dzieli zadania, przypisując je do takich kategorii jak: M, S, C lub W. Poniżej rozwinięcie tych skrótów.

Must have

M (must), czyli element kluczowy, bez niego projekt nie może istnieć. Nie podlega to żadnym negocjacjom. Z elementu oznaczonego “must have” nie da się zrezygnować, jest zbyt ważny, a jego implementacja konieczna. Popularne jest to, że na początku projektu często nadaje się elementom dużo oznaczeń “must have” jednak z czasem, w porównaniu z innymi kategoriami, rezygnuje się z tego i zauważa, że nie wszystkie z nich powinny mieć oznaczenie M.

Should have

S (should) to oznaczenie elementu projektu, który powinien być jego częścią, ale nie jest takim priorytetem jak M. Są to tematy ważne dla funkcjonowania produktu, ale nie kluczowe. Najczęściej to wymagania, które można ostatecznie zastąpić innymi rozwiązaniami. Elementy oznaczone jako “should have” są bardzo ważne dla finalnego kształtu produktu, ale jednocześnie możliwe do obejścia. Jednak rezygnacja z tego elementu niekoniecznie jest najlepszym rozwiązaniem. Jeśli tak się dzieje, przestaje mieć status “must have”, a zyskuje właśnie “should have”.

Could have

C (could) - could’y to tematy, które dobrze, by były, ale można się bez nich obejść. Nie są niezbędne, ale na pewno wzbogacają projekt. Z punktu widzenia dewelopera realizacja zadań typu “could have” może zająć dużo pracy, ale na dalszym etapie. Nie wpływa natomiast na sam start realizacji zlecenia. Dzięki elementom could have poprawia się finalna jakość produktu oraz jego funkcjonalność.

Won’t have

W (won’t), czyli sprawy, które można „odpuścić” w danym terminie i na danym etapie projektu, ponieważ nie są ani niezbędne, ani kluczowe czy nawet opcjonalne. Odrzucamy je, ponieważ są tematy ważniejsze, które musimy zrealizować w określonym czasie i budżecie.

Według specjalistów wymagania typu M powinny stanowić do 60% wymaganych zadań, S, czyli should have to około 20%, Could have - 20%. Wymagań typu won’t have nie umieszcza się w tworzonym harmonogramie prac.

Analiza MoSCoW – dlaczego warto stosować ją w projektach?

Metoda MoSCow pozwala na kontrolę budżetu i dobre zagospodarowanie funduszy. Taka priorytetyzacja zadań daje możliwość podziału projektu na fazy, a przede wszystkim na stworzenie MVP, co przyspiesza pracę i wypuszczenie produktu. Dzięki wersji MVP sklep czy strona może już działać i zarabiać, a zespół jest w stanie zająć się kolejnymi funkcjonalnościami, których wdrożenie nie było niezbędne, by produkt powstał.

Technika MoSCoW w praktyce

Jak technika MoSCow wygląda w praktyce? Załóżmy, że mamy do stworzenia sklep internetowy. Klient chce sprzedawać produkty ze zdrową żywnością. Podczas planowania produktu tworzy się tzw. listę funkcjonalną, która zawiera spis potrzebnych funkcjonalności. Warto spotkać się wcześniej z całym zespołem i dokładnie omówić listę, prześledzić ją i zdecydować, co jest potrzebne do stworzenia danej funkcjonalności oraz jaki priorytet powinniśmy jej nadać. Dzięki temu jesteśmy w stanie określić elementy “must have”, które będą podstawą do stworzenia tak zwanego MVP, czyli pierwszej wersji produktu. Kluczowe jest to, by elementy MVP mieściły się w budżecie i by zespół był cały czas w kontakcie z inwestorem, który musi zatwierdzać wymagania. Takim M dla sklepu internetowego jest koszyk zakupowy czy karta produktu, bez nich sklep nie może istnieć. Should have w tym przypadku będzie płatność ratalna lub możliwość wpisania kodu rabatowego podczas zakupów, could have program lojalnościowy, a won’t have to np. wyskakujące pop-upy.

Technika MoSCow a Agile

MoSCow bardzo dobrze sprawdza się w firmach, które bazują na Agile. Pozwala to priorytetyzować backlog projektu. Umożliwia podzielenie wdrożenia na etapy, np. każdy z nich może składać się z kilku sprintów, które zawierają poszczególne zadania z nadanym priorytetem. Zmienność wymagań w czasie jest bardzo popularna, szczególnie przy projekcie, który jest rozbudowany. Przy stosowaniu metody MoSCow to nie jest problemem, można przesuwać poszczególne elementy i zmieniać im priorytety. To, co jest ważne, to stałość rzeczy do zrobienia do następnego sprintu oraz jasne komunikaty dla zespołu. Musi on wiedzieć, czym w najbliższym czasie powinien się zająć. Metoda MoSCow bardzo dobrze odnajduje się z podejściem Agile – nie jest sztywna, pozwala na w miarę szybkie reagowanie na zmiany. W zasadzie jest doskonałym narzędziem dla każdego typu projektu.