Trvalo to nějakou dobu, ale hlubší pochopení agilních principů probíhá už i na našem malém českém trhu. Po létech se mantra “stejný scope – stejní lidé s fragmenty kapacit – 10x rychleji” začíná rozpadat. Vedení firem začíná chápat, že agilní myšlení a řízení je o něčem jiném než o rychlém doručování features (rozuměj často balastu). Přichází pochopení, že přínos je ve vyřešení palčivých problémů klientů, za které jsou ochotni platit, ne v chrlení features, o kterých si my myslíme, že jsou super. A zde je nezastupitelná role schopných produktových rolí se znalostí discovery procesů, technik human-centred designu spolu s dovedností umět říkat NE na slabé nebo neověřené věci a vyhodnocování přínosů. Od agilních prvohor procesů a Scrum Masterů se dostáváme k podstatě, tedy druhohorám projeveným klientskou hodnotou a schopnými produkťáky. Konečně!
Na úvod jen zdůrazním, že druhohory by bez prvohor nevznikly. Nezpochybnitelná role agilních nadšenců ve firmách, schopných manažerů a samozřejmě agilních koučů / Scrum masterů umožnila pomocí dat a transparentnosti vytvořit půdu pro pochopení skutečných agilních principů – tedy udržitelné doručování skutečné hodnoty pro klienty i firmu místo rychlejšího doručování 127 paralelních projektů pochybné hodnoty (které samozřejmě nikdy paralelně neběžely). Odklon od velmi drahých plošných náletů na klienta formou mnoha features bez kontextu a hodnoty, je právě výsledkem skvělé práce výše zmíněných, typicky díky následujícím krokům:
● transparentnosti backlogů, cílů a roadmap (i když zatím často těch tradičních prvohorních ve formě feature-datum),
● snaze definovat a navázat sprint cíle na cíle firmy, ukazující jejich nesladění, velkou fragmentaci či nepochopení těch hlavních cílů (pokud v nich má management vůbec jasno a existují),
● častým demonstracím uživatelům (či jejich reprezentantům), které odhalují, že klient není, neznáme ho, nebo že nikdo o tu klíčovou strašně důležitou feature vlastně nestojí (kromě autora, který na demo ale také nepřišel),
● úpravě plánovacího procesu, který počítá s nejistotou a změnami (prostor v backlogu na ad hoc činnosti, změny, nová odhalení a discovery činnosti místo 100 % napráskaných hodin dle dopředných analýz)
● retrospektivám, které otevírají klíčové otázky (proč to musíme dělat? kdo to chce? proč nemáme čas na technický dluh současného řešení? proč se dozvídáme o této změně až nyní, když jsme realizační tým? proč má obchod úplně jiné cíle, které nám způsobují problémy?),
● práci na přebírání odpovědnosti a vlastnictví za věci a jejich obsah (u týmů) a jejich vzdávání se (u managementu),
● prokopávání komunikačních tunelů a rozbíjení informačních a organizačních sil,
● hledání udržitelnosti pracovního tempa a mentálního zdraví týmů – což třeba výše zmíněných 30 kolegů na 127 paralelních projektech opravdu neumožní…
V tomto článku se ale zaměříme na současnou evoluci v podobě agilních druhohor, tedy na roli produktového managementu a jeho činností v agilním vývoji, které vedou k lepšímu naplnění klíčových potřeb zákazníka vhodným řešením.
Od kobercového náletu features k řešení důležitých byznys problémů
Agilní přístupy pochopené jako vyšší efektivita a produktivita generují rychleji a více nepoužívaných a nechtěných věcí, což pro firmu nepřináší kýženou hodnotu a zisk. Naopak přináší vyšší náklady, komplexitu řešení a jeho náročnější údržbu a horší používání. Důsledkem takového (ne)pochopení agilních principů je vlastně přesný opak původního cíle.
Agilní myšlení nás má vést k pochopení problémů klienta (jejich validaci) a rychlému doručení první verze (její validaci), která je obsluhuje, řeší. Následuje měření dopadu a přínosu, sběr zpětné vazby a doručení druhé verze, která produkt dále vylepšuje. To je tzv. quick feedback-loop. Jde tedy o kombinaci správně identifikovaných palčivých problémů a jejich vhodným řešením pro daného klienta. Zde je nutné ještě dodat „s fungujícím byznys modelem“, jinak nemá takové podnikání dlouhodobou udržitelnost, jak vidíme například u mnoha opěvovaných startupů, které jen pálí peníze a fungující byznys model stále hledají.
Snižování rizika a nejasností
Cílem agilního procesu je snižování rizika, zda bude zamýšlená akce (ne nutně nová SW funkce) fungovat, jak očekáváme. Dosahujeme toho typicky následujícími kroky:
● Zadání a soustředění kapacit, pozornosti a dovedností ve firmě pomocí jasných priorit a měřitelných cílů (typicky OKR a outcome-driven přístupy).
● Rychlé a levné validování domněnek (např. rozhovor nebo experiment s prototypem je násobně rychlejší a levnější než vývoj funkce, která pak navíc v produktu zůstane, i když je nepoužívaná).
● Odhalování problémů určitého specifického segmentu, uživatelů včetně jejich specifických potřeb.
● Analýza dat o daném trhu, chování klientů, využívání existujících produktů (víte třeba, které funkce vašeho produktu nikdo nepoužívá a proč?).
● Společné hledání vhodného řešení za účasti více rolí v ýmu, včetně zástupců vývoje! Takové návrhy řešení, později i validované klientem, vypadají často jinak, než bylo v úvodu zamýšleno. Zapojení vývoje do hledání řešení pomáhá nejen navrhnout lepší varianty, ale také odbourává spousty nepochopení a předělávek, což je také výrazně levnější.
● Rychlé ale kvalitní vytvoření první verze (někdy často jen MVP v jiné formě, než je cílené skutečné řešení, nebo také manuální řešení bez střev) a jeho nasazení k užívání.
● Měření a vyhodnocení přínosů (tzv. rychlá zpětná vazba a učení).
● Rozhodnutí, zda bude následovat další iterace nebo zda tento přínos v dané oblasti prozatím stačí (a je třeba větší, než jsme předpokládali v úvodních hypotézách).
Akce s dopadem místo nekonečného vývoje
Potom akce, které volíme k naplnění cílů mohou být zcela jiného typu než nové funkce v produktu. Může jít o lepší komunikaci klíčové cílovce v její řeči. Může jít o novou kampaň již existujících funkcí k důležité potřebě klienta, o které ještě neví. Mohou to být dokonce odebrané funkce a zjednodušený produkt. Rychlost a cena těchto kroků, kdy nesaháme na produkt, pak může být zlomkem nových namyšlených funkcí s domněnkou, že toto jsou funkce, které chybí, aby konečně naši uživatelé začali produkt používat.
Je důležité si uvědomit, že digitální produkt není vlastně nikdy hotový, na rozdíl od fyzických produktů. Fyzický produkt musím dodělat, abych jej mohl začít používat a téměř vždy jasně vidím, kdy jsem s produktem hotový (viz. telefon, nábytek, auto, talíř). Naopak digitální produkt můžeme neustále rozvíjet mnoha směry, tím ale zvyšuji jeho komplexitu a ztěžuji používání. Riziko vytvoření velmi komplexního nepoužitelného molochu je zde tedy velmi velké, vzpomeňte si na SAP nebo hledání vaší oblíbené funkce v MS Office.
Klíč tedy leží v poznání, co má smysl dále rozvíjet, co naopak stačí a co vůbec není třeba. Přesně k tomu potřebuji znát klienta, jeho potřeby, chování, priority a způsoby rozhodování. Bez toho poznání jde o nesmyslnou a velmi drahou střelbu naslepo. Ne všechny potřeby musím řešit, za každé řešení také není klient ochotný platit. Najít hranici, co už stačí, co dál ladit a kde říkat rezolutní NE, je svatým grálem produktového managementu. Discovery, maximální transparentnost, měření používání produktu a dopadů, rychlá zpětná vazba, výzkumy a malé experimenty, to vše jsou agilní principy, které nás k tomuto grálu přibližují.
Jak rozetnout smrtící spirálu nových a nových funkcí?
Hypotézy, data, výzkumy, ověřování, malé experimenty a měření přínosů jsou kroky, které dokážou rozetnout nekonečnou spirálu produktového managementu postaveného na přidávání dalších a dalších funkcí bez znalosti skutečných potřeb. Protože je produkt málo používán, přidáváme další a další funkce a myslíme si, že to zajistí jeho vyšší používání. Ono je to totiž výrazně jednodušší než vylézt z kanceláří a mluvit se zákazníkem.
Příčina této spirály leží v neznalosti a nepochopení potřeb klienta nebo nevhodnosti našeho řešení pro danou potřebu. Nové funkce ani silnější tlak marketingu nepomůžou, jen dočasně uměle navýší uživatele, ale za cenu velkého brzkého odpadu a vyšších nákladů na akvizici. Samozřejmě i takový byznys může fungovat, pokud jsou náklady na akvizici nižší než získané příjmy. Jde ale spíše o továrnu na peníze a uspokojování potřeb majitelů firmy než o řešení skutečných potřeb klientů a oblíbený produkt.
Discovery jako klíčová dovednost celého agilního týmu
Customer discovery a Customer development, tedy schopnost pochopení potřeb klienta, analýzy a interpretace dat, schopnost vést hloubkové rozhovory či uspořádat pozorování a identifikovat v nich klíčové problémy, umět navrhnout experimenty či prototypy, umět definovat vhodná řešení, umět je měřit a vyhodnotit dopady a přínosy... to jsou klíčové produktové dovednosti týmu, ne jedné role nebo pozice, ale týmu jako celku.
"Produktový management je poctivé řemeslo, které v agilním kontextu nebývá moc popsáno, ale proto rozhodně nikam nemizí, naopak je jádrem, které zaručuje tvorbu skutečné hodnoty pro klienta (a v důsledku i pro firmu) a tudíž je nesmírně důležité"
Typickou svatou trojicí, zastupující discovery dovednosti v agilním týmu, je produkťák, UX / designér a softwarový inženýr. Často jim s facilitací workshopů a celého discovery procesu pomáhají také agilní kouči a v komplexních byznysových či technických případech můžeme zapojit i další role (doménového experta, enterprise architekturu, právní, obchodníky, poradce ze sítě, risk, …). Tato skupinka pak společně prochází discovery činnostmi, provádí výzkumy a pozorování, identifikují v datech a vhledech klíčové silné problémy, spolutvoří a hledají možná řešení, ověřují jejich první verze s klienty a společně jsou odpovědní za byznys úspěch produktu (ne za doručení jeho části nebo nějaké funkce).
Společně musí tato skupinka také reflektovat hranice a omezení daná byznysem a jeho cíli, byznys modelem, produkty a službami, regulacemi, bezpečností, technologiemi i architekturou a v řešení tato omezení respektovat a reflektovat. Cílem discovery ani agilních přístupů není vymyslet úžasnou věc, kterou ale firma nechce nebo ji není možné realizovat z důvodu omezení existujících technologií, ale vyřešit byznys problém v kontextu daných limitů. Samozřejmě že se také neustále snažíme daná omezení zpochybňovat, zjednodušovat a překonávat. V agilním ekosystému k tomu vybízí ambiciózní OKR a vize produktů, autonomie týmů v definovaných hranicích, retrospektivy týmů a pak samozřejmě také inovace (k inovacím najdete více v těchto článcích: z pohledu kultury, našich kognitivních omezení a chyb a nebo jejich využití v době krize).
Nezapomínejte v discovery činnostech na vývojáře!
Spolupráce produkťáků s UX bývá běžná i v neagilních firmách. Hlavním rozdílem je ono zapojení vývojářů do discovery procesu a primárně do kroků návrhu řešení a také opravdová spolupráce v rámci diskuzí a workshopů, nejen formou předávek mezi odděleními. Proč?
● Zkrátíte tím vývojový cyklus a výrazně zrychlíte rozhodování, protože se hned dozvíte, jak by daná věc šla řešit, co je příliš drahé a co skoro nemožné.
● Odstraníte množství předělávek z důvodu vzájemného nepochopení, které jsou způsobeny předávkami zadání a dokumentace místo workshopů a spolutvorby řešení s intenzivními diskuzemi a vyjasňováním.
● Připravíte rychleji kvalitnější první verzi, protože využijete existující možnosti, na které vás vývoj navede.
Zapojení vývojářů a dalších delivery rolí do discovery činností je klíčová z následujících důvodů:
1/ Syntéza byznys problému, který řešíme, pomáhá pochopení a lepšímu návrhu řešení na straně vývoje. Jak na to?
● stačí třeba jen 30min syntéza dosavadních zjištění na straně klientských potřeb,
● stačí vývojáře občas zvát na rozhovory s klienty (v pasivní roli pozorovatele nebo jim je potom přehrát), aby je slyšeli mluvit a rozbilo jim to jejich domněnky a představy o tom, co vše klient potřebuje a musí mít,
● pokud je ta možnost, dělat demonstrace nebo návštěvy u klientů s vývojáři
2/ Zapojení do spolunávrhu řešení, např. takto:
● přizvat zástupce vývoje na návrhové workshopy
● udělat s nimi revize nad vašimi návrhy možných řešení
● řešit tyto kroky v rámci refinementu paralelně s rozpadem aktuálních témat k vývoji
Díky pochopení byznys potřeb a cílů a zapojení vývoje a dalších důležitých rolí do návrhu řešení, mohou vývojáři přinést zcela jiná, mnohdy i méně pracná řešení, která nás nemusela napadnout. Minimálně tím odbouráte spoustu nepochopení, předělávání a zbytečné práce, které by přišly ve fázi realizace.
Typickým symptomem, že se vám to ještě nedaří, jsou zoufalé výkřiky z vývoje typu:
● „A toto si jako vymyslel kdo?“
● „Probůh, proč tak složitě!“
● „Vždyť to šlo řešit úplně jinak, spoustu toho už v produktu máme…“
Discovery a řešení vhodných potřeb klienta tedy není jen o roli produkťáka nebo UX, ale o celém týmu, včetně vývojářů. Ti často mohou jen poslouchat, ale musí být vtaženi do podstaty problému a klíčových rozhodnutí.
Zbystřete, obzvlášť pokud máte outsourcovaný vývoj!
Role vlastníka produktu je obzvlášť důležitá, pokud máte IT a zvláště jeho vývoj outsourcované. Znalost trhu, klientů a vašich produktů je core kompetence vašeho podnikání, kterou za vás nikdo jiný neodpracuje. Někdo u vás musí držet vizi a směr produktu, mluvit s klienty, sbírat zpětnou vazbu, měřit dopad a používání a ladit produkty podle měnících se potřeb trhu a cílů firmy.
A kdo píše storky nebo use casy?
Produkťák není v agilním světě tvořič Use casů nebo User Stories. Ty si ostatně mnohdy tvoří tým sám, respektive vznikají jako výstup diskuzí a workshopů vhodně provedené discovery fáze, spolu s mnoha analytickými a návrhovými artefakty a prototypy. Proto v agilním světě neexistuje samostatná role analytika jako překladače zadání. Popisování US a jejich předávka týmu je na seznamu to poslední, co by měl produkťák v praxi denně dělat, často je tento projev symptomem oddělených rolí ve firmě (funkční sila) a nespolupráce mezi nimi, pasivity produktu i vývoje a jejich ustrnutí v neefektivním procesu postaveném na předávání dokumentů a artefaktů.
Produkťák je odpovědný za maximalizaci hodnoty pro klienta pomocí vhodného produktu / služby. Což může být v rozporu s tím, když se firma snaží maximalizovat hodnotu pro vlastníka. Produkťák pak nemůže rozhodovat, má svázané ruce a vlastně mu nezbývá nic jiné než psát ty storky (bez znalosti byznys kontextu), které mu zadal někdo jiný shora, často bez ověření s klienty. Paradoxem je, že pokud se zaměříme na zákazníka a děláme to dobře a máme fungující byznys model, tak má větší zisky i onen vlastník.
Role produkťáka je odpovědná za discovery činnosti, za pochopení a řešení klíčových potřeb klienta (pomocí pozorování a výzkumů s klienty, analýzy dat a trhu), za zapojování zbytku týmu a vysvětlování kontextu a také za společný návrh a realizaci vhodného řešení, jeho měření, vyhodnocování a neustálý rozvoj a provoz.
Ani zde neexistuje one-size-fits-all
Opět zapomeňte na one-size-fits-all přístup, procesy, ověřování všeho či jen a pouze hodnotové prioritizace. Existuje spousta odlišných kontextů, mnoho typů produkťáků podle kontextu (např. za byznysový produkt nebo SW platformu) a každý z nich bude mít trochu odlišné potřeby a náplň práce.
Vlastník byznys produktu bude dělat hodně discovery, mluvit s klienty a dokáže vyčíslit byznys hodnotu a bude zapojovat ty technické do spolunávrhu. Vlastník technologické platformy, na které třeba několik byznys produktů stojí, zase musí mít více technické znalosti a bude hodně mluvit s byznysovými produkťáky, aby našel nejlepší formu a verzi platformy pro jejich použití, aby oni mohli co nejlépe naplňovat byznys potřeby klientů. Bude diskutovat s CIO a reflektovat IT strategii firmy, aby byly použité preferované platformy a technologie z pohledu nákladů, znalostí, rychlosti a snadnosti údržby i rychlosti vývoje.
Své zákazníky, jejich potřeby, hranice produktů a napojení na cíle musí ale znát všechny typy, stejně jako u všech platí zapojení do discovery činností. Jen to bude v jiném poměru času a v trochu jiné formě.
Produktový management je poctivé řemeslo, které v agilním kontextu rozhodně nikam nemizí. Naopak je jádrem, které zaručuje tvorbu skutečné hodnoty pro klienta (a v důsledku i pro firmu) a tudíž je nesmírně důležité. Přes minimalistické agilní frameworky jako je např. Scrum jsme na to mohli trochu zapomínat.
Výše zmíněné kroky se také snažíme už nějakou dobu spolu s dalšími řemesly (hlavně customer journey experti, agilní kouči, vývojáři a dataři) šířit a praktikovat napříč agilními týmy v České spořitelně formou školení, workshopů, mikro-learningů, knihovny technik, case studies z praxe, průvodců a šablon k jednotlivým discovery činnostem, sdílením úspěchů i neúspěchů mezi klíčovými rolemi, guildami v tribech, ale také transparentností celého discovery procesu (kolik a kdy nápadů vlastně zabíjíme, jak hodnotné věci děláme, jak kvalitní je discovery).
P.S.: jaké bude moje příští zvolání o nové černé a třetihorách agility?
Lídři místo manažerů jako „new black“!
Dynamická organizační struktura s OKR jako „new black“!
Lidé a jejich dynamické dovednosti a kompetence místo fixních pozic jako „new black“!
Vyberte si podle svého kontextu, co bude další krok u vás.
Poznámka: záměrně v textu používám pojem produkťák nebo produktový management a nereferuji k žádnému konkrétnímu frameworku nebo procesu, protože je v nich produktové řemeslo záměrně popsáno jen minimalisticky, stejně jako často neřeší analytické, vývojové, testovací či integrační činnosti. V textu mi jde o vysvětlení principu fungování produktového managementu v agilitě a pokud jste četli pozorně, odnášíte si pochopení, že jeden univerzální postup pro všechny ani tady neplatí a každá konkrétní implementace bude mít svá specifika a trochu jiné zaměření daných rolí.
