Díl třetí: Jak uřídit priority na (nejen agilních) projektech

Screen Shot 2017-06-22 at 10.54.09V časopise IT Systems jsme publikovali seriál šesti článků se zajímavými tipy a nástroji IT manažera. Nyní pro vás přinášíme i na našem blogu.

Článek vyšel v časopise IT Systems 12/2016. Zde si můžete stáhnout PDF.

Řízení priorit požadavků je základní dovedností pro udržení rozsahu projektu, dodržení rozpočtu a časového rámce. Priority ve vazbě na spokojenost zákazníka umožní také dodat správný produkt za přijatelné peníze. V tomto článku vám představíme dvě praktické metody, jak priority uřídit. Bavit se budeme o metodě MoSCoW a KANO modelu.

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 jsem 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é funkcionalitě, 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 samolepící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. funkcionalita

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 pro to 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 (funkcionalita), 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)– funkcionalita, 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) – funkcionalita, 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 funkcionality (ekvivalentní velikosti investice, kvality, propracovanosti) zachycuje následující obrázek.

 Screen Shot 2017-06-22 at 10.57.30

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ů.

4 kroky použití KANO modelu jako dotazníku:

  1. Sesbírejte požadavky zákazníka a zaznamenejte je (například formou backlogu)
  2. Pro každý požadavek vytvořte dvě otázky – pozitivní a negativní (viz níže)
  3. Z otázek sestavte KANO dotazník
  4. Výsledky interpetujte a vytvořte KANO vyhodnocovací tabulku.

Nyní se podíváme na jednotlivé kroky blíže.

  1. Formou backlogu zaznamenejte všechny požadavky, které budou předmětem ověřování
  2. Pro každý požadavek vytvořte dvě otázky pro ověření konzistence odpovědi a odstranění schématického uvažování
    1. 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
    2. 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. Zaznamenejte dvě otázky k požadavku do dotazníku dle příkladu
    1. 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 24hodin po aktivaci a nelíbí se mu, pokud by to bylo více.
    2. Přeneste odpovědi do vyhodnocovací tabulky a vyjde vám, že požadavek spadl do kategorie Základ.

Screen Shot 2017-06-22 at 10.58.47

Vyhodnocovací tabulka pro odečtení kategorie požadavku

Screen Shot 2017-06-22 at 10.58.57

 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í).

  1. 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.

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 proto typovat 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 funkcionality (viz obrázek) a do něj jsme na základě diskuse v týmu umisťovali požadavky napsané na samolepící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.

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.

Zanechat Odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

WordPress.com Logo

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit /  Změnit )

Google+ photo

Komentujete pomocí vašeho Google+ účtu. Odhlásit /  Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit /  Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit /  Změnit )

w

Připojování k %s