Produktové nevyřízené položky jsou primární součástí agilního vývoje produktů organizace, protože obsahují položky, které musíte řešit v konkrétním bodě.
Vytvoření nového produktu začíná myšlenkou, která týmu umožňuje vybudovat něco speciálního. Dokonce i iPhone nejprve přišel jako prototyp a díky jejich specializovanému týmu si udělal cestu k popularitě.
Při řízení týmu musíte jako produktový manažer zůstat organizovaný se seznamy důležitých úkolů. No, není to tak snadné, jak se zdá.
Udržování seznamu úkolů a rozhodování, který z nich udělat jako první, je velmi obtížný úkol. A když existuje více zúčastněných stran, stává se to ještě více ohromující.
V důsledku toho organizace ztrácí mnoho času a zdrojů.
To je místo, kde stanovení priority produktů zjednodušuje všechny úkoly a pomáhá vám správně udržovat seznam úkolů.
V tomto článku podrobně rozeberu produktový backlog, jeho typické prvky, výhody a další.
Table of Contents
Co je produktový backlog?
Produktový backlog je seznam prioritních funkcí nebo pracovních položek, které vám pomohou splnit vaše produktové cíle a nastavit platná očekávání mezi vývojářskými týmy. Jednoduše řečeno, každý produkt ve fázi vývoje má vyhrazený produktový backlog.
Podobně má každý produktový backlog vyhrazený tým. Obecně existuje několik nevyřízených produktů s několika týmy pracujícími na větším produktu.
Pojmenujme například větší produkt jako „Produkt“ a menší produkty jako „Produkt A“, „Produkt B“ a „Produkt C“. Produkt A, produkt B a produkt C mají svůj vlastní produktový backlog a konkrétní týmy pro vývoj. Každý určený tým pracuje na menších produktech, aby nakonec vytvořil větší produkt.
Lze jej tedy definovat jako prioritní seznam práce, který je odvozen z plánu produktu a jeho požadavků na váš vývojový tým. Nejdůležitější položky jsou v horní části nevyřízené položky, aby vývojové týmy věděly, kterou z nich dodat jako první.
Produktový backlog je však živý dokument, který umožňuje produktovým manažerům lépe porozumět typickým problémům a řešením potřebným k dodání produktu.
Kdo upřednostňuje nevyřízené položky?
Produktový backlog je ve vlastnictví produktového vlastníka nebo produktového manažera. Vlastník produktu je zodpovědný za údržbu nevyřízených položek, zatímco ostatní členové týmu přispívají svým úsilím a časem k vývoji produktu.
Primárním účelem produktového backlogu tedy může být:
- Vytváření základny pro sladění týmů a zainteresovaných stran tak, aby vývojové týmy implementovaly cenné příběhy uživatelů
- Nabízí flexibilitu pro přizpůsobení se realitě a potřebám
- Zvýšení efektivity předpovědí uvedení produktu pomocí společného jmenovatele napříč různými týmy, aby se držely pohromadě u jednoho produktu.
Typické prvky produktového backlogu
Produktový backlog zahrnuje opravy chyb, funkce, získávání znalostí a technické dluhy. Tyto položky jsou samostatnými kusy hlavní práce, které bylo třeba dodat pro dokončení produktu.
#1. Oprava chyb
Vady a chyby jsou problémy, které jsou objeveny koncovými uživateli a které unikají během procesu kontroly kvality. Pokud chyby nejsou vyřešeny včas, mají tendenci se časem hromadit.
Váš tým řeší opravy chyb rychle, aby byla zachována integrita produktu. Některé chyby jsou natolik zásadní, aby přerušily aktuální sprint týmu, zatímco jiné mohou čekat na další sprint. Zůstává na vrcholu produktového backlogu, takže vývojový tým nikdy nezapomene na opravy chyb.
#2. Funkce
Funkce je funkce produktu, kterou uživatelé považují za hodnotnou. Je také známý jako uživatelský příběh. Funkce mohou být složité nebo jednoduché. Abyste však porozuměli potřebám uživatele, musíte vytvořit mapu příběhu.
Žádosti o nové funkce pocházejí z různých zdrojů. Mezi funkce patří správa produktů, podpora, prodej, koncoví uživatelé a další. Stanovení priority nových funkcí může být obtížné, protože budete muset vyvážit konkurenční požadavky:
- Udržování spokojených předchozích zákazníků
- Setkání s termínovými prodejními příležitostmi
- Práce na vyšší vizi produktu
Produktový manažer tyto zdroje sleduje a řeší konfliktní požadavky. Rutinní provádění vám umožní zajistit, aby produktový backlog měl nové funkce, které mohou přilákat zákazníky a učinit stávající zákazníky spokojenými.
#3. Získávání znalostí
Zde shromažďujete informace pro dokončení budoucích úkolů. Důležité je, že získávání znalostí je fází výzkumu. Když zjistíte funkci, která vyžaduje další výzkum, můžete vytvořit úkol získávání znalostí, jako je proof-of-concept, experiment nebo prototyp. To vám pomůže získat informace, abyste mohli začít pracovat na této funkci.
#4. Technické dluhy
Technický dluh je jako finanční dluh. Narůstá úrok, když dluh ignorujete. To se stane, když vývojáři posunou tuto fázi na konec nevyřízených záležitostí, pak je obtížnější ji dosáhnout.
Efektivní řízení produktového backlogu může zabránit technickému dluhu. Když váš vývojový tým zůstane organizovaný se seznamem a převezme technickou práci v denních nebo menších krocích, je méně pravděpodobné, že zaznamenáte zvýšený zájem o práci.
Technický dluh je výsledkem změny založené na následujících skutečnostech:
- Škálovatelnost a očekávání výkonu
- Rozsah a směr
- Technologie a osvědčené postupy
Produktové backlogy: Výhody
Produkt jistě představuje zpětnou vazbu z různých zdrojů, jako jsou prodejci, vývojáři a především uživatelé. Musíte být připraveni přijmout jejich zpětnou vazbu, spravovat ji, upřednostňovat ji a důkladně na ní pracovat pro budoucí dodávky produktů.
Bez správného procesu je vývoj vašeho produktu náročný. Dobře řízený a dobře zpracovaný backlog vám tedy pomůže soustředit se na produkt a povede k efektivnějšímu týmu.
Pojďme diskutovat o výhodách udržování produktového backlogu v organizaci:
- Vylepšené zaměření: Produktový backlog vám pomůže soustředit se na důležité úkoly a umožní vám vyhnout se rozptylování.
- Vylepšená efektivita: Upřednostňování položek zajišťuje, že váš tým na úkolech pracuje důkladně, což vede k lepší efektivitě.
- Lepší řízení rizik: Produktový backlog může identifikovat a řešit rizika v rané fázi vývojového procesu, díky čemuž je řízení bez rizika.
- Lepší spokojenost zákazníků: Spokojenost koncových uživatelů je vaším primárním cílem. Stanovení priorit nevyřízených položek je proto pro organizaci zásadní, aby byla spokojená tím, že zkontroluje, co je nutné přidat nebo odebrat z produktu, což z něj činí cenný produkt pro vaše uživatele.
- Lepší komunikace: Produktový backlog podporuje spolupráci a komunikaci mezi vaším týmem, což vede k lepšímu zaměření při vývoji produktu a lepším výsledkům.
- Vylepšená týmová morálka: Produktový backlog poskytuje týmu účel a smysl pro směr, což vede k lepší morálce.
- Podporuje flexibilitu: Produktový backlog se mění podle postupu vývojáře a rychlosti dokončení úkolů. Když se změní vývoj stavu produktu, produktový manažer znovu stanoví priority úkolů. Tato flexibilita je potřebná, aby se předešlo prostojům v pracovní době.
Kromě toho můžete najít spoustu výhod, jako je nejrychlejší návratnost vaší investice, vyšší spokojenost zákazníků, minimální rizika a další.
Jak vytvořit produktový backlog
Vlastník produktu má plnou odpovědnost za úkoly stanovení priorit. Chcete-li vytvořit dobře spravovaný produktový backlog, musíte provést následující kroky:
Krok 1: Přidání nápadů do produktového backlogu
Produktový backlog je seznam nápadů. Obsahuje prohlášení nebo zpětnou vazbu od členů týmu, zainteresovaných stran a zákazníků. Jednoduchým způsobem je potřeba přidat nápady do seznamu poté, co je prodiskutujete se zúčastněnými stranami, týmy a zákazníky o existujícím nebo novém produktu.
Zpočátku budete mít jen omezené nápady, ale během procesu vývoje získáte nové nápady, přičemž budete mít na paměti relevanci produktu na trhu a konkurenci.
Krok 2: Získání vysvětlení
Jakmile zúčastněná strana potřebuje nějaké změny ve vašem přidání nebo opravě produktu, je důležité si to předem vyjasnit. Vlastník produktu musí objasnit následující základní body, aby pochopil důležitost přidání:
- Důvod opravy: Udává, o jaký problém ve skutečnosti jde, jak byl způsoben a jak jej vyřešit.
- Hodnota, kterou přináší: Tým analyzuje, zda nový přírůstek pomůže přispět k celému produktu a zvýšit kvalitu. Přídavek musí zvýšit hodnotu produktu. Výsledkem je tedy zvýšení obchodní hodnoty a lepší návratnost investic.
- Specifikace položky: Specifikace musí být jasná z konce produktového vlastníka, aby vývojáři nikdy nenašli během procesu vývoje žádné potíže.
Krok 3: Stanovení priorit
Jakmile je vše v souladu, odpovědností produktového vlastníka je upřednostňovat nevyřízené položky od nejvyšší po nejnižší prioritu. Tato fáze je založena na strategické analýze informací. Dobře spravovaný seznam by mohl zlepšit komunikaci mezi různými týmy.
Vlastník produktu upřednostňuje nevyřízené položky na základě specifických kritérií:
- Výnosy: Jakákoli funkce nebo položka, která může vést k lepšímu příjmu, by měla být na seznamu s vysokou prioritou.
- Jedinečnost a oprava trhu: Pokud je funkce, kterou se rozhodnete přidat, na trhu jedinečná, pravděpodobně na trhu vyniknete. Také musíte zjistit, zda existující funkce může vyřešit problémy uživatelů, protože to je skutečný cíl.
- Složitost: Před upřednostněním nevyřízených položek je třeba zkontrolovat složitost navrhované funkce spolu s časem, který může trvat vývoj a vydání.
Krok 4: Pravidelně aktualizujte produktový backlog
Produktový backlog je živý dokument, který musí vlastník produktu včas aktualizovat. Proces zdokonalování, stanovení priorit a udržování nevyřízených položek v aktuálním stavu je nezbytnou součástí procesu vývoje.
Produktový backlog obsahuje mnoho nápadů. Budete muset upřesnit tyto myšlenky a vyřadit ty, které nejsou relevantní. V posledním kroku jsou nevyřízené položky upřednostněny a uspořádány podle úrovně priority.
Některé metody stanovení priorit
Existuje spousta metod, jak upřednostňovat nevyřízené položky. Pojďme diskutovat o několika z nich:
#1. Technika Moskva
Zdroj obrázku: StoriesOnBoard
MOSCoW je typ analýzy běžně používaný v produktovém managementu k pochopení toho, co je nezbytné udělat a co ne. Je to užitečná metoda pro komunikaci se zainteresovanými stranami o tom, na čem pracujete a proč.
Název zahrnuje čtyři kategorie priorit:
- Musí mít: Naprosto nezbytné požadavky
- Měl by mít: Funkce s vysokou prioritou
- Může mít: Možné funkce
- Nebude mít: Neimplementováno
„Musí mít“ představuje absolutní vlastnosti, které musí produkt obsahovat. Může to být z bezpečnostních, obchodních a právních důvodů. Za tímto účelem uveďte nejlepší a nejhorší scénář zahrnutí funkce do seznamu a nakreslete obrázek.
„Měl by mít“ označuje funkce, které mohou být zahrnuty, ale nejsou povinné.
„Mohl mít“ je pro položky, které lze přidat, pokud má organizace potřebné zdroje, ale není to nutnost k dosažení úspěchu.
„Nebudu mít“ neříká, že tato funkce již není vyžadována nebo že se jedná o položku v koši. Místo toho produktový manažer znamená „tentokrát ne“. Důvodů je několik, například nedostatek času nebo zdrojů.
#2. Eisenhowerova matice
Tato metoda je přímočarý způsob, jak správně řídit čas. Vznikl z rozhodovací matice Dwighta D. Eisenhowera. To se později změní na 4kvadrantovou vizualizaci, kterou lze použít k upřednostnění úkolů v seznamech nevyřízených položek.
Zdroj obrázku: ModelThinkers
Matice obsahuje dvě dimenze priority – důležitost a naléhavost. Tato technika vám umožňuje alokovat úkoly do čtyř částí matice, která obsahuje:
- S vysokou prioritou
- Střední priorita
- Naléhavé, ale důležité
- Nízká priorita
#3. Kano
Model Kano je jednou z vynikajících možností pro organizace, které hledají potěšení a spokojenost zákazníků. Produktových manažerů nevyřízených funkcí je nekonečný, ale chtějí vytvořit plán produktu s dokonalými funkcemi. Model Kano je robustní technika, která vede produktové manažery. Tato technika byla vyvinuta v 80. letech minulého století Noriaki Kano.
Tento model obsahuje tři prostory:
- Spokojenost, která odráží spokojenost zákazníků
- Reakce zákazníka závisí na vlastnostech a funkcích produktu
- Pocity zákazníků
#4. Vážená nejkratší práce jako první (WSJF)
WSJF je nástroj, který pomáhá vašim týmům stanovit priority seznamu iniciativ. Obvykle se tento nástroj používá v Scaled Agile Framework (SAFe). Tým spočítá skóre každé iniciativy vydělením nákladů na zpoždění velikostí nebo trváním úlohy. Položka, která získá nejvyšší skóre, je na horním seznamu jako vysoká priorita.
Jak spravovat nevyřízené položky
Dodržujte níže uvedené postupy, abyste zajistili správnou správu nevyřízených položek a udrželi své nevyřízené položky zdravé:
- Před jakýmkoli plánováním iterací zkontrolujte nevyřízené položky produktu, abyste se ujistili, že úkoly, které jste upřednostnili, jsou správné a že je také implementována předchozí zpětná vazba.
- Když se vaše nevyřízené položky zvětší, musíte položky kategorizovat na – krátkodobé nebo krátkodobé a dlouhodobé.
- Rozhodněte se, zda si položky ponecháte nebo je smažete podle jejich výhod
- Bez řádného plánování nepřidávejte žádné úkoly.
- Udělejte z tohoto procesu upřednostňování prioritu ve vaší organizaci.
Kromě toho můžete snadno změnit priority úkolů během procesu vývoje podle zpětné vazby od zákazníků. Kromě toho můžete předchozí prohlášení upřesnit a přidat nové požadavky.
Sprint Backlog vs. Product Backlog
- Produktový backlog uvádí všechny položky, které musí být dokončeny, aby byl proces vývoje v daném čase dokončen. Zatímco backlog sprintu zahrnuje položky z backlogu, které musí být dokončeny v rámci sprintu.
- Vlastníci produktů rozhodují o seznamech nevyřízených položek, zatímco vývojové týmy rozhodují o položkách nevyřízených sprintů.
- Produktový backlog je vytvořen na základě produktového cíle. Nevyřízený sprint se však zarovná s konkrétním sprintem.
- Produktový backlog se může v průběhu času měnit, zatímco backlog sprintu se po jeho nastavení nemění.
- Produktový backlog vyžaduje údržbu a zůstává až do dokončení projektu. Ale backlog sprintu nezůstane až do konce; končí to sprintem.
Závěr
Udržování produktového backlogu je základním krokem v procesu vývoje produktu. Poskytuje jasný přehled o probíhající práci, dokončené práci a vašich budoucích plánech. Je tedy načase, abyste vytvořili a udržovali efektivní produktový backlog a zůstali na vrcholu své hry.
Můžete také prozkoumat nejlepší software pro analýzu CFD a nástroje Scrum.