Perché Esistono i Ticket

La conoscenza del team conservata solo nelle teste è conoscenza del team con un singolo punto di fallimento. Un ingegnere che "sa e basta" come funziona la pipeline di deploy, quali variabili d'ambiente sono richieste, o perché il servizio di autenticazione ha quella strana logica di retry sta portando memoria istituzionale a cui il resto del team non può accedere, cercare o verificare.

I ticket esternalizzano quella conoscenza in un sistema condiviso e ricercabile. Quando un ingegnere crea un ticket per un pezzo di lavoro, non sta solo tracciando un'attività — sta registrando che il lavoro esiste, cosa richiede e perché è importante. Sei mesi dopo, quando qualcuno chiede "abbiamo mai risolto la race condition nel flusso di pagamento?", la risposta è una query di ricerca, non un messaggio Slack a qualcuno che potrebbe aver lasciato l'azienda.

L'alternativa — tenere il lavoro nelle teste, nei thread di Slack e nei post-it — funziona per un team di 3 persone in una stanza con memoria perfetta. Si rompe nel momento in cui qualcuno va in vacanza, cambia progetto o si licenzia. Ogni pezzo di conoscenza conservato esclusivamente nella testa di una persona è un rischio bus-factor che il team sceglie di portarsi dietro. I ticket non eliminano il bisogno di conversazione, ma danno a quelle conversazioni un artefatto durevole che sopravvive alle persone che le hanno avute.

Ogni decisione non banale in una codebase viene prima o poi messa in discussione. "Perché abbiamo aggiunto questo endpoint?" "Chi ha deciso di abbandonare il supporto per IE?" "Quando è cambiata la logica dei prezzi?" Senza ticket, rispondere a queste domande richiede archeologia — scavare in Slack, contattare ex colleghi, leggere i diff dei commit e indovinare l'intento.

I ticket creano una traccia delle decisioni. Ogni ticket registra chi ha richiesto il lavoro, quando è stato prioritizzato, quali erano i criteri di accettazione e — attraverso PR e commit collegati — esattamente quale codice è cambiato per soddisfarlo. Non è burocrazia; è la differenza tra "penso che l'abbiamo cambiato a marzo" e "ecco il ticket, la PR e la discussione della review".

La tracciabilità conta anche per la conformità e la risposta agli incidenti. Quando emerge un bug in produzione, la domanda "cos'è cambiato di recente?" dovrebbe richiedere secondi, non ore. Un team con una buona igiene dei ticket può tracciare da un deploy a un merge, da un merge a una PR, da una PR a un ticket, e da un ticket alla richiesta originale. Un team senza può solo leggere git log e indovinare.

I ticket sono il livello di coordinamento per i team che non possono stare nella stessa stanza allo stesso momento. In un team co-localizzato di tre persone, puoi coordinarti girando la sedia. In un team distribuito di otto persone su tre fusi orari, "basta parlare tra voi" non è una strategia di coordinamento — è un desiderio.

Un sistema di ticket dà a ogni pezzo di lavoro un URL stabile, uno stato e un proprietario. Un ingegnere a Londra può prendere un ticket, vedere cosa ci si aspetta, controllare i criteri di accettazione e iniziare a lavorare — senza aspettare che l'ingegnere a San Francisco che l'ha creato si svegli. Il ticket è il punto di passaggio asincrono.

Questo scala verso il basso così come verso l'alto. Anche un team co-localizzato beneficia del coordinamento asincrono quando le persone sono in riunione, malate o immerse in lavoro di concentrazione. Il ticket è sempre disponibile. La persona che l'ha scritto no.