Znasz to uczucie, gdy masz do wykonania tyle zadań, że nie wiesz od czego zacząć? Świetnie idzie Ci robienie list „to do” ale nie udaje Ci się wykonać wszystkich zaplanowanych czynności, co prowadzi do frustracji? Być może przez przytłaczającą ilość obowiązków oraz brak nadania im odpowiedniej rangi zbyt dużą uwagę przykładasz do czynności błahych, które zabierają Twój czas i energię uniemożliwiając staranne wykonanie ważniejszych zadań. Z pomocą przychodzi technika MoSCoW opracowana i opublikowana w 1994 roku przez Dai’a Clegg’a z firmy Oracle i służąca właśnie definiowaniu priorytetów. Początkowo technika wykorzystywana była podczas ustalania istotności wymagań oprogramowania, jednak jej zastosowanie może być dużo szersze.

4 kategorie istotności

W ramach techniki MoSCoW każde element składający się na realizację zamierzonego celu powinien zostać przypisany do jednej z czterech kategorii istotności: 

MUST haves – elementy konieczne do osiągnięcia celu, np. uruchomienie strony internetowej dla sklepu działającego tylko online. (bez niej klienci nie będą w stanie dokonywać zakupów).

SHOULD haves – elementy o wysokim priorytecie, których brak nie przekreśli realizacji celu np. uruchomienie możliwości płatności online w sklepie internetowym (to bardzo przydatna i wygodna funkcja z punktu widzenia użytkowników, jednak bez jej uruchomienia wciąż możliwa jest płatność za zakupy np. tradycyjnym przelewem).

COULD haves – elementy pożądane, ale nie kluczowe i o niższym priorytecie niż should haves. Do ich realizacji można przystąpić po wykonaniu must haves i should haves np. powiadomienia smsowe dla klientów sklepu internetowego o postępach w realizacji ich zamówienia.

WON’T haves – elementy, które ze względu na warunki lub inne ograniczenia nie mogą zostać wykonane w danym momencie lub okresie czasu, np. aplikacja mobilna dla sklepu internetowego. Zarówno podczas realizacji dużych projektów, jak mniejszych przedsięwzięć (chociażby tworzenia własnej listy „to do”) warto jest od razu ustalić, które zadania nie mogą zostać wykonane na danym etapie. Ułatwi to organizację pracy oraz zmniejszy szansę na wystąpienie nieporozumień, czy też frustracji.

Czy wszystkie wymagania to MUST haves?

Podczas realizacji projektów wdrożeniowych niejednokrotnie spotykaliśmy się z sytuacją, gdy wszystkie zadania wydawały się być MUSTem. Jednak z biegiem czasu i urealnieniem wymagań wynikającym z rzeczywistego tempa prac okazuje się, że możliwa jest rezygnacja z części z nich, jeżeli pozwoli to na realizację projektu w zakładanym terminie. Proponowany rozkład zadań podczas ich priorytetyzacji wynosi 60% – 20% – 20%. Dlaczego akurat taki? A to dlatego, że według statystyk minimum, które realizowane jest podczas projektów wynosi ok. 60% pierwotnego planu, a jak już wspominaliśmy technika MoSCoW swoje korzenie ma właśnie w dziedzinie projektów informatycznych.

 20% should haves i 20% could haves to nasz margines, który daje pole manewru i umożliwia modyfikację planu bez zagrożenia realizacji pierwotnego planu.

Jak odróżnić MUST haves od SHOULD haves i COULD haves?

Niezależnie od sytuacji, w której korzystamy z techniki MoSCoW zazwyczaj na początku wszystkie zadania, czy też wymagania wydają się być konieczne. W ten sposób powstaje ogromna lista must haves i dokładnie zero should haves i could haves. Przy każdym elemencie zakwalifikowanym jako must warto zadać sobie kilka pytań:

Bez których zadań nie mogę zrealizować pozostałych?

Bez czego produkt nie zadziała?

Bez spełnienia których wymagań projekt nie będzie miał sensu?

Pytania podyktowane są zagadnieniem, którym się zajmujemy. Inny zestaw pasuje do realizacji wdrożenia oprogramowania, a inny do tworzenia osobistego harmonogramu pracy jednak łączy je wspólny mianownik – wykonanie których elementów warunkuje wykonanie pozostałych?

SHOULD haves a COULD haves

Różnica pomiędzy tymi elementami jest bardzo płynna i trudna do jednoznacznego zdefiniowania. Można jednak spróbować podejść do tematu w ten sposób – niewykonanie should haves jest po prostu bardziej bolesne i często wymaga dodatkowej pracy. Pominięcie could haves wpływa na realizację celu w zdecydowanie mniejszym stopniu.