ianuarie 23, 2018
votează Ron Yang

povești. Ai sute de ei, dacă sunteți un manager de produs. Fiecare descrie experiențele minunate pe care doriți să le aibă clienții dvs. în timp ce utilizați produsul. Și ca orice povestitor bun, ai nevoie ca poveștile tale să fie clare și de impact.

toți cei mai buni manageri de produse pe care îi cunosc sunt responsabili pentru partajarea a ceea ce își doresc cu adevărat clienții prin poveștile utilizatorilor.

dar aici este atunci când a fi un manager de produs este o muncă grea. Există, de asemenea, momente în care trebuie să definiți cerințele pentru ceea ce trebuie să construiască echipele dvs. de dezvoltare — fără a oferi „de ce” din perspectiva utilizatorului.

în timp ce majoritatea funcționalităților noi ar trebui definite din perspectiva unui utilizator, Acest lucru nu este întotdeauna fezabil sau chiar util. De exemplu, luați în considerare caracteristicile de securitate sau cerințele de infrastructură care nu sunt întotdeauna cu care se confruntă clientul.

deci întrebarea devine: când folosiți aceste vase diferite? Înainte de a putea răspunde la asta, trebuie să înțelegeți ce le face diferite.

există o distincție majoră între poveștile utilizatorilor și cerințe: obiectivul.

povestea utilizatorului se concentrează pe experiență — ceea ce persoana care utilizează produsul dorește să poată face. O cerință tradițională se concentrează pe funcționalitate-ce ar trebui să facă produsul. Diferențele rămase sunt o listă subtilă, dar importantă, a „cum”, „cine” și „când”.”

Iată cum diferă poveștile și cerințele utilizatorilor:

cum este scris?

poveștile utilizatorilor ar trebui să fie scrise într-una sau două propoziții și să surprindă cine este utilizatorul, ce vrea și de ce. O structură simplă pentru definirea caracteristicilor sau a poveștilor utilizatorilor poate arăta cam așa: ca____, vreau să obțin _ ___astfel încât să realizez următorul beneficiu al____.

exemplu: ca utilizator, vreau să-mi pot reseta parola pentru a putea reveni în sistem dacă o uit.

cerințele tind să fie foarte detaliate și să dureze mai mult timp pentru a scrie. Acestea intră adesea în detalii specifice (uneori extrem de tehnice) cu privire la modul în care ar trebui să funcționeze software-ul. Aceste detalii apoi ghid echipa de dezvoltare cu privire la modul de a construi o nouă caracteristică sau funcționalitate.

exemplu: utilizatorului i se permite să-și reseteze parola după ce a primit un e-mail de resetare a parolei. E-mailul trebuie să conțină un link unic pentru resetarea parolei și acel link ar trebui să expire după două ore.

cine o scrie?

poveștile utilizatorilor pot fi scrise de aproape oricine apropiat de software — dezvoltatorii care ridică probleme, un tester QA care descoperă un defect în UX — atâta timp cât reprezintă perspectiva utilizatorului final. Dar managerul de produs sau proprietarul este cel care menține restanțele de povești ale utilizatorilor.

cerințele sunt scrise de managerul de produs, proprietarul produsului sau analistul de afaceri. Conducerile tehnice sunt adesea implicate, precum și inginerii care vor fi responsabili pentru lucrul la caracteristici sau îmbunătățiri.

când sunt scrise?

poveștile utilizatorilor sunt scrise în întreaga clădire a unui produs. Și actualizarea poveștilor (sau adăugarea de noi) se poate întâmpla în orice moment. Pentru echipele agile, restanțele de produse servesc ca o listă prioritară a funcționalității care trebuie dezvoltată. Aici sunt păstrate poveștile utilizatorilor până când sunt lucrate-de obicei în timpul sprinturilor de dezvoltare.

cerințe, de asemenea, pot fi artizanale în orice moment. Cu toate acestea, cel mai bine este să definiți mai întâi ceea ce se dorește din punctul de vedere al utilizatorului dacă sunt necesare atât povești, cât și definirea cerințelor. Mai departe de-a lungul o echipa este cu planificarea lor, mai mult echipa înțelege nevoile de utilizator și de afaceri. Deci, definirea cerințelor dure prea devreme poate duce la necesitatea de a le schimba mai târziu — sau la construirea a ceva care nu oferă pe deplin rezultatul dorit al clientului.

deși obiectivul unei povești sau cerințe de utilizator diferă, obiectivul este întotdeauna același — construirea unui produs pe care clienții îl iubesc.

fie că scrieți o poveste de utilizator sau o cerință, trebuie să vă concentrați asupra a ceea ce contează cel mai mult: să descrieți rezultatul dorit pentru client și să oferiți dezvoltării ceea ce au nevoie pentru a-l construi cu succes.

știu că poate fi confuz să decizi ce să scrii. Deci, aici este un ghid simplu pentru a face această alegere.

dacă ceea ce solicitați să construiți are un beneficiu direct pentru utilizatorii finali, scrieți o poveste de utilizator. Dacă este mai central pentru nucleul unui produs sau infrastructură, treceți la cerințele definitorii.

ce diferențe ați adăuga la listă?

Lasă un răspuns

Adresa ta de email nu va fi publicată.