La sfida dei sistemi di Product Requirements

A nessuno piace scrivere documentazioni di requisiti di prodotto lunghe e ultra-dettagliate. E non è tutto: a nessuno piace neanche leggerle.

Creare un ottimo prodotto richiede innumerevoli ricerche e pianificazioni. Allora da dove iniziare? I Product Manager spesso partono dalla redazione di un documento di requisiti prodotto (PRD).

Questo documento serve per definire il prodotto che si intende sviluppare, e pertanto deve delineare: lo scopo del prodotto,  le sue caratteristiche, funzionalità e comportamento.

Successivamente, si condivide il documento con i team di business e di tecnici dei relativi stakeholders; da questi si richiede inoltre un contributo alla costruzione, lancio o commercializzazione del prodotto.

Una volta che tutti i soggetti interessati si trovano allineati, il PRD serve come bussola nel fornire una direzione chiara verso gli obiettivi del prodotto, e garantendo al contempo una visione condivisa tra team di business e team tecnici.

LA RACCOLTA DI REQUISITI IN UN MONDO AGILE

Come avviene la raccolta requisiti in un mondo Agile? Può sembrare complicato- e forse lo è. Ma non preoccuparti, ad Atlassian sappiamo tutto su come creare PRD in un ambiente Agile.

Qui alcuni aspetti da tenere a mente:

I requisiti Agili sono i migliori amici del product owner. I product owners che non fanno ricorso a requisiti “agili” devono tirar fuori ogni minimo dettaglio per fornire il giusto software (ed incrociare le dita che abbiano individuato i giusti elementi).

I requisiti Agili, invece, dipendono da una comprensione del cliente condivisa tra product owner, designer e team di sviluppo. Tale comprensione condivisa del cliente target è di immenso valore per i product owner. Questi possono infatti focalizzarsi sui requisiti di alto livello e lasciare che sia il team di sviluppatori ad occuparsi dei dettagli di implementazione. Loro ne sono totalmente in grado, proprio grazie a quella medesima comprensione condivisa (Boom!)

CREARE UNA COMPRENSIONE CONDIVISA TRA TEAM

Se ti interessa creare una comprensione condivisa, ma non hai la più pallida idea di come fare, basta seguire questi suggerimenti:

• Quando effettui interviste al cliente, fa’ partecipare anche un membro dei team di design e sviluppo, in modo che ascoltino direttamente dal cliente piuttosto che fare affidamento esclusivamente sulle note del product owner. Ciò darà loro anche la possibilità di approfondire maggiormente gli argomenti più critici mentre il tema è ancora fresco nella mente del cliente.
• Fa’ dello sviluppo e dell’utilizzo di customer personas un lavoro di squadra. Ciascun membro del team ha le proprie prospettive e intuizioni, e ha necessità di comprendere che influenza hanno i diversi ruoli sullo sviluppo del prodotto.
• Inoltre, occupati dello smistamento di issue e del governo del backlog. Queste sono ottime opportunità per  assicurarti che tutti siano allienati e comprendere perché il product owner ha dato proprio quell’ordine di priorità al lavoro da svolgere.

      

Vuoi provare? Iscriviti o accedi a Confluence >>
Crea un template di intervista ai clienti per documentare le idee dei tuoi clienti. Segui il nostro tutorial su come condurre interviste di valore ai clienti:

• Crea migliori pagine di intervista clienti
• Trasforma le informazioni in conoscenza con la Piramide di Intervista al Cliente

Quando il team e il product owner condividono la stessa mentalità, una documentazione di requisiti ultra-dettagliata è superflua.

Situazioni da evitare:

• L’intero progetto è già dettagliato con gran specificità prima che il lavoro ingegneristico abbia inizio
• Revisioni approfondite e sign-off rigidi sono richiesti da tutti i team prima ancora di avviare i lavori
• I designer e gli sviluppatori non sanno se e quando sono stati aggiornati i requisiti
• I requisiti non vengono mai aggiornati
• Il product owner scrive i requisiti senza il contributo del team

Ok: hai appena finito di discutere col tuo designer e ingegnere su una serie di user stories. Sei andato avanti e indietro, hai avuto alcune discussioni alla lavagna, e hai finito per concludere che ci sono ancora alcune dimensioni di cui tener conto per quella feature sulla quale state lavorando. Hai bisogno di approfondire alcune ipotesi sulle quali vi state basando, comprendere come ciò si inserisca nello schema complessivo delle cose e tener traccia di tutte quelle domande che devono ancora trovare una risposta. Qual è il prossimo passo?

MANTENERE I REQUISITI SNELLI IN UNA PAGINA-CRUSCOTTO

Quando si scrive un documento di requisiti, è utile utilizzare un modello coerente tra i team in modo che tutti possano seguire insieme e dare un feedback. In Atlassian, usiamo Confluence per creare i requisiti di prodotto con l’apposito blueprint. Abbiamo scoperto che una sezione simile a quella che vi presentiamo fornisce il giusto livello di contesto per comprendere i requisiti di progetto e il suo impatto sugli utenti:

1. Definire le specifiche di progetto

Vi suggeriamo di inserire direzioni di alto livello a inizio pagina, nella maniera che segue:

• Partecipanti: chi è incluso? Definisci il product owner, il team e gli stakeholder
• Status: qual è lo stadio corrente del progetto? In target, a rischio, in ritardo, rinviato..
• Target di release: per quando è programmato il rilascio?

2. Obiettivi del team e di business

Va’ dritto al punto. Informa ma senza annoiare

3. Contesto e strategia

Perché stiamo facendo questo? Come si integra ciò gli obiettivi generali d’azienda?

4. Ipotesi

Elenca le assunzioni tecniche, di business o di utenti sulla quale vi state eventualmente basando

5. User Stories

Elenca o inserisci i collegamenti verso le user stories coinvolte. Inserisci anche link alle interviste effettuate e screenshot utili. Fornisci informazioni sufficienti a creare una storia completa, includendovi anche le metriche di successo.

6. Interazione utente e design

Dopo che il team ha dato soluzione per ogni user story, inserisci esplorazioni progettuali e wireframe nella pagina

7. Domande

Quando il team ha compreso il problema da risolvere, probabilmente avrà delle domande. Inserisci una tabella di “Cose da decidere o ricercare” per tener traccia di tutti questi item

8. Cosa non stiamo facendo

Per mantenere la squadra concentrata sul lavoro può essere utile definire chiaramente gli argomenti che rimangono fuori del campo di applicazione al momento, ma che potrebbero essere considerati in un secondo momento

ProTip: Il manifesto Agile ci ricorda che possiamo essere flessibili nel modo in cui creiamo i requisiti. Alcuni team svolgono esercizi per la mappatura delle user stories per identificare problemi e soluzioni. A volte l’intera triade responsabili di prodotto (product owner, sviluppatore e designer) visitano un cliente e successivamente fanno brainstorming per individuare la soluzione ad un particolare problema segnalato dal cliente.

Non importa come i requisiti vengano individuati, è importante che il team li considerino come uno dei diversi modi con cui definire e comunicare i problemi del cliente. Va’ alla nostra sezione sull’ agile design per comprendere come i product owner possono usare Keynote e Powerpoint per convertire esperienze reali in requisiti.

Esempio di PRD in una singola pagina

Qui puoi osservare un approfondito documento di requisiti prodotto che abbiamo creato in Confluence.

Ricorda che non ci sono due requisiti di prodotto che saranno perfettamente uguali. Usa questo esempio per comprendere i differenti elementi da includere nel tuo PRD, ma non la maniera definitiva in cui farlo.

Vuoi provare? Iscriviti o accedi a Confluence >>

Una volta effettuato l’accesso, seleziona il blueprint per i requisiti di prodotto, poi segui il nostro tutorial per iniziare a impostare i requisiti.

• Come creare un documento per i requisiti di prodotto

Aspetti principali del metodo “a una pagina”

Se vuoi apprendere qualcosa di utile da questo blog post, cerca di comprendere il “perché”, e non il “cosa”. E’ infatti il “perché” che potrà aiutarti a selezionare ciò che è più adatto al tuo team.

Ecco i vantaggi e le sfide che abbiamo osservato con l’approccio dashboard (cruscotto) a una pagina:

VANTAGGI

1. Una pagina, una fonte

Rendi le cose semplici. Il product requirements document (PRD) diventa la “landing page” per tutto ciò che è collegato all’insieme di problemi entro un particolare epic. In questo modo i membri del tuo team risparmiano tempo nel reperire le informazioni e ottengono una visione chiara e coincisa.

2. Extra agilità

Una delle cose migliori nell’usare una singola pagina su cui collaborare (piuttosto che un requirements management tool dedicato) è che puoi gestire la tua documentazione in maniera agile! Non devi necessariamente attenerti al medesimo formato di volta in volta. Fa’ ciò di cui hai bisogno, quando ne hai bisogno, sii agile. Taglia e cambia all’occorrenza.

3. Il livello giusto di contesto e dettaglio

Spesso dimentichiamo quanto un link possa essere semplice e utile allo stesso tempo. Noi inseriamo un sacco di link nei nostri PRD. Ciò aiuta a ridurre la complessità e a rivelare le informazioni al lettore all’occorrenza. Può essere utile inserire link del genere:

• Interviste al cliente per dare un background, una convalida o un ulteriore contesto alla feature
• Pagine o blog in cui sono state discusse idee simili
• Precedenti discussioni o documentazioni tecniche e diagrammi
• Video di demo del prodotto o altro contenuto correlato proveniente da fonti esterne

4. Stories dinamiche

Vedo un sacco di clienti fare questo. Una volta che le stories sono state elaborate e inserite come issue in JIRA Software, è possibile collegarle alla nostra pagina (e, di conseguenza viene creato anche un collegamento dalla issue alla pagina). La sincronizzazione bi-direzionale tra Confluence e JIRA Software permette di osservare lo stato corrente della issue direttamente dalla pagina dei requisiti.

5. Saggezza collettiva

Catturare requisiti di prodotto in Confluence rende facile per membri di team differenti dare il proprio contributo o suggerimenti. Sono stato sorpreso di quanto spesso qualcuno da un altro team si inserisse in una conversazione con un commento che fornisse un importante feedback, suggerimento o lezione apprese da progetti simili. Ciò aiuta una grande organizzazione a sentirsi parte di un unico piccolo team

6. Inserimento di “extra”

Diagrammi costruiti con strumenti come  Visio, Gliffy, o Balsamiq aiutano a comunicare meglio i problemi al tuo team. Inoltre, puoi inserire immagini e video da fonti esterne, e contenuti dinamici.

7. Collaborazione!

La cosa più importante di tutto ciò è coinvolgere tutti. Non redigere mai un PRD da solo – dovresti sempre avere con te uno sviluppatore e redigere il documento insieme. Commenta, fa’ domande, incoraggia gli altri a contribuire con i propri pensieri e le proprie idee. Questo è particolarmente importante per i team dislocati che spesso non hanno la possibilità di discutere un progetto di persona.

SFIDE

In ogni approccio ci sono degli aspetti negativi. Ecco di seguito le 2 sfide principali che abbiamo affrontato e osservato dai clienti

1. La documentazione può diventare datata

Cosa succede quando si implementa una story e si ricevono feedback e poi si modifica la soluzione? Qualcuno torna mai indietro per aggiornare la pagina dei requirements con l’implementazione finale? Questa è una sfida per ogni tipo di documentazione, e vale sempre la pena chiedersi fronteggiare trade-off del genere. Parla col tuo team della maniera in cui comportarsi in situazioni simili.

2. Mancanza di partecipazione

“Cosa posso fare per incoraggiare le persone a lasciare un commento?”, “Come posso invogliarle a scrivere più specifiche e stories sul nostro intranet?”. Questo è un bel problema da affrontare, e spesso si finisce per adottare diversi wiki all’interno dell’organizzazione. Ci sono innumerevoli risorse per aiutarvi a superare il problema. Tuttavia, molto spesso le maggiori cause sono di natura culturale.

E ora, al lavoro!

Quando i requisiti sono agili, il product owner ha più tempo per comprendere e adeguarsi ai cambiamenti del mercato. E il mantenere i requisiti informativi-ma-sintetici rende il team di sviluppo in grado di adottare qualsiasi implementazione si adegui meglio alla propria architettura e tecnologia.

Articolo originale: https://www.atlassian.com/agile/requirements?utm_source=newsletter&utm_medium=email&utm_campaign=jira-insiders-newsletter_april-2017&jobid=101413815&subid=906751488

di Dan Radigan, Senior Agile Evangelist of Atlassian

Traduzione di Davide Schillaci

[metform form_id=”15820″]