Článek
Nejlepší digitální produkty jsou tvořeny, designovány a stavěny týmem, který se skládá z designéra, produktového manažera a tech leada. Designér zastupuje uživatele a přináší podněty k tomu, aby byl produkt co nejintuitivnější a co nejlépe se používal. Produktový manažer zastupuje byznys a stará se o to, aby produkt přinášel zisk. SW inženýr přináší technický pohled a stará se o to, aby byl produkt spolehlivý, stabilní a schopný vývoje. Společně se nazývají produktové trio.
Jak se práce na digitálním produktu vyvíjela
Tak tomu ale nebylo vždy. Kdysi většina týmů fungovala výhradně tak, že se soustředili jen na vývoj nových funkcionalit a produktů. Na discovery fázi nebyl kladen téměř žádný důraz. Dělala se možná jednou ročně (spolu se zveřejněním nových funkcionalit), kdy se vyspecifikovaly konkrétní plánované projekty (nejčastěji na základě zadání managementu) a ty se přidělily vývojovým týmům. Takové týmy ale narážely na to, že vývoj mnohdy nestíhal deadliny, přesáhnul rozpočet a zákazníci nebývali s výsledky spokojeni (což se však zjistí až na konci celého procesu).
Tým vývojářů nebyl spokojen s tehdejším stavem v delivery týmech. Přišel s tzv. Agile manifestem, kde požadovali kratší vývojové cykly s častější zpětnou vazbou od zákazníků. Zároveň chtěli udržitelnější pracovní tempo místo spěchu za dalším milníkem. Dále chtěli větší flexibilitu v rámci reagování na zpětnou vazbu od zákazníků. A na závěr požadovali jednoduchost – nechtěli vyvíjet produkty, které se nakonec nepoužijí, místo toho chtěli, aby se více vykreslovalo, co se bude vyvíjet ak tomu byl kladen větší důraz. Na základě toho vznikly dnes asi nejčastěji používané modely Scrum a Kanban.
Stále se ale naráželo na problémy. Například majitelé či manažeři měli problém vzdát se svých původních nápadů, i když se neshodovaly se zpětnou vazbou od zákazníků nebo šly zcela proti ní. Zároveň se na kratší cykly adaptovaly jen vývojové týmy a ne celé organizace, což neposkytovalo dostatečný prostor pro flexibilitu. Zákazníci přicházeli do procesu až na závěr při testování použitelnosti. A týmy byly hodnoceny na základě toho, co vytvořili a ne toho, jestli to někdo reálně používal.
V současnosti jsou ty nejvyspělejší týmy ve fázi, kdy přichází rozhodování o tom, co vyvíjet, na základě spolupráce celého produktového týmu. Zákazníci jsou zapojeni do celého procesu a nevidí produkt až na konci. Nejčastěji jsou přímo na začátku a pomáhají s vývojem produktu již svými nápady a potřebami. Tak vlastně Continuous Discovery vzniklo.
Co to vlastně je Continuous Discovery?
Oficiální definice Continuous Discovery zní: Minimálně každý týden kontakt se zákazníky a týmem, který buduje produkt. Probíhají tak malé výzkumné aktivity ve snaze dosáhnout požadovaného cíle.
Jeho nesporné plusy při zavedení do organizace jsou tyto:
- detailní zjištění potřeb, obav a cílů zákazníků,
- byznysové cíle budou v souladu s požadavky zákazníků,
- vývoj se bude věnovat skutečně tomu, co zákazníci chtějí (nebudou se vyvíjet nepotřebné věci),
- stakeholdeři budou zainteresováni do celého procesu a budou chápat, proč se produkt vyvíjí tak, jak se vyvíjí,
- neustálé obnovování si znalostí o klientech,
- ušetření času a finančních zdrojů tím, že se věnujeme správným oblastem ve vývoji.
Jako každý model i Continuous Discovery má však některé nevýhody:
- náročnější proces adaptace ve firmách orientovaných na delivery proces,
- náročné dostat na svou stranu vedení firmy, pokud není dostatečně vysvětlena přidaná hodnota,
- nutnost do procesu zaškolit celý tým a detailně mu vysvětlit, jak proces funguje a jaké výhody v něm spočívají.
Jak s ním v organizaci začít?
Je důležité definovat cíl tak, aby vyhovoval byznysu, ale aby se zároveň soustředil na zákazníka a na základě řešení jeho potřeb, pain pointů či tužeb byl splněn i byznysový cíl.
Ideálně tedy mají začít tím, že definují produktový cíl. Následně definují problém pomocí příležitostí. Na závěr k vybraným příležitostem vymýšlejí řešení. K tomuto zobrazení je nejvhodnější používat tzv. Opportunity Solution Tree, viz. vizualizace. Tento strom by ale tým neměl vytvořit jen jednou na začátku celého procesu, měl by jej kontinuálně upravovat, doplňovat a měnit.
Strom pomáhá dělat průnik mezi byznysovými a zákaznickými požadavky a to tak, že příležitosti se nahlížejí z pohledu zákazníka, ale produktové trio by mělo následovat jen ty příležitosti, které podporují byznysový cíl.
Na problém by se produktové trio mělo dívat přes potřeby uživatelů, které je nutné primárně vyřešit. Také je nutné, aby se nezastavili u prvního řešení, protože nemusí být to nejlepší. Namísto toho se musí snažit vygenerovat těch řešení více a teprve potom vybrat to nejvhodnější.
Zároveň je nutné činit malá rozhodnutí často a podporovat je experimenty – díky tomu bude možné tato rozhodnutí vzít zpět a nespálit se natolik, jako bychom udělali jedno obrovské rozhodnutí, ve kterém už musíme pokračovat, i když později zjistíme, že je nesprávné (například kvůli vynaloženým nákladům).
Po zjištění toho, že nějaký nápad nefungoval, je vždy nutné se zastavit a reflektovat z jakého důvodu. Co jsme špatně pochopili ohledně uživatelů nebo jaké naše předpoklady byly nesprávné, že jsme na základě toho vytvořili toto řešení. Jinak budeme vždy jen hádat, co by fungovat mohlo a co ne.
Není nutné při tvorbě stromu postupovat jen od cílů k řešením, může to být i naopak. Na základě experimentů při řešeních si můžeme upravovat příležitosti a těmi pak ovlivňovat cíle.
Tímto článkem jsme ukončili minisérii o Product Discovery. Pokud vás toto téma zajímá, můžete mrknout na naše další články nebo si poslechnout náš podcast s Michalem Vojákem. Případně si rovnou vyzkoušet nástroj UserUP, který vám s Product Discovery pomůže.
Zdroje
Teresa Torres – Continuous Discovery Habits
Podcast