Come rispondi a: "Fin dall'aggiornamento ..." domande dai clienti? [chiuso]

Se ti capita ogni volta che ti schieri, potrebbe esserci un grave difetto nel tuo processo di sviluppo. Sospetto un paio di cose che stanno causando i problemi.

1. Ti sviluppi contro a database che ha la stessa dimensione (all'incirca) come produzione? Altrimenti, allora avrai sempre questi problemi perché le query vanno bene i piccoli insiemi di dati sono spesso cani con quelli più grandi.
2. carica il test in QA? Che cosa funziona bene con un test utente è molto diverso da come andranno le cose rispondere con 1000 utenti che cercano di fare cose allo stesso tempo.
3. Prendi l'utente la percezione è sbagliata e li tratta come se fossero stupidi lamentarsi? Se è così, allora il tuo l'atteggiamento sta causando più lamentele non diminuendoli.
4. Stai facendo un buon lavoro il test? Le funzionalità del test di regressione non vengono modificate per vedere se sono interessate dal cambiamento? Ti importa anche per quanto tempo le cose prendono fino a quando non colpiscono prod?
5. Prestate attenzione a quando è a     buon momento per gli utenti quando tu     distribuire o distribuire allegramente a     passare al sistema di contabilità il     il libro paga del giorno viene eseguito e chiedo perché     gli utenti sono arrabbiati per il rallentamento?
6. Hai ambientale differenze tra dev e prod. A volte quelle fastidiose differenze in sistemi operativi o database le versioni causeranno problemi come questo anche. Spesso è una buona idea avere un ambiente di staging che è esattamente come prod, alcune attrezzature stesso sistema operativo, stesso database con dat che è il più vicino possibile ai dati di produzione. Questo è usato per testare la tua implementazione. Eseguilo prima su questo server e alcuni utenti o tester lo visitano e eseguono alcuni test.
7. Quanto è buono il processo di implementazione, ti mancano spesso i passaggi? Può essere gestito da qualcuno diverso dal sviluppatore perché è chiaro cosa il codice va nel ramo che sei la distribuzione? Siamo molto meglio a distribuire il codice quando abbiamo ottenuto un team di gestione della configurazione e nessuno aveva i diritti di sedere con prod e fai da babysitter facendo "oopsie" i cambiamenti. Automatizzare la tua build può aiutare moltissimo. Nessuno dovrebbe essere in grado di indovinare che cosa deve andare a fare come avrebbe dovuto andare al controllo di qualità e alla messa in scena per primi e tutti i problemi di implementazione risolti. Anche le modifiche ai database di scripting sono fondamentali. Devono essere negli script e nel controllo del codice sorgente, quindi il processo di compilazione può prenderli senza che qualcuno debba ricordare, oh sì, abbiamo bisogno di cambiare la lunghezza sulla colonna B a 241 da 50. Trovo che le persone dimentichino spesso di trattare il database cambia come codice preferendo usare la GUI che è praticamente sempre una cattiva idea su prod.

How do you field criticism framed in "You must be a bad programmer because you're making your software worse"?

Ma tali critiche sono per lo più giustificate. Una nuova versione non dovrebbe essere peggiore della precedente, ma come sappiamo, in realtà spesso lo è, ed è colpa nostra perché ce l'abbiamo fatta.

Fare errori è umano, e non rende nessuno un "programmatore cattivo", quindi non prendere le critiche personalmente (non prenderei mai alcuna critica professionale da un non-collega sul serio comunque). Ringrazia il cliente per aver segnalato il problema e risolverlo il prima possibile. È il tuo lavoro come un buon programmatore.

Beh, al lavoro non interagiamo molto direttamente con i clienti, quindi dovrò rispondere a questo dal lavoro di progetto personale. Sto scrivendo un motore di gioco che le persone possono usare per costruire i propri giochi. È ancora in pre-alpha, ma ho alcuni utenti interessati e a volte ho dei bug.

Quando ottengo un rapporto come questo da un utente, cerco di usare il tocco personale. Non volevo introdurre bug, e voglio che abbiano una buona esperienza con il mio motore, quindi ho bisogno di farglielo credere. In primo luogo, ottenere un handle di messaggistica istantanea in modo che possiamo parlare. Chiederò all'utente il loro progetto e cercherò di ottenerne una copia. Questo rende la riproduzione molto più semplice. Chiedi loro cosa stavano facendo quando si è verificato il problema tecnico. Nel frattempo, ho il motore aperto nel debugger e sto cercando di capire il problema mentre stiamo parlando.

Se si tratta di un'eccezione, di solito è piuttosto semplice. Riproduce il problema e il debugger lo prende e ti porta direttamente al percorso dell'errore con una traccia dello stack completo, ed è ovvio cosa sta succedendo. Se si tratta di prestazioni lente o comportamento scorretto, potrebbe essere necessario un po 'più di tempo. Ma nella maggior parte dei casi posso avere una soluzione pronta entro i primi 20 minuti, al massimo. Lo comprimo e lo mando a testare. "OK, penso di aver capito. Vedi se questo funziona alla fine?"

La risposta è quasi universalmente un misto di stupore e gratitudine, perché molti sviluppatori (leggi: società di software) non risolvono bug e rilanciano così velocemente. E poi, se è stato corretto, ho trasformato un potenziale critico in un fan. È una tecnica davvero buona; Spero solo che altri sviluppatori lo adottino.

Personalmente, prendo il problema in modo positivo. Interagisco sempre con un sacco di custodi e continuo a scrivere codice.

Quando scaricano una nuova versione e mi dicono qualcosa del genere, dico sempre qualcosa del tipo:

Thanks for reporting me that bug. Maybe it has been introduced together will all the new features we added. We'll fix it asap.

In effetti, il cliente è il tuo vero capo. Se l'esperienza con te è brutta, è male anche per te.

Anche se non ha ragione, tu come parte della compagnia, dovresti cogliere l'occasione per:

• impara da lui, raccogliendo potenziali miglioramenti che potresti apportare al prodotto.
• converti un cliente infelice in uno felice, così felice che parlerà di te in giro (incluso il tuo capo)
• sii orgoglioso di quello che stai facendo

Dettagli, Dettagli, Dettagli. Chiedo cosa stavano facendo e quando, sii specifico. Potrebbe essere qualcosa o potrebbe essere solo il video Justin Beaber appena pubblicato su youtube. I file di registro sono tuoi amici in entrambi i casi.

Chiedo anche le date in cui l'hanno notato. A volte, soprattutto nei negozi aziendali, gli utenti non sanno quando viene rilasciato un rilascio, sanno solo che qualcosa richiede molto tempo per essere completato e ora si lamentano solo di questo.

Ombra di lavoro. Non posso enfatizzare abbastanza questo Se sei abbastanza fortunato da avere utenti nelle vicinanze, guardali mentre lavorano da tempo. Trovo spesso che ignorino i problemi evidenti e non li denunciano mai. Spesso si lamentano solo quando sanno che qualcosa è nuovo o inizialmente notano un problema.

Il primo passo è che devi venire da una mentalità che questo (l'aggiornamento rompe altre cose) non è normale. Il tuo aggiornamento non dovrebbe interrompere o rallentare altre parti dell'app. Non va bene, non è previsto, e non è colpa degli utenti quando si lamentano. Dovresti fare più test possibile per cercare di evitarlo. Quando succede, hai un problema e uno urgente.

Il passaggio 2 è che devi sapere cosa hai fatto. Il tuo sistema di controllo del codice sorgente potrebbe essere in grado di aiutarti, o qualche tipo di sistema di tracciamento del lavoro, ma devi essere in grado di dire nel momento in cui ricevi uno di questi reclami "ok, ho aggiunto una colonna a questa tabella, ho cambiato questa griglia per calcolare le nuove tasse, ha aggiunto quelle due nuove relazioni ... "e così via.

Il passaggio 3 è che devi avere esperienza nell'individuare problemi di perf e arresti anomali rapidamente, in modo che tu sappia che genere di cose potrebbero causarli e che puoi arrivare al problema immediatamente. Questa cosa è andata in onda e devi trovare rapidamente il problema e ottenere una patch. La modifica di un rapporto non può rallentare una parte dell'app che non utilizza il rapporto. Sei in modalità di emergenza ora e devi capire dove si trova l'errore e cosa fare al riguardo - senza interrompere un'altra parte dell'app nel processo.

Il passaggio 4 è per ciascuna di queste miserie, dovresti imparare una lezione che testerai per la prossima volta. Diventerai "quel ragazzo" che obietta a certi costrutti perché "quello sarà orribile quando ci sono 10.000 record".

Un po 'di più sul fronte "questo è normale". Corro (tra tutte le altre cose che stiamo facendo) un progetto agile per un cliente esterno. Abbiamo fatto le pubblicazioni all'incirca ogni 6 settimane per due o tre anni. E sì, l'uscita è programmata al minuto. Ne abbiamo appena fatto uno alle 8 di ieri. E all'incirca ogni quarto o quinto rilascio (una o due volte l'anno, in altre parole) qualcosa si rompe dal vivo, e saltiamo in azione e facciamo il più velocemente possibile. Anche se testiamo, testiamo e testiamo prima del rilascio. Poi diciamo loro cosa è successo. "Nella distribuzione di giugno c'era un piccolo bug che lasciava vuoto questo campo, ma non lo abbiamo mai notato perché non stavamo usando il valore in quel momento. Quindi in questa distribuzione quando iniziammo ad usare il campo, quelli che erano vuoti causarono quel messaggio di errore che hai visto. Abbiamo corretto il bug in modo che non possano essere vuoti, inserisca i valori nei record danneggiati e confermato che non esploda più. O "Il cambiamento di emergenza che hai implorato, solo due giorni prima del rilascio, ha avuto conseguenze a cui non pensavamo e non ci siamo testati, ricorda perché resistiamo ai cambiamenti di emergenza?" Potrei non essere un cattivo programmatore per peggiorarlo con l'aggiornamento, ma sicuramente ho fatto una brutta cosa. E ho bisogno di farlo bene.

Solo per coprire un altro aspetto:

Teniamo un elenco di clienti che dichiarano questo quando non si è rivelato. Mentre il software è bacato, spesso molto bacato, molti dei nostri clienti reclameranno "avviato con l'aggiornamento" per ottenere un'attenzione immediata, non rendendosi conto che questo finisce per sprecare il tempo di tutti mentre percorriamo i delta per la funzione indicata alla ricerca del problema. Se il cliente dice la verità, tende a farlo trovare velocemente. Se il cliente è sulla lista falsa troppe volte non ci preoccupiamo perché non ci piace perdere tempo.

Non riesco a immaginare quale modo di pensare sia necessario per pensare di dirci una bugia accelererebbe il processo. Queste persone sono o lavorano con i medici e dovrebbero sapere perfettamente cosa succede quando le persone mentono ai medici. Lo stesso principio si applica.