MoSCoW – czyli jak nadać znaczenie wymaganiom w projekcie.

MoSCoW to metoda priorytetyzowania zakresu projektu, którą poznałam stosunkowo niedawno – jakieś dwa, trzy lata temu – i od razu pożałowałam, że nie znałam jej wcześniej. Odkąd zaczęłam stosować MoSCoW życie moje i klientów mych stało się relatywnie o parę ciężkich westchnień lżejsze.

MoSCoW

MoSCoW to narzędzie pierwotnie stosowane przy priorytetyzacji wymagań do oprogramowania. Swoje korzenie ma w metodyce DSDM (Dynamic Software Development Method). To jedna z pierwszych (jeśli nie pierwsza) metod Agile. Powstała w 1994 roku kiedy to jeszcze iteracyjne podejście do wytwarzania produktu brzmiało jak pomysł polecenia klientowi by wykąpał się zimą w przeręblu w Wiśle, a sama nazwa Agile po prostu nie istniała. Ale o tej metodyce bardzo chętnie, innym razem 😉 Skupmy się na narzędziu.

MoSCoW daje nam przepis na posortowanie wymagań projektu odpowiednio co do istotności.

Kategorie istotności wymagania

MUST haves (muszą być) – zbiór wymagań inaczej nazywany Minimum Usable SubseT. Mówimy zatem o wymaganiach, bez których projekt nie ma sensu. W przypadku oprogramowania będą to funkcjonalności bez których nowa aplikacja nie ma szans zaistnieć, a bynajmniej nie może spełnić swojej podstawowej użyteczności. Dla przykładu, w projekcie bankowości mobilnej byłaby to możliwość logowania na konto przez klienta.

SHOULD haves (powinny być) – zbiór wymagań, które nie są krytyczne dla projektu, jednak są istotne, wartościowe z punktu widzenia użytkownika. Na przykład, w naszym projekcie bankowości mobilnej mogłaby to być możliwość zapisywania odbiorców. Bez tej funkcji nadal mogę robić przelewy z każdego urządzenia na całym świecie. Jednak opcja tworzenia listy odbiorców to standard, którego oczekuje każdy użytkownik.

COULD haves (mogłyby być) – zbiór wymagań, które są mile widziane i mogłyby zostać zapewnione bez większego wysiłku, czy kosztu. Jeśli pojawi się zagrożenie nie skończenia projektu na czas, te wymagania jako pierwsze nie zostaną zrealizowane. W przypadku naszego przykładu bankowości mobilnej mogłaby to być dodatkowa funkcja kalkulatora na rachunku mobilnym.

WON’T haves (nie będzie) – zbiór wymagań, które chcemy mieć zrealizowane, jednak nie w tej fazie, nie w tym projekcie, nie w tym sprincie. Inaczej klasyczne out of scope.

Kiedy stosować MoSCoW?

MoSCoW można zastosować zarówno do zakresu całego projektu, jak i do zakresu kolejnych faz, czy sprintów. Narzędzie to jest obecnie bardzo popularne wśród zespołów działających zwinnie, choćby scrumowo. Dzięki niemu, możemy tworzyć elastyczne plany z naturalnie wbudowanym buforem. Takim zapasem stają się wszystkie wymagania z kategorii Could haves i Should haves. Zatem MoSCoW to narzędzie idealne dla projektów, w których działa timeboxing.

Z kim klasyfikować istotność wymagania?

Dla praktyków zarządzania projektami to pytanie z kategorii pytań „co się kręci: słońce, czy ziemia”.  Jednak by potraktować temat holistycznie, powiedzmy sobie wprost. Wymagania biorą się od interesariuszy, a zatem od: klientów, użytkowników, zespołów realizacyjnych, instytucji regulujących rynek, na którym funkcjonuje nasz produkt, konkurencji itd. Pamiętajcie więc, by nie tylko zebrać od nich wymagania, ale i zapytać, przeanalizować istotność wymagań z ich punktu widzenia.

Skąd wiedzieć co jest SHOULD, a co COULD?

Przychodzę na spotkanie i mówię: słuchajcie, tu jest taka metoda MoSCoW, które z Waszych wymagań to Must haves? STOP, nie do końca to tak wygląda. W dojrzałym zespole scrumowym na pewno tak. Ale u klienta, dla którego prowadzę projekt po raz pierwszy lub u klienta spoza branży IT takie rozpoczęcie miałoby dwa skutki:

  • Kompletna konsternacja,

po chwili otrząśnięcia:

  • Wszystkie wymagania sklasyfikowane jako MUST haves.

W myśl zasady „dostosuj swój komunikat do odbiorcy”, czasem nawet nie wymieniam nazwy narzędzia. Jeśli zapytam, które z wymagań jest najważniejsze, zazwyczaj dowiaduję się, że wszystkie są krytyczne dla projektu. Klientom bardzo często wydaje się, że wszystko jest ważne i pilne.

Pamiętajcie: takie odpowiedzi dostajecie, jakie zadajecie pytania.

Oto przykłady pytań, które można zadać:

MUST haves

Bez czego ten produkt nie zadziała?

Kiedy ten produkt nie będzie miał sensu?

Które funkcjonalności są krytyczne z punktu widzenia użytkownika?

Które wymagania bezpośrednio spełniają cel użytkowy produktu?

Które wymagania realizują korzyść biznesową?

Bez których wymagań produkt nie będzie spełniał zasad bezpieczeństwa?

Bez których wymagań produkt nie będzie zgodny z przepisami?

SHOULD haves i COULD haves

Aby uzyskać te dwie kategorie, najlepiej jest przejrzeć listę MUST haves i do każdego (czasem ponownie) zadać pytanie:

Czy bez tej funkcjonalności produkt będzie działał?

Kolejna metoda to uszczegółowienie MUST haves, a dokładnie: rozpisanie ich na mniejsze wymagania. W ten sposób, w myśl zasady granulacji, otrzymamy również SHOULD haves i COULD haves.

Różnica między tymi dwoma kategoriami jest taka, że brak realizacji SHOULD haves jest bolesny w skutkach. Zazwyczaj niesie ze sobą jakieś konsekwencje, np. musimy napisać procedurę, zrobić dodatkowe testy, naprawić coś innego. Pominięcie COULD haves nie wiąże się z poważniejszymi konsekwencjami (poza nieco niezadowolonym zamawiającym, który chciał wszystko).

WON’T haves:

Czego nie zrobimy tym razem?

Co możemy zaadresować w kolejnej fazie projektu?

Ile MUST, a ile reszty?

Dobre praktyki mówią, że powinniśmy dążyć do podzielenia listy wymagań na:

60% MUST haves

20% SHOULD haves

20% COULD haves

W ten sposób tworzymy sobie wspomniany wcześniej bufor. Jesteśmy w stanie zobowiązać się do ukończenia np. sprintu w danym terminie wiedząc, że w razie niedoszacowań, problemów, będziemy mogli zrezygnować z części COULD haves, a w najbardziej czarnym scenariuszu dowieziemy jedynie MUST haves. Skąd te proporcje? Otóż statystyki mówią, że minimum, które realizujemy w większości projektów, to właśnie 60-65% pierwotnego planu.

Konieczność aktualizacji

Oczywiście Wasz MoSCoW nigdy nie będzie wykuty w skale. Będzie się zmieniał tak często, jak często klient zmienia zdanie, jak często zmienia się otoczenie projektowe. Już na początku projektu warto ustalić cykle, w których będziecie przeglądać listę wymagań celem aktualizacji priorytetów.

Korzyści ze stosowania MoSCoW

MoSCoW to narzędzie szczególnie przydatne w metodykach zwinnych, w których mamy do czynienia z timeboxami. Chroni czas realizacji projektu i jakość produktu. Najpierw skupiamy się na tym, co krytyczne, bez konieczności obniżania jakości wykonania by zdążyć również z pozostałymi funkcjonalnościami. MoSCoW idealnie sprawdzi się w projektach regulowanych, w których termin końcowy projektu jest z góry określony. Można też go zastosować wobec budżetu, w projektach, w których koszty stanowią nieelastyczne ograniczenie.

——————————

Pisząc ten artykuł też miałam swoje wymagania:

Must – ma być opisane narzędzie, mają być przykłady, narzędzie praktyczne w rzeczywistości, nie w teorii, narzędzie uniwersalne, poprawna polszczyzna

Should – załączony fajny obrazek do tekstu

Could – nie powinno być dłużej niż 2 strony w Wordzie

Won’t – tym razem nie ma być o zarządzaniu zespołami, strategią, ani o komunikacji

Mój timebox to był wieczór. Zaczęłam po północy i jest prawie 5 rano, więc wyszło trochę dłużej, ale w ostatecznym terminie – przed wyjazdem na urlop – się zmieściłam 😉

Jedno mnie teraz martwi – moje wymagania, spisałam je chybcikiem, fragmentarycznie i (nazwijmy to po imieniu) flejtuchowato. Przy takim wyimaginowanym projekcie można sobie na to pozwolić. W rzeczywistości nigdy nie mogłabym sobie pozwolić na niedbale spisane wymagania (komu się to zdarzyło, ten wie jakie piekło to oznacza). Ale o tym może następnym razem…

 

Gdy chcemy zrobić dużo naraz, przydaje się plan strategiczny

Wiem, długo nie pisałam. Trochę przez intensywny czas zawodowy i prywatny. Trochę przez pułapkę myślową, którą ostatnio regularnie sama na siebie zastawiam.

Wpadłam w schemat myślenia pt. „to już było”, „to jest oczywiste”, „o tym wszyscy wiedzą”, „nic nowego”. To myślenie strasznie zabija każdy kolejny pomysł na artykuł. Do tego doszedł jeszcze jeden aspekt: zdałam sobie sprawę z tego, że nie lubię się wymądrzać.

I wtedy pomyślałam sobie: hej Ania, przecież to tak samo jak z projektami, które prowadzisz. Nie blokuj się, zrób sobie listę zagadnień, które chcesz zgłębić w książkach, artykułów, które chcesz napisać. Taką odważną listę, bez skrupułów i zahamowań. Potem zaplanuj co zrobisz najpierw. Nie, nie rób planu na dwa lata. Po prostu ustal jaką książkę przeczytasz pierwszą, jaki wpis napiszesz, i po skończeniu zobaczy się co dalej. O! I to jest zwinne działanie w praktyce.

Myślenie o wszystkich zadaniach, które trzeba wykonać blokuje działanie.

To trochę jak jazda autem w nocy. Wiem dokąd zmierzam, ale nie znam w szczegółach całej drogi. Światła oświetlają mi dokładnie kolejne kawałki trasy, na których się skupiam. Jak zbliżam się do miasta, moim celem jest sprawnie przez nie przejechać. Skupiam się na tym co pokazuje nawigacja i na sztuce jazdy. Nastawiam zmysły na takie przedmioty jak: znaki, skrzyżowania, piesi, dziury w drodze, radary itd. Gdy jadę przez las, zwalniam, włączam długie światła, skupiam się na niebezpiecznych zakrętach, a na długiej prostej dodaję gazu i modlę się, żeby nie wskoczyła mi sarna na maskę;)

„podejście projektowe”

W pierwszym kroku zastanowiłam się po co ja w ogóle piszę. Tak, zrobiłam to po raz kolejny, może nawet dziesiąty. Ostatni raz był chyba z pół roku temu – jak dla mnie całkiem niedawno. Taka analiza upewnia mnie w działaniu, dodaje motywacji. Następnie zaczęłam tworzyć listę pomysłów na wpisy. Odnalazłam notes, który zaczęłam zapisywać lata temu gdy tworzyłam tego bloga. Tam znalazłam sporo fajnych pomysłów. Za kolejne źródło posłużył notatnik w telefonie – też kilka perełek się znalazło (mam tam taką listę, którą rozbudowuję przy okazji rozmaitych autorefleksji). Lista zaczęła automatycznie się uzupełniać. Przyznam Wam, że uśmiech zaczął pojawiać się na twarzy, tętno przyspieszyło – entuzjazm gotowy! Pomyślałam sobie, że jeszcze brakuje mi trzeciego źródła – Waszych sugestii. Więc już nie po raz pierwszy zwrócę się do Was z zapytaniem:

o czym chcielibyście czytać na tym blogu?

Oczywiście czekanie na Wasze pytania nie blokuje mnie w pisaniu tego, co sama zaplanowałam. Mogę wybrać sobie temat z listy i pisać, jednocześnie rozbudowując listę. Takie proste to i oczywiste, ale pozwolę sobie jeszcze przedstawić Wam graficznie:

pisanie

Zauważcie, że nie stworzyłam szczegółowego planu działania z zadaniami, harmonogramu z poszczególnymi tematami. Kiedyś tak robiłam. To podejście zabijało chęć do pisania. Bo zazwyczaj po napisaniu pierwszego artykułu pojawiał się pomysł na kontynuację. Często też wydarzało się coś ciekawego w moich działaniach zawodowych, czytelnik zgłaszał zainteresowanie konkretnym tematem, wpadła mi ciekawa książka w rękę, albo spadała na mnie inspiracja na konferencji, czy z Internetu. Tym razem więc określiłam sobie podejście do pisania na blogu:

  1. Ustaliłam jakie korzyści daje mi pisanie artykułów i prowadzenie bloga, co chcę przez to osiągnąć (Opisywać trendy? Ściągać zainteresowanie czytelników? Uczyć się opisując coś nowego? Utrzymywać ruch na stronie?…)
  2. Zaplanowałam etapy, w których podejdę do działania, a w ramach tych etapów ustaliłam:
    • Czy warto dzielić działania na etapy i czym się dany etap będzie wyróżniał?
    • Jaki ma być efekt końcowy etapu?
    • Jaka korzyść powstanie dla mnie?
    • W jaki sposób zrealizuję dany etap (krytyczne działania, zasoby itd.)?
    • W jaki sposób zadecyduję co dalej, jaki będzie kolejny etap?
  3. Teraz pozostaje odświeżać sobie to podejście za każdym razem gdy się zagubię lub zdemotywuję do pisania na blogu.

To, co opisałam powyżej i nazwałam podejściem do projektu mądre książki nazywają

planem strategicznym.

Taki plan przydaje się zawsze i bez niego ani rusz z projektem. Robicie takie plany w Waszych projektach? Komu powierzylibyście robienie planu strategicznego w świecie biznesu i co jeszcze mogłoby się w nim znaleźć?

Poniżej mała ściąga dla Was:

plan strategiczny

 

 

 

 

 

 

 

 

Inspirefulness

Because sharing is caring

Lean Agile Organization Tesis

Just another WordPress.com site

A Girl's Guide to Project Management

Project Management musings for one and all