Požiadavky na nové fičúry alebo hlásenie bugov prichádzajú neustále a zo všetkých strán. V tomto článku vám ukážem prakticky príklad ako si v týchto procesoch upratať a nastaviť si ich tak aby váš IT tím pracoval efektívne.

Požiadavky môžete zbierať rôznymi spôsobmi. My si dávame pravidelné stretnutia s používateľmi, kde requesty zapisujeme manuálne a zároveň máme aj priamo v appke formulár, kde useri môžu kedykoľvek odoslať svoj request

Okrem spôsobu akým požiadavky zbierate je veľmi dôležitý flow, ktorý máte vo svojom manažment toole nastavený, tak verím že overený proces ktorý tu krok po kroku opíšem vám pomôže vo vašej efektivite.

Tool na manažment používame Clickup, ale tento proces viete aplikovať v akomkoľvek inom toole ako sú Jira, Asana, Notion a pod.

Embednutý formulár v appke

Clickup, poskytuje možnosť si customizovať vlastný formulár, ktorý si jednoducho cez script vložíte do svojej appky. Formulár má aj svoj unikátny link, ktorý viete zdieľať.

Úžasné na tom celom je že po odoslaní formulára vám clickup ihneď založí task do konkrétneho listu a ak máte dobre nastavené automatizácie, tak vám task assigne a odošle upozornenie na email v prípade prijatia requestu aj po jeho vypracovaní. Vám tak veľa manuálnych úkonov odpadne a zároveň efektívne vyriešite aj feedback loop (user je happy že jeho požiadavka bola zapracovaná a menej happy keď mu ju odmietnete – samozrejme so zmysluplným odôvodnením).

Aby ste lepšie rozumeli presunom taskov medzi foldrami a listami, ktoré budem v článku opisovať, tak naša hierarchia itemov v Clickupe vyzerá nasledovne:

• Space: Software department
• Space “Software department” obsahuje tri samostatné foldre: 📅Initiate&Planning, ⏱️Sprints a ⚙️Features and Bugs
• Folder “⚙️Features and Bugs” obsahuje dva samostatné listy: 🐞Bug report a 💡Feature request
• List “🐞Bug report” a “💡Feature request” obsahuje tieto statusy: TO DO > SPECIFICATION > REVIEW > ACCEPTED > REJECTED

🐞Bug report

Pozrime sa ako to vyzerá v našom liste “🐞Bug report”. 

V prvom rade potrebujete vedieť o bug requeste základné údaje. Formulár by mal teda obsahovať nasledovné vstupy: 

• Kto si? Zadaj svoj e-mail.
• Kto nahlásil problém?
• Krátky popis problému (tento vstup nám clickup doťahuje do názvu tasku).
• Popíš problém viac do hĺbky.
• URL adresa kde konkrétne sa problém vyskytuje.
• Dátum a čas kedy nastal problém.
• Možnosť vložiť screenshoty alebo video.

Takto vyzerá flow kde sa tasky presúvajú medzi statusmi, foldrami a listami: 

To do

Každý bug, ktorý bol vytvorený cez formulár sa vytvorí automaticky v liste “🐞Bug report” so statusom TO DO a s príznakom (label) REQUEST. Clickup do detailu tasku dotiahne všetky vstupy z formulára a teda ak zadávateľ zrozumiteľne opísal svoj problém, tak vy ako PM môžete s taskom začať ihneď pracovať.

V tomto liste pracujeme s nasledovnými statusmi: TO DO, SPECIFICATION, REVIEW, ACCEPTED a REJECTED (CLOSED).

Automatizácie, ktoré máme nastavené:

• Clickup odošle confirm email zadávateľovi o prijatí požiadavky.
• Clickup priradí do tasku Projektového manažéra.
• Clickup automaticky priradí tasku label REQUEST.

Specification

PM presúva task z TO DO > SPECIFICATION a sa snaží simulovať chybu, ktorú opísal zadávateľ. PM sa snaží task špecifikovať do takého stavu aby keď ho pridelí developerovi tak mu bolo všetko jasné. Akonáhle má PM hotovo presúva task do REVIEW.

Review

Kontrola tasku zo strany Product ownera (PO), alebo Developera ak si to situácia vyžaduje.

Accepted

Keď je zadanie kompletné, tak PM priradí tasku prioritu:

• Ak je priorita URGENT (red flag) alebo HIGH (yellow), tak PM bezodkladne presúva task do aktuálneho sprintu
  • URGENT (red flag) znamená to, že je potrebný hotfix a oprava sa releasuje samostatne mimo plánovaného releasu – asap!
  • HIGH (yellow), bugfixy sa releasujú podľa štandardného harmonogramu v najbližšom plánovanom release
• Ak má task prioritu nižšiu, tak PM presunie task do listu “ 📅Initiate and planning” pod statusom READY TO DEVELOPMENT.

Automatizácia:

• Clickup automaticky odošle email zadávateľovi o zapracovaní keď sa v šprinte zmení status z ANY na DEPLOYED (podmienka musí mať ten task label REQUEST).

Rejected (Closed)

Napíšeme dôvod odmietnutia do tasku (THE REASON OF THE REJECTION) a až potom dáme status REJECTED. Clickup automaticky pošle e-mail zadávateľovi spolu s dôvodom.

Automatizácia:

• Clickup odošle e-mail zadávateľovi.

💡Feature request

Formulár by mal obsahovať nasledovné inputs:

• Kto si? Zadaj svoj e-mail.
• Krátky popis requestu (tento vstup nám clickup doťahuje do názvu tasku).
• Popis requestu viac do detailu.
• Popíšte dôvod prečo by ste to chceli a aké sú vaše očakávania.
• Možnosť vložiť screenshoty alebo video.

Flow je viac menej rovnaký ako pri bug requestoch. Akurát pri feature requestoch tasky nikdy nehoria a teda priority urgent a high nevyužívame.

Samozrejme vždy musíte vedieť zhodnotiť ktoré nápady sú dobrý nápad a ktoré nie. Ak sú dobré, tak vedieť si povedať aj prečo sú také dobré a kedy je ten správny čas ich vyvinúť, vzhľadom na všetky ostatné veci, ktoré sa v tom čase dejú vo firme a na trhu. Ale o tom ako hodnotiť requesty si povieme v ďalšom článku.

Rozhovory s používateľmi

Ak sme na meetingu a používateľ nám nahlási request, tak ho zapíšeme manuálne do Clickupu do listov “🐞Bug report” alebo “💡Feature request”. Samozrejme pri každom requeste sa pýtame rovnaké otázky ktoré máme vo formulári. Proces je už ďalej rovnaký ako som opísal vyššie v článku.

Ak by vám nebolo niečo jasné prípadne by ste potrebovali poradiť, tak ma neváhajte kontaktovať na e-mail kantor@cluu.design. Budem sa tešiť!