Stanovení priority

Podle Mitch Lacey.Vlastník, Mitch Lacey & Associates, Inc., konzultační společnost se specializací na zavádění účelných vylepšení a vylepšení typu scrum.

Leden 2012

V tomto článku se Mitch Lacey zabývá třemi metodami, které se ukázaly jako velmi přínosné pro mnoho týmů Agile: model Kano spokojenosti zákazníků, řada inovačních her od Luke Hohmanna a relativní model vážení od Karla Weigerse.Kterákoli z těchto možností vám pomůže přejít od hrubého stanovení priorit pro nevyřízené položky k přesnému pořadí, které uspokojivě zváží riziko, důležitosti a spokojenost zákazníka.

Platí pro

Správa životního cyklu aplikací; server Team Foundation Server

V tomto článku:

• Úvod

• Model Kano spokojenosti zákazníka

• Inovace hry

  • Vyřazení stromu produktu

  • Koupit funkci

• Relativní důležitost – Karl Weigers

• Závěr

Pokud chcete zachovat efektivní fungování týmu, musíte určit pořadí rezervních položek produktu podle priority a poté aktualizovat tyto priority v průběhu projektu.Pro nevyřízené položky všech produktů musí být stanoveny priority na základě obchodní hodnoty a rizika.Dodržováním tohoto pořadí priorit se může tým lépe zaměřit na funkce, které jsou nejpravděpodobnějším faktorem pro úspěch produktu.Uspořádané a prioritizované nevyřízené položky vyplatí nejen ve spokojenosti týmu a zákazníka, ale také v celkovém výsledku vašeho podniku.Další informace o nahromaděných položkách naleznete zde: Vytváření a správa produktu Nevyřízené položky, Vytvoření nebo přidání do nevyřízených položek produktu a Správa a odhadování nevyřízených položek.

Při objednávání a prioritizaci rezervních položek produktu je třeba vzít v úvahu mnoho faktorů a také zvládat zdůvodnit svá rozhodnutí.Při zahájení s čistou produktovou zálohou se může proces jevit téměř náročný.Naštěstí nemusíte okamžitě dokonale seřadit všechny své nevyřízené položky.V sekci Odhad, popisuji techniku zvanou „Velká stěna“. Jedná se o efektivní způsob, jak rychle odhadnout množství nezpracovaných zakázek a spolupracovat se zúčastněnými stranami při hrubém přidělování priority.

Toto hrubé nastavení priorit je vhodným výchozím bodem a může být dostačující za vašich okolností.V některých případech však můžete chtít zpřesnit tyto priority nebo určit prioritu backlogu více vědeckým způsobem.Toto lze provést také pomocí řady technik.V následujícím článku popisuji tři metody, které se ukázaly jako velmi přínosné pro mnoho týmů Agile: model Kano spokojenosti zákazníků, řadu inovačních her od Luke Hohmanna a relativní model vážení od Karla Weigerse.Kterákoli z těchto možností vám pomůže přejít od hrubého stanovení priorit pro nevyřízené položky k přesnému pořadí, které uspokojivě zváží riziko, důležitosti a spokojenost zákazníka.

Model Kano spokojenosti zákazníka

Model Kano spokojenosti zákazníka byl navržen v roce 1980 profesorem Noriaki Kano na univerzitě Rika v Tokiu.Jeho model poskytuje schéma jednoduchého hodnocení, které rozlišuje mezi základními a rozlišovacími atributy.Přístup založený na dotazech: model představuje efektivní způsob pro znázornění vlastností produktu a vyvolání diskuze v rámci týmu designerů.

V Kano můžeme položit řadu otázek ve dvou různých formách: funkční a nefunkční.Například, řekněme, že se ptáme zákazníků na navigační systém GPS pro automobily.Nejprve se ptáme dotazem ve funkčním tvaru:

• Jak byste se cítili, pokud by toto auto mělo navigační systém GPS?

Omezujeme ohlasy na následující odpovědi:

• Tak by se mi to líbilo

• Čekal bych, že to tak bude

• Jsem neutrální

• Takhle bych to přežil

• Tak by se mi to nelíbilo

V tomto příkladu předpokládejme, že naši fiktivní zákazníci odpověděli „Mám to rád takhle.“

Dále se zeptáme nefunkční formou dotazu:

• Jak byste se cítili, pokud by toto auto nemělo navigační systém GPS?

Naši fiktivní zákazníci si mohou vybrat z kterékoli uvedené odpovědi.Odpověď však často může být, a obvykle je, jiná.Pro tento příklad si představme, že naši fiktivní zákazníci odpověděli „Očekávám, že to bude tak a tak“ do dysfunkčního formulářeotázky.

Když tento postup uplatníme pro aktuální projekt, můžeme tímto seznamem konfrontovat protichůdné otázky více skupin zákazníků, různé sady jednotlivců, kteří představují různé funkce v organizaci zákazníka.Pravděpodobně máte marketingovou skupinu, účetní skupinu, výrobní skupinu, atd.Pro účely pochopení modelu si představme, že se ptáme pouze na jednu otázku jedné skupiny klientů.Po kompilaci našeho páru odpovědí (odpovědi na funkční a nefunkční formulář) je namapujeme do mřížky, jak znázorňuje tabulka 1.

Tabulka 1 – mapování Kano

Všimněte si, že v našem příkladu fiktivní zákazníci odpověděli jako na funkční otázku a očekávají dysfunkční otázku.Když tento pár mapujeme do mřížky, je zřetelné, že průsečík těchto dvou atributů je E, jak znázorňují žlutě zvýrazněné čtverce.Prozkoumejme, co to znamená pro náš backlog s určenou prioritou.

• E = Budiče.Jedná se o funkce, které zákazník neočekával, a které skutečně liší produkt od konkurentů.Je obtížné je určit, zvláště zpočátku, kdy může být obtížné navrhnout otázky, které vyžaduje získání zajímavých funkcí.Z tohoto důvodu mají budiče tendenci zvyšovat svoji prioritu, jak projekt postupuje vpřed a začíná přicházet zpětná vazba zákazníka.

  • Zákazníkům tyto funkce přinesou vysokou spokojenost a zákazníci jsou ochotni zaplatit cenu navíc, aby je získali.Například, iPod od společnosti Apple potěšil zákazníky s jeho intuitivní možností otočení obsahu tak, aby odpovídal orientaci obrazovky.Absence funkce by snížila spokojenost, avšak protože zákazník nevěděl, že ji má očekávat.

  • V našem příkladu by použití GPS navigace bylo zajímavou funkcí.Zkoumání této funkce, alespoň do bodu obdržení názorů zákazníků, by mělo mít relativně vysokou prioritu.

• B = směrný plán.Tyto funkce musí být ve výrobku.Jsou nezbytnou, nejdůležitější funkcí.

  • Bez ohledu na to, jak dobře jsou provedeny tyto základní atributy, zůstane zákazník ve vztahu k produktu neutrální.Textový procesor musí mít například funkce „vytvořit dokument“ a „Uložit dokument“.Jsou vstupní cenou.

  • Pokud bychom se skupiny našich zákazníků zeptali ohledně bezpečnostních pásů, většina lidí by odpověděla, že očekávají, že nové auto bude dodáno s bezpečnostními pásy a že by se jim nelíbilo, kdyby to tak nebylo.Pokud bychom zmapovali tyto dvě odpovědi v grafu, zjistili bychom, že bezpečnostní pásy jsou minimálním požadavkem (B), bezpodmínečně vyžadovanou vlastností.

• L = lineární.Lineární funkce, rovněž označované jako funkční požadavky, korelují přímo se spokojeností zákazníka.Spadají pod základní funkce, ale jejich priorita musí být vyvážena s jejich náklady.

  • Lepší funkce nebo kvalita provádění zvyšuje spokojenost zákazníků.Snížená funkčnost vede k nižší spokojenosti.

  • Cena produktu často souvisí s těmito atributy.

• I = Lhostejný.Tyto funkce jsou pro zákazníka nejméně důležité a jako takové by měly být v produktu nejméně důležité.Pravděpodobně vrátí malou nebo žádnou obchodní hodnotu.

Tabulka 1 ukazuje také Q a R.

• Q: Sporný – otázka je pravděpodobně nesprávná nebo odpověď je podezřelá.

• R: zpětné – kombinaci odpovědí nelze vypočítat.Přijměte navigační systém GPS – pokud někdo odpoví, že očekávali jeho přítomnost, ale jeho nepřítomnost jim nevadí, jedná se o odpověď R.

Pokud je pár odpovědí je hodnocen Q nebo R, je třeba znovu a pečlivěji přezkoumat otázky a pár odpovědí.

Inovace hry

Inovation games (inovační hry) jsou nástroje, které přispívají k rozvoji primárního výzkumu trhu.Pomocí těchto hrají zákazníci „hry“ s cílem vytváření zpětné vazby a utváření názoru o produktu nebo službě.Luke Hohmann vytvořil více než 12 těchto her, které popisuje ve své knize Innovation Games, která je skvělým doplňkem jakékoli knihovny.Mé dvě oblíbené hry pro určení priority backlogu jsou Prune the Product Tree a Buy a Feature, které popisuje Luke v tomto výtahu z této knihy (použito se svolením):

Vyřazení stromu produktu

Zahradníci prořezávají stromy, aby tak ovlivnili jejich růst.Někdy bývá prořezávání umělecké a můžeme skončit u keřů ve tvaru zvířat nebo zajímavých abstraktních tvarů.Většinu času je čištění je určeno pro sestavení vyrovnaného stromu, který dává ovoce vysoké kvality.Proces není o „bourání“ – je o „tvarování“. Pomocí této metafory vytvořte produkt, který si zákazníci přejí.

Hra

Začněte kreslit velký strom na tabuli, řeznický papír nebo vytiskněte obrázek stromu jako velkoformátový plakát.Tlusté končetiny představují hlavní oblasti funkcí v systému.Okraj stromu – jeho nejvzdálenější pobočky – představují funkce dostupné v aktuální verzi.Zapište potenciální nové funkce na několik indexových karet, ideálně ve tvaru listů.Požádejte zákazníky, aby umístili požadované funkce kolem stromu, a definovali tak další fázi jeho růstu.Vytvářejí strukturu stromu, který roste vyrovnaným způsobem?Nastává u některé z větví, například základní funkce produktu, hromadný růst?Stává se méně využitý aspekt stromu silnějším?Víme, že kořeny stromu (podporu a infrastrukturu péče o zákazníky) je nutné rozšířit alespoň na úroveň vašich rozhledů.A vaše?

Produktový strom –Hohmann

Proč funguje

Vy i vaši zákazníci víte, že funkce se liší v závislosti na důležitosti.Proto typicky chceme umístit naše úsilí za nejdůležitější funkce – ty funkce, které poskytují zákazníkům nejvyšší hodnotu.Bohužel někdy to znamená, že vynakládáme příliš málo úsilí pro funkce, které jsou nezbytné k dokončení produktu.Prořezávání stromu hry produktu poskytuje vašim zákazníkům způsob vstupu do rozhodování s pohledem na sadu funkcí, které zahrnují provedení produktu holistickým způsobem.

Koupit funkci

Která funkce zákazníky přesvědčí zakoupit produkt?Které funkce přimějí zákazníky upgradovat?Které funkce uspokojí zákazníky natolik, že budou ignorovat nebo tolerovat funkce, které si přejí opravit nebo odstranit?

Plánovači produktu nepřetržitě kladou tyto a jiné otázky.Výběr správné sady funkcí pro přidání do vydání často představuje rozdíl mezi krátkodobým selháním nebo dlouhodobým úspěchem.Bohužel příliš mnoho plánovačů produktů provádí tuto volbu bez účasti osob, kterých se nejvíc týká – zákazníků.Nákup doporučené hry zlepšuje kvalitu tohoto rozhodnutí, když požádáte zákazníky s pomocí při něm.

Koupit funkci – Sterne

Hra

Vytvořte seznam možných funkcí a u každé uveďte cenu.Stejně jako v reálném produktu může být cena založena na nákladech na vývoj, hodnotě zákazníka nebo něčem jiném.Ačkoli cena může odpovídat skutečným nákladům, které chcete za funkci účtovat, není to obvykle nutné.Zákazníci kupují funkce, které v další verzi produktu požadují, pomocí fiktivních peněz, které jim dáte.Ujistěte se, že některé funkce mají dostatečně vysokou cenu, aby je žádný ze zákazníků nemohl zakoupit.Doporučte zákazníkům, aby peníze shromáždili na nákup zejména důležitých a/nebo drahých funkcí.Tím pomůžete stimulovat jednání mezi zákazníky o tom, které funkce jsou nejdůležitější.

Tato hra je nejvhodnější se čtyřmi až sedmi zákazníky ve skupině, takže můžete vytvořit více příležitostí pro investice jejich fondů skrze vyjednávání.Na rozdíl od hry Pole produktu, hra Nákup funkce je založena na seznamu funkcí, které by mohly mít takovýto plán rozvoje.

Proč funguje

Plánovači produktu často upadnou do pasti, když si myslí, že zákazníci jasně vymezili priority produktu.Některé mají.Většina ne.Pokud prezentaci pojmete jako sadu možností, mnoho zákazníků jednoduše prohlásí „Chci vše.“ a odpovědnost za stanovení priorit svých požadavků přenese na vaše ramena.Alternativně produktoví manažeři často shromažďují priority funkcí ve spolupráci se jednotlivými zákazníky a v průběhu, možná nevědomky, opět přebírají odpovědnost za stanovení priorit funkcí.Zapojením zákazníků jako skupiny a poskytnutí omezeného množství prostředků jim dáte příležitost k určení priorit svých požadavků jako skupiny.To však není podstatou.Kouzlo spočívá v uspořádání konverzací tak, aby zákazníci vyjednávali mezi sebou o specifických funkcích.Právě toto vyjednávání vám umožňuje lépe pochopit, co vaši zákazníci opravdu chtějí.

Relativní důležitost – Karl Weigers

Další vynikající metodou pro stanovení priority je relativní vážení, které Karl Weigers zavedl v roce 1999.Tato metoda poskytuje nejen mechanismus pro stanovení priorit požadavků založených na vstupu uživatele a jeho názorů, ale zahrnuje také posudek týmu.Jako u Kano a inovačních her umožňuje relativní vážení vlastníkovi produktu lépe měřit, které funkce má implementovat a v jakém pořadí priority.

Prvním krokem je přiřazení váhy k relativní výhodě funkce.Výhoda je výhodou pro uživatele, kteří mají k dispozici funkci v konečném produktu.Dalším krokem je přiřazení relativní sankce.Penalizace je následkem pro uživatele, kteří nemají k dispozici funkci v konečném produktu.(Vyhodnocení výhod a nevýhod má stejný vliv, jako funkční a nefunkční forma otázky podle metody Kano.) Váhy jsou libovolná čísla, která představují, jak společnost hodnotí prospěšnost a rizika funkce.Je to velmi podobné tomu, jak učitel určuje váhu domácích úkolů, docházky, testů a zkoušek při určování celkové známky. U jednotlivých učitelů se tento přístup může lišit.Pokud se rozhodnete, že výhody převažují nad sankcemi, zvyšte podle svého uvážení hmotnost nad sankci.Pokud se rozhodnete, že sankce převažují nad výhodami, upravte váhu odpovídajícím způsobem.V příkladu v tabulce 2 jsme přiřadili výhodě relativní váhu 2 a sankci relativní váhu 1, což znamená, že výhoda bude mít větší faktor při určování konečné priority.

Stejným způsobem můžeme určit váhu procentní části nákladů a rizik.V následujícím příkladu nebylo riziko pro projekt tolik významné, proto byla procentní části nákladů přidělena váha 1 a procentní části rizika váha 0,5.(Všimněte si, že ačkoli jsou výhody a nevýhody vyhodnoceny před výpočtem procentuální hodnoty, náklady a rizika jsou váženy jako procenta.) Pokud se setkáte s vysoce rizikovým projektem, může být riziko vyšší než náklady.

Nyní, když jsou nastaveny váhy, požádáme uživatele, aby ohodnotili relativní přínos a relativní nevýhody každé z funkcí.Každý přínos i sankce jsou hodnoceny podle stanoveného měřítka – Weigers doporučuje 1 až 9, ale můžete zvolit jiné měřítko, pokud je budete používat konzistentně.Relativní výhodou je hodnota, která bude poskytovat funkci; relativní penalizace je potenciální negativní dopad nevytvoření funkce.

Například, řekněme, že možnou funkcí je „Vytvořit aplikaci vyhovující zákonu Sarbanes Oxley." Nepředstavuje prakticky žádné relativní výhody pro uživatele, relativní obchodní sankce jsou značné - nevyhovění by mohlo společnost zruinovat.Takto můžeme vidět skóre 1 nebo 2 pro relativní výhody a skóre 8 nebo 9 pro relativní postih.

V následujícím příkladu uživatelé hodnotili relativní výhody funkce „Stav dotazu objednávky dodavatele“ hodnotou 5.Hodnotili relativní sankce jako 3.Chcete li odvodit celkovou hodnotu funkce, můžeme vynásobit dvě čísla podle jejich relativní váhy a sečíst je společně:

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

V tomto případě je celková hodnota funkce 13 bodů.

Když získáme celkovou relativní hodnotu a procentuální hodnotu funkcí, můžeme odhlédnout od uživatelů a získat přehled z pohledu týmu.Můžeme požádat tým, aby odhadl relativní náklady na implementaci jednotlivých funkcí pomocí stejného měřítka.Karl Weigers vysvětluje, že „Vývojáři odhadují náklady na základě faktorů, například složitosti požadavku, rozsahu požadované práce na uživatelském rozhraní, potenciální možnosti opakovaného použití stávajících návrhů nebo kódů a potřebné úrovně testování a dokumentace.

Jakmile odhadneme relativní náklady, provedeme odhad relativního rizika.Weigers opět říká: „Vývojáři odhadují relativní stupeň technického nebo jiného rizika souvisejícího s každou funkcí na stupnici od 1 do 9.Odhad 1 znamená, že jej můžete naprogramovat ve spánku, zatímco 9 označuje vážné obavy ohledně proveditelnosti, dostupnosti pracovníků s potřebnými odbornými znalostmi nebo použití nevyzkoušených či neznámých nástrojů a technologií.Tabulka vypočítá procento celkového riziko, které pochází z každé funkce.“

Jakmile zaznamenáme hodnoty pro relativní přínos, sankce, náklady a riziko, provedeme součet každého sloupce.Tyto součty se použijí k výpočtu procent.

• Celková procentuální hodnota: součet hodnot relativní výhody a sankce vydělte celkovým součet dole.V následujícím příkladu je to 13/154 = 8%.

• Relativní náklady v procentech: podělte hodnotu relativních nákladů celkovým součtem relativních nákladů ve spodní části.V následujícím příkladu je to 2/42 = 4.8%.

• Relativní riziko v procentech: podělte hodnotu relativních rizik celkovým součtem relativních rizik ve spodní části.V následujícím příkladu je to 1/33 = 3%.

• Priorita: Rozdělit podíl hodnoty (procento nákladů * hmotnost nákladů) + (procentuální hodnota * hodnota hmotnosti).V následujícím příkladu je to 8,4 % / ((4,8 % * 1) + (3 % * 0,5).Tím je určena hodnota priority (1,345).

Jakmile získáme hodnoty priority, seřadíme sloupec priority v sestupném pořadí tak, aby položky s nejvyšší prioritou byly nahoře.Při přidání položek do nevyřízených položek produktů nebo objevení dalších informací o článku musíme přehodnotit priority.

Nakonec, list vypadá jako tato tabulka:

Použitím tohoto přístupu můžete lépe pochopit rozsahy práce týmu a zapojených subjektů.Také poskytuje lepší podklad pro diskuse, protože může být obtížné objektivně zohlednit prvky, např. výhody, sankce, náklady a rizika pro každou funkci.

Weigers vysvětluje, jak vytvořit model, který více odpovídaly modelu vaší reality:

„Kalibrujte tento model pro vlastní použití pomocí sady dokončených požadavků nebo funkcí z předchozího produktu.Váhové faktory upravte, dokud vypočítané pořadí priorit nebude souhlasit s následným vyhodnocením toho, jak důležité požadavky v testovací sadě skutečně byly.Tento model může také pomoci při navrhování kompromisů, když vyhodnocujete navrhované nové požadavky.Odhadněte jejich priority pomocí modelu, abyste zjistili, jak odpovídají stávajícím požadavkům a mohli zvolit odpovídající sekvenci realizace.Všechny akce, které můžete provést pro přesunutí priorit požadavků z politické arény do objektivní a analytické oblasti, zlepší schopnost projektu poskytnout nejdůležitější funkce v nejvhodnější sekvenci.“

Karl Weigers napsal dvě knihy, které se podrobněji zabývají relativním vážením: Software Requirements, druhé vydání a More About Software Requirements: Thorny Issues and Practical Advice.

Používáte-li jednu z těchto metod nebo některé jiné techniky, nezapomeňte, že záloha produktu je živý organismus.Priorita není nastavována jednorázově – změny jejího nastavení jsou očekávány jako součást údržby funkční zálohy.Pokud chcete zachovat plánovaný průběh projektu, musí neustále přehodnocovat příběhy, jejich význam projektu a jak ovlivňují nové informace rezervní položky.Je třeba vynaložit úsilí k udržení zájmu zúčastněných stran a zákazníků v celém projektu.Pamatujte si, že odhad položky je nezbytný při určování její priority.Nenechte nevyřízené položky zastarat a odumřít.Investujte čas a úsilí do zlepšování a pěstování vašeho backlogu – uvidíte výsledky, nikoli pouze konečný produkt, ale také výsledný zisk.

Viz také

Koncepty

Začínáme pracovat v týmu

Agilní plánování a iterací

Žádost a názory účastníky procesu pomocí týmový Web Access

Sledování práce a správa pracovního postupu

1. Požadavky na agilní software, Dean Leffingwell, Addison Wesley

   „Atraktivní kvalita a povinná kvalita“ Noriaki Kano, Quality JSQC, svazek14, č. 2, říjen 1984.Původní článek z Kano.

2. http://www.processimpact.com/articles/prioritizing.html