Informare gli utenti di bug in sospeso

Question

Informare gli utenti di bug in sospeso

#1 da (7 voti)

3

Qual è il modo migliore per informare gli utenti che è stato riscontrato un errore in alcuni software utilizzati?

Ad esempio, diciamo che un utente trova un bug in qualche software e lo segnala al team di sviluppo che decide che la correzione di questo errore verrà eseguita in una prossima versione (piuttosto che una patch singola) a causa del basso rischio (accade molto raramente e ha un impatto minimo, sebbene negativo)

Qual è il modo migliore per informare gli altri utenti che potrebbero essere interessati dallo stesso bug che sappiamo di un bug e offrire loro una soluzione alternativa?

Vorremmo essere proattivi nella notifica agli utenti al fine di ridurre al minimo il verificarsi del bug.

Un collega ha suggerito di avere un registro dei bug nella pagina di destinazione del software, anche se mi sembra che questo ingombrare la homepage con informazioni che gli utenti non leggono, la mia discussione è stata che quando accedo ad Amazon / Ebay ecc. loro costringono una lista di bug su di me.

Forse una buona via di mezzo è avere una notifica di un nuovo bug quando l'utente apre il software che l'utente riconosce e una volta riconosciuto, la notifica smetterà di apparire?

I commenti sarebbero apprezzati

bug issue-tracking bug-report

posta SEarle1986 14.02.2018 - 15:19

fonte

1 risposta

Leggi altre domande sui tag bug issue-tracking bug-report

Le migliori pratiche per mantenere i modelli precedenti nel codice? 'Assegnare' una classe base a una classe derivata?

score 7 · Accepted Answer

Dipende molto dal tipo di software, dal tipo di bug e dal possibile impatto di non dirlo agli utenti.

Per la maggior parte dei bug, l'unico posto ragionevole in cui gli utenti devono essere informati è IMHO il log delle modifiche dell'ultimo aggiornamento o patch, dopo il bug è stato corretto lì. Ciò mostra in realtà ai tuoi clienti o utenti che non stai fornendo bug, ma soluzioni ai problemi.

Esiste solo un tipo di situazione in cui è necessario informare gli utenti in modo proattivo prima di distribuire una correzione o un aggiornamento:

il bug ha una certa gravità, forse qualche problema di sicurezza, o potrebbe causare un danno reale (finanziario, fisico, legale)
le informazioni sul bug aiuteranno a proteggere i tuoi clienti dal danno (idealmente puoi dire loro una soluzione alternativa, ma se non aiuta in alcun modo, potresti raccomandare di non usare certe funzionalità nel tuo software finché non c'è una soluzione )
non puoi consegnare una correzione APPENA POSSIBILE, o ti aspetti che i tuoi clienti non siano in grado di installare la correzione APPENA POSSIBILE

Naturalmente, c'è una certa classe di bug che non causa questo tipo di danno, ma può essere fastidioso per gli utenti se non conoscono la soluzione giusta (che si spera non sia fastidiosa). Nel caso in cui non sia possibile o non si desideri correggerli rapidamente per qualche motivo, la documentazione del prodotto è il posto giusto per descrivere la soluzione alternativa. Questi potrebbero anche far parte delle domande frequenti sul sito Web del tuo prodotto o solo in qualche altro posto in cui gli utenti possono trovare facilmente le informazioni quando ne hanno realmente bisogno .

Tieni presente che informare preventivamente i tuoi utenti, su eventuali bug e soluzioni alternative disponibili per funzionalità che potrebbero non aver mai utilizzato in passato, o che non verranno utilizzati in futuro, probabilmente li infastidirà più del bug stesso.