Gennaio 23, 2018
di Ron Yang

Storie. Ne hai centinaia se sei un product manager. Ognuno descrive le fantastiche esperienze che desideri che i tuoi clienti abbiano durante l’utilizzo del tuo prodotto. E come ogni buon narratore, hai bisogno che le tue storie siano chiare e di impatto.

Tutti i migliori product manager che conosco sono responsabili della condivisione di ciò che i clienti vogliono veramente attraverso le storie degli utenti.

Ma qui è quando essere un product manager è un duro lavoro. Ci sono anche momenti in cui ci si aspetta di definire i requisiti per ciò che i team di sviluppo devono creare, senza fornire il “perché” dal punto di vista dell’utente.

Mentre la maggior parte delle nuove funzionalità dovrebbe essere definita dal punto di vista dell’utente, ciò non è sempre fattibile o addirittura utile. Ad esempio, considera le funzionalità di sicurezza o i requisiti dell’infrastruttura che non sono sempre rivolti al cliente.

Quindi la domanda diventa: quando usi queste diverse navi? Prima di poter rispondere, è necessario capire cosa li rende diversi.

C’è una distinzione importante tra storie utente e requisiti: l’obiettivo.

La storia utente si concentra sull’esperienza — ciò che la persona che utilizza il prodotto vuole essere in grado di fare. Un requisito tradizionale si concentra sulla funzionalità-ciò che il prodotto dovrebbe fare. Le restanti differenze sono un sottile, ma importante, elenco di” come”,” chi “e” quando.”

Ecco come differiscono le storie e i requisiti degli utenti:

Come è scritto?

Le storie degli utenti dovrebbero essere scritte in una o due frasi e catturare chi è l’utente, cosa vuole e perché. Una struttura semplice per la definizione di funzionalità o storie utente può assomigliare a questa: come____, voglio ottenere _ _ _ _ in modo da realizzare il seguente vantaggio di ____.

Esempio: Come utente, voglio essere in grado di reimpostare la mia password in modo da poter tornare nel sistema se lo dimentico.

I requisiti tendono ad essere molto dettagliati e richiedono più tempo per scrivere. Questi spesso vanno in dettaglio specifico (a volte altamente tecnico) su come il software dovrebbe funzionare. Questi dettagli guidano quindi il team di sviluppo su come creare una nuova funzionalità o funzionalità.

Esempio: L’utente è autorizzato a reimpostare la propria password dopo aver ricevuto un’e-mail di reimpostazione della password. L’e-mail dovrebbe contenere un link univoco per reimpostare la password e tale link dovrebbe scadere dopo due ore.

Chi lo scrive?

Le storie degli utenti possono essere scritte da chiunque sia vicino agli sviluppatori di software che sollevano problemi, un tester QA che scopre un difetto nell’UX, purché rappresenti la prospettiva dell’utente finale. Ma è il product manager o il proprietario che mantiene l’arretrato delle storie degli utenti.

I requisiti sono scritti dal product manager, dal product owner o dall’analista aziendale. I lead tecnici sono spesso coinvolti così come gli ingegneri che saranno responsabili del lavoro sulle funzionalità o sui miglioramenti.

Quando vengono scritti?

Le storie degli utenti sono scritte durante la costruzione di un prodotto. E aggiornare le storie (o aggiungerne di nuove) può accadere in qualsiasi momento. Per i team agile, il product backlog funge da elenco prioritario delle funzionalità che devono essere sviluppate. È qui che le storie degli utenti vengono mantenute fino a quando non vengono lavorate, in genere durante gli sprint di sviluppo.

Requisiti possono anche essere realizzati in qualsiasi momento. Tuttavia, è meglio definire ciò che è desiderato dal punto di vista dell’utente prima se sono richieste sia le storie che la definizione dei requisiti. Più un team è in fase di pianificazione, più il team comprende le esigenze dell’utente e del business. Pertanto, definire i requisiti rigidi troppo presto può comportare la necessità di cambiarli in un secondo momento o la creazione di qualcosa che non fornisca pienamente il risultato desiderato dal cliente.

Anche se l’obiettivo di una storia utente o requisito diverso, l’obiettivo è sempre lo stesso — la costruzione di un prodotto che i clienti amano.

Che tu stia scrivendo una storia utente o un requisito, devi concentrarti su ciò che conta di più: descrivere il risultato desiderato per il cliente e dare allo sviluppo ciò di cui hanno bisogno per costruirlo con successo.

So che può essere fonte di confusione decidere cosa scrivere. Quindi ecco una semplice guida per fare questa scelta.

Se ciò che si richiede di costruire ha un vantaggio diretto per gli utenti finali, scrivere una storia utente. Se è più centrale per il nucleo di un prodotto o di un’infrastruttura, passare alla definizione dei requisiti.

Quali differenze vorresti aggiungere alla lista?

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.