Documenti sui requisiti del prodotto, versione ridotta

A nessuno piace scrivere documenti pesanti e ultra dettagliati sui requisiti del prodotto. A quanto pare, a nessuno piace nemmeno usarli.

Dan Radigan Dan Radigan
Esplora argomenti

Riepilogo: il documento sui requisiti del prodotto (PRD) definisce i requisiti di un particolare prodotto, inclusi lo scopo, le funzioni, la funzionalità e il comportamento del prodotto. Serve come guida per i team aziendali e tecnici per aiutarli a creare, lanciare o commercializzare il prodotto.

Creare un ottimo prodotto richiede montagne di ricerche e una pianificazione completa. Ma da dove si inizia? I product manager spesso iniziano con un documento sui requisiti del prodotto (PRD).

Un documento sui requisiti del prodotto definisce il prodotto che si sta per creare: ne delinea lo scopo, le funzioni, le funzionalità e il comportamento.

Documenti sui requisiti del prodotto Agile | Agile Coach Atlassian

Successivamente, condividi il PRD con gli stakeholder, chiedendo loro anche di dare un contributo, e con i team aziendali e tecnici che ti aiuteranno a creare, lanciare o commercializzare il prodotto.

Una volta che tutti gli stakeholder sono allineati, il PRD funge da bussola, fornendo una chiara direzione verso lo scopo di un prodotto e creando una base di conoscenze condivise tra i team aziendali e tecnici.

Raccolta dei requisiti in un mondo Agile

Che aspetto ha il processo di raccolta dei requisiti in un mondo Agile? Sembra complicato, anzi lo è. Ma non preoccuparti. In Atlassian, sappiamo tutto sulla creazione di PRD in un ambiente Agile. Ecco alcune cose da tenere a mente:

I requisiti Agile sono i migliori alleati dell'owner di prodotto. Gli owner di prodotto che non utilizzano i requisiti Agile, si ritrovano a dover specificare ogni dettaglio per rilasciare il software giusto (e poi incrociano le dita sperando di aver specificato gli elementi giusti). I requisiti Agile, invece, dipendono da una conoscenza del cliente che è condivisa tra l'owner di prodotto, il designer e il team di sviluppo. La conoscenza condivisa e l'empatia nei confronti del cliente target dà vita a larghezze di banda nascoste per gli owner di prodotto, che possono concentrarsi sui requisiti di livello superiore e lasciare i dettagli dell'implementazione al team di sviluppo, che è perfettamente attrezzato per occuparsene grazie, anche in questo caso, a questa base di conoscenze condivise. (Boom).

Creazione di una base di conoscenze condivisa tra i team

Se sei entusiasta dell'idea di avere conoscenze condivise, ma non sai come crearle, prova alcuni di questi suggerimenti:

  • Quando conduci i colloqui con i clienti, includi un membro dei team di progettazione e sviluppo in modo che possano ascoltare direttamente il cliente invece di fare affidamento sulle note dell'owner di prodotto. Ciò darà loro anche la possibilità di approfondire quando l'argomento è fresco nella mente del cliente.
  • Rendi lo sviluppo e l'utilizzo di clienti tipo un impegno dell'intero team. Ogni membro del team ha prospettive e informazioni approfondite uniche e deve capire in che modo gli utenti tipo influenzano lo sviluppo del prodotto.
  • Rendi anche la valutazione dei ticket e il backlog grooming uno sport di squadra. Queste sono ottime opportunità per assicurarsi che tutti siano sulla stessa lunghezza d'onda e capire perché l'owner di prodotto ha stabilito una certa priorità per le attività da svolgere.

Vuoi provare? Registrati o accedi a Confluence >>

Crea un modello di colloquio con i clienti per documentare le informazioni approfondite raccolte su questi ultimi. Segui il nostro tutorial per iniziare a condurre utili colloqui con i clienti:

Anti-pattern a cui prestare attenzione
  • L'intero progetto è già dettagliato prima dell'inizio di qualsiasi attività di progettazione
  • Prima ancora che il lavoro inizi, sono necessarie una revisione approfondita e un'approvazione completa da parte di tutti i team
  • I designer e gli sviluppatori non sanno quando i requisiti sono stati aggiornati
  • Per cominciare, i requisiti non vengono mai aggiornati (perché tutti li hanno firmati, ricordi?)
  • L'owner di prodotto scrive i requisiti senza la partecipazione del team

Ok: hai parlato di una serie di storie utente con l'ingegnere e il designer. C'è stato uno scambio di messaggi, avete tenuto alcune sessioni di pianificazione e concluso che ci sono alcune altre dimensioni da considerare per la funzione su cui state lavorando. Devi rimpolpare alcune supposizioni, riflettere più a fondo su come tutto ciò si adatti al quadro generale e tenere traccia di tutte le domande aperte a cui devi rispondere. E poi?

Requisiti snelli con dashboard di una pagina

Quando si scrive un documento sui requisiti, è utile utilizzare un modello coerente a livello di team in modo che tutti possano seguire e fornire il proprio feedback. In Atlassian, utilizziamo Confluence per creare requisiti di prodotto con il modello di documento sui requisiti del prodotto. Abbiamo scoperto che la sezione seguente fornisce contesto "sufficiente" per comprendere i requisiti di un progetto e il suo impatto sugli utenti:

1. Definire le specifiche del progetto
Consigliamo di includere indicazioni generali nella parte superiore della pagina come segue:

  • Partecipanti: chi è coinvolto? Includi l'owner di prodotto, il team, gli stakeholder
  • Stato: qual è lo stato attuale del programma? Rispondente all'obiettivo, a rischio, ritardato, differito ecc.
  • Rilascio di destinazione: quando è previsto il rilascio?
Requisiti Agile | Agile Coach Atlassian

2. Obiettivi del team e obiettivi aziendali
Arriva subito al punto. Informa senza annoiare.

3. Background e valore strategico
Perché lo stiamo facendo? In che modo si inserisce negli obiettivi generali dell'azienda?

Requisiti di prodotto Agile | Agile Coach Atlassian

4. Presupposti
Elenca i possibili presupposti tecnici, aziendali o degli utenti.

5. Storie utente
Elenca o crea collegamenti alle storie utente coinvolte. Collega anche i colloqui con i clienti e includi gli screenshot di ciò che hai visto. Fornisci dettagli sufficienti per creare una story completa e includi le metriche di successo.

Story sui requisiti Agile | Agile Coach Atlassian

6. Interazione con l'utente e progettazione
Dopo che il team ha arricchito la soluzione per ogni storia utente, collega le esplorazioni di progettazione e i wireframe alla pagina.

diagramma di confronto

7. Domande
Via via che comprende i problemi da risolvere, spesso il team ha delle domande. Crea una tabella di "cose da decidere o su cui svolgere ricerche" per tenere traccia di questi elementi.

8. Cosa non stiamo facendo
Mantieni il team concentrato sul lavoro da svolgere evidenziando in modo chiaro gli elementi esclusi dal lavoro. Segnala gli elementi che al momento sono esterni all'ambito, ma che potrebbero essere presi in considerazione in un secondo momento.

Suggerimento:

Il Manifesto Agile ci ricorda che possiamo creare i requisiti in modo flessibile. Alcuni team eseguono esercizi di mappatura delle storie utente per identificare problemi e soluzioni. A volte l'intera triade del prodotto (owner di prodotto, sviluppatore e designer) si reca dal cliente e fa quindi un brainstorming delle soluzioni a un particolare problema menzionato dal cliente.

Indipendentemente da come nascono i requisiti, è importante che il team li consideri come uno dei tanti modi in cui può definire e comunicare i problemi dei clienti. Consulta la nostra sezione sulla progettazione Agile per scoprire come gli owner di prodotto possono utilizzare Keynote e Powerpoint per simulare esperienze reali come requisiti.

Esempio di requisiti del prodotto di una pagina

Ecco un documento completo sui requisiti del prodotto che abbiamo creato utilizzando Confluence. Ricorda che nessun requisito del prodotto è mai uguale all'altro. Usa questo esempio per capire i diversi elementi che dovrebbero essere inclusi nel PRD, ma tieni sempre presente che non si tratta dell'unica soluzione possibile.

Esempio di documento sui requisiti del prodotto | Agile Coach Atlassian
Documento sui requisiti del prodotto | Agile Coach Atlassian

Vuoi provare? Registrati o accedi a Confluence >>

Dopo aver eseguito l'accesso, scegli il modello dei requisiti del prodotto e segui il tutorial riportato di seguito per iniziare a impostare i requisiti:

Aspetti chiave dall'approccio con documento di una pagina:

Come concetto da tenere a mente dalla lettura di questo blog, cerca di comprendere il "perché" e non il "cosa", poiché il "perché" ti aiuterà a esplorare le soluzioni migliori per il tuo team. Ecco i vantaggi e le sfide che abbiamo riscontrato con l'approccio della dashboard di una pagina:

1. Una pagina, una sola fonte
Non complicare le cose. Il documento sui requisiti del prodotto diventa la "pagina di destinazione" per tutto ciò che riguarda l'insieme di problemi all'interno di un determinato epic. Avere un punto di riferimento centrale consente ai membri del team di risparmiare tempo per accedere a queste informazioni e offre loro una panoramica sintetica.

2. Agilità extra
Una delle cose fantastiche dell'utilizzo di una semplice pagina per la collaborazione (rispetto a uno strumento di gestione dei requisiti dedicato) è che puoi godere di agilità riguardo alla documentazione. Non devi seguire lo stesso formato ogni volta: fai ciò che ti serve, quando ti serve e muoviti con agilità. Taglia e cambia in base alla necessità.

3. La quantità giusta di contesto e dettagli
Spesso dimentichiamo quanto possa essere potente un semplice link. Incorporiamo molti link nei nostri documenti sui requisiti del prodotto: aiutano a estrarre la complessità e a divulgare progressivamente le informazioni al lettore secondo necessità. Il collegamento di risorse dettagliate può includere elementi come:

  • Colloqui con i clienti per informazioni di background, convalida o ulteriore contesto relativo alla funzionalità
  • Pagine o blog in cui sono state proposte idee simili
  • Discussioni o documentazione tecnica e diagrammi già esistenti
  • Video delle demo dei prodotti o altri contenuti correlati provenienti da fonti esterne

4. Story dinamiche
Vedo che anche molti clienti le usano. Una volta che le story sono state abbozzate e inserite come ticket in Jira Software, ci colleghiamo ad esse nella nostra pagina (che, opportunamente, crea anche un collegamento dai ticket alla pagina). La sincronizzazione bidirezionale tra Confluence e Jira Software ci consente di vedere automaticamente lo stato attuale di ogni ticket direttamente dalla pagina dei requisiti.

5. Saggezza collettiva
L'acquisizione dei requisiti di prodotto in Confluence consente ai membri di team diversi di contribuire e fornire suggerimenti. Sono rimasto stupito dal numero di volte in cui un membro di un altro team è intervenuto nella conversazione con un commento fornendo ottimi feedback, suggerimenti o nozioni apprese da progetti simili. In questo modo, le organizzazioni di grandi dimensioni possono avere l'impressione di essere un solo team.

6. Utilizzare degli "extra"
I diagrammi realizzati con strumenti come Visio, Gliffy o Balsamiq comunicano meglio i problemi al team. Puoi anche incorporare immagini esterne, video e contenuti dinamici.

7. Collaborazione
L'aspetto più importante di tutto questo è riuscire a coinvolgere tutti. Non scrivere mai un documento sui requisiti del prodotto da solo: dovresti sempre collaborare con uno sviluppatore per scriverlo insieme. Condividi la pagina con il team e ricevi il feedback. Commenta, fai domande, incoraggia gli altri a contribuire con pensieri e idee. Questo è particolarmente importante per i team distribuiti che spesso non hanno la possibilità di discutere dei progetti di persona.

Sfide

Ogni approccio ha i suoi aspetti negativi. Di seguito sono riportate due sfide principali che abbiamo affrontato e osservato anche dal punto di vista dei clienti:

1. La documentazione può diventare obsoleta
Cosa succede quando si implementa una story, si riceve un feedback e si modifica la soluzione di conseguenza? Qualcuno torna indietro e aggiorna la pagina dei requisiti con l'implementazione finale? Questa è una sfida che riguarda qualsiasi tipo di documentazione ed è sempre utile chiedersi se valga la pena fare compromessi di questo tipo. Parla con il tuo team su cosa faresti in uno scenario come questo.

2. Mancanza di partecipazione
"Cosa posso fare per incoraggiare le persone a lasciare un commento?", "Come posso incoraggiare le persone a scrivere più specifiche e story sulla nostra rete Intranet?" Questa è una bella gatta da pelare e si riduce a varie tecniche di adozione wiki all'interno dell'organizzazione. Ci sono molte risorse che puoi usare in questa situazione. Potrebbero esserci in gioco anche questioni culturali più profonde.

Ora mettiamoci al lavoro!

Quando i requisiti sono agili, l'owner di prodotto ha più tempo per capire e stare al passo con il mercato. E mantenere i requisiti esplicativi ma succinti consente al team di sviluppo di utilizzare qualsiasi implementazione si adatti meglio all'architettura e allo stack tecnologico.

Una volta che i requisiti di un progetto sono stati ragionevolmente ben preparati, consigliamo di collegare le storie utente nella sezione 5 sopra alle story corrispondenti nello strumento di monitoraggio dei ticket del team di sviluppo. Ciò rende il processo di sviluppo più trasparente: è facile vedere lo stato di ogni elemento di lavoro, il che consente all'owner di prodotto e ai team a valle, come quello di marketing e di assistenza, di prendere decisioni più informate.

Suggerimento:

Non tenere traccia delle storie utente che provengono dai requisiti del progetto in un sistema e dai difetti in un altro. La gestione del lavoro su due sistemi è una sfida inutilmente impegnativa e fa solo perdere tempo.

Ricorda: occorre essere agili nell'evoluzione dei requisiti di un progetto. Non è un problema cambiare le storie utente man mano che il team crea, rilascia e riceve feedback. Mantieni sempre alta la barra della qualità e una sana cultura di progettazione , anche se ciò significa rilasciare meno funzioni.