Takže cíl je jasný, opravit „děkovací obrazovku eShopu“. Začínáme tím, že si zmapujeme zákaznické cesty, tedy kudy zákazníci na tuto obrazovku přicházejí.
Sešli jsme se na to ve třech a během hodiny jsme našli cca 60 zákaznických cest, například:
- zákazník si objednává službu
- zákazník ruší službu
- zákazník si ke své službě objednává další, doplňkovou službu
- zákazník si objednává službu s hardwarem, který mu bude instalovat technik
- atd.
Možná namítnete, že takhle „od stolu“ popsané zákaznické cesty mohou být totálně zavádějící. Správný postup by byl vzít je jen jako hypotézu a prověřit, jak se to, co jsme popsali, děje doopravdy. Ve SCRUMU se ale děje všechno rychle a najednou, takže pokud takový výzkum nedoručí už product owner, během sprintu není moc šance to zvládnout. Je to problém?
Ne takový, jak by se zdálo. Součástí „agilního mindsetu“ je i vědomí, že vše, co dělám, je do jisté míry špatně. Pokud je to hodně špatně, brzy se to projeví a v některém z dalších sprintů to spravíme.
Mým úkolem je připravit wireframe. Vybírám tedy několik „nadějných“ zákaznických cest, které působí důležitě – buď prodávají důležité produkty, často se používají nebo jsou něčím specifické.
Postupně se mi tedy podařilo zpracovat 8 cest (zapsali jsme je do podoby osmi user stories) a každá do návrhu přinesla něco nového. Předpokládám, že i zbylých 52 by nám odhalilo spoustu věcí, ale na to už není čas. Raději dodat nedokonalé něco, než dokonalé nic. Nikdo z nás z toho ale nemá moc dobrý pocit.
Dobře vedený SCRUM je sice hektický, ale v podstatě působí uklidňujícím dojmem – lidi jdou přímočaře za jasně domluveným cílem, bez zmatků a starostí „co kdyby“. Jediné, na co člověk myslí, je DODAT, ideálně hned.
Tohle je ovšem pravý opak – topíme se v přívalu scénářů, u nichž neznáme jejich hodnotu, takže nevíme který řešit dřív. Navíc hrozí, že výsledek té spousty práce bude nicotný a bezvýznamný. Bude to stačit, aby korporátní lidi pochopili, že dělit scope podle obrazovek je nesmysl?