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

In ufficio siamo appena usciti da un lungo periodo in cui rilasciavamo patch su una base troppo frequente. Verso la fine di quel periodo stavamo facendo in media quasi tre cerotti alla settimana.

Oltre a questo è stato molto demotivante per gli sviluppatori, mi chiedevo cosa ne pensasse il cliente. Ho posto la domanda da solo e ho concluso che non avevo mai conosciuto un software aggiornato di frequente. Tuttavia, per il caso che si avvicina di più non mi interessa davvero poiché le patch vengono applicate abbastanza rapidamente.

I clienti che hanno ricevuto queste patch differiscono molto gli uni dagli altri. Alcuni stavano davvero aspettando la patch dove ad altri non importava davvero, eppure avevano tutti le stesse patch. Il tempo di aggiornamento del software del cliente è inferiore a 30 secondi, quindi non mi aspetto alcun problema relativo al tempo. Tuttavia, devono essere disconnessi.

Quindi la mia domanda in modo più dettagliato: ricevere aggiornamenti frequentemente dà un messaggio "negativo" al destinatario?

Certo, potrei chiedere ai clienti, ma non sono in quella posizione né voglio "Risvegliare i cani che dormono".

PS: Se c'è qualcosa che potrei fare per migliorare la mia domanda, ti preghiamo di lasciare un commento.

Come per molte cose nell'informatica, dipende. Se le patch rispondono 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, la tua azienda verrà considerata incompetente.

Testare il software sui tuoi clienti è di gran lunga il modo più costoso possibile per rilevare i bug, indipendentemente da ciò che dicono tutti. È una falsa economia; la manodopera gratuita che ritieni 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.

Ho voglia di rilasciare diverse patch nelle immediate vicinanze riflette male sulla società. Mi fa sempre sentire come se non avessero testato abbastanza in anticipo, che gli sviluppatori fossero incompetenti o che il management non avesse idea di cosa stessero facendo.

Detto questo, l'altro lato del token è che il rilascio di più patch vicine tra loro mostra che la società sta adottando un approccio proattivo al proprio prodotto e continua a migliorare il proprio prodotto per il consumatore.

Sono più propenso 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 (ovviamente) sarà la scelta migliore, ma solleverà anche il problema all'interno della base clienti che potrebbero non essere stato a conoscenza inizialmente.

Sempre più aziende seguono le orme di Chrome e hanno versioni sempre più frequenti 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 accesa, riceve un flag minore consigliargli di riavviare l'applicazione nel momento opportuno e l'applicazione fa quindi lo sforzo di riportarlo al suo stato precedente dopo il riavvio.

Questo metodo rende felice il cliente, poiché non è necessario che sia a conoscenza di ogni aggiornamento e poiché le versioni delle funzionalità sono frequenti, le versioni di correzione dei bug saranno altrettanto gradite.

Se, d'altra parte, le patch vengono dopo i bagliori evidenti dei bug di show-stopper, e si presentano in gruppi, poiché i precedenti non riuscivano a correggere il bug o creavano un bug più grande, state certi che i vostri clienti ne sentiranno l'odore. Ciò si rifletterà sicuramente in modo negativo sulla reputazione professionale del fornitore e ridurrà gli standard software percepiti dal fornitore. La consegna continua si basa fortemente su test unitari efficaci e test di integrazione per garantirne il successo.

Per quanto riguarda il fatto di non parlare con i tuoi clienti per "far mentire i cani che dormono", credo che questa sia una strategia sbagliata: i clienti non sono ciechi e non sono sciocchi. Credo che una buona comunicazione con i tuoi clienti possa solo rassicurarli sul fatto che sono la tua priorità e che sei ricettivo alle loro critiche. Se hai rilasciato un paio di volte di cattive pubblicazioni e non le senti lamentare - dovresti sicuramente preoccuparti - non è che non se ne siano accorte, più probabilmente sono solo impegnate a trovare un sostituto per te ...

Le patch specifiche per i clienti che hanno rilevato un problema dovranno ovviamente uscire il prima possibile.

Ho visto software in grandi aziende quindi adottare l'approccio secondo cui altri clienti riceveranno quelle 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 utilizzate solo per ridurre il possibile impatto dell'effetto di cui ti preoccupi.

Ho anche visto persone incoraggiare l'installazione di patch in repository o su siti Web in cui i clienti possono scaricare e installare quelli che desiderano. Questo può creare problemi nel sapere quali patch hanno i clienti, quindi quando chiamano un problema devi determinare esattamente quale codice stanno eseguendo, ma con attenzione che possono essere monitorati. È quindi possibile forzare le persone a passare a uno dei "pacchetti" più grandi quando viene rilasciato uno che raggruppa molte patch.

L'eccezione sono le patch di sicurezza. Una grande società di software con sede a Washington è nota per entrare nell'acqua calda aspettando il terzo giovedì del mese prima di rilasciare patch di sicurezza critiche e le informazioni sull'hacking sono trapelate e hanno costretto la mano presto a un imbarazzo ancora maggiore.

Google Chrome risolve il problema aggiornando automaticamente molto frequentemente, anche loro richiedono il ciclo del programma (riavvia Chrome o, nel tuo caso, esci). 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 un'integrazione continua o l'aggiornamento con le funzionalità richieste dai nuovi utenti molto frequentemente, penso che siamo ancora in un momento in cui le persone si aspettano che tu abbia fatto un discreto numero di test prima del rilascio. Se saresti imbarazzato di incontrare i tuoi clienti e parlare della frequenza delle correzioni di bug, probabilmente non stai facendo abbastanza test. Hai rilasciato il rischio che stavi correndo prima di rilasciare il codice. C'è un argomento per rilasciare il codice buggy molto presto, purché tu sappia che è quello che è, ma penso che tu debba avere una buona comprensione della tua qualità nota, il che significa capire e tenere sotto controllo il tuo tempo per conoscere la qualità.