L'importanza della descrizione dei ticket...

La corretta gestione dei ticket, si sa, è una questione difficile. O meglio, non è certo la difficoltà di compilare
qualche campo in una form web, bensì è lo shift mentale che vi è richiesto per organizzare
bene i singoli ticket e le varie attività.


Un errore che vedo fare molto spesso, anche da persone che si definiscono dei professionisti informatici è quello
di usare la descrizione del ticket come il testo di una email. Ecco un esempio inventato ma non molto lontano
da diversi ticket che vedo regolarmente:

Ciao Mr.X,
avrei bisogno che mi controllassi il problema di stampa dei pdf prodotti in automatico, che hanno
l'orientamento orizzontale e non verticale. Questo non è comunque urgente, piuttosto è molto
urgente risolvere il problema di autenticazione del nuovo collega G., che non riesce
ad accedere al sistema.

Saluti,
Mr. Y

Quanti errori ci sono nella descrizione del suddetto ticket?


Anzitutto il tono "discorsivo" e quasi formale con saluti di apertura e chiusura, cosa corretta in una email, ma non
in un ticket (che ha già un owner (Mr. Y) e un assignee (Mr. X). Tali dettagli fanno solo perdere tempo e spazio,
e non sono assolutamente rilevanti per la risoluzione del ticket stesso.


Il secondo errore è la specificazione, verbale, della priorità dell'attività: […]non è comunque _urgente_[…].
Tutti i sistemi di ticketing includono la possibilità di specificare la priorità delle singole attività collegate
al ticket, e il modo corretto di farlo è ovviamento usando tali campi. Perché? Beh, semplicemente perché chi prende in
mano il vostro ticket lo potrebbe fare basandosi su un filtro per priorità, dunque se il vostro ticket risulta a priorità
"normale", il fatto che voi inseriate la dicitura "urgente" non farà balzare il ticket nei primi posti della lista.


Infine, errore ancora piu' subdolo, nella descrizione di cui sopra si specificano due attività distinte (con due distinti
gradi di priorità):

1. risolvere il problema dell'orientamento dei PDF, priorità bassa;
   
2. risolvere il problema di autenticazione di un singolo utente, priorità alta.
   

La modalità corretta è quindi quella di aprire due ticket differenti, con priorità differente e descrizione limitata
al problema specifico.
Ecco cosa avrei prodotto io:

Ticket 1
Priorità: bassa

Problema layout stampa PDF: attualmente tutti i PDF escono con orientamento orizzontale,
mentre l'orientamento deve essere VERTICALE.

Ticket 2
Priorità: Alta

L'utente G. (username=g) non riesce ad autenticarsi. Il messaggio di errore
che riceve è "username o password errati".
Questo è per lui bloccante, non può collegarsi al sistema.

Come si può notare, oltre a "spaccare" un singolo messaggio in due, si usano livelli di priorità differente
e si specifica in maniera dettagliata ma senza fronzoli (saluti, ecc.) i problemi e i messaggi di errore.


Usare un sistema di ticketing può risultare in un meccanismo particolarmente potente e strutturato per la gestione
delle attività, ma occorre una impostazione mentale adeguata e rigorosa.
Uno dei consigli che mi sento di dare a chi si vuole "formare" e preparare adeguatamente a questo approccio è quello
di usare un sistema di ticketing anche per progetti mono-sviluppatore. In questo sistemi integrati come
Fossil consentono di unire agilmente la gestione del codice e dei ticket.