Požiadavky bez šumu. Stručne, štruktúrovane, zmysluplne.

cover

Stručné, jasné, štruktúrované požiadavky, napriek času ich prípravy, môžu výrazne pomôcť zmysluplnému výsledku, zladeniu, inováciám a ušetreniu času tímom, biznisu aj prevádzke.

Jano, poctivý  Product Owner

Produktový backlog je základným kameňom každého agilného tímu. Zhmotňuje želania zákazníka, víziu a stratégiu biznisu, sny technológov a riešenia obáv prevádzky.

Časom sa však z backlogu stane jedno menšie hnojisko. Dávame do neho všetko aby sa nezabudlo. A nielen to. Zapisujeme do neho všetko podrobne. Aby sa nezabudlo.

Jano, produktový vlastník, má úspešný produkt, ktorý spolu tvorí s výborným agilným tímom. Sú už skúsení, Scrum hrajú už dlho. Je im už jasné kto má ako fungovať, čo je cieľom a prečo sa veci riešia tak ako sa riešia. Chápu princípy. Proces si zjednodušili a prispôsobili ako mohli, chceli a vedeli.

Jano je ale po nejakom tom roku v svojej úlohe Product Ownera vyčerpaný. Začína prejavovať vyhorenie. Vďaka Scrum sa jeho život stal taký neustály kolotoč. Planningy, dailies, reviews, retro a medzitým sa stretáva s klientmi, UX, architektami, baví sa s CX oddelením, marketingom, content writermi. Je toho veľa. A čím viac sa im darí, tak tým je všetkého viac.

Pri našej debatke sme došli k tomu, že za úspechom v tíme vidia kvalitne pripravené požiadavky. Je v nich napísané všetko tak ako potrebuje tím. Presné popisy, jasné návody, požiadavky až na technický level. Vývojári si veľmi chvália, že im stačí požiadavky mnohokrát prepísať do kódu. Jano si dokonca dáva prácu aj s databázovými typmi, constraints a pod. To u iných Product Ownerov nevidno. Tím je skutočne spokojný.

Janovi táto pozitívna spätná väzba dáva energiu. Snaží sa, vníma, že to pomáha tímu aj produktu.

Jediný problém je, že Jano na to nemá veľa času. Požiadavky musí pilovať po večeroch. A to ešte sa pripraviť na stretnutia na nasledujúci deň. Ale keď treba, treba!

Žeby root cause Janovho začínajúceho vyhorenia?

S Janom sme skúsili teda experiment. Skúsili sme nájsť hranicu, kedy popis bol stručný, no ešte stále zmysluplný. Popis, ktorý možno nebol úplný, ale vytvoril priestor aj pre tím.

Skúsili sme nasledujúci postup, ktorým sa môžete inšpirovať aj Vy.

Všade optický šum

Ego a slovíčko ALE nechajte pred dverami miestnosti, v ktorej sedíte.

Zobrazte si požiadavky, ktoré máte niekde ‚na stole‘.

A teraz otvorte aj oči. Lepšie. Odstúpte ďalej od monitora.

Mám pre vás jednoduchú otázku:

Ktoré slová sú v názve požiadavky úplne zbytočné? Bez hodnoty? Výplne? Taký optický šum?

Skopírujte si názov požiadavky do textového editora.

Vyhoďte optický šum a preformulujte názov.

Opäť pauza, nádych, výdych a opäť sa pozrime na názov.

Je tam ešte optický šum?

Ak áno, tak poďme ho odstrániť. Napíšte ďalšiu verziu názvu požiadavky.

A opakujte, Až po minimum. Len pozor, o chvíľu to môže byť až príliš stručné.

A potom to spravte s detailnejším popisom, akceptačnými kritériami a inými poznámkami v požiadavke.

Zbytočnosť Extra Features

Medzi siedmymi typmi zbytočností sa vyníma Extra Features. Mnohí z nás si prestavia iba funkcionality, ktoré klient nepoužíva. Ale tento typ zbytočností je aj o optickou šume. O slovách, ktoré neprinášajú hodnotu. Nepoužívajú sa.

Menej slov, lepšie vybraných a formulovaných vedie k rýchlejšiemu a presnejšiemu zladeniu tímu, zákazníkov aj používateľov. Popis ideálne z pohľadu používateľov bez technikálií prinesie vzájomne porozumenie a zníženie konfliktov.

Menej slov prirodzene zafunguje v dnešnej dobe keď ľudia text iba skenujú. Nie nečítajú. A väčšinou vôbec nie s porozumením. Skenujú. Tak nastavte text tak, aby mal hodnotu aj pri skenovaní.

Kratší text napíšete rýchlejšie. Možno nie zo začiatku keď sa budete učiť nájsť si správnu stručnosti. Ale časom určite.

Menej textu vám prinesie väčšiu priepustnosť na plánovaní, implementácii, testovaní a akceptácii.

žiadne okrasné slová Implementácia, Realizácia, Vývoj, Zmena, Chyba, Požiadavka. Chcela by som poprosiť, Žiadam, Potrebujem.

Nepíšte slovesá, ale podstatné mená. Nie kto čo ma spraviť. Ale čo má byť výsledok. A lepšie čo chcete dosiahnuť, vývojári sú inteligentní ľudia, prídu s inováciou aká vám nenapadne.

Prečo písať inak?

Možno to vyzerá, že je to len o písaní. Ale v skutočnosti je to o efektivite a produktivite. Menej textu je viac. Len pozor na osekanie stromu po korene 😀.


Zaraďte sa medzi najlepších Product Ownerov na Slovensku, ktorí absolvovali naše programy Product Ownership MasterMind: Stratégia produktu alebo Product Ownership MasterMind: Dodávka produktu.

Product OwnerBacklog Refinement

Mohlo by Vás zaujímať

Produktový vlastník. Rodič produktu?

Produktový vlastník. Rodič produktu?

Nie tak dávno sme sa stretli s nastavením roly Produktového vlastníka, ktoré odrážalo maximálne možnosti, ktoré...

Keď kríza vypukne tri mesiace pre vianočnou kampaňou a Agile

Keď kríza vypukne tri mesiace pre vianočnou kampaňou a Agile

Pred niekoľkými rokmi ma pozvali do jednej poisťovne pomôcť so zavedením Agilných praktík.Nešlo o celkovú transformáciu....

Prečo prečo?

Prečo prečo?

Prečo, ako, čo, pre koho? Keď si dáme dokopy otázky ktoré počujeme najčastejšie, bude to pravdepodobne zoznam ktorý...

Novinky

Naše Agiloviny

Nenechajte si ujsť výber toho najlepšieho z Agile, s čím sa stretli naši mentori. Nielen zo sveta produktov, vývoja, tipov a trikov, ale občas aj humoru. Posielame pravidelne, raz za občas :) #QualityOverQuantity

Posielať na

spracovaním osobných údajov

Ďakujeme