Os patches são um mau sinal para o cliente? [fechadas]

No escritório, acabamos de sair de um longo período em que lançamos patches com muita frequência. Perto do final desse período, estávamos fazendo quase três patches por semana, em média.

Além disso, isso foi muito desmotivador para os desenvolvedores, e fiquei pensando o que o cliente pensaria sobre isso. Eu mesmo fiz a pergunta e concluí que nunca conhecia softwares atualizados com tanta frequência. No entanto, para o caso mais próximo, não me importo, pois os patches são rapidamente aplicados.

Os clientes que receberam esses patches diferem muito um do outro. Alguns estavam realmente esperando pelo patch, onde outros realmente não se importavam, mas todos receberam os mesmos patches. O tempo para atualizar o software dos clientes é inferior a 30 segundos; portanto, não espero problemas com o tempo. Eles precisam estar desconectados.

Portanto, minha pergunta com mais detalhes: as atualizações são frequentes, dando uma mensagem 'negativa' ao destinatário?

Claro, eu poderia perguntar aos clientes, mas não estou nessa posição nem quero 'Despertar os cães adormecidos'.

PS: Se houver algo que eu possa fazer para melhorar minha pergunta, deixe um comentário.

Como muitas coisas na computação, isso depende. Se os patches forem uma resposta às solicitações dos clientes por novos recursos ou melhorias, sua empresa será vista como responsiva. Se, por outro lado, seus patches forem uma resposta a relatórios de erros, sua empresa será vista como incompetente.

Testar software em seus clientes é de longe a maneira mais cara possível de detectar bugs, independentemente do que alguém diga. É uma economia falsa; o trabalho livre que você acha que está recebendo é mais do que compensado pelo esforço de atendimento ao cliente, interrompendo o ciclo de vida de desenvolvimento de software e perdendo a confiança do cliente.

Sinto que o lançamento de vários patches nas proximidades reflete mal a empresa. Sempre me faz sentir que eles não testaram com bastante antecedência, que os desenvolvedores são incompetentes ou que a gerência não tem ideia do que está fazendo.

Dito isso, o outro lado do token é que a liberação de vários patches próximos um do outro mostra que a empresa está adotando uma abordagem proativa do produto e continua aprimorando o produto para o consumidor.

Estou mais inclinado a achar que o primeiro é o modo como a maioria encarará do ponto de vista do consumidor, mas falar diretamente com ele será (obviamente) a melhor escolha, mas também levantará a questão na base de clientes que eles podem não tinha conhecimento inicialmente.

Mais e mais empresas seguem os passos do Chrome e têm lançamentos de clientes cada vez mais frequentes.

O pré-requisito para implementar ciclos de liberação curtos é uma atualização simples - no Chrome, por exemplo, a atualização é feita sem a intervenção do usuário na inicialização do aplicativo e, se o usuário mantiver seu aplicativo sempre ativo, ele receberá um sinalizador menor aconselhando-o a reiniciar o aplicativo no momento oportuno, e o aplicativo se esforça para devolvê-lo ao estado anterior após o reinício.

Esse método deixa o cliente satisfeito, pois ele não precisa estar ciente de todas as atualizações e, como os lançamentos de recursos ocorrem com frequência, os lançamentos de correções de bugs serão igualmente bem-vindos.

Se, por outro lado, os patches vierem após bugs gritantes, e eles vêm em grupos, já que os anteriores não conseguiram corrigir o erro ou criaram um bug maior - tenha certeza de que seus clientes sentirão o cheiro. Definitivamente, isso refletirá mal na reputação profissional do fornecedor e diminuirá os padrões de software percebidos pelo fornecedor. A entrega contínua depende muito de testes de unidade eficazes e testes de integração para garantir seu sucesso.

Sobre o assunto de não conversar com seus clientes para 'deixar os cachorros dormirem', acredito que essa é uma estratégia errada - os clientes não são cegos e não são tolos. Acredito que uma boa comunicação com seus clientes possa apenas garantir que eles são sua prioridade e que você é receptivo às críticas deles. Se você fez lançamentos ruins algumas vezes e não os ouviu reclamar - você definitivamente deveria estar preocupado - não é que eles não tenham notado, é mais provável que estejam ocupados em encontrar um substituto para você ...

Patches especificamente para clientes que detectaram um problema obviamente precisarão ser lançados o mais rápido possível.

Eu já vi softwares de grandes empresas adotando a abordagem de que outros clientes receberão esses patches como service pack em intervalos regulares programados. Normalmente, porque os patches exigem algum esforço para instalar e testar no ambiente do cliente, mas, no seu caso, ele pode ser usado apenas para diminuir o possível impacto do efeito com o qual você está preocupado.

Também vi pessoas advogando a colocação de patches em repositórios ou em sites em que os clientes podem baixar e instalar os que desejam. Isso pode criar problemas para saber quais patches os clientes têm; portanto, quando eles ligam com um problema, é necessário determinar exatamente qual código eles estão executando, mas com cuidado que pode ser rastreado. Em seguida, você pode forçar as pessoas a atualizar para um dos 'pacotes' maiores quando for lançado um pacote que inclua muitos patches.

A exceção são os patches de segurança. Sabe-se que uma grande empresa de software com sede em Washington entra em água quente aguardando a terceira quinta-feira do mês antes de liberar correções críticas de segurança e informações sobre o hack vazaram e forçaram suas mãos cedo a um constrangimento ainda maior.

O Google chrome soluciona o problema atualizando automaticamente com muita frequência; eles também exigem que você alterne o programa (reinicie o chrome ou saia do seu caso). Eles agora adotaram essa prática normal para navegadores e as pessoas nem sequer pensam nisso. Mas nem todo mundo pode ser o Google.

Os aplicativos SaaS resolvem o problema fazendo as atualizações em segundo plano.

No entanto, acima de tudo, a menos que você esteja fazendo integração ou atualização contínua com novos recursos solicitados pelo usuário com muita frequência, acho que ainda estamos em um momento em que as pessoas esperam que você tenha feito uma quantidade razoável de testes antes do lançamento. Se você ficaria envergonhado de conhecer seus clientes e falar sobre a frequência das correções de bugs, provavelmente você não está fazendo testes suficientes. Você liberou o risco que estava correndo antes de liberar o código. Há um argumento para liberar códigos de bugs muito cedo, desde que você saiba o que é, mas acho que você precisa entender bem sua qualidade conhecida, o que significa entender e manter sob controle seu tempo para conhecer a qualidade.