Dzisiaj trochę o priorytetyzacji. W ramach każdego projektu znajduje się określona lista zadań. Wykonanie każdego z tych zadań spełnia określoną potrzebę.
Życie pisze różne scenariusze. Aczkolwiek w przypadku projektów w IT mamy w 90% przypadków 2 scenariusze. Zawsze ale to zawsze będzie tak że zespół developerski powie że nie ma żadnych ale to żadnych szans na to że uda się spełnić aby wymarzona lista zadań została zrealizowana w określonym czasie. Kolejny scenariusz z cyklu tych zawsze ale to zawsze jest fakt że za określoną kwotę nie jesteśmy w stanie tego zrobić albo że cały zakres to możemy zrobić ale za miliony monet. Wtedy zazwyczaj musimy się zdecydować co jest do zrobienia najpierw. I pojawia się problem jak tego dokonać aby programiści i inni ludzie związani z developmentem wiedzieli co jest najważniejsze a co jest mniej lub mało ważne ale w sumie to fajnie by było jakbyśmy to wdrożyli.
Wtedy na białym koniu wjeżdża priorytetyzacja. Przeważnie wykonujemy ją na zasadzie Wysoki, niski, brak. Bloker, krytyczny, niski itp. Dzisiaj chcę pokazać inne podejście które bardzo mi się podoba. Ta metoda jest nazywana przez inne mądre głowy jako MoSCoW.
Nazwa wzięła się od nazw priorytetów i połączenia ich literką „o” która nie ma żadnego znaczenia. Z założenia priorytetyzacja wykonana tą metodą ma zaprwnić jasno zrozumianą metodę priorytetyzacji przez każdą osobę która ma styczność z projektem. I moim skromnym zdaniem to działa bardzo dobrze.
Zanim jednak o priorytetyzacji to pragnę jedną zaznaczyć jedną rzecz bez której priorytetyzacja nie ma żadnego znaczenia. Zadania muszą być odpowiednio nisko zdekomponowane. Bez dekompozycji funkcjonalnej nie mamy co podchodzić do pirorytetyzacji bo zwyczajnie nam wyjdzie że cały projekt jest must have.
Na czym to dokładnie polega:
M czyli Must Have albo Minimum usable subset
Pierwsza duża litera opisuje priorytet który opisuje się jako zadanie bez którego dostarczenie projektu jest bez sensu bo nie spełniamy podstawowych potrzeb albo rozwiązanie przestanie być w jakikolwiek sposób lepsze od obecnego. Bez must have nie ma po co robić release projektu na produkcję. Jeśli jednak można zrobić taki release to takie zadanie wcale nie miało takiego priorytetu.
Should have
To są zadania które mają taki sam priorytet jak Must Have tylko jak ich nie wdrożymy w zakładanym terminie to teoretycznie będzie jeszcze istnieć bufor czasowy który pozwoli na ich dogranie po czasie terminu. Z Polskiego na nasze to spełnimy zapotrzebowanie w minimalnym stopniu a potem pogasimy pożary 😉
Could have
To są wymagania które opisujemy na zasadzie że fajnie żeby były. Są to zadania typu takich dzięki którym bardziej zadowolimy klienta z ich wykonania.
Want to have but won’t have this
Są to takie wymagania które chcemy zrealizować aczkolwiek mogą one poczekać. Dodajemy je z takim priorytetem aby pamiętać o tym że pewnego dnia mogą one w skoczyć w should have albo nawet w must have.