Týmto článkom by som vás rád inšpiroval ako sa dá produkovať produkt agilným prístupom s riadením pomocou Scrum. Trochu poodkryjem ako robíme produkt Štart! Pri tvorbe aplikujeme všetky (tie ‚teoretické‘) postupy, ktoré učíme aj našich klientov konzultačného tímu.
Vopred sa ospravedlňujem za množstvo anglických pojmov, ale bohužiaľ ich preklad do slovenčiny by len zhoršil porozumenie. Tak dúfam, že to až tak nevadí.
Tak začnime z husta. Nie od vlastností , ale od biznis stránky a používateľov.
Aký problém? Koho problém?
Za tie roky vývoja sme sa naučili asi najdôležitejšiu vec pre úspešný produkt. Produktu často stačí minimum vlastností pokiaľ riešia skutočné problémy skutočných ľudí. Aj preto dnes úspešné startupy sa tak intenzívne venujú pochopeniu problému, bolesti potenciálnych klientov. Ak totiž poskytnete nálepku na ranu, tak klient bude považovať produkt za užitočný.
V ScrumDesku sa preto dnes skoro každá vlastnosť začína analýzou a snahou pochopiť používateľa, jeho problémov a toho čo vôbec hľadá. Robí to produktový vlastník pomocou Value Proposition Canvas. Ak vás to zaujíma, pozrite si aj článok z reálnej aktivity u klienta, kde sme pomáhali rozbehať nový produkt.
ScrumMaster a retrospektíva. Príklad draftu Value Proposition Canvas.
Vytvorenie tejto stránky sa zdá byť jednoduché, ale chce to poriadne veľa času, validácie so živými ľuďmi a overení si, že problémy, ktoré možno vidíte vy ako produktový vlastník, sú aj skutočne problémami používateľov. Aj preto sa tvorba propozície robí iteratívne v niekoľkých kolách. Radšej investujeme trochu viac času do prípravy než do vývoja. Inak by sa mohlo ľahko stať, že vytvoríme síce peknú vlastnosť, ale nenájde sa nikto kto by to využil. Okrem nás samotných.
Lean Canvas
Po príprave prvých value proposition canvasov sa pri štarte produktu pokračuje Lean Canvasom, alebo Business Model Canvasom, ktoré by mali validovať produkt z ďalších pohľadov. Náš vám však neukážem, keďže ide o obchodné údaje.
Lean Canvas popisuje a validuje biznis
Elevator statement
Ďalší krok je takou malou odbočkou. Je veľmi dôležité vydestilovať z Lean canvasu stručnú vetu, ktorá bude celému tímu pripomínať prečo vlastne existuje daný produkt, čím nie je a čím sa líši od konkurencie. Práve Elevator statement je takouto vetou, ktorú by ste mali v tíme vedieť naspamäť, pretože nikdy neviete, kedy sa vás niekto opýta: „A čo to vlastne robíte u vás vo firme?“ A verte, alebo nie, máte iba max. 15 sekúnd, aby ste človeka zaujali. Predáva totiž každý člen tímu. A elevator statement je navyše aj definíciou vízie, ktorá sa dá poľahky použiť pre validáciu potreby vlastností. Pretože nie je nič tak zlé vo vývoji produktov ako mrhanie času a života ľudí na implementácii nepotrebných vlastností.
A tak vám neostáva nič iné len destilovať. Elevator statement.
Draft verzia elevator Statementu produktu ScrumDesk@Hand
Personas
Vo value proposition canvase a Lean canvase ste sa venovali vašim používateľom. Máte tak pripravené celkom kvalitné podklady pre popísanie prototypu používateľa vo forme Personas.
Tento koncept je vynikajúcim nástrojom pre agilné tímy a ich prevtelenie sa do kože používateľa. Približuje totiž používateľa ako človeka s popisom prostredia, v ktorom žije, popisom jeho dňa, hodnôt a preferencií. Parametre, ktoré chcete sledovať sú na vás. Sú zväčša dané obchodným modelom a tomu, aby váš tím si vedel predstaviť o koho ide. Nezabudnite sa porozprávať s reálnymi ľuďmi reprezentujúcej danú personu.
Aj personas slúžia predovšetkým na identifikáciu zbytočných vlastností. Majú byť prirodzenou brzdou v pridávaní vlastností. Ak totiž vlastnosť je v rozpore s personou, tak máte prvú indikáciu zbytočnosti vlastnosti. A nič iné ako produktový vlastník nepotrebujem viac.
Draft persony ScrumMaster pre produkt ScrumDesk@Hand
BACKLOG TIME
Až teraz sa ako produktový vlastník začínam pracovať na produktovom backlogu. Najprv koncepčne na úrovni eposov, tém a veľkých vlastností.
Vlastnosti vyberáme podľa:
- vízie,
- nápadov a hlasovaní klientov poskytnutých cez UserVoice,
- rozhovorov s používateľmi,
- support email a LiveChatoo pluginu na stránkach,
- pozorovaní počas konzultačnej činnosti,
- na základe analýzy správania sa a využívania aplikácií pomocou MixPanel.com a MouseFlow.com,
- konkurenčných produktov,
- produktov z úplne iných cieľových oblastí.
Vlastnosti do produktového backlogu pridá produktový vlastník tak neskoro ako sa dá. Tvrdý limit 0.
V ScrumDesku preferujeme v tejto príprave fyzické karty, ktoré ale neskôr prenesieme do nástrojov ScrumDesk, v ktorom pokračujeme v detailizácii a priorizácii.
Backlog produktu sa snažíme udržiavať vo forme mapy user stories. V tejto mape sú ukladané jednotlivé vlastnosti v rôznej hĺbke detailu.
Jednotlivé vlastnosti sú priebežne priorizované podľa MoSCoW, biznis hodnoty, KANO atď.
Tie najdôležitejšie, ktoré budú implementované v najbližších verziách a sprintoch, sú spodrobnené produktovým vlastníkom vo formáte user stories. Tie, ktoré sú určené pre nasledujúci sprint majú dané aj akceptačné kritériá.
Príklad user story s akceptačnými kritériami
Minimum minima z minima
V určitom momente sa po príprave základných požiadaviek dostanete k príprave prvej verzie produktu. Tá by nemala byť rozsahom veľká, pretože vám bude trvať dlho ju pripraviť a v podstate tak predĺžite čas kedy sa dozviete pravdu o vašich prvotných stratégiách pre dosiahnutie vízie. Potrebujete jednoducho validovať, či to čo ste si doteraz písali a zisťovali aj bude skutočnou pravdou.
Produktoví vlastníci v ScrumDesku sa snažia zamerať na tzv. Minimum Viabale Product (MVP) a Minimum Marketable Features. Predstavte si to pre jednoduchosť ako malé verzie vášho produktu, ktoré budú následnými rozširované o ďalšie vlastnosti, resp. o hĺbku implementácie vlastností.
Táto minimálna verzia musí produktového vlasntíka bolieť. Musí to byť minimum z minima, ktoré si myslel, že je minimom. Navyše to musí dávať zmysel používateľom. Nestačí mu len povedať, že môžete pridať novú kartu na tabuľu, ale plánovať ju budete môcť až neskôr. Možno v prvej verzii nepotrebujete prílohy k úlohám, toto bude stačiť aj neskôr. Keď si to vyžiadajú klienti.
Čas na plány
Rozsah MVP je potrebné rozdeliť možno do viacerých iterácií, alebo dokonca do viacerých verzií. Niektoré z týchto verzií budú na začiatku možno iba pre internú validáciu produktu.
V ScrumDesku sa snažíme mať neustále pripravovanú aj ďalšiu verziu (v4 na obrázku). Kým tím tvorí jednu (v3), produktoví vlastníci pracujú na príprave nasledujúcej (v4) tak, aby keď nastane čas na začatie vývoja, táto už bola pripravená.
Aktuálna verzia (v3) je rozdelená do viacerých sprintov (S#8, S#9, S#10). Aj tu platí, že produktový vlastník pripravuje detaily nasledujúceho sprintu (S#10). V tomto prípade ide predovšetkým o akceptačné kritériá, wireframy, potrebné textácie atď. Tak konkrétne, aby tím na plánovaní už vedel veľmi presne odhadnúť náročnosť.
V tom istom čase tím implementuje user stories zo sprintu S#9.
Takto jednak riadime vývoj, zároveň plánujeme aj v krátkodobom aj v strednodbom časovom horizonte.
Štartujte, šprintujte
Plánovanie sprintu nezačína u nás prvým dňom sprintu. V našom prípade sa snažíme o tzv. preplanning stretnutia, na ktorých produktový vlastník predstaví plánovaný obsah nasledujúceho sprintu. Obsah musí spĺňať Definition of Ready, inak je tím oprávnený vrátiť požiadavku produktovému vlastníkovi.
PO následne dostane od tímu spätnú väzbu o možnostiach realizácie, potrebe upresnenia akceptačných kritérií a aj hrubý odhad náročnosti implementácie.
Prvý deň sprintu potom začneme plánovaním sprintu, počas ktorého tím rozbije user stories na menšie úlohy v max. veľkosti niekoľkých hodín. Samozrejme so zvážením dohodnutej Defintion of Done.
Úlohy sa odhadnú a zráta sa kapacita tímu.
Rozsah sprintu sa validuje voči kapacite a historickej rýchlosti (ang. velocity).
Sprint sa následne naštartuje a začíname papierikovať.
Vidím. Ťahám. Verím. Prispôsobujem sa.
Po začatí sprintu je už všetko postavené na otvorenosti, guráži a disciplíne tímu. Samozrejme používame Kanban (lepšie povedané Scrumban) tabuľu. Členovia tímu si úlohy ťahajú sami. Podľa poradia zhora.
Našim spoločným cieľom je vlastnosti dokončovať priebežne a vedieť ich nasadzovať aj častejšie než každé 2 týždne. Aj preto sa snažíme vlastnosti najprv uzatvárať a až potom začať pracovať na ďalšej. Takto sme pripravení kedykoľvek vydať verziu, ktorá prináša niečo nové. A to najdôležitejšie je v sprinte prvé. Takže je predpoklad, že najdôležitejšie môže ísť na produkciu čo najskôr.
Každá user story je rozbitá na viaceré úlohy. Všimnite si, že máme aj úlohy s názvom akceptácia. Táto úloha je priradená produktovému vlastníkovi. Ten ju musí spraviť tak rýchlo ako sa dá, aby tím vedel, či vlastnosť implementoval správne. V ScrumDesku má na to produktový vlastník čas max. 24 hodín. Tvrdý limit č. II.
Tím aktualizuje úlohy priebežne, nielen raz za deň, ale okamžite. Tvrdý limit č.III. Vie sa tak lepšie koordinovať v reálnom čase. Aj napriek distribuovanosti tímu sa tak nestane, že dvaja robia na tej istej úlohe.
V prípade zmien musí produktový vlastník odkomunikovať príčinu zmeny a nechať si potvrdiť tímom, že je schopný danú zmenu implementovať. Niekedy to skončí odobraním inej požiadavky. Častejšie sa ale stane, že produktový vlastník sa snaží minimalizovať množstvo takýchto zmien a radšej odkomunikuje s klientom posun vývoja do ďalšej iterácie.
Meraj. Meraj. Meraj. Rež.
Priebežná aktualizácia umožňuje mať metriky, ktorým sa dá veriť a hlavne použiť ich pre správnu adaptáciu. Aj preto sú BurnDown grafy pre tím a produktového vlastníka podstatné.
A nielen graf sprintu, ale aj verzie.
Ako inak?
Poslednou udalosťou sprintu je retrospektíva, ktorá nám umožňuje sa kontinuálne zlepšovať a odstraňovať zbytočnosti. Zberom nápadov sa to ale nekončí. Dôležitá je ich realizácia. Ale to je iná téma.
A čo má z toho Fero?
Celé toto úsilie sa prejavlo po pomerne krátkej dobe. Našou snahou je, aby išlo o potvrdenie skutočnými klientmi a používateľmi. V prípade ScrumDesk Start! sme týmito postupmi boli schopní získať viac než 4 000 nových spoločností v priebehu pol roka. A čo nás teší viac je ich feedback.
Výsledok sebadisciplíny, identifikácie zbytočností, výberu vlastností tak neskoro ako sa dá, ich realizácie tak skoro ako sa dá, s neustálou viditeľnosťou a dôverou, bez mikromanažmentu a zbytočných byrokracií. Navyše vo veľmi intenzívnej komunikácii s klientmi a hlavne so životom v ich koži.
