Praca z klientami to trudne zadanie, zwłaszcza jak jest wielu klientów i każdy ma inne wymagania. Użytkownik końcowy potrzebuje nowych przycisków, PM – zrealizowania milestonów pochodzących z Umowy, a CEO się pyta kiedy koniec projektu. I każdy się pyta: kiedy?
Pytania
- Jak to wszystko ogarnąć w zmiennym środowisku?
- Jak ułożyć zadania?
- Jak wytłumaczyć zespołowi takie a nie inne wymagania?
- Dlaczego nie robimy tego co było ważne miesiąc temu?
- Jak ustalić wartość dla klienta?
MoSCow w zadaniu
W takich przypadkach możemy wykorzystać analizę biznesową opartą na metodzie MoSCow, i do każdego zadania dodać oznaczenie jednoliterowe.
- M – MUST
- S – SHOULD
- C – COULD
- W – WON’T
Takie oznaczenie od razu sortuje nam listę wymagań – od tych co muszą zostać zrealizowane do tych co mogą być oraz tych co nie powinny być wdrażane w aktualnym momencie. W Product Backlog mogą znajdować się wymagania które na stan dzisiejszy nie są porządane.
Po dokładne wytłumaczenie odwołuję się do wikipedii: https://pl.wikipedia.org/wiki/Metoda_MoSCoW, tutaj opiszę jak wykorzystanie tych czynników wpłynie na przejrzystość priorytetyzacji.
Komunikacja
W trakcie zbierania wymagań jasno określajmy jakie kryterium spełnia oczekiwania. Często się okazuje, że wszystko Musi być, lecz z doświadczenia wiem, że to nie prawda. PO powinien umieć analizować sytuację tak aby inteligentnie balansować pomiędzy wymaganiami różnych interesariuszy wychwytując te – które przyniosą największą wartość do produktu.
Jeżeli mamy działającą funkcjonalność, a końcowy użytkownik potrzebuje zmienić lekko design, musimy zdiagnozować czy ta modyfikacja będzie miała większą wartość niż totalnie nowa rzecz. Bardzo często w trakcie dyskusji można dojść do porozumienia, że design powinien wyglądać inaczej, ale bardziej konieczne jest wprowadzenie innego modułu.
Product Backlog
Z pomocą przychodzi nam Product Backlog – czyli jedno prawdzie źródło wymagań produktu. Poprzez prezentowanie tej listy interesariuszom PO zyskuje pewność w jasności sytuacji – jeden z filarów Scrum – Transparentność. W przypadku oznaczenia każdego zadania jako Must każdy inteligentny interesariusz zobaczy, że aktualna sytuacja jest patowa, i niestety trzeba pójść na kompromis i należy uporządkować listę zupełnie inaczej.
Podsumowanie
Metoda MoSCoW sama z siebie pozwala na ustalanie priorytetów. W przypadku wielu zadań “Musi być”, należy szukać alternatywnego rozwiązania – spotkanie wszystkich interesariuszy, wspólne podjęcie decyzji – lub też autorytarna decyzja PO, która w Scrum’ie musi być respektowana.
Takie sytuacje nie są komfortowe natomiast musimy ufać Właścicielowi Produktu, że aktualny porządek zadań rzeczywiście odzwierciedla największą wartość rozwojową Produktu – nawet gdy czasem końcowy użytkownik będzie musiał dłużej poczekać na realizację krytycznej dla niego zmiany.