Jak ważna jest MOSKWA (MoSCoW, czyli priorytetów część 2)

Jak ważna jest MOSKWA (MoSCoW, czyli priorytetów część 2)
95354917 © creativecommonsstockphotos | Dreamstime.com

Hetman Chodkiewicz patrzył na przedpola Moskwy z rosnącą w sercu rozpaczą. Miasto, które jego wojska zajęły dwa lata temu po wielu dniach walki było stracone. Wieści, które z rzadka docierały do obozu wojsk spieszących z odsieczą były straszne i hetman nie mógł spokojnie myśleć o jego żołnierzach cierpiących głód i tortury.

– Rzeczpospolita, żeby patrzeć spokojnie w przyszłość, MUSI mieć Moskwę. Dzisiaj ją traci i przyszłość naszej ojczyzny zdaje mi się niepewną… Zarządzam odwrót!

Niemal 200 lat później, pułkownik Umiński zatrzymał konia i spojrzał przed siebie. Przed nim rozciągało się olbrzymie miasto. Złote kopuły cerkwi i pałaców, kolorowe ściany domów nawet z tej odległości oślepiały. Obok pułkownika stanął chorąży 10 Pułku. Jego bogaty, granatowy strój ze złotymi obszyciami tak był różny od tego, co kilka lat temu Umiński zastał podczas organizacji jednostki.

– Ruszajmy. Cesarz POWINIEN mieć Moskwę – to zmusi cara do kapitulacji.

Niespełna półtora wieku później kolejna armia stanęła u bram stolicy Rosji. Tym razem jednak feldmarszałek Walther von Brauchitsch szybko się przekonał, że Hitler mógł co najwyżej powiedzieć, że CHCIAŁBY mieć Moskwę. A po wielu tygodniach kampanii wiedział, że NIE BĘDZIE jej miał. I tylko fanatyczny optymista mógłby dodać:

– Tym razem!

MoSCoW – czym jest?

Te trzy historie pokazują, jak różnie można podchodzić do priorytetów w zależności od tego, jakie mamy zasoby i możliwości realizacji projektów, bo niczym innym jak złożonym projektem jest przecież kampania wojenna. Historię walk o to miasto przytoczyłem nie bez powodu. Nazwa MoSCow jest akronimem dla jednej z najczęściej wykorzystywanych metod priorytetyzacji zadań. Słowa wchodzące w skład tego akronimu wypowiedzieli bohaterowie opowieści ze wstępu i oznaczają:

Must have

o

Should have

Could have

o

Won’t have (this time)

W poprzednim, pierwszym wpisie, dotyczącym priorytetów mówiłem o HIPPOpotamie, czyli metodzie ustalania priorytetów dla zadań w projekcie bazującym na opinii najlepiej zarabiającej osoby. Metoda MoSCoW jest już pewną formą dialogu między klientem projektu a jego wykonawcami – nie idealną, ale dopuszczającą racjonalną argumentację.

MoSCoW- jak się do niej zabrać?

Masz więc, jako klient software house’u, świeżo upieczony business owner lub product manager pulę wymagań do wykonania w zakresie wdrożenia. Wiesz, że w wyznaczonym terminie masz maksymalnie 100 godzin pracy developerów… Ale Scrum Master, Project Manager z IT, albo po prostu Twój opiekun twierdzi, że wdrożenie w tym zakresie będzie trwało nie mniej niż 200h. I to już po negocjacjach i wykorzystani przez Ciebie argumentów, że ze stworzeniem back-endu dla aplikacji bazodanowej spełniającej wymagania RODO poradziłby sobie licealista w maksymalnie tydzień!

To co musisz teraz zrobić, to usiąść z osobami odpowiedzialnymi zarówno za biznes jak i wdrożenie i przeanalizować każde wymaganie, dając mu jeden z następujących priorytetów:

    M – MUST HAVE (musi być): wymaganie, które musi zostać dostarczone

    S – SHOULD HAVE (powinien być): Wymaganie bardzo ważne, wnoszące dużą wartość, które powinno znaleźć się  w rozwiązaniu, jeżeli jest to tylko możliwe.

    C – COULD HAVE (może być): wymaganie, które jest pożądane, ale niekonieczne. Zostanie ono zawarte, jeżeli pozwolą na to czas i zasoby.

    W – WON’T HAVE… this time (nie będzie): Reprezentuje wymaganie, które – za zgodą wszystkich zainteresowanych – nie będzie implementowane w danym wydaniu, ale może być wdrożone w przyszłości.

Tak – literki “o” zostały dodane tylko dlatego, że MSCW nic nie znaczy i z niczym się nie kojarzy. A MoSCow to przecież zupełnie co innego! 😉

No dobrze, ale które wymaganie jest MUST, a które tylko COULD have?

Teoretycznie jest to bardzo proste. Wymaganie z kategorii MUST HAVE musi spełniać następujące warunki:

  • Bez niego nie ma sensu dostarczać w wyznaczonym terminie
  • Bez niego rozwiązanie nie będzie zgodne z obowiązującym prawem
  • Bez niego nie spełnione zostaną wymagania bezpieczeństwa
  • Bez niego nie można dostarczyć realnego rozwiązania
Są nawet tacy, którzy twierdzą, że słowo MUST również jest akronimem, od Minimum Usable SubseT, czy minimalny użyteczny podzbiór.
 
Przykład: Twoja aplikacja będzie wymagała podania od klientów danych osobowych. W związku z tym rozwiązanie będzie musiało spełniać wymagania w zakresie RODO, bezpieczeństwa i integralności danych. Te wymagania muszą otrzymać znacznik MUST HAVE, bo bez nich rozwiązanie będzie niezgodne z prawem, i nie zostaną dostarczone krytyczne zabezpieczenia.
 
Cóż….Wyobraźni twórcom tej metody wystarczyło wyłącznie na te dwa słowa (czyli MOSCOW i MUST), pozostałe kategorie już nie miały takiego szczęścia.  

Wymagania z kategorii SHOULD HAVE to takie, które są:

  • Ważne, ale nie krytyczne dla funkcjonowania systemu
  • Pominięcie może być bolesne, ale rozwiązanie jest nadal wykonalne
  • Jego brak może wymagać uproszczeń procesowych, stworzenia rozwiązań “tymczasowych”, nieefektywnością, etc. Obejście może być tylko tymczasowe

 

Przykład: Twoja aplikacja ma umożliwiać klientom skanowanie dokumentów i rozpoznawanie ich typu po specyficznych metadanych (np. po rozpoznaniu ciągu znaków FVAT uznaje, że jest to faktura, a dla ciągu “Umowa”, że jest to dokument umowy). Wykonawca rozwiązania twierdzi jednak, że integracja OCR (systemu do odczytywania dokumentów) będzie trwała dłużej, niż wyznaczony termin komercyjnego startu aplikacji. W trakcie negocjacji dochodzicie do wniosku, że funkcjonalność zostanie dostarczona w pierwszym możliwym terminie (np. Sprincie, jeżeli pracujecie w SCRUM). A do tego czasu zeskanowane dokumenty będą trafiały do obróbki ręcznej przez zespół wsparcia.

Could have to wymagania, które jako pierwsze padają pod kosą nazywaną “termin jest zagrożony”. Krótko mówiąc, takie wymaganie jest:

  • Poszukiwane lub pożądane, ale mniej ważne i nie jest krytyczne dla rozwiązania
  • Ma mniejszy wpływ, jeśli zostanie pominięte (w porównaniu z wymaganiami z poprzedniej grupy)

 

Wielu zespołom projektowym spory problem sprawia odróżnienie wymagań z tych dwóch grup. I dyskusja czy coś jest MUST czy SHOUD przypomina wówczas spory średniowiecznych teologów o wyższość Bozego Narodzenia nad Wielkanocą. Jedną z metod na rozwiązanie tego problemu jest odejście od analizy i argumentacji dotyczącej korzyści i skupienie się na stratach lub tzw. poziomie bólu. Straty te mogą być wyrażone zarówno w wymiarze finansowym, ale również liczbą klientów dotkniętych brakiem tej funkcjonalności.  

Przykład: Twoja aplikacja ma mieć możliwość zgłoszenia problemu przez klienta bezpośrednio z poziomu formularza w niej zawartego. Budżet na Must i Should have jednak jest tak napięty, że uznajesz, że na początek wystarczy umieszczenie numeru telefonu do Działu Obsługi Klienta. Kosztem będzie zarówno zwiększona liczba połączeń na CallCenter (i np. mniej wykonanych połączeń sprzedażowych), jak i niższy wskaźnik satysfakcji klienta.

Ostatnią kategorią jest WON’T HAVE. Z czysto kurtuazyjnych powodów (i empatii wobec właściciela), w nawiasie dodaje się jeszcze dwa słowa – THIS TIME. Są to wymagania, co do których klient i dostawca zgodzili się, że nie zostaną umieszczone w zakresie danego projektu / sprintu / etapu wdrożenia.

Przykład: Specjalista od UX uznał, że niezbędna jest zmiana separatora oddzielającego logo od menu z graficznego na CSS. Zmiana nie jest znacząca, ale wykracza poza dostępny budżet. Zostaje oznaczona jako WON’T HAVE i będzie realizowana w przyszłości, o ile znajdzie się czas.

Ile czasu potrzebujesz na każdą z kategorii?

Ze względu na sposób priorytetyzacji oraz rolę każdej z kategorii wymagań dobrze jest zapewnić odpowiedni czas dla każdej z grupy wymagań. I tak:
  1. Wymagania MUST HAVE powinny w „budżecie” czasowym projektu / sprintu zająć nie więcej niż 60 proc. czasu
  2. Wymagania SHOULD HAVE, łącznie z MUST HAVE to maksymalnie 80 proc. czasu
  3. Wymagania SHOULD HAVE, MUST HAVE i COULD HAVE to łącznie 100 proc. czasu z zastrzeżeniem, że wymagania z grupy COULD HAVE są buforem na nieprzewidziane sytuacje / przekroczenia czasu w dwóch poprzednich kategoriach.

Skąd się wzięła priorytetyzacja MoSCoW i jak ją wykorzystać na co dzień?

Jak większość takich metod, ta metoda priorytetyzacji wymagań jest wykorzystywana w zwinnych metodykach prowadzenia projektów. Nie oznacza to jednak, że nie możemy z niej skorzystać w zarządzaniu swoim prywatnym życiem. Wyobraźmy sobie, że czeka nas wyjazd na wakacje, a ze względu na ograniczenia bagażowe nie możemy zabrać całej szafy. Patrzymy na wszystko, co leży przed nami i kategoryzujemy:

  • Jedziemy poza obszar Unii Europejskiej, więc paszport będzie MUST HAVE
  • Będzie na pewno gorąco, więc strój kąpielowy również będzie MUST HAVE
  • Opcjonalnie będziemy mogli skorzystać z wycieczek w górzysty teren, więc wygodne buty będą Should Have. Jeżeli ich nie weźmiemy, najbezpieczniej będzie zrezygnować z takiej wycieczki
  • Może się zdarzyć, że będzie dyskoteka na plaży, więc bolerko będzie doskonałym wyborem…, ale zamiast niego również można wykorzystać chustę – jest więc Could Have.
  • Istnieje 10 procentowe ryzyko, że trafimy na 1 dzień w  roku, kiedy temperatura w miejscu, do którego jedziemym spadnie poniżej 15 stopni. Patrzymy na walizkę, wybrane już rzeczy i wiemy, że ciepły sweter znajdzie się w kategorii Won’t Have. This time oczywiście, bo następny wyjazd planujesz na Islandię!

Udanych wakacji w stylu AGILE!

Dodatkowe informacje:

https://www.agilebusiness.org/page/ProjectFramework_10_MoSCoWPrioritisation
https://pl.wikipedia.org/wiki/Metoda_MoSCoW

Jedna z nielicznych biblii właściciela produktu. Jeżeli szukasz informacji o tym jak budować roadmapę, ustalać priorytety, dyskutować je z interesariuszami, ta pozycja jest dla Ciebie MUST HAVE, 😉

Dobra mapa drogowa produktu jest jednym z najważniejszych i najbardziej wpływowych dokumentów, jakie organizacja może opracować, opublikować i stale aktualizować. W rzeczywistości ten jeden dokument może pokierować całą organizacją, jeśli chodzi o realizację strategii firmy.

Książka jest w formie eBooka, dostępna w księgarni Helion

Wakacje MoSCoW
89964147 © creativecommonsstockphotos | Dreamstime.com
0 0 Głosy
Oceny wpisu
Subscribe
Powiadom o
guest
0 komentarzy
Komentarze w treści
Zobacz wszystkie