Informazioni insufficienti in Bug / Ticket [duplicate]

Parte del mio lavoro consiste nel rispondere ai ticket dell'help desk per l'applicazione principale del mio team, che viene utilizzata da poche migliaia di utenti interni. Mentre la semantica e il sistema sono leggermente diversi, il principio di base è lo stesso.

Chiedi sempre maggiori informazioni se non è immediatamente chiaro dall'invio dell'utente quale comportamento si aspettano e non riceve. Se possibile, apri l'applicazione e guardala da solo, nel caso in cui il comportamento è così ovvio che "fare clic su X non funziona" era una relazione sufficiente. Se si tratta di supporto interno, è possibile che una chat o una telefonata siano appropriate.

Idealmente, usa lo stesso fraseggio usato nel loro addestramento o materiale di aiuto per riferirti al problema. Non aver paura di chiedere messaggi di errore o schermate, o semplicemente esci e chiedi chiaramente cosa si aspettavano che accadesse e non.

Non aver paura di chiedere agli utenti di scattare schermate, riavviare il computer o fornire file. Esiste un certo livello di esperienza informatica che è semplicemente imperdonabile non possedere nel mondo di oggi se si utilizza un computer nel lavoro quotidiano e se il proprio datore di lavoro o il cliente desidera assumere tali persone dovrebbero avere un supporto in sede che possa assistere loro.

Il problema con i modelli è che tendono a diventare troppo complessi. Le persone tendono a sovraccaricare quelli con campi che potrebbero fornire informazioni sul bug che a volte aiuta il processo di debug e sempre a gravare sul mittente del ticket.

Certo, potrebbe essere utile sapere quale sistema operativo e browser l'utente ha usato quando ha incontrato il bug, ma la maggior parte dei bug è "multipiattaforma", ma l'utente è sempre costretto a inserire quei dati.

Anche se questi campi sono opzionali, avere troppi di essi renderà il modello complesso ed ingombrante.

Se mantieni il template piccolo, non verrebbe ignorato. In sostanza, è necessario conoscere due considerazioni sul bug:

1. Cosa ha fatto l'utente
2. Cosa non ha funzionato.

E questo è tutto! Metti un ulteriore campo "informazioni aggiuntive" per tutto ciò che l'utente ritiene importante e resisti al tentato di inserire altri campi (a meno che non si tratti di informazioni di contatto che non puoi ottenere manualmente).

Gli scrittori di biglietti devono essere istruiti su come scrivere biglietti utili per gli sviluppatori.

se ricevo un

"Function X is broken"

risponderei:

what do you currently get if you execute 'X' ?

what are the steps to reproduce the broken 'X'

what exactly would you expect to happen, when "X" is executed ?

I miei clienti hanno appreso che ottengono cambiamenti / correzioni più rapidi se scrivono i biglietti con questi articoli.

è anche utile fare complimenti a un cliente che segue questa regola

Non ho familiarità con quel software, ma in genere qualsiasi software di tracciamento dei bug che ne valga la pena richiede (o può essere impostato per richiedere) alcuni campi prima che i bug possano essere inviati.

Se alcuni utenti inviano regolarmente rapporti di scarsa qualità, vorrei verificare se solo alcuni utenti potrebbero inviare bug o se altri membri del personale potrebbero agire come gatekeeper.

Qualcosa che non citi è se qualcuno di questi bug ha una priorità. Chiaramente, se tutti i tuoi errori hanno raggiunto la priorità (o la stessa) priorità, il sistema viene abusato.

Potrebbe essere allettante (come altri hanno sottolineato) semplicemente chiuderle come "più informazioni richieste", "vaghe" o "incapaci di riprodurle", ma parlando agli utenti per prendere in giro più informazioni potresti imparare alcune cose che non ti sei reso conto di come stanno usando il sistema. Ancora meglio, potresti correggere uno showstopper in anticipo piuttosto che lasciarlo ammazzare.