Le patch sono un brutto segno per il cliente? [chiuso]

Come per molte cose in informatica, dipende. Se le patch rappresentano una risposta alle richieste dei clienti di nuove funzionalità o miglioramenti, la tua azienda verrà considerata reattiva. Se, d'altra parte, le tue patch sono una risposta alle segnalazioni di bug, allora la tua azienda sarà considerata incompetente.

Il test dei software sui tuoi clienti è di gran lunga il metodo più costoso per rilevare i bug, a prescindere da ciò che qualcuno dice. È una falsa economia; la manodopera gratuita che pensi di ottenere è più che compensata dallo sforzo del servizio clienti, interrompendo il ciclo di vita dello sviluppo del software e perdendo la fiducia dei clienti.

Mi sento come se rilasciare diverse patch in stretta prossimità riflette male sulla società. Mi fa sempre pensare che non siano stati testati abbastanza in anticipo, che gli sviluppatori sono incompetenti, o che la direzione non ha idea di cosa stiano facendo.

Detto questo, l'altro lato del token è che rilasciando diverse patch vicine l'una all'altra mostra che l'azienda sta adottando un approccio proattivo al proprio prodotto e sta continuando a migliorare il proprio prodotto per il consumatore.

Sono più incline a pensare che il primo sia il modo in cui la maggior parte lo guarderà dal punto di vista del consumatore, ma parlare direttamente con loro sarà (ovviamente) la scelta migliore, ma solleverà anche il problema all'interno della base di clienti di cui forse non erano a conoscenza inizialmente.

Sempre più aziende seguono le orme di Chrome e hanno sempre più frequenti versioni dei clienti.

Il prerequisito per l'implementazione di cicli di rilascio brevi è un aggiornamento indolore: in chrome, ad esempio, l'aggiornamento viene eseguito senza l'intervento dell'utente all'avvio dell'applicazione e se l'utente mantiene la sua applicazione sempre attiva, riceve una bandiera minore che gli consiglia di riavviare l'applicazione al momento opportuno, e l'applicazione fa quindi lo sforzo di riportarlo al suo stato precedente dopo il riavvio.

Questo metodo lascia il cliente felice, dato che non ha bisogno di essere a conoscenza di ogni aggiornamento, e dal momento che le versioni vengono frequentemente, i rilasci di correzioni di bug saranno i benvenuti.

Se, d'altra parte, le patch arrivano dopo i vistosi bug di show-stopper, e arrivano in cluster, poiché i precedenti non riuscivano a correggere il bug, o creavano un bug più grande - certi che i tuoi clienti ne sentiranno l'odore. Questo sicuramente si rifletterà in modo negativo sulla reputazione professionale del fornitore e abbasserà gli standard del software percepito dal fornitore. La consegna continua dipende in gran parte dall'efficacia dei test unitari e dei test di integrazione per garantirne il successo.

Sulla questione di non parlare con i tuoi clienti di "lasciare dormire i cani che dormono", credo che questa sia una strategia sbagliata: i clienti non sono ciechi e non sono stupidi. Credo che una buona comunicazione con i tuoi clienti possa solo rassicurarli sul fatto che sono la tua priorità e che tu sei ricettivo alle loro critiche. Se hai consegnato versioni difettose un paio di volte, e non li senti lamentarsi, dovresti essere sicuramente preoccupato - non è che non se ne siano accorti, più probabilmente sono solo impegnati a trovare un sostituto per te ...

Le patch specificatamente per i clienti che hanno rilevato un problema hanno ovviamente bisogno di uscire il prima possibile.

Ho visto software di grandi aziende che hanno adottato l'approccio che altri clienti otterranno tali patch come service pack a intervalli regolari programmati. Normalmente perché le patch richiedono un certo sforzo per l'installazione e il test nell'ambiente del cliente, ma nel tuo caso potrebbero essere semplicemente utilizzate per ridurre il possibile impatto dell'effetto che ti preoccupa.

Ho anche visto persone invocare la messa a punto di patch in repository o su siti Web dove i clienti possono scaricare e installare quelli che vogliono. Questo può creare problemi con la conoscenza delle patch che i clienti hanno, quindi quando chiamano con un problema devi determinare esattamente quale codice sono in esecuzione, ma con attenzione che può essere monitorato. È quindi possibile forzare le persone a eseguire l'aggiornamento a uno dei "pacchetti" più grandi quando ne viene rilasciato uno che raggruppa molte patch.

L'eccezione sono le patch di sicurezza. Una grossa società di software con base a Washington è stata conosciuta per entrare in acqua calda aspettando il terzo giovedì del mese prima di rilasciare patch di sicurezza critiche e le informazioni sull'hack sono trapelate e costrette la mano presto a un imbarazzo ancora maggiore.

Google Chrome aggira il problema con l'aggiornamento automatico molto spesso, anch'essi richiedono il ciclo del programma (riavvia Chrome o, nel tuo caso, disconnetti). Ora hanno fatto quella pratica normale per i browser e le persone non ci pensano nemmeno più. Ma non tutti possono essere Google.

Le applicazioni SaaS risolvono l'intero problema eseguendo gli aggiornamenti in background.

Tuttavia, soprattutto, a meno che tu non stia facendo l'integrazione continua o l'aggiornamento con nuove funzionalità richieste dall'utente molto frequentemente, allora penso che siamo ancora in un momento in cui le persone si aspettano che tu abbia fatto una discreta quantità di test prima del rilascio. Se ti vergogneri di incontrare i tuoi clienti e parlare della frequenza delle correzioni dei bug, probabilmente non stai facendo abbastanza test. Hai rilasciato il rischio che stavi assumendo prima di rilasciare il codice. C'è un argomento per il rilascio di codice buggy molto precoce, purché tu sappia che è quello che è, ma penso che tu abbia bisogno di avere una buona comprensione della tua qualità nota, il che significa capire e tenere sotto controllo il tuo tempo per conoscere la qualità.