Migra alla versione Cloud con GetConnected! Atlassian server – end of support in…
Giorni
Ore
Minuti
Secondi

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:

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.

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.

Una volta che i requirements di progetto sono stati raccolti a regola d’arte, raccomandiamo di collegare le stories utenti (visti nella sezione 5) alle loro stories corrispondenti nell’issue tracker del team di sviluppo. Ciรฒ rende il processo di sviluppo piรน trasparente: รจ facile osservare lo status di ciascuna parte del lavoro, il che porta a delle decisioni piรน consapevoli da parte del product owner, e a cascata lo stesso vale anche per i team di marketing e support.

ProTip: Non tracciate le user stories che vengono dai requirements di un progetto in un sistema e i difetti in un altro sistema. Gestire il lavoro attraverso 2 sistemi รจ inutilmente impegnativo e fa solo sprecare tempo.

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