Registrazione di suggerimenti e feedback non strutturati in un tracker di problemi?

Question

Registrazione di suggerimenti e feedback non strutturati in un tracker di problemi?

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

3

Mi piacerebbe sostenere l'uso del software di tracciamento dei problemi all'interno di un'organizzazione che attualmente non la usa.

Ma c'è un aspetto della loro situazione per cui non sono sicuro di cosa suggerire: i loro progetti ricevono spesso feedback verbali informali o commenti casuali in riunioni o in passaggio da un ampio gruppo di parti interessate, e tutte queste informazioni devono essere registrato.

La maggior parte di questi messaggi è disturbata, ma è fondamentale registrarli e condividerli con gli sviluppatori per due motivi:

Spesso vengono fuori buoni suggerimenti da questo processo.
Può essere necessario avere evidenza dei commenti dei clienti quando dimenticano le istruzioni precedenti o cambiano idea.

Questo è il tipo di informazioni che dovrebbero essere archiviate in un sistema di tracciamento dei problemi o mantenute separate in una soluzione separata? Il sistema di tracciamento dei problemi può avere un buon supporto per questo tipo di informazioni non strutturate?

project-management issue-tracking client-relations requirements-management

posta Ian Mackinnon 29.01.2011 - 19:41

fonte

4 risposte

Leggi altre domande sui tag project-management issue-tracking client-relations requirements-management

Devo inoltrare la chiamata a .Equaliti su .Equalisti? Proprietà intellettuale per lo sviluppo interno [chiuso]

score 3 · Answer 1

Se sei quello che riceve le informazioni / i suggerimenti informali, chiedi alla persona di inviarti un'email. Chiedi scusa in anticipo e sottolinea che non vuoi dimenticare una così buona idea e che il tuo capo preferisce un processo più formale prima di prendere in considerazione qualsiasi cosa.

Non penso che sia necessario un sistema separato per il tracciamento, ma le richieste dovrebbero essere identificate. Non sono sicuro che ci sia una differenza tra una caratteristica critica che non esiste e una caratteristica critica con un bug esistente. In teoria, il bug dovrebbe essere più facile / veloce da indirizzare, ma non sempre. A volte c'è un'ulteriore pressione sui bug perché è fondamentalmente una funzione che hai fatto un accordo da includere ma che non è riuscito a mantenere la tua parte dell'accordo.

I tracker di buoni problemi dovrebbero essere in grado di gestire i suggerimenti e accettare input via email. Utenti come email Soprattutto quando risolvi il problema e la loro casella di posta si apre con la tua risposta.

score 0 · Answer 2

Abbiamo due metodi per implementarlo. Uno, abbiamo un forum dove i nostri rivenditori e / o distributori possono inviare richieste o problemi comuni. Due, teniamo traccia delle richieste di funzionalità e richieste nel nostro software di tracciamento dei bug (fogbuzz). Supporto e QA hanno accesso a questo. Manteniamo questo separabile per ovvi motivi.

score 0 · Answer 3

Penso che dovresti separare richieste / commenti di funzionalità dal tuo sistema di tracciamento di bug / funzionalità.

Ecco come faccio:

Uso un sistema come uservoice.com . È semplice da utilizzare sia per gli utenti che per te.

Periodicamente, li consulto e aggiorno il product backlog di conseguenza.

Quando pianifichiamo un'iterazione, aggiungiamo funzionalità e / o bug nel nostro sistema di tracciamento di bug / funzionalità.

score 0 · Answer 4

Perché no. Finché puoi registrare la differenza tra "richieste di funzionalità" e "bug" (molte volte sono la stessa cosa), non mi sembra che ci siano problemi a farlo.

Redmine, ad esempio, viene fornito con tipi di tracker per bug e funzionalità.

Il tuo problema principale è tenere aggiornato un ticket con qualsiasi conversazione sulla richiesta di funzionalità - se c'è una discussione estesa da parte di persone che non hanno accesso al tracker stesso, allora dovrai trovare un modo per inserirlo nel ticket (o dare loro l'accesso, conosco sistemi che possono aggiungere note a un ticket via email) o ottenere un proprietario interno per ogni ticket per aggiornarlo di conseguenza.

Ho visto bug che proseguono con discussioni estese sia che si tratti di un bug o di 'working by design', di bug in cui nessuno sa quali siano i problemi, e bug in cui nessuno può concordare quale tipo di correzione da inserire. Questi non sono particolarmente diversi dalla tua richiesta di funzionalità.

Come extra, inserire le richieste di funzionalità nello stesso ticket tracker significa che puoi tenere traccia delle modifiche - dalla vaga richiesta di funzionalità a una serie di requisiti di progettazione alle istruzioni di lavoro, ai bug che emergono dall'implementazione. Questo livello di tracciabilità non ha prezzo.