Come rispondete a: "Fin dall'aggiornamento ..." domande dei clienti? [chiuso]

Sin dall'aggiornamento, la gente continua a chiamare e a dire "Dall'aggiornamento X, Y e Z sono lenti, danneggiati e si bloccano"

Questo è successo fin dagli albori degli aggiornamenti.

Cosa si aspettano le persone? Gamma arriva dopo la beta e i test gamma trasformano sempre i nostri utenti in The Incredible Hulks ...

Forse non l'hai mai sentito da un cliente, forse sei al college o un FLOSS Dev che può diffondere la colpa tra più di 5 o 6 ragazzi, forse hai testato il tuo codice, forse non ti trovi in ​​quella situazione interessante dove i clienti ti chiamano per richiedere l'ora esatta del giorno in cui rilascerai la patch di oggi (mi piacerebbe farlo a Microsoft) o forse sei un dispiaciuto figlio di biscotti come me che ha appena spedito un nuovo aggiornamento e tornò a casa e teme di tornare al lavoro domani.

Ad ogni modo, sarai comunque più intelligente di me. In che modo le critiche sul campo incorniciate in "Devi essere un cattivo programmatore perché stai peggiorando il tuo software"?

Se questo accade a te ogni volta che lo schieri, potrebbe esserci un grave difetto nel tuo processo di sviluppo. Sospetterei un paio di cose che stanno causando i problemi.

1. Si sviluppa su un database delle stesse dimensioni (approssimativamente) della produzione? Altrimenti avrai sempre questi problemi perché le query che vanno bene con piccoli set di dati sono spesso cani con quelli grandi.
2. Carichi test in QA? Ciò che funziona bene con i test di un utente è molto diverso da come le cose risponderanno con 1000 utenti che provano a fare le cose contemporaneamente.
3. Pensi che la percezione dell'utente sia sbagliata e li tratti come se fossero stupidi per lamentarsi? Se è così, allora il tuo atteggiamento sta causando più lamentele non diminuendole.
4. Stai facendo un buon lavoro di test? Ritieni che le funzionalità del test di regressione non siano state modificate per vedere se sono interessate dalla modifica? Ti importa anche quanto tempo impiegano le cose prima che colpiscano?
5. Presti attenzione a quando è il momento giusto per gli utenti quando esegui la distribuzione o distribuisci allegramente una modifica al sistema di contabilità il giorno in cui vengono gestite le buste paga e ti chiedi perché gli utenti sono arrabbiati per il rallentamento?
6. Hai differenze ambientali tra dev e prod. A volte quelle fastidiose differenze nei sistemi operativi o nelle versioni del database causano problemi come questo. È spesso una buona idea avere un ambiente di gestione temporanea che sia esattamente come prod, alcune apparecchiature stesso sistema operativo, stesso database con dati il ​​più vicino possibile ai dati prod. Viene utilizzato per testare la distribuzione. Eseguilo prima su questo server e fai in modo che alcuni utenti o tester lo accedano e eseguano alcuni test.
7. Quanto è buono il processo di distribuzione, ti mancano spesso i passaggi? Può essere eseguito da qualcuno diverso dallo sviluppatore perché è chiaro quale codice va nel ramo che si sta distribuendo? Siamo molto più bravi a implementare il codice quando abbiamo un team di gestione della configurazione e nessuno ha avuto i diritti di stare seduto con prod e fare da babysitter apportando modifiche "oopsie". Automatizzare la tua build può essere di grande aiuto. Nessuno dovrebbe indovinare cosa deve andare a prode come dovrebbe essere andato al controllo qualità e messa in scena prima e tutti i problemi di depilazione risolti. Anche le modifiche al database di scripting sono fondamentali. Dovrebbero essere negli script e nel controllo del codice sorgente, quindi il processo di compilazione può raccoglierli senza che qualcuno debba ricordare, oh sì, dobbiamo cambiare la lunghezza della colonna B in 241 da 50.

In che modo le critiche sul campo incorniciate in "Devi essere un cattivo programmatore perché stai peggiorando il tuo software"?

Ma tale critica è per lo più giustificata. 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 "cattivo programmatore", quindi non prendere sul personale le critiche (comunque non prenderei mai le critiche professionali da un non collega). Basta ringraziare il cliente per aver segnalato il problema e risolverlo il prima possibile. È il tuo lavoro di buon programmatore.

Bene, 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-alfa, ma ho alcuni utenti interessati e a volte ricevo bug.

Quando ricevo un rapporto come questo da un utente, provo a usare il tocco personale. Non intendevo introdurre bug e voglio che abbiano una buona esperienza con il mio motore, quindi devo fargli credere. Innanzitutto, procurati un gestore IM 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 mi sto occupando del problema mentre parliamo.

Se è un'eccezione, di solito è piuttosto semplice. Riproduce il problema e il debugger lo afferra e ti porta direttamente alla posizione dell'errore con una traccia dello stack completo, ed è ovvio cosa sta succedendo. Se si tratta di prestazioni lente o comportamento errato, potrebbe richiedere un po 'più di tempo. Ma nella maggior parte dei casi posso avere una soluzione pronta entro i primi 20 minuti, al massimo. Lo zip e lo invio a loro per testare. "OK, penso di averlo capito. Vedi se funziona alla tua fine?"

La risposta è quasi universalmente un misto di stupore e gratitudine, perché la maggior parte degli sviluppatori (leggi: società di software) non corregge i bug e rilascia nuovamente così velocemente. E poi, se è stato risolto, ho trasformato un potenziale critico in un fan. È davvero una buona tecnica; Vorrei solo che più sviluppatori lo adottassero.

Personalmente prendo il problema positivamente. Interagisco continuamente con molti clienti e continuo a scrivere codice.

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

Grazie per avermi segnalato quel bug. Forse è stato introdotto insieme tutte le nuove funzionalità che abbiamo aggiunto. Lo ripareremo al più presto.

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

Anche se non ha ragione, tu come parte dell'azienda, 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 (incluso il tuo capo)
• sii orgoglioso di quello che stai facendo

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

Chiedo anche delle date quando lo notano. A volte, specialmente nei negozi aziendali, gli utenti non sanno quando esce una versione, sanno solo che il completamento di qualcosa richiede molto tempo e proprio ora si stanno lamentando.

Job Shadow. Non posso sottolinearlo abbastanza. Se sei abbastanza fortunato da avere utenti nelle vicinanze, guardali lavorare di tanto in tanto. Trovo spesso che ignorino i problemi evidenti e non li segnalino mai. Spesso si lamentano solo quando sanno che qualcosa è nuovo o inizialmente notano un problema.

Il passaggio 1 è che devi pensare che questo (l'aggiornamento interrompe altre cose) non è normale. L'aggiornamento non dovrebbe interrompere o rallentare altre parti dell'app. Non va bene, non è prevedibile, e non è colpa dell'utente quando si lamentano. Dovresti fare tutti i test possibili per cercare di prevenirlo. Quando succede, hai un problema 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, aggiunto quei due nuovi rapporti ... "e così via.

Il passaggio 3 è che devi avere esperienza nella ricerca di problemi perf e arresti anomali rapidamente, quindi sai quali tipi di cose sono suscettibili di causarli e puoi risolvere immediatamente il problema. Questa cosa è diventata attiva 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. Ora sei in modalità di emergenza 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 ognuna di queste miserie, dovresti imparare una lezione che testerai per la prossima volta. Diventerai "quel ragazzo" che si oppone a determinati costrutti perché "sarà orribile quando ci saranno 10.000 dischi".

Un po 'di più sul fronte "questo è normale". Gestisco (tra le altre cose che abbiamo in corso) un progetto agile per un cliente esterno. Abbiamo pubblicato circa ogni 6 settimane all'incirca da due o tre anni. E sì, l'uscita è programmata al minuto. Ne abbiamo fatto uno alle 8 di ieri. E all'incirca ogni quarta o quinta uscita (una o due volte l'anno, in altre parole) qualcosa si rompe dal vivo, e saltiamo in azione e lo facciamo nel modo più veloce possibile. Anche se testiamo e testiamo e testiamo prima del rilascio. Quindi diciamo loro cosa è successo. "C'era un piccolo bug nella distribuzione di giugno che lasciava questo campo vuoto, ma non ci siamo mai accorti perché non stavamo usando il valore in quel momento. Quindi in questa distribuzione quando abbiamo iniziato a usare il campo, quelli che erano vuoti hanno causato quel messaggio di errore che hai visualizzato. ho corretto il bug in modo che non potessero essere vuoti, mettere i valori nei record errati e confermare che non esplode più. Ci scusiamo. "O" Quel cambiamento di emergenza che hai chiesto, solo due giorni prima del rilascio, ha avuto conseguenze a cui non abbiamo pensato e per cui non abbiamo testato. Ricordi perché resistiamo ai cambiamenti di emergenza? "Potrei non essere un cattivo programmatore per aver peggiorato le cose con l'aggiornamento, ma sicuramente ho fatto una brutta cosa. E ho bisogno di farlo bene. Potrei non essere un cattivo programmatore per aver peggiorato le cose con l'aggiornamento, ma sicuramente ho fatto una brutta cosa. E ho bisogno di farlo bene. Potrei non essere un cattivo programmatore per aver peggiorato le cose con l'aggiornamento, ma sicuramente ho fatto una brutta cosa. E ho bisogno di farlo bene.

Giusto per coprire un altro aspetto:

Manteniamo un elenco di clienti che lo dichiarano quando non è stato così. Sebbene il software sia difettoso, spesso molto difettoso, molti dei nostri clienti dichiareranno "iniziato con l'aggiornamento" per ottenere una pronta attenzione, non rendendosi conto che ciò finisce per sprecare il tempo di tutti mentre cammineremo tra i delta per la funzionalità indicata alla ricerca del problema. Se il cliente dice la verità, tende a trovarlo rapidamente. Se il cliente è nella falsa lista troppe volte non ci preoccupiamo perché non ci piace perdere tempo.

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