Quale livello / formato di accesso dovrebbe essere dato a un cliente al sistema di tracciamento del problema?

2

Quindi, pensavo che sarebbe stata una buona idea dare al cliente l'accesso al sistema di tracciamento dei problemi, ma ora ho visto che crea situazioni meno che ideali, come:

  • Il cliente giudica i progressi solo sul numero di ticket
  • Gli sviluppatori hanno negato di aggiungere problemi per evitare che i clienti pensino che ci siano meno progressi
  • Il cliente nomina le persone dalla loro parte per aggiungere problemi che non sempre fanno un buon lavoro (un sacco di problemi duplicati, informazioni insufficienti da riprodurre e altre cose che distolgono le persone dal fare il loro vero lavoro)

Tuttavia, ritengo che i clienti debbano avere accesso ad alcuni indicatori o dimostrare che sono stati fatti progressi, oltre al diritto di segnalare bug.

Quindi, quale sarebbe la soluzione ideale a questa situazione? Specialmente, uscire o migliorare la prima situazione descritta?

    
posta dukeofgaming 19.11.2012 - 12:50
fonte

3 risposte

2

È difficile da dire. Per usare un'analogia, alcuni ristoranti ti permettono di vedere in cucina, così puoi vedere quanto duramente lavorano gli chef. Alcuni no.

Tuttavia, siamo programmatori e non chef. Direi che hai bisogno di un forum in cui gli sviluppatori possano essere onesti, così come il lavoro può essere fatto. La soluzione è quella di regolare le impostazioni di sicurezza in modo che alcune cose rimangano private (lo abbiamo nel mio attuale luogo di lavoro) o per vedere se è possibile educare meglio i clienti.

Giudicare la produttività sul numero di biglietti è un po 'come giudicare le prestazioni di un cavallo in una gara sulla quantità di fieno che sta mangiando.

Il sistema che utilizziamo è ZenDesk . Ciò consente ai nostri clienti di inviare ticket, ma utilizziamo le autorizzazioni per mantenere alcune cose private.

    
risposta data 19.11.2012 - 13:18
fonte
2

L'hai taggato con "Agile", quindi suggerirei che uno degli strumenti "agili" potrebbe essere una buona opzione: utilizzare un Product Backlog, contenente un elenco di ciò che deve essere fatto e avere un prodotto Il proprietario lo gestisce. Il Product Owner dovrebbe condividere ciò che è nel backlog con tutte le parti interessate ed essere in grado di spiegare perché i problemi appaiono (o meno). Ciò dà visibilità ai progressi fatti, che è una buona cosa, ma limita la quantità di confusione che potrebbe creare.

Fondamentalmente, hai identificato un'area in cui la fiducia e la visibilità sono a rischio nella tua organizzazione, quindi hai bisogno di qualcuno per gestirlo.

    
risposta data 19.11.2012 - 13:46
fonte
0

Penso che sia necessaria una certa trasparenza. I clienti se lo aspettano e possono separarti da un concorrente che non fa quel passo in più.

Ad esempio, potresti volere che i tuoi clienti vedano lo stato della loro richiesta, come "aperto" o "chiuso" nella loro interfaccia. D'altra parte, l'amministratore potrebbe avere una gamma più ampia di stati che sarebbe invisibile al cliente. Questo ci aiuta a tenere i clienti al corrente.

    
risposta data 28.11.2014 - 11:34
fonte

Leggi altre domande sui tag