Il cliente è "profondamente deluso" nel nostro software a causa di un bug. Come rispondere? [duplicare]

Sembra che per la maggior parte, hai un buon rapporto con questo cliente. ("Tutto sta andando bene finora.") Presumibilmente vuoi mantenere questa relazione.

Ma sembra che questo scenario sia accaduto più di una volta. Forse hai in qualche modo (involontariamente, forse) lasciato credere al cliente che non sei infastidito da questi bug occasionali tanto quanto lo sono. In tal caso, il cliente potrebbe ritenere che dovrebbe aumentare il proprio livello di preoccupazione espresso per il problema al fine di ottenere maggiore attenzione da parte dell'utente.

In questi casi, più ti sembra di eliminare il problema, più si lamenteranno.

Al di fuori di (forse) alcuni processi di sviluppo molto costosi, è forse inevitabile che a volte venga trovato un bug dopo il rilascio. Ma non deve mai essere accettabile (o "OK") per far passare i bug. Puoi conciliare queste due convinzioni mettendo in chiaro che non vuoi vuoi per distribuire il software buggy e che prendi la scoperta di un solo bug come qualcosa da affrontare. Il prossimo passo è capire come affrontarlo.

Se fai capire al cliente che sei in cima alla situazione e fai tutto il possibile per risolvere il problema, potrebbero lamentarsi di meno. Se in qualche modo ti informano dell'esistenza del bug (come in una email che dice "Ehi, è questo che dovrebbe succedere?") prima dell'incontro dove ti dicono quanto sono delusi, tu potrebbe anche essere in grado di capire preventivamente (anche prima dell'incontro) quanto seriamente si prende questa situazione e in questo modo si può forse deviare alcune delle critiche.

1. Accetta con tutto il cuore il cliente che i bug ripetuti sono un problema

2. Fai in modo che il cliente sia d'accordo sul fatto che si debba lavorare di più per prevenire questi bug

3. Il cliente è d'accordo sul fatto che più qa e più test sono appropriati

4. Chiedi al cliente che inizialmente sembrerà che rallenti un po 'e che costino di più

5. Fai più qa e scrivi più test durante lo sviluppo.

6. Fattura di conseguenza

Come per qualsiasi altro cliente: "Mi dispiace molto che tu abbia avuto problemi. Che cosa possiamo fare per aiutarti?"

Ora, probabilmente non sarai in grado di fare tutto ciò che chiedi, e certamente non per quanto libero vorrebbe che fosse. Questa è una questione di negoziazione. Ma la tua prima comunicazione è scusa seguita da aperture positive e costruttive.

Sembra che tu non sia stato onesto sulla natura del tuo lavoro con il cliente sin dall'inizio. Non sono sicuro dalla tua domanda che tu e il tuo cliente comprendiate che Tutto il software è bacato.

E intendo tutti . Anche la tua app HelloWorld è "buggy" se ci si aspetta che ... Non lo so ...

• Traduci automaticamente in base alle impostazioni locali
• Pronuncia "Ciao mondo" ad alta voce per gli utenti con problemi di udito
• Esegui su un tostapane
• Altre cose irragionevoli

O anche se ci si aspetta che faccia qualcosa un po 'ragionevole che non era inizialmente atteso:

• Visualizza visivamente "Hello World" anche quando STDOUT viene reindirizzato a /dev/null

I bug sono spesso solo caratteristiche viste da un'altra prospettiva. Se ci sono delusioni a questo proposito, chiariscile.

MA PRIMA, è saggio a scusa se una delle seguenti condizioni è vera:

• Il bug è grave
• Il bug è il risultato di qualche incuria sul tuo lato
• Se il cliente non è stato completamente istruito sul processo, sulla natura del software o sulla natura dei bug
• Il client è molto turbato (anche se non è colpa tua)

Ciò che fai da lì dipende dal tuo contratto e dal desiderio di mantenere il cliente. Se fatturi a ore, è tra te e il cliente se è il tempo fatturabile. Ciò potrebbe richiedere alcune indagini da parte tua prima di poter determinare se il problema era correlato al recente lavoro fatturabile. Se è un prezzo fisso per il completamento di X, dovresti probabilmente correggerlo gratuitamente. Ma, niente è al di fuori del regno della negoziazione - anche se sei in un contratto.

Fondamentalmente, conversa con il cliente e raggiungi un accordo. Parla come gli umani. Assicurati di dare una considerazione esplicita alle esigenze e alle aspettative del cliente. Assicurati, nel modo più educato possibile, che il cliente capisca anche le tue esigenze nel rapporto (per guadagnarsi da vivere) se la redditività del progetto diventa discutibile.

E se questo è un evento comune:

• Educa il cliente e accetta le correzioni di errori e le procedure di richiesta di modifica (e fatturazione).
• Aggiorna il tuo processo di sviluppo e controllo qualità.
• Aggiorna il tuo atteggiamento .

Il tuo compito è principalmente sapere cosa stai facendo e offrire un lavoro di alta qualità . Se non si dispone di processi in atto per garantire che il client ottenga un prodotto stabile, è necessario correggerlo immediatamente. In secondo luogo, ma altrettanto importante, è il tuo lavoro educare educatamente il cliente quando sorgono incomprensioni sul lavoro, sul prodotto o sul processo.

Immagina di portare la tua auto nel meccanico per sostituire una batteria. Poco dopo la sostituzione, senti "rumori divertenti" quando giri un angolo. Quando ritorni con la tua auto, il tuo meccanico (dovrebbe) indagare educatamente sul problema, spiegare la situazione e fare una fattura in base al fatto che il nuovo rumore sia correlato all'installazione della batteria.

Probabilmente non va dai suoi amici dire "Ho un cliente patetico", a meno che tu non sia stato veramente indisciplinato - nel qual caso, un buon meccanico potrebbe offrire un rimborso e consiglia un altro meccanico.

La risposta immediata alla tua domanda è di rimanere professionale, ma devi eseguire il backup con l'azione. In particolare, affrontare le preoccupazioni del cliente in modo oggettivo ed equo.

È importante avere linee di comunicazione aperte e un modo semplice per segnalare e tenere traccia dei bug. Normalmente questo passa attraverso il project manager o il lead di sviluppo, a volte il cliente ha accesso diretto al sistema di tracciamento (ad esempio Jira).

Se il cliente si sente rassicurato di poter segnalare bug e di essere effettivamente riparato, questo è molto importante per migliorare il loro atteggiamento nei confronti sia del software stesso che dei processi utilizzati per crearlo.

L'importante è avere un processo chiaramente definito che l'intero team segue quando segnala bug, pianificandoli per essere corretti e convalidando che sono corretti. A seconda del tipo di errore, ciò potrebbe comportare la scrittura di più casi di test o il test manuale. Ci dovrebbe essere anche una chiara strategia di regressione nel caso in cui un errore per il quale non esiste un test (ad esempio l'errore di ortografia) venga di nuovo rotto in seguito. Assicurati di lavorare con il cliente per identificare le aree ad alto rischio per ottenere il massimo ritorno sull'investimento dal tuo QA.

Qualcosa che può aiutare è sottolineare che lo sviluppo del software è simile a un ambiente di produzione. Anche gli ambienti più severi, come i reattori nucleari, comprendono che l'ignoto deve essere limitato statisticamente. I loro limiti sono solo più stretti dei nostri.

Spiega ai tuoi clienti che puoi portare i bug ad un livello arbitrariamente raro, come l'elusivo "6 sigma" che è così popolare oggigiorno. Tuttavia, lo sviluppo di applicazioni di grandi dimensioni a questo livello è estremamente costoso. Se apprezzano veramente una bassa percentuale di errori, sono liberi di pagarne il costo.

Un altro approccio che puoi adottare è creare ulteriori requisiti testabili. Se vogliono che tu raggiunga un altissimo livello di affidabilità nel tuo software, i requisiti che ti verranno dati dovranno essere sempre più specifici. Se mi viene dato il requisito

Users should feel the interface is interactive

Non riesco a raggiungere un alto livello di affidabilità. Se mi viene dato il requisito

When the user clicks on the interface, it should respond within 0.1 second 95% of the time. In 4.99% of the remaining cases, it should display a 'waiting' icon while it is processing

quindi posso cercare un alto livello di affidabilità perché posso sviluppare un processo di test per mitigare i bug.

Come seguito, vorrei suggerire un'alternativa alla ricerca. Il tuo cliente si comporta come un cliente. Se ti viene data l'opportunità, prova a lavorare con loro per trasformarli in un partner. La relazione cliente / fornitore non è stabile come la relazione partner / partner. Quest'ultimo può effettivamente gestire meglio gli errori.

Le elencherò di seguito perché in realtà non affronta la tua domanda, ma trovo che sia qualcosa di importante da considerare quando si tratta di clienti a lungo termine.

Stai davvero chiedendo sul sito sbagliato. Come programmatore, non rispondi a questo. Il tuo manager, o meglio il tuo product manager, o forse i tuoi addetti alle vendite, sono loro a rispondere al cliente.

Ora, se il tuo manager, product manager o addetto alle vendite, viene da te e ti chiede perché hanno così tanti reclami sui bug nel software, allora la cattiva risposta è "deve essere perché sono uno sviluppatore patetico". La buona risposta sarebbe "ti ricordi come ti abbiamo detto che una settimana di test non è abbastanza? E come ti abbiamo detto che non dovremmo fare questi grandi cambiamenti appena prima del rilascio? E come ti abbiamo detto che dobbiamo passare un po 'di tempo a migliorare la qualità invece di aggiungere altre funzionalità? "

Risolvi il bug, ovviamente, ma ci sono un paio di fattori da considerare. Ricorda che alla fine della giornata è una relazione d'affari: una proposta value-for-value.

1) La relazione complessiva è buona? Stanno usando il software? Vogliono continuare il rapporto commerciale? Potresti non essere in grado di correggere i loro sentimenti feriti, ma puoi certamente concentrarti su risultati positivi e lungimiranti.

2) A volte le persone si esprimono in modi divertenti. Parlano della fine del mondo, ma è solo il modo in cui parlano. (La mia bambina lo fa.)

3) Potrebbero essere preoccupati per affrontare il problema. Alla gente piace la strada felice. Quindi i loro sentimenti di delusione possono essere dovuti al fatto di doverne parlare come se avessero il problema.

4) Potrebbe essere una tattica di negoziazione, come in "Vorremmo che tu facessi più lavoro per noi, ma abbiamo bisogno di uno sconto a causa di questo TERRIBILE INSERIMENTO NELL'ULTIMA VERSIONE." OK sicuro.

5) Potrebbero esserci dei costi legittimi, come in, come pagare il tempo necessario per correggere il problema.

Ho riscontrato che ho a che fare con clienti esterni e interni, se mi concentro sui risultati e affronta diligentemente qualsiasi problema, l'interazione diventa più fluida con il miglioramento della fiducia. Risolvi il problema e prendi la visione lunga. Quando stabilisci le basi della tua relazione, devi concentrarti su aspetti lungimiranti.

Se non altro, è un ottimo esempio di interazione con il cliente da cui imparare.