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

Spesso ho a che fare con clienti o utenti che segnalano errori nelle applicazioni. Il più delle volte il loro contenuto è qualcosa di inutile

• ERRORE!!!
• x non funziona

senza molte più informazioni.

Per risolvere il problema, devo richiederne ogni singolo dettaglio, che spesso richiede più tempo rispetto alla risoluzione del problema stesso. Altri inviano informazioni in formati non ideali, come schermate (di record di dati, non di errori) sebbene possano inviare un collegamento (abbiamo accesso ai sistemi) e così via.

In che modo dici ai tuoi utenti / clienti di descrivere i problemi con maggiori dettagli in modo che l'intero processo possa essere più facile per entrambe le parti?

modificare

Questa domanda riguarda più le abilità sociali che come ottenere una raccolta programmatica di registri e informazioni sugli errori. Sono consapevole del fatto che questo dovrebbe far parte di una buona progettazione del software.

Premia i tuoi utenti per segnalazioni di errori, puniscili per quelli cattivi (almeno un po ').

L'utente deve capire che una buona segnalazione di bug è essenziale per risolvere rapidamente il problema e quindi va bene anche per lui, perché otterrà la soluzione molto più velocemente.

Quindi la prima risposta potrebbe essere qualcosa del tipo "Okay, ho letto il tuo rapporto ma non so da dove cominciare. Puoi dirmi: è successo una volta? È un fenomeno ricorrente? Potresti provare X e dirmi cosa Y sembra dopo? " e così via.

Molto spesso quando le persone ricevono questo tipo di feedback che dicono loro cosa fare e dicono loro (direttamente o indirettamente) cosa non hanno fatto in primo luogo, impareranno. Forse non immediatamente, ma più segnalazioni stanno archiviando, più anticiperanno (spesso inconsciamente) cosa chiederai loro e forniranno direttamente la risposta.

Sì, questo è un processo graduale 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 le segnalazioni di bug, con sezioni per le informazioni comunemente necessarie.

Se disponi di un sito di segnalazione di bug o di un'applicazione a cui i tuoi clienti hanno accesso, verifica se puoi renderne una versione vuota il testo predefinito del campo di descrizione del bug. Altrimenti, mettilo da qualche parte in cui possono trovarlo (o dove puoi indicarlo), ad esempio sul tuo sito o nella directory di installazione del tuo prodotto.

Nel tuo caso, questo 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 è 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 richiamarli per maggiori informazioni in occasione, ma abbastanza spesso riesco a vedere il problema semplicemente guardando lo screenshot

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

Il pessimista: non puoi. È la stessa situazione di 40 anni prima, tranne che ci sono più utenti, più sistemi, più applicazioni.

(Nota che un pessimista è solo un ottimista con esperienza.)

Renderlo facile per loro o non lo faranno.

Preferibilmente, è il modo più semplice per segnalare un errore nel modo che ti fornisce le informazioni di cui hai bisogno. Ciò significa quasi sicuramente automatizzare il processo di segnalazione degli errori nel software.

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

Quando finisci la conversazione con il cliente, digli "La prossima volta che ciò accade, ti preghiamo di tenere pronti i dati A, B, C, ecc.". Naturalmente, questo funziona solo se questi sono gli stessi clienti che richiamano ripetutamente. 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ù rapida.

Se la maggior parte di loro sono chiamanti occasionali, potrebbe essere meglio aggiornare "ERRORE!" schermata con testo che dice "Devi raccogliere gli elementi di dati A, B, C, ... prima di parlare con i nostri rappresentanti". Questo dipenderà davvero da quanto controllo hai sull'app, quindi potrebbe non essere affatto fattibile. Anche questo non è un modo sicuro, ma spero che l'idea del cliente urli "ERRORZ PLZ HLP !!!" non è abbastanza.

Il problema con i messaggi di errore nelle applicazioni moderne è che è praticamente impossibile includere tutto il contesto che potrebbe essere rilevante. Qualsiasi cosa dall'architettura del processore all'ora del giorno può essere rilevante, motivo per cui sia la segnalazione che la gestione degli errori sono più arte che scienza. Sistemi come apport-bugsono utili in quanto raccolgono informazioni pertinenti e te le inviano. Sfortunatamente, fino ai giorni dei replicatori di materia, dei viaggi nel tempo e dei compensatori di Heisenberg, non c'è modo di essere sicuri che le informazioni ottenute dagli utenti saranno sufficienti per eseguire il debug o persino riprodurre il problema.

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

Un'altra opzione è quella di utilizzare un client desktop remoto per vedere di persona cosa non va. In questi giorni è facile come consentire al client di scaricare un exe.

Dovrai porre domande mirate ed essere molto esigente da parte tua per darti tutte le risposte. A volte il loro reclamo per il problema sarà intervallato dai loro piani per il fine settimana, lamentele per il loro altro significativo o il tempo. Prova a mantenerli 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 ed 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 acquisire la schermata, raccogliere tutti i registri disponibili per la sessione, (potrebbe valerne la pena) aprire la condivisione dello schermo diretta sulla schermata dell'utente, mostrargli il modulo semplice e inviare automaticamente i dati al server.

-Provare a chiedere a un utente il meno possibile se la tua app può ottenere dati da sola. Risoluzione dello schermo, versione del sistema operativo, nome utente, accesso, ultime azioni e registri

-Assegnare un biglietto a un utente e fornirgli un collegamento, in modo che sappia di avere il numero di bug 1234 su www.yoursite.issues / 1234

-Chiedere a un utente cosa ha cercato di ottenere.

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

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