Come insegnare ai tuoi utenti / clienti a inviare descrizioni degli errori migliori

Premi i tuoi utenti per buone segnalazioni di bug, punirli per quelli cattivi (beh, almeno un po ').

L'utente deve capire che un buon bug report è essenziale per te per risolvere il problema velocemente e quindi è un bene anche per lui, perché otterrà la soluzione molto più velocemente.

Quindi la prima risposta potrebbe essere qualcosa come "Ok, ho letto il tuo rapporto ma non so da dove cominciare.Puoi dirmi: è successo una volta? È un fenomeno ricorrente? Puoi provare X e dimmi che aspetto ha Y dopo? e così via.

Abbastanza spesso quando le persone ricevono questo tipo di feedback dicendo loro cosa fare e dicendo loro (direttamente o indirettamente) cosa non hanno fatto, in primo luogo, che impareranno. Forse non immediatamente, ma più report vengono archiviati più spesso (spesso inconsapevolmente) anticipano ciò che stai per chiedere loro e forniscono la risposta direttamente.

Sì, questa è una procedura dettagliata e non risolverà tutti i problemi di comunicazione fino a domani mattina, ma è comunque un inizio.

Una cosa che ho visto fare diversi progetti open-source è scrivere un "modulo" standard per segnalazioni di bug, con sezioni per informazioni comunemente necessarie.

Se si dispone di un bug che riporta il sito o l'applicazione a cui i clienti hanno accesso, vedere se è possibile renderne una versione vuota il testo predefinito del campo di descrizione del bug. Altrimenti, mettilo da qualche parte in modo che possa trovarlo (o dove puoi puntarlo), ad es. sul tuo sito o nella directory di installazione del tuo prodotto.

Per il tuo caso, potrebbe essere qualcosa del tipo:

URL where the error occurred:

What you did:

What you expected to happen:

What actually happened:

<Some other information you (ckeller & colleagues) often find useful>:

Any extra information you think might be relevant:

("Tu" qui si riferisce ai clienti)

L'idea è di incoraggiarli a fornire informazioni utili fornendo un elenco del tipo di informazioni che è più spesso utile.

Di solito chiedo loro uno screenshot dell'errore ogni volta, e alla fine iniziano a inviarmi lo screenshot con la loro richiesta di errore perché sanno che lo chiederò.

Devo ancora chiamarli per maggiori informazioni occasionalmente, ma abbastanza spesso riesco a vedere il problema osservando lo screenshot

Ma sono d'accordo con il commento di @ Mahmoud che il modo migliore è quello di far sì che l'applicazione invii errori invece di fare affidamento sugli utenti.

La presa pessimistica: non puoi. È la stessa situazione come 40 anni prima, eccetto che ci sono più utenti, più sistemi, più applicazioni.

(Si noti che un pessimista è solo un ottimista con esperienza.)

Rendi più facile per loro o non lo faranno.

Preferibilmente fai il modo più semplice in cui possono segnalare un errore nel modo in cui ti forniscono le informazioni di cui hai bisogno. Questo quasi certamente significa automatizzare il processo di segnalazione degli errori nel software.

Mantenere un file di registro dettagliato e averlo allegato il rapporto di errore è un inizio.

Quando finisci la conversazione con il cliente, dì loro "La prossima volta che succede, si prega di avere gli elementi dati A, B, C, ecc .. pronti per me". Naturalmente, questo funziona solo se questi sono gli stessi clienti che ripetutamente richiamano. Ho avuto successo con questo approccio, in cui gli utenti hanno appreso alcune cose chiave che avrebbero a) accelerare la chiamata, b) rendere la risoluzione complessiva molto più veloce.

Se la maggior parte di loro sono chiamanti occasionali, potrebbe essere meglio aggiornare "ERRORE!" schermo con testo che dice "Devi raccogliere gli elementi di dati A, B, C, ... prima di parlare ai nostri rappresentanti". Questo dipenderà molto da quanto controllo hai sull'app, quindi potrebbe non essere affatto in grado di farlo. Neanche questo è un modo infallibile, ma si spera che l'idea arrivi nella testa del cliente che urla "ERRORZ PLZ HLP !!!" non è sufficiente.

Il problema con i messaggi di errore nelle applicazioni moderne è che è praticamente impossibile includere tutti i contesti che potrebbero essere pertinenti. Tutto ciò che va dall'architettura del processore all'ora del giorno può essere rilevante, ed è per questo che sia la segnalazione degli errori che la gestione degli errori sono più arte che scienza. Sistemi come apport-bug sono utili in quanto raccolgono informazioni rilevanti e te le presentano. Sfortunatamente, fino ai giorni dei replicatori di materia, del viaggio nel tempo e dei compensatori di Heisenberg, non c'è modo di essere sicuri che le informazioni ottenute dagli utenti siano sufficienti per eseguire il debug o addirittura riprodurre il problema.

Registra tutto ciò di cui hai bisogno . Abbiamo un file di registro progressivo di x mb. Se succede qualcosa di brutto, l'utente invia il file di log e spesso è sufficiente per risolvere un problema.

Un'altra opzione è utilizzare un client desktop remoto per vedere da sé cosa c'è che non va. In questi giorni è facile come consentire al client di scaricare un exe.

Dovrai porre domande mirate ed essere molto esigente da parte loro per darti tutte le risposte. A volte la loro denuncia del problema sarà inframmezzata con i loro piani per il fine settimana, i reclami sul loro altro significativo, o il tempo. Cerca di tenerli in attività e chiedi loro: "Ok, quando fai X ma non fai Y, cosa succede?" Annota le loro risposte in modo da iniziare a creare un diagramma di sequenza degli eventi che puoi in seguito tornare indietro e eseguire il debug.

Puoi investire un po 'di tempo e aggiungere un pulsante rosso "Segnala un bug" nell'angolo in alto a destra della tua app. Quando un utente preme il pulsante tenta di scattare una schermata, raccoglie tutti i registri disponibili per la sessione, (potrebbe essere il suo valore) aprire la condivisione diretta dello schermo sullo schermo dell'utente, mostrargli il modulo semplice e inviare automaticamente i dati al tuo server.

: prova a chiedere ad un utente il meno possibile se la tua app può ottenere i dati stessi. Risoluzione dello schermo, versione del sistema operativo, nome utente, accesso, ultime azioni e log

-Assegnare un ticket a un utente e fornirgli un link, quindi sa di avere il bug numero 1234 su www.yoursite.issues / 1234

: chiedi a un utente cosa ha cercato di ottenere.

Penso che tutto questo insieme, o anche parzialmente, possa aiutarti a ricevere abbastanza dati e mostrare all'utente che può aiutarti a migliorare il tuo software.

Il modo più semplice è utilizzare uno strumento in grado di "capire" ciò che effettivamente desidera il cliente. Ci sono molti strumenti, ma forse il migliore è Usersnap. Vedi questa storia qui.