Test di accettazione degli utenti Difetto Classificazione durante lo sviluppo per un cliente esterno

Puoi dire "Problema segnalato del cliente" o qualsiasi altra cosa se rende felici le persone. Ho intenzione di dire "Bug" perché ha una storia così grande ed è il termine standard del settore. In una nuova lista di bug, ci si potrebbe aspettare di sistemare vicino al 100%. Ma più bug vengono aggiunti all'elenco, meno ce ne si aspetta di risolvere. Infatti, la maggior parte degli strumenti di tracciamento dei bug ti consente di chiudere i bug per vari motivi: duplicati, richieste di funzioni, non riproducibili, in attesa, feedback aggiuntivi necessari, ecc.

L'importante è catturare il feedback e le azioni intraprese su quel feedback. Rendiamo molto chiaro ai nostri clienti che possiamo scegliere quali bug risolvere e quali funzionalità implementiamo. Lo facciamo sulla base di ciò che pensiamo renderà più felici i clienti, ma è la nostra scelta.

Sii rispettoso nel fornire feedback su questi bug. Se non hai intenzione di aggiustare qualcosa, dì loro perché. A volte va bene dire che non sei pronto a impegnarti in una particolare soluzione per un determinato bug. O che un bug sia fuori portata per questa versione (o questo prodotto). O che un bug nel modo in cui funziona il sistema potrebbe essere "corretto" attraverso una documentazione migliorata (come ad esempio la modifica dell'interfaccia utente o della documentazione in modo che gli utenti non facciano ciò che ha causato l'errore). Ovviamente, se correggi qualche bug, il tuo client sarà più aperto a non correggere gli altri.

Se il cliente ha grossi problemi nell'utilizzo del software, nessun sistema di denominazione bug li renderà felici. Se amano il tuo software, anche il nome non avrà importanza. Crea un ottimo software, sii rispettoso nei confronti del tuo cliente e non rimanere impigliato nelle categorie di bug.

Quello che devi capire è che nelle grandi aziende, ci deve essere un processo chiaramente definito, oppure che ognuno fa le sue cose, e la squadra A non sa quale sia la definizione di "difetto" della squadra B. Quindi, probabilmente c'è un sistema di classificazione piuttosto rigido, in modo che i team possano immediatamente sapere di cosa parlano gli altri team.

Tuttavia, questo non significa che quei termini dovrebbero avere alcun significato nella tua organizzazione. Infatti, solo perché è una priorità per loro, non significa necessariamente che debba essere una priorità per te (so che è spaventoso da pensare perché probabilmente sono un grande cliente). Ai loro occhi, ogni volta che fa qualcosa di inaspettato , è un difetto, sia che l'imprevisto sia progettato o meno. Inoltre, se si dispone di un software complesso, può essere facile confondersi su come dovrebbero funzionare le cose. Vorrei che il nostro software di tracciamento dei bug avesse una ragione di chiusura di "Non stai facendo bene".

Ad esempio, la scorsa settimana, presso la mia azienda (non siamo un negozio di sviluppo personalizzato, abbiamo prodotti software reali), un cliente ha presentato un bug tramite il suo rappresentante account e ha agito come se fosse un bug reale, ovvero, il il prodotto non ha funzionato correttamente. Ho spiegato che il prodotto ha funzionato come progettato e come nel contratto, quello che volevano era un miglioramento. Non è così spaventoso per la gestione come "bug" o "difetto".

Assicurati di di non "correggere" i difetti che non rientrano nell'ambito del progetto. È così che ottieni clienti che credono che farai tutto gratuitamente.

Sì, potresti metterti nei guai accettando accecamente le classificazioni dei clienti di bug / difetti / caratteristiche / non-sanno-cosa-loro-vogliono / requisiti. Come sottolinea Greg Bair, ci sono casi in cui "Stai sbagliando" è il problema, non il vero software.

Spesso si presentano perché le persone che definiscono i requisiti non usano il software giorno per giorno. Una cosa per aiutare a mitigare questo sarebbe stabilire un canale per ottenere un feedback diretto degli utenti invece che attraverso i team di supporto / supporto.

Idealmente, il tuo team avrebbe la possibilità di parlare con le persone che hanno inserito i difetti in modo da poter estrarre specifiche. Spesso le volte semplicemente parlando con l'individuo e spiegando perché qualcosa fa quello che fa (anche dicendo che i requisiti dicono che deve) può farli tornare indietro di un difetto.

Sarebbe bello pensare che ci sia un modo per risolvere questo problema, ma scoprirai che come un piccolo fornitore di una grande azienda, dettano piuttosto dei termini. Sono in questa situazione da molto tempo con un'enorme multinazionale, e dobbiamo imparare a rotolare con il loro modo di pensare.

La mitigazione più importante è quella di avere buoni rapporti con le persone coinvolte, specialmente i decisori. Quindi puoi influenzare delicatamente, e se le cose si mettono male, loro parleranno per te.

Ovviamente puoi assicurarti di avere buoni termini legali / contrattuali che ti proteggono, ma non saranno di grande aiuto se il cliente decide davvero che non ti piacciono e che renderà la vita difficile. Ecco perché le relazioni personali sono così importanti.

Are we being paranoid here? Or could we be setting ourselves up for problems down the line by agreeing to this classification?

Questo mi sembra un argomento / problema di gestione dei clienti.

Sembra che il tuo approccio di sviluppo stia utilizzando la metodologia Agile / Scrum che è la più corretta per questo tipo di client. Tuttavia, il proprietario del tuo prodotto potrebbe conoscere meglio qual è il reale bisogno del cliente e le sue aspettative essenziali - che dovrebbe essere l'alta priorità da includere nella pianificazione dello sprint e dello sviluppo

Il tuo approccio per registrare tutti i difetti di medio e basso livello è importante, perché potresti includerli in altre iterazioni o fasi del prodotto da consegnare. Pertanto, si giunge al punto precedente che la chiara comprensione da parte del proprietario del prodotto dei requisiti aziendali essenziali è il fattore chiave da tenere in considerazione.