Počas našich konzultácií s agilnými tímami sme sa v každom tíme doteraz vždy stretli s neznalosťou ako deliť požiadavky na menšie správym spôsobom. Vačšinou to končí pripomienkami, že nie je možné rozdeliť požiadavku na menšie časti.
To sa nedá, to nemá zmysel, to nie je možné, ale u nás je to iné, ale vy to nechápete, ale je to veľmi málo.
Počúvame to vždy. Tak sme sa rozhodli vám ukázať ako sa to dá.
Príklady boli vytvorené vo forme user story map s použitím ScrumDesk aplikácie, v ktorej si môžete prehľadne vytvoriť backlog od epikov, cez vnorené features až po user stories.
Delenie podľa krokov procesu
Mnoho produktov, služieb, alebo aplikácií umožňuje klientom spracovávať údaje ich komplikovaných interných, alebo komerčných procesov. A práve kroky procesu môžu byť veľmi dobrým spôsobom delenia požiadaviek.
Navyše ak sa zameriate na proces od začiatku do konca:
- umožní to vytvoriť veľmi rýchlo funkčnú aplikáciu,
- podporuje základný pracovný tok,
- rýchlo sa vytvorí základná, no správna, architektúra, ktorá sa dá ďalej priebežne vylepšovať,
- získate veľmi rýchlo spätnú väzbu od používateľov, pretože si nemusia predstavovať ako to bude vo výsledku,
- produkt sa dá skoro použiť.
Musí byť výsledok dodateľný na produkčné prostredie?
V prípade malých aplikácií môže byť výsledkom prvá verzia, prvý minimum marketable product. V prípade komplexnejších produktov však netreba delenie požiadaviek zahadzovať do koša ako nepotrebné. Výjdite zo svojej komfortnej zóny.
Menšie požiadavky umožňujú produkt budovať postupne, možno ho dokonca použiť ako minimum viable product. A až keď je hotové dostatočné množstvo funkcionality, až vtedy ho publikovať na produkčné prostredie. A aj preto má delenie produktov na epiky, prípadne až user stories určite praktický význam.
Netflix
Asi najjednoduchším príkladom pre pochopenie je Netflix. Zároveň je to aj príklad všeobecnejšie zameranej funkčnosti, v ktorej sa menia údaje, s ktorými aplikácia pracuje, nemení sa ale proces samotný.
Kroky procesu sú jasné asi každému. Vyberiem si film z ponuky, pozriem si film, ohodnotím ho. Ok, predtým sa musím prihlásiť.
Mimochodom, tiež máte podobný zážitok s Netflixom? V tomto prípade je možno minimálny produkt iba hľadanie v Netflix 🙂
eCommerce
eCommerce aplikácie sú najlepším príkladom pre vysvetlenie delenia podľa krokov procesu. Každý z nás už niečo nakupoval v podobnom systéme.
- Nakupujúci si najprv prezerá produkty v katalógu produktov.
- Produkty, ktoré sa mu páčia si vkladá do nákupného košíka, alebo do zoznamu obľúbených položiek.
- V prípade, že sa rozhodne pre kúpu, položky v nákupnom košíku zaplatí.
- A nakoniec neostáva nič iné ako sledovanie stavu dodávky.
Predstavte si teraz, že vaša aplikácia má tieto kroky funkčné. V princípe si klient môže už produkt aj priamo zakúpiť, alebo aspoň nasimulovať ich kúpu. A vy, dodávateľ produktu, viete veľmi rýchlo získať spätnú väzbu.
Každý takýto epik sa dá samozrejme implementovať rôznymi spôsobmi. A to pomôže identifikovať minimálny produkt. Napr. v prvej verzii budete podporovať iba platbu na účet, alebo iba výber produktu zo zonamu bez hľadania. Alebo iba cez hľadanie.
Banková aplikácia
Ďalším príkladom je aplikácia elektronického bankovníctva. Tieto aplikácie sú dnes už komplexnejšie, keďže podporujú nielen klasických klientov, ale aj produkty poistenia, investícií, dôchodkových fondov, atď.
V našom príklade sa pozrieme na bank retail, teda na oddelenia banky starajúce sa o nás, klasických klientov. Náš život je v tomto prípade pomerne jednoduchý.
Prezeráme si naše účty. Potrebujeme potom zaplatiť účtenky, faktúry. A potom prezeráme prehľady atď. My sa pozrieme na platby:
- Najprv si vyberieme, resp. zadáme prijímateľa platby.
- Potom zadávame detaily platby.
- Po zadaní je obvykle dobré umožniť používteľom skontrolovať platbu pred zaplatením a zaplatiť.
- A nakoniec umožniť používateľovi prípadné stiahnutie potvrdenia o zaplatení.
Poistenie
V prípade aplikácie pre poisťovne si vieme ukázať ľahko príklad dvoch procesov:
- celkového procesu od výberu typu poistenia až po jeho vyplatenie v prípade škodovej udalosti,
- a podproces spracovania škodovej udalosti.
V prípade škody poškodený skontaktuje poisťovňu a oznámi škodovú udalosť. Pre spraovanie tejto udalosti je k prípadu priradený zamestnanec poisťovne. Ten následne skontaktuje poškodeného klienta a vyhodnotí mieru oprávnenosti vyplatneia poistenia a mieru škodovosti. Následne rozhodne o výsledku spracovania škodovej udalosti a uzavrie ju.
Po tomto spracovaní sa následne spustí ďalší krok hlavného procesu, a to vyplatenie poistenia.
Telekomunikačný operátor – self-care aplikácia
Ak ste produktový vlastník u telekomunkačného operátora, može byť vašou zodpovednosťou aplikácia pre starostlivosť o zákazníkov. Resp. aplikácia pre self-service zákazníka.
Po úvodnom príhlásení sa používateľ zvyčajne dostane na obrazovku s prehľadom jeho aktuálnych produktov. Následne si vie pozrieť detaily svojich produktov, alebo zakúpiť, aktivovať, nové produkty a služby. Alternatívne zaplatí za dodané služby a produkty. A ako posledný krok je možnosť prípadnej podpory klienta.
HR
Takéto delenie nie je iba záležitosťou IT. Predstavte si, že chcete zvizualizovať HR procesy, v ktorých máte ako vedúci HR mať prehľad. Alebo máte ako produktový vlastník vytvoriť IT systém podporujúci HR. V oboch prípadoch vieme použiť rozdelenie na menšie časti so zohľadnením HR procesov.
V tomto príklade sa pozrieme na proces zameraný na zamestnancov:
- Pracovník HR začne nábor nových zamestnancov.
- Následne sa začne výber potenciálnych uchádzačov.
- Keď ich identifikuje, potrebuje s nimi uzavrieť pracovnú zmluvu, informovať sociálnu poisťovňu, zabezpečiť vytvorenie účtov do interných IT systémov a pod.
- Pracovník musí byť následne zaškolený.
- Keď začne úspešne pracovať, potrebuje byť naďalej podporovaný či už v jeho osobnom rozvoji, alebo povýšením.
- A nakoniec príde koniec. Odchod zamestnanca z firmy.
Opäť si asi viete domyslieť, že každý krok sa dá spraviť rôznymi alternatívami. A o tom neskôr, keď sa budeme baviť o ďalších spôsoboch delenia.
Napadá vám niečo ďalšie?
Tak neváhajte si to zapísať do svojho backlogu a vyskúšať, že všetko veľké sa skladá z malých vecí. A menšie veci dokončíte skôr, s menším počtom chýb a hlavne s rýchlejším feedbackom a overením zo strany používateľov.
