MoSCoW framework

Tvoříme obsáhlou knihovnu znalostí o produktovém vývoji jako součást naší mise. Knihovna slouží všem, kteří se snaží zlepšit v rozhodování, především v rozhodování o dalším rozvoji produktu. Ať už jsi vynálezce, produktový manažer nebo Chief Product Officer, používání určité rozhodovací metody zvyšuje šanci na vytvoření správných produktů a jejich funkcí pro správné publikum (build the right thing for the right audience). Dnes si představíme MoSCoW framework.

Název frameworku: MoSCoW.

Vynálezce: Dai Clegg.

Rok prvního použití: 1994.

Odkaz na původní autorův výzkum:

1. Kniha, Case Method Fast Track: A Rad Approach (Computer Aided System Engineering) (1994).

Důležité osobnosti v rozvoji frameworku:

1. Kurt Bittner,

2. Ian Spence,

3. Jennifer Stapleton,

4. Agile Business Consortium.

Důležité milníky v rozvoji frameworku:

1. Využití v modelování Use Cases, Use Case Modeling (2003),

2. Online Kniha, DSDM Atern Handbook,

3. Začlenění do Agile Business Consortium,

4. Akademický výzkum, Moscow Rules: A Quantitative Exposé.

Historie prvního použií

Dai Clegg vytvořil metodu MoSCoW za účelem prioritizace požadavků v prostředí, kde je přesně daný čas na vývoj. V tehdejším prostředí, kde měl projekt přesně stanovený čas na vývoj, se snažil najít metodu, která určí důležitost požadavků, jež má výsledný produkt obsahovat. Převážná část vývoje nových funkcí v 90. letech 20. století byla řízena projektově pomocí tzv. waterfall metody.  MoSCoW metoda umožňovala pružnější přístup k vývoji a zároveň dodržení původně stanoveného termínu uvedení produktu na trh.

Základní princip prioritizace

Základním principem prioritizace je vývoj funkcí podle jejich důležitosti v rámci omezeného rozpočtu reprezentovaného časem. Funkce jsou kategorizovány podle přínosu pro produkt jako celek a následně vyvíjeny.

Každá kategorie má přiřazený rozpočet v procentuálního zastoupení v celku. Původní rozdělení bylo stanoveno následovně: 60% Must Have, 20% Should Have, 20% Could Have a 0% Won't have.

Výsledný vývoj funkcí poté probíhá v tomto pořadí:

1. Must Have (česky „Musí být“) funkce,

2. Should Have (česky Mělo by být“) funkce,

3. Could Have  (česky „Může být“) funkce,

4. Won't have  (česky „Nebude“) funkce.

Začleněním do DSDM vznikla zcela nová agilní metoda, která určuje, jak prioritizovat požadavky uvnitř jednotlivých kategorií.

Přehled kategorií

Vývoj jednotlivých funkcí respektuje přesné pořadí stanovené kategoriemi. Čím dále se klasifikované funkce nacházejí od kategorie Must Have, tím menší je pravděpodobnost, že budou skutečně vyvinuty.

Must Have funkce

Tato skupina funkcionalit zaručuje, že produkt bude uveden na trh. Nazývá se také Minimum Usable SubseT (zkráceně MUST). Funkce spadající do této kategorie může hodnotitel identifikovat tám, že zjistí, zda funkce má následující kvality:

• Pokud funkce nebude doručena, nemá smysl uvést produkt na trh,

• Funkce je nezbytná z pohlede zákona,

• Funkce je nutná pro zajištění bezpečnosti,

• Funkce je nezbytná, protože bez ní není řešení funkční,

• Pokud hodnotitel na otázku „Co se stane, pokud funkce nebude doručena?“ odpoví „Vývoj produkt bude zastaven“, jedná se o funkci Must Have. Pokud však existuje alespoň nějaký postup (workaround), který může nahradit hodnotu dané funkce, jedná se spíše o Should Have kategorii.

Should Have funkce

Tato skupina funkcionalit umožňuje identifikovat funkce, které pomáhají zmírnit uživatelskou bolest (degree of pain) při používání finálního produktu. Uživatelská bolest se většinou měří podle potenciálního počtu zasažených uživatelů. Funkce spadající do této kategorie může hodnotitel identifikovat tím, že zjistí, zda splňuje některou z následujících charakteristik:

• Funkce je důležitá, ale není kritická pro daný produkt,

• Bez této funkce je používání produktu složité a bolestivé pro uživatele, ale neomezuje hlavní hodnotu produktu.

• Aby funkce fungovala, vyžaduje řízení očekávání uživatelů, změny v procesech, nebo obojí současně.

Could Have funkce

Tato skupina funkcionalit umožnuje identifikovat funkce,  které nejsou uživateli považovány za Should Have. Důležitý rozdíl mezi Should Have a Could Have je míra bolesti, kterou uživatel pociťuje v rámci finálního produktu. Funkce spadající do této kategorie může hodnotitel identifikovat tím, že zjistí, zda splňuje některou z následujících charakteristik:

• Funkce jsou obecně méně poptávané uživateli,

• Funkce mají jen malý dopad na tržby a profit společnosti.

Tato kategorie funkcí má nejvyšší pravděpodobnost, že nebude implementována, protože je poslední v pořadí priorit pro vývoj.

Won't Have funkce

Tato skupina funkcionalit je souhrnem všech ostatních požadavků, které by produkt mohl mít. Funkce v této kategorii nebudou vyvinuty, alespoň ne v rámci uvedení produktu na trh.

Ukázka prioritizace

Náš produkt je e-shop, který prodává bavlněné oblečení.

Must Have funkce

• Příkladem Must Have funkcí je obrázek prodávaného oblečení, možnost zadání dodací adresy, nebo zobrazení ceny a tlačítka nakoupit.

Should Have funkce

• Příkladem funkcí v této kategorii může být přiblížení (zoom) na obrázek prodávaného zboží, přidání zboží do oblíbených, nebo zvýraznění/topování produktů pro marketingové oddělení.

Could Have funkce

• Tato kategorie může obsahovat například dvoukrokový checkout pro rychlejší nákup nebo implementaci doporučování produktů pomocí personalizace.

Won't Have funkce

• Tato kategorie funkcí nebude vyvinuta jako součást nového produktu. Sem může například patřit věrnostní program pro uživatele e-shopu.

Vizuální ukázka prioritizace