Sesbírali jste všechny požadavky, pečlivě je zapsali a diskutovali jste se zadavatelem jejich prioritu.

Výsledkem je pravděpodobně dlouhý seznam naprosto nezbytných požadavků v Excelu. Nyní se děsíte prioritizační schůzky, které se mají účastnit všichni stakeholdeři. Tušíte, že vás čeká dlouhá, neefektivní a obtížně řiditelná akce plná emocí, protože každý bude považovat své požadavky za nejdůležitější a nebude ochoten z nich slevit. Protože udělat to znamená, že nikdy nebudou dodány. Ale všechny požadavky se do rozpočtu projektu nevejdou. V tomto článku vám představíme dva nástroje, s jejichž pomocí tento nelehký úkol lze zvládnout. Výrazně vám v určování priorit pomůže, pokud budete mít požadavky uspořádané do impact mapy, jak jsme popisovali v minulém díle seriálu (IT systems 11/2016).

MoSCoW

Nejprve se podíváme na MoSCoW prioritizaci, jejíž přínos spočívá v zavedení jasné definice kategorií pro jednotlivé typy požadavků z pohledu jejich důležitosti pro výsledný produkt.

Metoda z prioritizace odstraňuje prvek osobních preferencí a nahrazuje jej posouzením vlivu realizace/nerealizace dané funkčnosti na použitelnost/přínos výsledného řešení.

Název prioritizační metody MoSCoW je odvozen z pojmenování jednotlivých priorit požadavků vytvářeného produktu/služby, které jsou seřazeny podle důležitosti:

Must Have – musí mít

Tyto požadavky představují tzv. Minimum Usable Subset (MUS), tedy minimální požadavky, které musí být projektem dodány. Pokud by tyto požadavky nebyly realizovány, projekt/ řešení jako takový by ztratil smysl. Pokud dokážete najít jiné řešení daného požadavku, byť i méně komfortní, jedná se o Should Have nebo Could Have požadavek. Přesunutí požadavku do kategorie Should nebo Could Have neznamená, že nebude dodán, ale pouze to, že dodání není zaručeno.

Doporučuje se, aby požadavky Must Have představovaly maximálně 60 % celkového plánovaného úsilí na projektu.

Should Have – mělo by mít

Požadavek, který je kritický a měl by být součástí řešení, pokud je to alespoň trochu možné. Tento požadavek je důležitý, ale ne kritický pro otázku ukončení či pokračování projektu. Může být nepříjemné tento požadavek vynechat, ale řešení přesto bude mít smysl (například se „pouze“ sníží uživatelská přívětivost). Tento požadavek může být v případě nouze realizován i dočasným nebo zástupným řešením, které může znamenat určitou neefektivitu, papírovou agendu atp.

V této kategorii by mělo být alokováno maximálně 20 % práce. Must Have a Should Have společně tvoří tedy maximálně 80 % předpokládaného úsilí projektu (z pohledu odhadů na začátku projektu/fáze).

Could Have – bylo by dobré, kdyby mělo

Požadavky označené jako Could jsou žádoucí, ale nikoliv nezbytné. Většinou pomáhají zlepšit uživatelskou přívětivost nebo spokojenost zákazníka s minimálními náklady na vývoj. Tyto požadavky jsou typicky realizovány v případě, že na ně zbyde čas v rámci daného časového okna.

Could Have požadavky tvoří zbylých 20 % práce a představují buffer pro případ, že vše nepůjde, jak jsme plánovali. Zavedení tohoto bufferu hned na začátku nám dává možnost riziko rozsahu řídit operativně a bez zbytečných průtahů.

Won’t Have this time – zatím nebude mít

Požadavky, u kterých bylo odsouhlaseno, že jsou pro současné časové okno mimo rozsah. Je potřeba rozlišit požadavky, které budou brány v úvahu pro další časové okno a které by měly být vyřazeny trvale.

Tipy pro úspěšnou MoSCoW prioritizaci

• Na začátku projektu jasně definujte, co pro daný projekt znamenají jednotlivé priority – společně, celý tým.
• Používejte všechny kategorie priorit.
• Diskutujte o nezbytnosti Must Have požadavků – pamatujte, pokud existuje workaround, nejde o Must Have požadavek.
• Řiďte celkový počet Must Have požadavků.
• Pokud jste si z požadavků sestavili impact mapu, pak ji používejte jako podpůrný nástroj pro diskuse – ukazujte si, jaké dopady, zákazníky a cíle daný požadavek podporuje a jaké budou dopady, pokud bude realizován v omezené funkčnosti, atd.
• Používejte prioritizaci pro cokoliv – pomůže to k lepšímu pochopení a procvičení principu prioritizace, která se tak stane běžnou součástí každodenních činností týmu.
• Prioritizaci provádějte co nejvíce vizuálně – doporučujeme pro každou oblast MoSCoW nalepit na zeď jeden flipchart a na něj lepit jednotlivé požadavky napsané na samolepicích papírkách (pro agilní projekty epics/user story). Toto funguje nejlépe tak, když papírky lepí zadavatelé a při jejich umísťování vysvětlují, jak požadavek naplňuje domluvená kritéria pro zařazení.
• Společně diskutujte o tom, jestli vám tento způsob prioritizace a nastavená kritéria vyhovují, a případně je po dohodě upravte.
• Výsledné priority zaneste do impact mapy a zvažte, jestli není třeba upravit kritéria dopadů nebo cílů projektu.

KANO model – spokojenost zákazníka vs. funkčnost

KANO model přináší do procesu prioritizace prvek spokojenosti/nadšení zákazníka a více tak akcentuje emoce spojené s jednotlivými vlastnostmi produktu nebo služby. I proto je důležité KANO model používat pro prioritizaci funkcí, které mají cílovému zákazníkovi přinést nějaký jasný benefit. Ve svém článku „Attractive Quality and Must-Be Quality“ z dubna 1984 Dr. Noriaki Kano a kolegové uvádějí, že z hlediska zákazníka není každý požadavek stejně významný.

Jednotlivé požadavky (funkčnosti) lze rozdělit do následujících kategorií: 

• Tahoun (Performance) – klíčová vlastnost (funkčnost), u které platí, že čím bude lepší, tím spokojenější bude zákazník. Na druhou stranu čím vyšší výkon (zákazník dostane více, lepší parametry…), tím větší jsou náklady. Příklad: rychlost internetového připojení, životnost baterie notebooku, celkový počet kilometrů, které auto ujede na plnou nádrž).
• Základ (Must-be) – funkčnost, kterou potřebujeme (MUST BE). Pokud by chyběla, zákazník by produkt považoval za nehotový, nebo jednoduše nepoužitelný. Tedy, pokud by základní funkčnost chyběla, zákazník bude nespokojený. Ale bez ohledu na to, jak skvělá bude tato oblast, vyšší spokojenost zákazníka nepřinese. Z hlediska nákladů tedy postačí, když ji dodáme v běžném rozsahu. Pokud se v této oblasti budeme snažit o zásadnější inovaci, jen zbytečně propálíme čas a peníze. Příklad: očekáváme, že z mobilního telefonu půjde uskutečnit hovor, auto bude mít brzdy a v hotelovém pokoji bude postel a tekoucí voda.
• Lákadlo (Attractive) – typicky inovativní věc, která, pokud se udělá pořádně, tak ji budou všichni milovat. Ale pozor! Časem se z lákadla stává základ. Je potřeba také ohlídat množství investovaných nákladů, protože po dosažení určitého bodu jsou další investice již zbytečné, jelikož míra nadšení je už tak jako tak dostatečně veliká. Je zde také riziko investice do něčeho, co za lákadlo považuje jen realizační tým, nikoliv zákazník. Příklad: Ještě před pár lety byla dostupnost wi-fi na hotelovém pokoji vnímána jako příjemný nadstandard. Nyní to spíše očekáváme, či jsme rozladěni, pokud chybí. Podobně vnímáme dotykové ovládání telefonu, mobilní bankovnictví apod.
• Neutrální (Indifferent) – funkčnost, která je zákazníkovi více méně lhostejná, bez ohledu na to, jak moc do ní investujeme. Je tedy potřeba dávat si pozor a neutopit zde zbytečně peníze. Příklad: Většině zákazníků je patrně lhostejné, zda na pokoji v hotelu má běžný ručník, nebo ručník s vyšitým logem hotelu. Stejně tak je koncovému zákazníkovi lhostejné, zda jako podkladovou technologii pro svůj e-shop využijete standardizované řešení za pár korun, nebo si necháte vyvinout systém na míru.

Vztah mezi mírou spokojenosti a rozsahem funkčnosti (ekvivalentní velikosti investice, kvality, propracovanosti) zachycuje obrázek 1. 

Obr. 1: Graf zjednodušeně znázorňuje vztah mezi mírou spokojenosti a rozsahem funkčnosti (ekvivalentní velikosti investice, kvality, propracovanosti).

Praktické použití KANO modelu

Výhodou KANO modelu je možnost použít ho formou dotazníkového šetření. To je ideální pro sběr zpětné vazby od většího množství zákazníků. Použití KANO modelu jako dotazníku zahrnuje čtyři základní kroky.

1. krok

Sesbírejte požadavky zákazníka a zaznamenejte je (například formou backlogu), zaznamenejte všechny požadavky, které budou předmětem ověřování.

2. krok

Pro každý požadavek vytvořte dvě otázky (pozitivní a negativní) pro ověření konzistence odpovědi a odstranění schematického uvažování:

• První otázka je pozitivní a ptá se na to, jak by zákazník vnímal, pokud by jeho požadavek BYL naplněn.
• Druhá otázka je negativní a ptá se na to, jak by zákazník vnímal, pokud by jeho požadavek NEBYL naplněn.

3. krok

Z otázek sestavte KANO dotazník – zaznamenejte dvě otázky k požadavku do dotazníku dle příkladu:

• Označte odpověď zákazníka do tabulky. V našem případě zákazník odpověděl, že služba musí být aktivní do 24 hodin po aktivaci a nelíbí se mu, pokud by to bylo více.
• Přeneste odpovědi do vyhodnocovací tabulky a vyjde vám, že požadavek spadl do kategorie Základ. 

Tab 1: Příklad otázek v KANO dotazníku

Tab. 2: Vyhodnocovací tabulka pro odečtení kategorie požadavku. LEGENDA: Z – základ, T – tahoun, L – lákadlo, ? špatná odpověď (nedává smysl), N – Neutrální (bez preference), R – reverse (zákazník chce opak toho, co nabízíme)

Jak je patrné, negativní otázka slouží v KANO modelu jako kontrola konzistence odpovědi. Kombinace odpovědí na pozitivní i negativní otázku pomáhá určit typ požadavku. V případě, že získáte větší množství odpovědí vyhodnocených jako ?, je pravděpodobné, že zákazníci nerozumí tomu, co jim nabízíte. V takovém případě se zamyslete nad změnou prezentace vaší nabídky (popisu funkčností).

4. krok

Seskupte odpovědi od jednotlivých zákazníků tak, abyste byli schopni vyhodnotit, do které kategorie požadavek přidělit celkově. Z výsledků v tabulce je patrné, do jakých kategorií jednotlivé požadavky patří. V případě stejných nebo velmi podobných výsledků preferujte kategorii více vlevo. 

Tab. 3: Z tabulky shrnující seskupené odpovědi vyplyne, do které kategorie požadavek přidělit.

Jak dále pracovat s požadavky v kategoriích

Poté, co se nám podařilo požadavky seskupit, postupujeme v tomto pořadí:

• Základ – Tyto požadavky je zapotřebí standardním způsobem naplánovat a co nejjednodušším způsobem vyrobit. Hlídáme si přitom, abychom do nich neinvestovali příliš mnoho financí a času. Snažíme se o přístup good enough quality.
• Tahoun – Tyto požadavky jsou citlivé na perfektní provedení. Je proto vhodné naplánovat několik prototypů pro maximalizaci výsledného efektu a včasného odhalení slepých uliček. Je také vhodné pravidelně vyhodnocovat postup a hodnotit výsledky. S naplněním těchto požadavků úspěch projektu stojí a padá. Jedná se totiž o oblast, která generuje benefity projektu.
• Lákadlo – U požadavků v této kategorii je nutné především důsledně posoudit rizika. Může jít o skvělý inovativní nápad, ale také o myšlenku, kterou dosud nikdo nezrealizoval z poměrně dobrých důvodů. Doporučujeme prototypovat a až po úspěchu prototypů uvažovat o větších investicích.
• Doplněk – Pokud do této kategorie zákazník sám požadavky zařadil, pravděpodobně bude ochoten danou věc vyškrtnout, a ušetřit tím čas i peníze. Na těchto funkcích pracujeme, teprve pokud je potřebujeme pro něco, co nemá dopad na zákazníka.

V praxi se nám také osvědčilo použít KANO model ve velmi zjednodušené podobě jako facilitační nástroj pro diskusi. Pro tento případ jsme zvolili diagram KANO modelu zachycující vztah mezi mírou spokojenosti a rozsahem funkčnosti (viz obrázek) a do něj jsme na základě diskuse v týmu umisťovali požadavky napsané na samolepicích papírcích. Přínosem byla vizualizace a možnost posoudit význam a vzájemný vztah požadavků na základě jejich relativního rozmístění v ploše diagramu.

Shrnutí

Představili jsme si dvě prioritizační metody, každou vhodnou pro trochu jinou situaci. Zatímco metoda MoSCoW umožní lépe moderovat diskusi o skutečných prioritách požadavků z hlediska jednotlivých skupin stakeholdera a je jednodušší na použití, KANO model nabízí postup pro vyhodnocení i značně komplexního zadání, včetně zohlednění dopadů do zákaznické spokojenosti.

http://bit.ly/evamachackova http://bit.ly/zdenekmachacek

Eva a Zdeněk Macháčkovi Autoři článku pracují jako konzultanti ve společnosti Principal engineering. Zaměřují se na strategické poradenství a vzdělávání v oblasti nových trendů businessu a podnikového IT. Stojí také za zrodem projektu www.agileware.eu, který má za cíl zpřístupnit metody a nástroje pro efektivnější práci a úspěch projektů.