Dual-track Agile: Jak optimalizovat vývoj produktů?

Agilní vývoj produktů pro externí zákazníky může být velmi náročný. Především proto, že z pohledu zákazníka může být obtížné pochopit pojem, že pro tento účel neexistuje pevný rozsah nebo pevná časová osa. Když si klienti najmou vás nebo vaši společnost pro vývoj jejich dalšího digitálního produktu, musí mít nutnost přesně vědět, co a kdy dostanou. Teď, když mluvíme o MVP (kde není moc místa pro de-scoping funkce) a pevné časové ose, nebude to vypadat jako vodopádový projekt přestrojený za agilní?

Krátká odpověď zní: ne. Alespoň ne nutně. Všechno bude záležet na tom, jak to zvládnete jako produktový manažer. Můžete se rozhodnout spustit Discovery zcela odděleně od vývoje, což je situace, kdy nevidím velký rozdíl od přístupu k vodopádu, vzhledem k tomu, že jediným agilním aspektem vývoje vašeho produktu by bylo přijetí vývojových sprintu a jeho ceremonií.

Jiným přístupem je přiblížit zákazníka vašemu týmu. Aktivně se zapojit do celého procesu, uvědomovat si, co se děje, sledovat vývoj a kompromisy podle potřeby. Někdy z vlastní iniciativy. Zmírnění frustrace, která obecně nastává, když je třeba učinit takové rozhodnutí.

Dual-Track Agile, autor Jeff Patton

Dual-Track Agile vám může hodně pomoci při sbližování vašich zákazníků. V zásadě budete mít dvě odlišné, přesto vzájemně propojené skladby: Discovery and Development. I když to může znít jako další práce, úkoly a schůzky s vaším týmem, zlepší to efektivitu vašeho týmu prostřednictvím mnoha aspektů, které uvedu později.

Klíčovou věcí je, aby váš zákazník byl zapojen do objevovací dráhy. Zapojte zákazníky, když nejsou obeznámeni s Agile. Netrvá však dlouho, než se výsledky ukážou a budou vnímat hodnotu.

Aby to fungovalo, je důležité mít předem definované role a pravidla. Dejte zákazníkovi vědět, co a kdy očekávat. To jim také pomůže vidět postupující pokrok.

Je velmi běžné, že produkty, kde je zákazníkem SME (Subject Matter Expert), jsou překvapeny obchodními požadavky, které nebyly původně identifikovány - nebo alespoň nebyly zmapovány, jak je požadováno pro MVP -, aby se zjistilo, jak je skutečně požadováno poté, co máme začal se vyvíjet. Pravděpodobně tato situace ovlivní původní odhady. Proto je potřeba mít zákazníka na palubě od začátku.

Discovery track je místo, kde budou dříve zmapované funkce podrobně a vylepšeny. Je velmi pravděpodobné, že počáteční odhady jsou založeny na velmi vysokých požadavcích. Obecně budou vycházet z funkcí, jako je „objednávka pizzy“. Bude však na cestě k objevu této funkce, že bude na vás, abyste ji uvedli na nižší úroveň, aby zákazník viděl, že i taková zjevná vlastnost - alespoň pro ně, kteří jsou na ni zvyklí každý den a mít ve svých hlavách všechna obchodní pravidla a logiku - může se stát, že to nebude tak zřejmé pro ty, kdo to budou muset vybudovat. Zákazník už může vědět, jak si objednat pizzu, a dokonce to udělat „automaticky“. Ale když se to stane funkcí pro váš produkt, musíte znát několik věcí, jako například: jak bude objednána pizza (web / telefon)? Kdo obdrží objednávku? Co je chuť a velikost? Co bychom měli dělat, když poskytovatel pizzy neodpovídá nebo není k dispozici příchuť a velikost?

To je to, co musíme udělat na této trati: zpochybněte všechny podrobnosti procesu. Mapujte, určujte obchodní pravidla, nakreslete vývojové diagramy, identifikujte mezery, blokátory a nefunkční požadavky potřebné pro danou funkci. Možná i předchůdci, kteří musí být na místě, aby tato funkce fungovala nebo měla hodnotu. Většina z těchto odpovědí přijde od vašeho zákazníka. Důvodem pro to, aby se stali součástí procesu. Na této trati také bude náš UX Designer pracovat na prototypech a ověřovat je u uživatelů.

Pouze pokud je objekt dobře definován a dostatečně jasný, přesune se na další stopu: Vývoj. Do této chvíle bude tým dev již vědět, co se očekává a proč. A to bude znamenat rozdíl, protože jejich rychlost bude mít tendenci se výrazně zvyšovat, protože se k nim funkce dostane již vylepšená a ověřená.

Toto jsou výhody, které můžete očekávat při osvojování Dual-Track Agile:

  • Zákazníci se více angažují, protože se cítí být součástí tohoto procesu;
  • Pochopení zákazníků, že požadavky, které se jim mohou zdát zřejmé a jednoduché, se mohou ukázat jako skutečně složitější, než se očekávalo, když provádíte dokumentování obchodních pravidel a procesů za nimi;
  • Aby byli zákazníci součástí tohoto procesu, jsou neustále informováni o dosaženém pokroku, aniž by museli mít pravidelné zprávy, které mohou být velmi časově náročné;
  • Rychlost týmu se zvyšuje, když nemusí trávit mnoho času objasňováním funkcí / příběhů;
  • Kompromisy bývají pro zákazníka méně bolestivé;
  • Výsledky a přínosy jsou zaznamenány v krátkém časovém horizontu, aniž by vyžadovaly velké úsilí, aby váš zákazník při tom vnímal hodnotu.

Výsledky se samozřejmě mohou - a budou - lišit v závislosti na produktu, projektu, zákazníkovi atd. Pamatujte: „Nezáleží na tom, jak dobrý je váš tým techniků, pokud jim není dáno něco, co stojí za to vybudovat.“ - Marty Cagan