Il costo nascosto dei ticket Jira vaghi
Un ticket Jira vago raramente sembra rischioso all’inizio. Il vero problema compare più tardi, quando persone diverse colmano i vuoti con ipotesi diverse e diversi giorni di lavoro concentrato finiscono puntati nella direzione sbagliata.
Perché i ticket vaghi sopravvivono
Una sviluppatrice backend prende in carico un ticket il lunedì mattina. Il titolo sembra specifico: "Aggiungere notifiche utente sugli aggiornamenti dell’ordine". La descrizione contiene due frasi e un link a un thread Slack di tre settimane prima. A prima vista sembra sufficiente. Lei passa tre giorni a costruire una pipeline di notifiche e-mail attivata a ogni cambio di stato dell’ordine.
Il giovedì, durante la review della PR, la PM entra e dice: "Non intendevo questo. Ci servivano solo notifiche in-app per gli eventi di spedizione, e gli utenti dovevano poterle disattivare". Nessuno aveva torto. Nessuno aveva lavorato male. Il ticket semplicemente non aveva mai fatto emergere le decisioni che teneva nascoste.
Nessuno scrive un ticket vago di proposito. Lo si scrive in due minuti tra una riunione e l’altra, con la sincera intenzione di tornarci sopra più tardi e aggiungere dettagli. Poi quel momento non arriva mai. Chi lo scrive ha tutto il contesto in testa. Sa quali eventi contano, quali canali ha in mente, quali utenti verranno coinvolti.
Nulla di tutto questo finisce sulla pagina, perché a chi scrive sembra ovvio. Per chiunque altro, non lo è.
Jira peggiora la situazione proprio perché la rende facile. Non esiste un campo obbligatorio che chieda cosa sia esplicitamente fuori ambito. Non c’è nessun vincolo che rifiuti una descrizione sotto le venti parole. Puoi scrivere tre parole nel riepilogo, lasciare vuota la descrizione e premere Crea. Jira non ti ferma. È un vantaggio e una trappola insieme. Il risultato è un backlog pieno di ticket che a colpo d’occhio sembrano completi e mostrano la loro vaghezza solo quando qualcuno inizia davvero a costruire.
Cosa contiene davvero un piano pronto da costruire
La maggior parte dei ticket risponde a una sola domanda: che cosa vogliamo? Un piano pronto da costruire ne risponde sei.
| Parte | A cosa risponde |
|---|---|
| Ambito | Che cosa rientra e che cosa è esplicitamente escluso |
| Vincoli | Che cosa non può cambiare né rompersi |
| Passi | Che cosa deve accadere e in quale ordine |
| Casi limite | Che cosa succede quando il percorso più ovvio si rompe |
| Dipendenze | Che cosa deve esistere prima |
| Definizione di completato | Come tutti sapranno che il lavoro è davvero finito |
Questa non è una lista da usare per ogni minuscolo bugfix del backlog. Però qualsiasi cosa entri in sprint, qualsiasi attività che probabilmente consumerà più di qualche ora del tempo di qualcuno, ha bisogno di queste risposte prima di partire. L’ambito è la parte che i team saltano più spesso. Dire cosa resta fuori sembra superfluo quando tutti sono concentrati su ciò che sta dentro. Eppure è proprio lì che nasce una quantità sorprendente di rifacimenti.
I vincoli sono i requisiti silenziosi:
- Non rompere il flusso esistente di e-mail sugli ordini.
- Restare dentro l’attuale servizio di notifiche.
- Nessuna nuova infrastruttura in questo sprint.
Questi dettagli raramente vengono scritti perché chi redige il ticket presume che tutti li conoscano già. Non è così. E la definizione di completato è la linea che separa "secondo me è finito" da "siamo tutti d’accordo che è finito". Una buona definizione di completato è osservabile e verificabile.
Le domande vengono prima della struttura
Ogni istanza di Jira, prima o poi, attraversa lo stesso ciclo. Qualcuno aggiunge un template alla descrizione con sezioni come Riepilogo, Criteri di accettazione, Note tecniche e Fuori ambito. Per qualche settimana tutti lo compilano. Poi lo stesso linguaggio vago che prima viveva in una descrizione spoglia comincia semplicemente a distribuirsi in più caselle etichettate. La struttura è migliorata. Il modo di pensare no.
I template non risolvono il problema perché il problema non è strutturale. È cognitivo. Chi scrive non sa che cosa gli manca. Una sezione vuota chiamata Casi limite non aiuta chi non ha ancora pensato ai casi limite. Le domande invece sì. Domande specifiche, concrete, che costringono a decidere.
Cinque domande fanno emergere particolarmente bene le decisioni nascoste:
- Che cosa cambia nel comportamento del sistema?
- Chi è l’attore principale e che cosa sta cercando di ottenere?
- Esiste un caso in cui questo non dovrebbe accadere?
- Che cosa si rompe se non rilasciamo questa cosa?
- Vale per utenti esistenti, nuovi utenti o entrambi?
Queste domande funzionano perché sono abbastanza precise da poter ricevere una risposta, ma abbastanza ampie da valere per quasi qualsiasi ticket di funzionalità. Rispondere a queste domande è già pianificazione. Il template è solo il posto in cui le risposte finiscono.
Esempio completo
Ecco come si presenta nella pratica. Il ticket originale è minuscolo: "Aggiungere notifiche utente sugli aggiornamenti dell’ordine". La descrizione dice soltanto che gli utenti devono ricevere una notifica quando lo stato dell’ordine cambia e include una nota per verificare con il design il trattamento visivo. Basta per farlo entrare in sprint, ma è ben lontano dall’essere sufficiente per sviluppare con sicurezza.
Un breve giro di chiarimento cambia tutto:
| Domanda di chiarimento | Risposta |
|---|---|
| Quali cambi di stato contano? | Solo spedito e consegnato |
| Quali canali? | Solo in-app per questo sprint |
| Gli utenti possono disattivarle? | Sì, con preferenza predefinita attiva |
| Che succede con utenti offline? | La notifica resta in coda fino al login successivo |
| Vale per ordini esistenti? | No, solo per quelli nuovi |
| Che succede se la consegna fallisce? | Un tentativo di nuovo, poi registrazione nel log |
Quindici minuti dopo, il ticket significa una sola cosa per tutti. La versione finale ha un ambito reale, vincoli reali, passi ordinati, casi limite reali e una definizione di completato verificabile. È lo stesso ticket. La chiarezza è completamente diversa. La differenza non è un template migliore. È una piccola quantità di domande poste con intenzione prima di iniziare il lavoro.
Dove entra l’IA in questo processo
L’IA non scrive i ticket. I ticket li scrivono le persone. Però l’IA è utile in un punto molto specifico del processo: dopo che l’intento esiste, prima che la struttura sia definitiva. Un modello linguistico sa leggere una descrizione vaga e chiedere: "Avete considerato cosa succede quando l’utente è offline?" Sa prendere risposte sparse dentro un thread Slack e organizzarle in ambito, vincoli e passi. Sa notare che il piano cita una migrazione del database ma nella lista delle dipendenze non compare la revisione delle persone giuste.
Quello che l’IA non sa fare bene è prendere al posto tuo le decisioni di prodotto. Può chiedere se questa cosa debba essere un’e-mail, una push notification o una notifica in-app. Non può decidere quale di queste opzioni sia corretta per i tuoi utenti e per questo sprint. Può generare una definizione di completato plausibile, ma solo una persona che conosce davvero il prodotto può sapere se quella definizione è giusta.
Lo schema è semplice: gli umani decidono, l’IA struttura. Gli umani definiscono l’ambito, l’IA intercetta i buchi. È proprio su questo schema, chiarire, pianificare, eseguire, che è costruito Just su Atlassian Marketplace dentro Jira. Lo stesso schema funziona anche manualmente. L’IA rende solo il ciclo più veloce.
Tre cose da applicare oggi
- Prima del prossimo sprint, prendi il ticket più vago del backlog e poni le cinque domande di questo articolo prima che qualcuno scriva codice. Quasi sicuramente troverai almeno due decisioni che nessuno aveva realizzato fossero ancora aperte.
- Scrivi le risposte come ambito, vincoli e definizione di completato verificabile, non in un documento separato, ma nel ticket stesso, dove la persona che dovrà svilupparlo le vedrà davvero.
- Considera il template qui sopra come un punto di partenza, non come uno standard rigido. Adattalo al linguaggio del tuo team, ma non saltare le domande. Se vuoi il quadro più ampio del perché questo passaggio di chiarimento conta ancora di più quando i ticket vaghi vengono passati direttamente all’IA, il primo articolo della serie spiega nel dettaglio il problema di allineamento: Perché la maggior parte degli strumenti di IA per Jira peggiora il problema di allineamento invece di risolverlo.
