Nel mondo del product management, una comunicazione chiara e precisa con i developer è fondamentale per garantire il successo del prodotto. Uno degli strumenti più efficaci per raggiungere questo obiettivo è la redazione di un ticket ben strutturato. Il ticket fornisce ai developer le informazioni necessarie per implementare una specifica funzionalità del prodotto, mantenendo sempre la prospettiva dell’utente al centro del processo.
In questo articolo, esploreremo come scrivere un ticket efficace, concentrandoci sugli elementi chiave per completarlo, quali la descrizione, gli acceptance criteria (AC), gli user flow e prototipi, le dipendenze, il copy, la gestione degli stakeholder e i sign-off, e l’identificazione degli elementi fuori scopo.
Descrizione
La descrizione è la prima parte del ticket e dovrebbe fornire informazioni dettagliate sulla funzionalità attesa in un linguaggio comprensibile anche a persone senza conoscenze tecniche.
All’interno della descrizione si possono includere informazioni sul contesto, i requisiti funzionali e non funzionali, ed eventuali riferimenti a documenti o risorse esterne utili. Un errore da evitare è aggiungere informazioni non pertinenti, dare indicazioni troppo dettagliate sull’aspetto della funzionalità, o eccessivamente tecniche.
User Story
La user story è una descrizione breve e concisa del problema o della necessità dell’utente, espressa dal punto di vista dell’utente stesso. È importante che la user story sia chiara, specifica e focalizzata sul valore che la funzionalità porterà agli utenti. Per scrivere una buona user story, segui questo formato:
Come [ruolo utente],
voglio [azione]
per poter [beneficio]”.
Esempio: “Come utente registrato, voglio poter aggiungere prodotti al mio carrello per poterli acquistare in seguito.”
Acceptance Criteria (AC)
Gli acceptance criteria (spesso abbreviati in AC) sono un insieme di condizioni che devono essere soddisfatte affinché la funzionalità sia considerata completa e funzionante correttamente. Gli acceptance criteria aiutano a stabilire le aspettative riguardo la user story e a ridurre le ambiguità tra i team di product management e sviluppo. Per scrivere dei buoni acceptance criteria, assicurati che siano:
- Semplice e comprensibili
- Testabile e misurabili
- Indipendente da soluzioni tecnologiche specifiche
Esempio di AC per la user story sopra menzionata:
- L’utente può aggiungere un prodotto al carrello cliccando sul pulsante “Aggiungi al carrello”.
- Il prodotto viene visualizzato nel carrello con le informazioni rilevanti (nome, prezzo, quantità).
- L’utente può modificare la quantità di un prodotto nel carrello.
Un modo spesso utilizzato e molto apprezzato dai developer per spiegare gli acceptance criteria è usando il linguaggio Gherkin. Semplificando, la formula (in inglese Given/When/Then) è la seguente:
Dato [un contesto]
Quando [accade un evento]
Allora [produce un risultato]
L’esempio precedente in linguaggio Gherkin si tradurrebbe in questo modo:
Scenario: Aggiungere un prodotto al carrello
Dato che l’utente si trova sulla pagina del prodotto
Quando l’utente clicca sul pulsante “Aggiungi al carrello”
Allora il prodotto viene aggiunto al carrello
Scenario: Visualizzare il prodotto nel carrello con informazioni rilevanti
Dato che l’utente ha aggiunto un prodotto al carrello
Quando l’utente visualizza il carrello
Allora il prodotto viene visualizzato nel carrello con nome, prezzo e quantità
Scenario: Modificare la quantità di un prodotto nel carrello
Dato che l’utente ha aggiunto un prodotto al carrello
Quando l’utente modifica la quantità del prodotto nel carrello
Allora la quantità del prodotto nel carrello viene aggiornata
User flow e prototipi
Gli elementi di design che aiutano i developer a capire in che modo la funzionalità vada sviluppata sono un altro elemento fondamentale per scrivere una buon ticket.
Lo user flow descrive il percorso che l’utente seguirà per completare un’azione specifica all’interno dell’applicazione o del sito web. Gli user flow aiutano a identificare eventuali problemi di usabilità e a garantire che l’esperienza dell’utente sia fluida e intuitiva.
I prototipi sono sono strumenti visivi che mostrano l’aspetto dell’interfaccia utente e la disposizione degli elementi su schermo. Possono essere a bassa risoluzione, ad esempio mock-up o wireframes, o prototipi ad alta risoluzione. Essi consentono ai developer di comprendere meglio le aspettative estetiche e funzionali del prodotto e di evitare eventuali incomprensioni o errori.
User flow e prototipi sono necessari specialmente nel caso dello sviluppo di una nuova funzionalità o quando il team di developer non ha molta familiarità con il prodotto.
Dipendenze
Le dipendenze sono gli elementi che devono essere completati prima che la funzionalità possa essere implementata. Indicare le dipendenze aiuta i developer a pianificare e organizzare il loro lavoro in modo efficiente. Esempi di dipendenze possono includere l’integrazione con API esterne, la creazione di componenti di interfaccia utente o la realizzazione di altre funzionalità correlate.
Da non sottovalutare, specialmente se si opera in aziende di grandi dimensioni e con prodotti complessi, sono le dipendenze con altri team. È importante identificarle e risolvere per tempo, in modo da evitare spiacevoli sorprese e rallentamenti in fase di sviluppo.
Fuori scopo
Un accorgimento utile per evitare fraintendimenti, è definire chiaramente ciò che non è incluso nel ticket. Questo include tutti gli elementi o le funzionalità che non fanno parte del lavoro previsto per questa specifica storia, ma sui quali ci sono opinioni diverse all’interno dell’organizzazione o che sono stati sollevati come possibili ramificazioni della funzionalità.
Stabilire gli elementi “fuori scopo” aiuta tanto a prevenire eventuali malintesi e risparmiare il tempo necessatio a chiarirli, quanto a mantenere il focus sui requisiti essenziali della funzionalità.
Stakeholders e sign-off
Identificare gli stakeholder principali coinvolti nella funzionalità e assicurarsi che approvino i requisiti definiti prima che i developer inizino a lavorarci è fondamentale per garantire che tutti gli interessati siano allineati.
Copy e traduzioni
Il copy si riferisce a tutti i testi che verranno utilizzati nell’interfaccia utente, come pulsanti, titoli, descrizioni e messaggi di errore. Fornire ai developer il copy definitivo e le relative traduzioni all’interno del ticket è importante per garantire una corretta comunicazione con gli utenti e per evitare errori o ritardi dovuti a modifiche successive del testo.
Conclusione
La redazione di un ticket ben strutturato è fondamentale per garantire una comunicazione chiara e precisa tra il team di product management e i developer. Un ticket efficace contiene una descrizione dettagliata, una user story ben definita, acceptance criteria chiari e misurabili, user flow e prototipi, le dipendenze, gli elementi fuori scopo, la gestione degli stakeholder e i sign-off, e infine il copy e le traduzioni necessarie.
Seguendo questi passaggi, potrai assicurarti che il tuo team abbia tutte le informazioni necessarie per implementare con successo le funzionalità richieste, migliorando l’efficienza del processo di sviluppo e riducendo al minimo le incomprensioni e i ritardi. Ricorda che una buona comunicazione tra i vari team è alla base del successo di ogni prodotto.
