Ešte aj v dnešnej dobe je veľa firiem, ktoré pracujú s waterfall prístupom. Vyvíjajú funkcie bez priebežnej spätnej väzby zákazníka či validácie. Dual-track agile tieto nedostatky eliminuje priorizáciou výskumu a simultánnou spoluprácou medzi výskumníkmi, dizajnérmi a vývojármi. Zavedenie takejto zmeny ale nie je jednoduché.

Michal Blažej sa v 15. epizóde Minimum Viable Podcast zhovára o agile a discovery fáze s Lukášom Marvanom, ktorého skôr poznáte ako BoBa Marvana. Bob je Discovery managerom pre antivírusový softvér Avast, ktorý je dnes súčasťou značky Gen Digital. Bob má na starosti podporu spôsobu práce s využitím dual-track agile metód.

Vážne nechcete koláčiky?

Aby ste si mohli prezrieť tento obsah na našej stránke, musíte súhlasiť s používaním cookies tretích strán. Alebo môžete použiť link, ktorý vás presmeruje na nasledujúcu adresu: https://open.spotify.com/episode/268qFbw6rLLW3dG2P1uids

Minimum Viable Podcast nájdete na:

Som nesmierne rád, že už sme za tým obdobím waterfallu, kedy sme testovali raz za projekt, keď sme na konci zistili, že používatelia nášmu produktu nerozumejú. Mne agilita priniesla to, že sme testovali pravidelnejšie, používatelia videli naše prototypy a mohli nám k nim dať spätnú väzbu, ale chýbal mi tam výskum. Mal si aj ty z toho tento pocit?

Ja som na agilitu narazil, keď som bol v Sezname, kde sme s ňou začínali doslova na zelenej lúke. Vtedy sa nám stávali tie začiatočnícke chyby, kedy dizajnéri pracovali, ale vývojári nemali čo robiť. Uvedomili sme si, že potrebujeme posun, aby sa dizajn o stupeň oddelil od toho, čo sa vyvíjalo, a pripravil prácu pre vývoj. Vtedy nám čiastočne chýbal strategický rozmer, potrebovali sme posun na úrovni vízií, ale nie úplne na úrovni výskumu – teda venovať sa nie iba fičúrkam, ale aj zaoberať sa tým, ako všetko funguje spolu ako celok. Úprimne si už nepamätám detaily, bol to asi rok 2008.

Takže vám tam chýbala stratégia a možno nejaká taktika. Mohol by si nám to priblížiť, čo to znamená?

Skôr stratégia než taktika. Na tomto príklade sa dá ilustrovať myšlienka „k stratégii sa nepretestuješ”. Keď človek robí dookola taktické kroky, tak skôr reaguje na situáciu, než by tú situáciu nastavoval. Takto sa môže stať, že vďaka testovaniu dosiahneš nejaké lokálne maximum, ale možno ti utečie iná možná vetva vývoja, pretože procesu chýbal strategický pohľad. Nie iba z vizionárskeho ale aj z výskumného hľadiska.

Teda nie iba, že si myslím, že kadiaľ by cesta mala ísť, ale aj to, že už mám nejako potvrdené, že daným smerom sa nejaká cesta rysuje a nie je to slepá vetva. Jedna vec je neustály vývoj toho, čo mám a druhá vec je, za ideálnych okolností, tiež neustále zisťovať, kde by som strategicky chcel byť.

Bob Marvan je jednou z najznámejších osobností českej komunity dizajérov.

Čiže ty prácu rozdeľuješ na strategickú a taktickú. Strategickú si popísal. Čo je prosím tá taktická časť práce?

Povedal by som, že prácu sa nesnažím rozdeľovať, ale spájať. Veľa môjho úsilia smeruje k tomu, ako prepojiť dizajn s vývojom alebo stratégiu s taktikou alebo úvodnú discovery s náväznou discovery. Tie činnosti sú na troch úrovniach. Najnižšia je taktická, potom stredná, a najvyššia je strategická alebo vizionárska.

Taktickú časť vnímam tak, že niečo sme vyrobili, niekoľkokrát sme to vylepšili a stále v tom pokračujeme. Dookola zbierame kvalitatívne a kvantitatívne dáta, identifikujeme problémy alebo malé príležitosti. Základom úspechu je donekonečna robiť tieto taktické kroky na elementárnej úrovni, čo zabezpečuje, že veci jednoducho fungujú správne.

Na strednej úrovni taktiky už nie sú úplne jednoduché úlohy. Sú to väčšie problémy, ktoré sa nedajú vyriešiť jednoducho, ale nie sú dostatočne veľké, aby sme stavali nový produkt alebo prerábali významnú časť súčasného produktu. A tu sa dostávame do dual-trackového rytmu.

Takéto problémy by sa najprv mali posunúť na premyslenie k dizajnérom. V momente ako sú si oni istí, že majú v rukách správne riešenie, tak ho posunú vývojárom, ktorí by ho mali správne implementovať. To už nehovoríme o strategickom testovaní produktu alebo služby (zistite, ako strategicky uviesť nový produkt na trh s naším Product Discovery návodom). V takejto situácii vieme, kam ideme, a vylepšujeme časti produktu. A nad týmto všetkým by malo byť strategické smerovanie.

Spomenul si dual-track. Ja to vnímam ako príležitosť dať agilnému vývoju smerovanie na zákazníka. Mohol by si nám tento dual-track popísať na nejakom konkrétnom príbehu alebo prípade, aby sme si mohli predstaviť, ako to funguje u vás?

Pravdou je, že úspešne rozbehnutých dual trackov som príliš veľa nezažil ani ja. Väčšinou bojujeme s tým, ako sa tomu čo najviac priblížiť. Popíšem ale, ako si myslím, že sa to má robiť.

Je bežné, že na úvod sa celý tím spolu stretne na začiatku nejakého šprintu a navzájom sa dohodnú, kto na čom bude robiť a spoločne sa snažia odhadnúť priority.

Toto ale často prestane vychádzať, pretože niekedy sa stane, že dizajnér veľmi dlho rozmýšľa, ako vyriešiť nejaký problém a keď už vývojár nakoniec vie, čo má robiť, tak to má hotové za pol dňa. Inokedy je to naopak - dizajnérovi je hneď jasné, čo sa má robiť, ale vývojári potrebujú niekoľko mesiacov na implementáciu.

Tu vzniká ten problém, že keď všetci idú v jednom tracku a dohadujú sa na rovnakých úlohách, nastáva táto nerovnováha. Jedna z ciest, ako jej predísť, je oddeliť ich do dvoch trackov. V jednom z nich sa schádza to najnevyhnutnejšie - to čo sa určite bude vyrábať. V tom druhom sa schádzajú nápady, problémy, priania - čiže veci na preskúmanie, ktoré potrebujú prejsť nejakým researchom, testovaním.

V momente, ako máme približnú úroveň istoty, že takto by to mohlo fungovať, ideme do vývoja. Hoci je veľmi pravdepodobné, že stále príde k nejakým zmenám a po vývoji bude tiež potrebné otestovať, či to bude fungovať.

Výhodou dual tracku je, že vývojári nie sú blokovaní čakaním na dizajn a naopak dizajnéri nie sú príliš naháňaní dedlajnami. Celé to vyžaduje vysokú mieru disciplíny na strategickej úrovni, pretože musí byť správne postavená produktová road mapa, aby bolo aspoň zhruba jasné, čo sa kedy má robiť. Z tohto ešte vychádza potreba nejakej predsadenej discovery, aby sa dané témy dali skúmať z rôznych perspektív - či už takticky alebo strategicky.

Takto sa ale dostávame k tomu, že nepotrebujeme len dual track, ktorý skôr odbavuje taktické úrovne, kedy vieme, kam smerujeme. V skutočnosti potrebujeme ešte viac trackov, ktoré udržujú inovačný proces v chode. To je prípad veľkých firiem, v ktorých sa ja hýbem.

"Výhodou dual tracku je, že vývojári nie sú blokovaní čakaním na dizajn a naopak dizajnéri nie sú príliš naháňaní dedlajnami."

Povedzme si, ako to vyzerá na úrovni zavádzania. Ja si to predstavujem tak, že potrebujeme jeden tím vývojárov. Tí možno so sebou majú nejakého usability experta, ktorý im vie pretestovať, či to, čo vyvinuli, má zmysel a tiež majú nejaký backlog, podľa ktorého pracujú. Potom máme tím dizajnérov, ktorí tiež pracujú na základe nejakého backlogu. Tam padajú rôzne nápady a oni ich skúmajú. Vyzerá dual track v praxi takto alebo si to zjednodušujem?

Povedal by som, že občas takto vyzerá, ale myslím si, že by nemal. V skutočností je to o oddelení týchto dvoch frontov, ale neznamená to nutne, že títo ľudia na seba nemajú vidieť a nemajú spolupracovať. Dizajnéri už v exploračnej fáze discovery tracku musia riešiť, či je ich nápad vyrobiteľný (zaujíma vás ako prichádzať s novými nápadmi? Prečítajte si náš článok o explorácii). Znamená to teda, že spolupráca s vývojármi je nevyhnutná.

Principiálne si myslím, že o to celé by sa mal starať jeden tím, v ktorom sú všetci - od produktových ľudí, či už owner alebo manažér, agilný coach, ktorý na to dohliada, cez dizajnovú časť - dizajnérí, researcheri, copywriteri až po developerov a kontrolu kvality.

Celý tento balík ľudí operuje s tými rôznymi frontami, prioritami a focusom. Aby sa napríklad predišlo tomu, že sa z celého procesu stane vodopád, tak by sa nemali všetci pustiť na discovery a zastaviť development a naopak.

Trik je v kontinuite, že na jednotlivé časti sú dedikované kapacity, čo nevyhnutne nemusí znamenať ľudské hlavy a ruky, ale môže to byť pomer času.

To isté platí aj naopak - ak vývojára na 100% zaťažíme výrobou, tak nemá šancu udržať kontakt s tým, čo sa vymýšľa a nemá šancu včas odhaliť nejaké nezmysly, a predísť tomu, že nenarazíme do múru. Čiže nie sme rozdelení na my a oni, ale sú to rôzne prioritizované fronty práce.

"Discovery by malo pomôcť určiť, čo vlastne budeme robiť, ako to budeme robiť, zistiť, či sa to vôbec dá robiť a podobne. V skratke - je to o znižovaní rizika."

Potom ale vzniká veľká práca s manažmentom zdrojov, áno? Predpokladám, že výzva spočíva v tom, že ľudia majú rozdelenú pozornosť medzi viacero vecí.

Áno. Keď som pracoval v MSD, bol tento systém relatívne dobre rozbehnutý na jednom produkte. V tíme boli podtímy a intenzívne tam makalo nie iba niekoľko dizajnérov a vývojárov, ale viac produkťákov, agilných koučov, viac researcherov. No stále to bol jeden tím. Mali veľký objem práce, ktorá bola kvalitne riadená.

Pre menšie tímy je tento systém taká psychohygiena - teda ako sa nezblázniť z ad hoc zadaní na vylepšenia. Ľudia takto dostávajú priestor aspoň pre strategické úvahy strednej úrovne.

Vo veľkých tímoch sa to zas rieši napríklad odelením úvodnej fázy mimo ten produktový tím No v superveľkých firmách máme dedikované malé tímy na discovery fázu, kedy ešte nemáme jasný strategický smer. Tým pádom nie je zostavený ani produktový tím.

Keď sa na to pozerám z môjho pohľadu, s mojím kontextom, je to akoby v organizácii vznikali malé agentúry, ktoré si zdieľajú kapacitu, majú veľmi presné riadenie zdrojov a snažia sa svoj čas rozdeliť medzi viaceré fronty. Je to tak?

Čiastočne áno. Akurát by to celé malo byť strategicky riadené jednak inovačným procesom po procesnej stránke, po obsahovej stránke nejakými zdieľanými cieľmi atď. Keď sa na to človek pozerá z mikropohľadu, tak to môže vyzerať ako veľké množstvo ad hoc úloh, ale v tom makropohľade by to malo byť veľmi dobre riadené a prioritizované. Buď procesom alebo témami.

Skôr ako sa dostaneme k inovačnému procesu a ako to do neho zapadá - povedzme si niečo o discovery. Tento pojem si už spomenul, no zatiaľ sme si ho nezadefinovali.

Discovery je zjednodušene fáza, ktorá predchádza delivery. Ale nie je to iba o researchi, je to naozaj o príprave podmienok pre delivery. Tiež je to o znižovaní rizika, ktoré na seba berieme v rámci delivery. To, že my sa pustíme do výroby, znamená, že rozbiehame to drahé, kde sa míňa veľa peňazí, maká tam veľa programátorov, prípadne sa nakupujú servery a podobne.

Discovery by malo pomôcť určiť, čo vlastne budeme robiť, ako to budeme robiť, zistiť, či sa to vôbec dá robiť a podobne. V skratke - je to o znižovaní rizika. Jedno riziko je, či ľudia vôbec ocenia to, čo im chceme dodať.

Ďalšie riziko je o tom, či to ľudia vôbec budú používať, či naozaj riešime ich problém alebo potrebu a teda, či je naša cesta tá správna. Ďalšie riziko, už sme ho spomínali, je v tom, či sa to, čo chceme vyrobiť, dá vyrobiť a nakoniec je rizikom, či to celé bude zarábať peniaze, teda, či naše riešenie bude akceptované trhom. Tieto riziká sa discovery fáza snaží minimalizovať.

Skúsme si vysvetliť rozdiel medzi waterfallom a discovery fázou. Ja by som mohol argumentovať, že v minulosti sme tiež svojím spôsobom robili discovery fázu. Urobili sme výskum, napísali sme špecializáciu a potom sa to išlo programovať. Aký je v tom rozdiel?

V čom si myslím, že to je iné oproti klasickému waterfallu je to, že waterfall sa to snažil vyriešiť až do úplných detailov. Teda najprv kompletné poznanie, potom kompletné nadizajnovanie, potom kompletná výroba, potom kompletné otestovanie.

Aby som to nejak zhrnul, tak svojím spôsobom sa dá povedať, že discovery je svojím spôsobom výrazne zrýchlený dizajnový proces, ktorý predchádza dizajnovému procesu.

Napríklad náš aktuálny prístup v Avaste je taký, že v danom čase sa v danej téme snažíme prepracovať čo najďalej, aby sme mali čo najväčšie poznanie - či už hovoríme o situácii, probléme, kontexte, možných riešení. Cieľom je, aby sme mali prehľad v tom, čomu sa ďalej potrebujeme venovať, teda aké budú ďalšie kroky - čo potrebujeme ešte preskúmať alebo aké dáta získať a podobne. Celé je to ale veľmi koncentrované.

Prirovnal by som to k prieskumu pred vojnou. Čiže predtým, než niekam vtrhne celá armáda, je vyslaná operatívna hliadka, ktorá to skontroluje a vráti sa s nejakým nástrelom toho, čo tú armádu čaká, na čo sa sústrediť. Niečo podobné robí discovery pre samotný dizajn a development - teda mapuje témy.

Čiže zisťujeme nie len funkčnosť prototypov ale aj koľko nás to bude stáť - dá sa to nejak otestovať v malom? Ok. Tak sa s tým niekto bude pár dní v malom hrať a na základe toho skúsi priniesť kvalifikovaný odhad problematiky.

Samotný kvalifikovaný odhad je vlastne strašne dôležitá vec. Výskumy dokázali, že keď človeka postavíte pred problém, a opýtate sa ho na odpoveď na tento problém, je obrovský rozdiel v tom, keď ho donútite k okamžitej odpovedi v porovnaní s tým, keď má päť alebo tridsať minút. Či sme skúsení alebo nie sme, keď iba „strieľame od boku”, mýlime sa. Akonáhle máme aspoň nejaký čas na premyslenie, naše odhady sa až zázračne spresňujú.

"Je nevyhnutné, aby sme sa nesústredili iba na to, že „čo, čo, čo”, teda tísícprvá fíčura, ktorú dodávame, ale revidovať aj to, ako to dodávame a ideálne aj prečo to dodávame."

Dobre sa mi na to pozerá optikou double diamondu. V prvom diamante sa chceme dostať k zadaniu ale nie úplne špecifikácii. Aby sme si to skúsili spresniť - čo sú typické výstupy fázy discovery?

To je super otázka, ale začnem na ňu odpovedať z druhej strany - teda, čo sú typické vstupy alebo oblasti záujmu v rámci discovery.

Je tu produktová discovery (prečítajte si aj naše Desatoro optimálnej Product Discovery), o ktorej sme sa dosť rozprávali, ale ja by som podotkol, že v súčasnosti sa veľká časť produktov správa ako služby. Môžeme sa baviť o tom, aký je rozdiel medzi produktom a službou, ale myslím si, že ako dizajnéri by sme mali k týmto veciam pristupovať skôr ako k službám než ako k produktom a prispôsobovať naše výstupy konkrétnym užívateľom. Teda tá produktová discovery by skôr mala byť discovery na úrovni služieb.

Potom sa v discovery zaoberáme procesnými záležitosťami. Aby sme mohli doručovať našu službu ľuďom, často si potrebujeme pozametať na vlastnom piesku a spraviť si interné procesy tak, aby to nám fungovala práca vo firme, a aby firma mohla dobre fungovať pre ľudí.

A nad tým všetkým je strategická úroveň discovery. Teraz myslím relatívne vysokú úroveň typu, čomu sa má tá ktorá divízia firmy najbližšie roky venovať. Prípadne, keď máme veľkú službu, aké sú jej najbližšie témy.

Od týchto troch vstupov sa odvíjajú výstupy.

Na spodnej úrovni produktu alebo služby je výstupom zvalidovaný prototyp alebo value proposition pre ľudí. Idea zvalidovaná kvalitatívne a aj kvantitatívne. Napríklad sa urobí nejaký fake door test, čiže ako by na možnú ponuku ľudia reagovali.

Na procesnej úrovni to býva návrh na prerobenie spolupráce v rámci viacerých tímov, aby nám práca lepšie odsýpala. Na strategickej úrovni sú to výstupy typu nová vízia alebo roadmapa, teda čomu sa budeme venovať najbližšie tri roky.

Veľmi dôležitá vec, ktorá toto odlišuje od waterfallového prístupu, je mindset. Ním treba “nakaziť” čím viac ľudí, aby verili, že pracujeme s našimi našími odhadmi, aby sme sa od statického rigidného plánovania mohli posunúť k dynamickému plánovaniu.

My v rámci discovery určujeme smer, ponúkame témy, ktoré je potrebné ďalej preskúmať. Keď sa toto začne ľudom vysvetľovať od začiatku, potom je reakcia na zmeny ďaleko príjemnejšia než keď niekto príde s kompletným zadaním a kolegom povie, aby to jednoducho to vyrobili. Uznávam, že je to na začiatku oveľa náročnejšie na časový manažment alebo udržanie motivácie. Ale táto zmena v myslení a prístupe sa vypláca.

Všetky tieto dizajnérske techniky a zmeny sú o mindsete a o tom, ako sa ľudia pozerajú na svoju prácu, preto je extrémne náročné priniesť takúto zmenu. Zaujímalo by ma, čo sú najväčšie problémy, ktorým ty čelíš pri zavádzaní dual tracku alebo celkovo takéhoto spôsobu práce.

Teraz rozmýšľam, ktoré z mojich problémov súvisia s touto zmenou práce, a ktoré s tým, že to už dva roky riešime online. Či chceme alebo nie, covid na to nejaký vplyv má a je ťažké to oddeliť. Je to tenký ľad, ale myslím si, že veľká časť problému je vo viere ľudí, či to môže alebo nemôže fungovať. Všetci sme sa už popálili a máme náš piesoček, kde sme zvyknutí fungovať.

Lámať sa to začína vo chvíli, kedy ľudia uveria, že by im to mohlo pomôcť. Ale aby uverili nie je o tom, že človek im to tisíckrát nakreslí na tabuli. To si žiada praktické príklady a ideálne aj vlastný zážitok.

Keď začíname od nuly, je náročné sprostredkovať tieto príklady, ale práve cez ne vedie cesta k vlastným zážitkom. Za týchto okolností neostáva nič iné ako obrniť sa trpezlivosťou, mať víziu a možno aj nejaký čas.

Moje doterajšie skúsenosti sú, že ono sa to časom jednoducho nejako zlomí, začne to smerovať tým správnym smerom, začne to prinášať výsledky. Ale spočiatku je to postupný, neviditeľný proces.

Ale ako som hovoril - potrebné je, aby ľudia uverili, že to bude pracovať pre nich, prípadne pre firmu, za ktorou sú znovu iba oni, ich ciele a odmeny. Keď ľudia neuveria, tak jednoducho neuveria. Môžete sa postaviť aj na hlavu, ale fungovať to nebude. No keď uverí aspoň niekto, tak sa to začne nabalovať.

"Keď ľudia neuveria, tak jednoducho neuveria. Môžete sa postaviť aj na hlavu, ale fungovať to nebude. No keď uverí aspoň niekto, tak sa to začne nabalovať."

Asi tomu celému pomáha aj podpora zhora. Čo sú tvoje hlavné argumenty alebo pridaná hodnota, ktorú vysvetľuješ manažmentu? Aké výsledky to vie priniesť?

Musíme to brať tak, že ideálne to nie je iba o dual tracku, ale  aj o discovery fáze, celkovom inovačnom procese a celé to na seba nadväzuje. To, čo by to typicky malo prinášať, je obmedzovanie rizík, čiže to šetrí peniaze a čas a teda aj nervy a náladu.

Ak nejaký tím už niekoľkýkrát vylieva výsledky svojej práce do záchoda, lebo niekto sa sekol v plánovaní, má to dopad na motiváciu ľudí. Robíme biznis a vo finále to vedie k peniazom. Cesta k nim ale častokrát vedie cez čas - že my dostatočne včas zistíme, čo je blbosť a čo by mohlo fungovať. Fór je ale v tom, že aj vedenie to musí vidieť a zažiť.

…vysvetliť, že chceme viac hodnotnej práce, je vždy ťažké na argumentáciu. Predstavme si teraz, že máme malý produktový tím o desiatich ľuďoch. Tvoríme si nejakú našu aplikáciu, snažíme sa najlepšie ako vieme, ale cítime, že sme frustrovaní, že nemáme viac priestoru na discovery a stále sme v kolobehu napĺňania backlogových položiek. Vedel by si poradiť, ktoré kroky by som ja ako produktový vlastník mal urobiť? Prípadne čím sa zmena transformácie k dual tracku začína?

Neviem, či je to transformácia k dual tracku, ale jedna z mojich obľúbených otázok je: „Čo nebudeme robiť?”. V našej firme ale aj v iných často pozorujem, že sa ide po kvantite ale nie po kvalite. Samozrejme nič proti kvantite, no musíme sa k nej prepracovať. Tu je priestor vylepšiť si interné procesy a nejde iba o dual track, ide o celkové nastavenie firmy alebo aspoň tímu.

Je nevyhnutné, aby sme sa nesústredili iba na to, že „čo, čo, čo”, teda tísícprvá fíčura, ktorú dodávame, ale revidovať aj to, ako to dodávame a ideálne aj prečo to dodávame. Toto sa ale nedá urobiť, ak človek nezbrzdí neustály tlak na doručovanie nových vecí. Potom ostane priestor, aby sme sa sústredili, čo robíme a ako robíme. A nad tým celým by mala byť strategická vízia - prečo to celé robíme.

Na úrovni tímovej spolupráce a dual tracku mi ale príde, že dôležitejšie je „čo” a „ako” a nie všeobjímajúce „prečo”. Určite je dôležité, ale na tomto poli sú dôležitejšie veci.

Vypočujte si celý rozhovor s Michalom Čudrnákom:

Vážne nechcete koláčiky?

Aby ste si mohli prezrieť tento obsah na našej stránke, musíte súhlasiť s používaním cookies tretích strán. Alebo môžete použiť link, ktorý vás presmeruje na nasledujúcu adresu: https://open.spotify.com/episode/5qkjjUjUhgEs4kutQUQNKZ

Mimimum Viable Podcast vám každý mesiac prináša Customer Experience štúdio Lighting Beetle*, ktoré sa sústredí na tvorbu kvalitného zákazníckeho zážitku.

Dizajn je všade okolo nás. Minimum Viable Podcast skúma dizajn s malým “d” – teda ten, ktorý hľadá riešenia na problémy ľudí. Spolu s hosťami sa v ňom venujeme témam, ktoré s dizajnom súvisia, no bežne ich s ním nespájame. Za spoluprácu na produkcii ďakujeme štúdiu Zeldeo a Mojmírovi Procházkovi.

Potešíme sa každému vypočutiu, followu, zdieľaniu aj podnetu na zlepšenie. Svoje tipy na zaujímavé osobnosti, s ktorými sa môžeme porozprávať o dizajne, nám posielajte na podcast@lbstudio.sk.

Príjemné počúvanie.