Puoi utilizzare i Documenti ClickUp per comunicare i requisiti del prodotto con il tuo team di ingegneria e gli stakeholder.
Continua a leggere per scoprire come Sam ha risolto un importante problema di comunicazione per il suo team Agile!
Incontra Sam
Sam è un product manager per una compagnia di software basata sul cloud. Stanno lavorando a una funzionalità specifica del loro prodotto con un team dedicato che include:
-
Un designer
-
Due sviluppatori
-
Un ingegnere QA
La sfida
Il team collabora bene, ma Sam nota che durante le riunioni giornaliere standup il team passa la maggior parte del tempo a fare domande a Sam sulla funzionalità e su come dovrebbe funzionare.
Sam decide di fornire indicazioni al team al di fuori delle riunioni rapide usando ClickUp Docs.
La soluzione
Sam decide che ogni funzionalità dovrebbe avere il proprio documento. Quando il team lavora su una funzionalità, tutte le informazioni rilevanti dovrebbero essere raccolte in un unico posto.
Utilizzare le pagine all'interno di un documento consente al team di trovare rapidamente le risposte pertinenti senza cercare e sfogliare documenti separati.
Sam crea alcune pagine all'interno del Doc per strutturare il brief del prodotto in base a ciò che il team deve sapere e potrebbe cercare.
-
Carta del team di funzionalità
-
Requisiti di progettazione
-
Requisiti funzionali
-
Requisiti UX
Consiglio: Cerca pagine specifiche o contenuti all'interno di un Doc utilizzando la funzione di ricerca!
Sam aggiunge titoli e altri elementi di formattazione a ogni pagina per comunicare la loro visione della funzionalità.
Sam condivide il documento con il team delle funzionalità. Lavorano insieme per redigere e concordare lo statuto.
Sam invita il team a fare domande aggiungendo commenti sul Documento, così tutti possono vedere le domande e le risposte.
Retrospettiva
Alcuni Sprint passano velocemente, e il team è grato per il Documento che li ha guidati. Le riunioni di Stand-up sono ora molto più efficienti ed efficaci.
Un miglioramento della funzionalità è stato implementato e aggiunto al prodotto. Sfortunatamente, ciò causa un nuovo errore in un'altra parte della funzionalità che non è stata aggiornata nella release.
Gli sviluppatori correggono rapidamente l'errore e, nella loro prossima retrospettiva, il team di funzionalità discute su come questo avrebbe potuto essere evitato.
Un ingegnere QA suggerisce una sorta di criteri di accettazione affinché nessuna modifica possa essere inviata alla produzione a meno che tutti i criteri di test non siano soddisfatti.
Il team è d'accordo! Sam aggiunge una nuova pagina al documento di sintesi della funzionalità per documentare i criteri di accettazione della funzionalità.
Sam utilizza i Blocchi di Codice ( /co ) per formattare i requisiti dei criteri di accettazione, poiché il team è già familiare con Gherkin, e ClickUp lo supporta per i blocchi di codice!
Il risultato
Mentre il team delle funzionalità implementa ulteriori miglioramenti e risolve bug, sempre più clienti adottano la funzionalità. Il team delle funzionalità cresce per includere altri due sviluppatori e un altro ingegnere QA.
I nuovi membri del team si adattano rapidamente e iniziano a contribuire con l'aiuto del documento di specifiche delle funzionalità di Sam!
Sam condivide anche il modello di documento per le specifiche delle funzionalità con altri responsabili di prodotto affinché possano adattarlo per i loro team basati su funzionalità.
È una grande vittoria per il team di Sam e anche per altri!