Jak określić co jest ważne – MoSCoW

      Wiele ludzi, nie tylko tych dobrze zorganizowanych, często tworzy listy rzeczy do zrobienia (To Do Lists), aby móc dobrze zaplanować, ile czasu potrzebują na wykonanie wszystkich zaplanowanych zadań i o niczym nie zapomnieć. Mnie też zdarza się je robić, szczególnie, gdy tych zadań jest sporo. Problem pojawia się, gdy pod koniec dnia mam wrażenie, że pomimo odhaczenia dużej ilości czynności nadal prawie nic nie zrobiłam. W przypadku projektów jest jeszcze trudniej. Zadań jest znacznie więcej i wszystkie wydają się ważne. Pamiętacie post Kacpra o Zasadzie Pareto? 20% wysiłku przynosi 80% korzyści i odwrotnie, 80% wysiłku może przynieść nam tylko 20% pożytku.

Więc jak wybrać ten ułamek czynności, który przyniesie na najwięcej korzyści? Z pomocą może przyjść tu metoda prioretyzacji MoSCoW. Każde zadanie lub pakiet zadań przyporządkowujemy do jednej z 4 grup:

M – Must have (musi być) – rzeczy, które muszą zostać spełnione a bez których całe rozwiązanie nie będzie funkcjonowało np. zaprojektowanie wejścia pod ładowarkę w nowym modelu telefonu, możliwość dokonywania płatności w sklepie internetowym czy zmycie naczyń podczas sprzątania kuchni (niestety, jeśli sprzątnęliśmy całą kuchnię na wysoki połysk, a nadal mamy górę brudnych naczyń w zlewie to nadal nie jest ona posprzątana).

S – Should have (powinien być) – rzeczy, które mają wysoki priorytet i powinny być zawarte w finalnym rozwiązaniu, ale nie jest od nich uzależnione powodzenie projektu. To wszystkie funkcjonalności, które na przykład zapewniają optymalne funkcjonowanie aplikacji i wygodę użytkownika i mają znaczny wpływ na odbiór całości rozwiązania.

C – Could have (może być) – rzeczy, które są postrzegane jako pożądane, ale niekonieczne. Mają one niższy priorytet niż should have. Są to wszystkie aspekty, które mają dopieścić nasz produkt. Nie mogą być jednak uznawane za bez znaczenia. Wykonuje się je, jeśli starczy nam czasu i pieniędzy, a wszystkie must have i przynajmniej część should have zostało wykonane.  

W – WON’T (nie będzie) – są to rzeczy, które nie będą wykonane w danym projekcie. Realizując dla kogoś zlecenie, warto od razu zawrzeć w umowie nie tylko zakres, który ma zostać wykonany, ale także te rzeczy, których nie zrobimy, Dzięki temu możemy na koniec uniknąć wielu nieprzyjemnych sytuacji.  

      Wszystkie Must Have tworzą tzw. Najmniejszy Użyteczny Podzbiór, bez którego całe rozwiązanie nie będzie uznane za wykonane (także bezpieczne). Should have i Could Have polegają na określeniu wartości tego, czego oczekujemy, że będzie w finalnym produkcie, a co jest tylko fajnym gadżetem. Oczywiście, jeśli robimy np. oprogramowanie dla klienta, to oczekuje on, że w gotowym produkcie znajdzie się wszystko, co było zaplanowane. Jeśli jednak zapytamy go, czy jest gotowy zapłacić więcej, albo wydłużyć termin realizacji, aby wszystkie zaplanowane funkcjonalności się w nim znalazły, to nagle część aspektów przestaje to być aż takie dla niego ważne.

Idealne proporcje nakładu pracy M:S:C to 60:20:20. To dosyć ważne, bo jeśli uznamy, że wszystkie zadania są niezbędne to szansa, że wykonamy 100% zakresu w zaplanowanym czasie i kosztach jest mała i raczej dąży do zera. Tu pojawia się też dosyć kontrowersyjna opinia, że klient nie potrzebuje wszystkiego. Nie wszystko też co było dla niego ważne na początku projektu, będzie miało taki sam priorytet przy jego zakończeniu.

Jak się do tego zabrać?

1. Robimy listę rzeczy do wykonania. Mogą to być czynności, jak również produkty, jakie chcemy wykonać. Najlepiej, jeśli da się je później podzielić na mniejsze zadania lub półprodukty. Łatwiej wtedy oszacować ich czas i koszt.
2. Każdej “dużej” rzeczy do wykonania przypisujemy odpowiednio priorytet M, S i C. Na rysunku poniżej te zadania mają czerwoną ramkę.
3. Większe czynności dzielimy na mniejsze i im również przypisujemy odpowiedni priorytet M,S,C

     4. Aby “duży” must mógł zostać uznany za sukces muszą zostać wykonane co najmniej wszystkie “małe” must’y, na które się on dzieli.  Podobnie, aby “duży” should lub could mógł zostać uznany za gotowy muszą zostać wykonane co najmniej wszystkie “małe” must’y na jakie się one dzielą.

Jeśli przykładowo jesteśmy programistami i wykonujemy dla Klienta platformę sklepu internetowego, to tak może wyglądać nasz podział struktury produktu z przypisanym priorytetem dla głównych zadań:

1. Grafika (M)
2. Zarządzanie panelem głównym (M)
3. Dodawanie produktów (M)
   1. Zdjęcie
   2. Opis
   3. Cena
   4. Opinie
4. Panel Klienta (M)
   1. Koszyk
      1. Dodawanie produktów
      2. Zapisywanie wyborów do następnej sesji
   2. Płatność
      1. Przelewy24
      2. eService
      3. DotPay
      4. PayU
      5. Karty kredytowe
      6. Płatność przy odbiorze
   3. Dostawa
      1. Poczta Polska
      2. DHL
      3. GLS
      4. Paczkomat
      5. Osobiście
      6. Drony
   4. Historia transakcji
5. Bezpieczeństwo (M)
   1. Połączenie SSL
   2. Kody CAPCHA przy rejestracji użytkownika
6. Wyszukiwarka (S)
   1. Sortowanie
   2. Filtrowanie
7. Zbieranie danych (S)
   1. Google Analytics
8. Porównywarki cen (C)
   1. Ceneo
   2. Nokaut
   3. Oferciak
   4. Okazje
   5. Radar
   6. Skąpiec
   7. Sklepy24
9. Pozycjonowanie strony, tagi (S)
10. Ostatnio sprzedane produkty (C)
11. Urządzenia mobilne (M)
    1. RWD

Rozważmy dokładniej Panel Klienta, który jest koniecznością w przypadku sklepu internetowego:

1. Panel Klienta (M)
   1. Koszyk (M)
      1. Dodawanie produktów (M)
      2. Sumowanie produktów (S)
      3. Zapisywanie wyborów do następnej sesji (C)
   2. Płatność (M)
      1. Przelewy24 (M)
      2. eService (M)
      3. DotPay (M)
      4. PayU (M)
      5. Karty kredytowe (S)
      6. Płatność przy odbiorze (S)
      7. Możliwość zakupu na raty (C)
   3. Dostawa (M)
      1. Poczta Polska (M)
      2. DHL (C)
      3. GLS (M)
      4. Paczkomat (M)
      5. Osobiście (S)
      6. Drony (W)
   4. Formularz reklamacyjny (S)
   5. Historia transakcji (S)
   6. Ocena produktu po zakupie (C)

Aby panel Klienta mógł być uznany za gotowy, musi się w nim znaleźć co najmniej Koszyk, Płatność i Dostawa. Te z kolei dzielą się na mniejsze funkcjonalności. Idąc od najniższego poziomu, aby wykonać Panel Klienta, musimy dostarczyć co najmniej:

• dodawanie produktów do koszyka
• płatność przelewem
• płatność przez Service, DotPay i  PayU
• dostawę Pocztą Polską i przez Paczkomaty.

Jeśli ktoś przyjrzał się dokładniej, to przy Dostawie występuje jeden Won’t (drony). Sygnalizujemy tym, że ten rodzaj dostarczania nie będzie funkcjonalnością platformy (na razie).

Podsumowanie:

• Wszystkie Must muszą być wykonane, aby dostarczyć Minimalny Użyteczny Podzbiór.
• Niewykonanie chociaż jednego Must oznacza, że projekt się nie powiódł lub nieprawidłowo oceniliśmy priorytety dla poszczególnych zadań.
• Should zawiera to, co Klient oczekuje, że będzie w jego produkcie. Bez wszystkich Should projekt może być uznany za sukces, jednak funkcjonowanie całości produktu może być uszczuplone.
• Could to wszystkie zadania, które możemy wykonać, jeśli po wykonaniu zadań o wyższym priorytecie pozostał nam jeszcze czas i zasoby.
• Idealne proporcje nakładu pracy M:S:C to 60:20:20.

Zdjęcia:

• Praca własna
• https://www.pexels.com/photo/person-holding-magnifying-glass-712786/