O user story (poveste de utilizator) este o descriere scurtă a unei cerințe, scrisă din punctul de vedere al celui care va folosi produsul. În loc de un document de zeci de pagini, echipa primește propoziții mici, ușor de discutat, de ordonat și de livrat. Pentru un startup în care fondatorul vorbește zilnic cu dezvoltatorii, formatul acesta păstrează comunicarea simplă.
Rezultatul depinde însă de calitatea poveștilor. O poveste vagă generează trei interpretări diferite și o săptămână pierdută. Articolul arată cum scrii user stories clare, cum le completezi cu criterii de acceptare și cum le verifici înainte să ajungă la echipă.
Ce este o user story și care este structura ei?
O user story are o formă fixă, în trei părți, care răspunde la întrebările cine, ce și de ce. Răspunsul scurt: „Ca [rol], vreau [acțiune], ca să [beneficiu].”
Exemplu: „Ca administrator de magazin online, vreau să export lista comenzilor într-un fișier, ca să o trimit contabilului.”
Fiecare parte are rolul ei:
- rolul spune cine are nevoia, deci pentru cine optimizezi;
- acțiunea spune ce vrea să facă, fără să impună soluția tehnică;
- beneficiul explică motivul și te ajută să respingi variante care nu-l servesc.
Cele trei C: card, conversație, confirmare
Metoda clasică vorbește despre trei elemente. Cardul este propoziția scurtă. Conversația este discuția dintre cel care știe nevoia și cel care construiește. Confirmarea sunt testele prin care verifici că ai livrat ce trebuia. Greșeala frecventă este să păstrezi doar cardul și să renunți la conversație; atunci povestea devine o comandă seacă.
Ce sunt criteriile de acceptare?
Criteriile de acceptare sunt condițiile concrete pe care povestea trebuie să le îndeplinească pentru a fi considerată terminată. Răspunsul direct: ele transformă „cred că merge” în „putem demonstra că merge”.
Un format des folosit este Dată-Când-Atunci (Given-When-Then):
- Dat fiind că sunt autentificat ca administrator și există cel puțin o comandă,
- când apas pe „Exportă comenzile”,
- atunci primesc un fișier cu o linie pentru fiecare comandă și cu coloanele data, client, total.
Ai nevoie și de cazuri limită: ce se întâmplă dacă nu există nicio comandă, dacă lista este foarte lungă sau dacă utilizatorul nu are dreptul să exporte. Cele mai multe defecte vin din situațiile pe care nu le-a gândit nimeni.
| Element | Ce conține | Exemplu |
|---|---|---|
| Rol | Cine face acțiunea | administrator de magazin |
| Acțiune | Ce vrea să facă | să exporte comenzile |
| Beneficiu | De ce contează | să le trimită contabilului |
| Criterii | Când e gata | fișier cu coloane definite, mesaj pentru listă goală |
Sfat: scrie criteriile împreună cu persoana care va face testarea sau cu dezvoltatorul. O jumătate de oră de discuție înainte economisește câteva zile de refaceri.
Cum recunoști o poveste bine scrisă cu regula INVEST?
O poveste bună respectă șase calități, grupate în acronimul INVEST. Răspunsul scurt: ea e independentă, negociabilă, valoroasă, estimabilă, mică și testabilă.
- Independent: poate fi livrată fără să aștepți altă poveste.
- Negociabil: detaliile se discută, nu sunt bătute în cuie.
- Valoros: aduce ceva util utilizatorului sau afacerii.
- Estimabil: echipa poate spune aproximativ cât durează.
- Small (mic): încape într-un ciclu scurt de lucru.
- Testabil: există un mod clar de a verifica rezultatul.
Dacă o poveste nu trece una dintre aceste probe, o rescrii sau o împarți. Cea mai frecventă problemă este mărimea: „Ca utilizator, vreau un cont” este de fapt un set de povești, de la înregistrare la resetarea parolei și ștergerea contului.
Cum împarți o poveste prea mare
- Caută pașii fluxului și transformă fiecare pas într-o poveste.
- Separă varianta simplă de variantele rare (de exemplu, plata cu cardul și plata prin transfer).
- Păstrează întâi traseul principal și lasă excepțiile pentru ciclul următor.
- Împarte după roluri, dacă două tipuri de utilizatori au nevoi diferite.
Unde se așază poveștile într-un proiect?
Poveștile trăiesc într-un backlog, adică lista ordonată a lucrurilor de făcut. Răspunsul direct: fondatorul sau responsabilul de produs ordonează lista, iar echipa preia din vârf cât poate livra într-un ciclu.
Ordinea nu se alege după intuiție. Poți folosi criteriile din articolul despre prioritizarea funcționalităților, iar direcția mai largă e descrisă în roadmap-ul de produs. Un truc practic este să detaliezi complet doar poveștile din vârful listei; cele din coadă pot rămâne câteva rânduri, fiindcă probabil se vor schimba până vin la rând. Ce intră în prima versiune este însă stabilit de logica MVP-ului.
Ce nu este o user story
- Nu este un document tehnic. Detaliile de arhitectură intră în notele echipei.
- Nu este un ticket de defect. Un defect repară ceva care nu merge, o poveste adaugă valoare.
- Nu este un substitut pentru discuții. Poveștile pornesc conversația, nu o înlocuiesc.
Ce greșeli apar cel mai des când scrii user stories?
Cele mai multe probleme vin din rol, din beneficiu și din mărime. Răspunsul scurt: povestea fie impune soluția, fie nu spune de ce există, fie e prea mare pentru a fi testată.
- Rolul lipsește sau e generic. „Ca utilizator” nu spune nimic; „ca nou abonat care nu și-a verificat adresa” este mult mai informativ.
- Beneficiul e un truism. „Ca să pot folosi aplicația” nu justifică nimic.
- Se amestecă soluția în acțiune. „Vreau un meniu derulant” blochează alternativele; „vreau să aleg luna” lasă loc de design.
- Lipsesc criteriile. Fără ele, „gata” înseamnă ceva diferit pentru fiecare.
- Poveștile sunt toate tehnice. Dacă backlog-ul nu conține nicio problemă a utilizatorului, ai pierdut legătura cu piața.
Sarcinile utilizatorului pe care le descoperi prin metoda din Jobs To Be Done sunt o sursă bună pentru beneficii reale. Beneficiile se aud cel mai bine în interviurile cu clienți. Iar când povestea ajunge în versiunea publică, verifică dacă a fost percepută ca atare prin testarea beta.
Întrebări frecvente
Când are sens să folosesc user stories într-un startup mic?
De îndată ce ai o persoană care construiește și alta care decide ce se construiește. Dacă lucrezi singur, formatul scurt tot ajută să-ți clarifici ce vrei înainte să scrii cod.
Câte criterii de acceptare trebuie să aibă o poveste?
De obicei între trei și șapte. Dacă ai mai multe, povestea este probabil prea mare și merită împărțită.
Cine scrie user stories: fondatorul sau dezvoltatorul?
Fondatorul sau responsabilul de produs propune povestea, iar echipa o rafinează. Cele mai bune rezultate apar când ambele părți o discută împreună.
Este nevoie de un instrument special pentru ele?
Nu. O foaie de calcul sau o tablă cu carduri este suficientă la început. Instrumentele dedicate ajută mai târziu, când crește numărul de povești.
Cum tratez cerințele nefuncționale, precum viteza sau securitatea?
Le scrii ca limite sau criterii de acceptare pentru povești, de exemplu „pagina se încarcă în câteva secunde pe o conexiune obișnuită”. Astfel devin verificabile.
