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

14

No escritório, acabamos de sair de um longo período em que lançamos os patches frequentemente. Perto do final desse período, fazíamos quase três patches por semana, em média.

Além disso, isso foi muito desmotivador para os desenvolvedores, fiquei me perguntando o que o cliente pensaria sobre isso. Eu mesmo fiz a pergunta e concluí que nunca conheci um software que fosse atualizado com tanta frequência. No entanto, para o caso que vem mais próximo, eu não me importo realmente, já que os patches são aplicados rapidamente.

Os clientes que receberam esses patches diferem muito uns dos outros. Alguns estavam realmente esperando pelo patch onde os outros não se importavam, mas todos receberam os mesmos patches. O tempo para atualizar o software do cliente é de menos de 30 segundos, portanto, não espero nenhum problema com relação ao tempo. Eles precisam ser desconectados.

Então, minha pergunta com mais detalhes: está recebendo atualizações frequentemente dando uma mensagem 'negativa' para o receptor?

É claro que eu poderia perguntar aos clientes, mas não estou nessa posição nem quero 'Acordar os cachorros adormecidos'.

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

    
por Mixxiphoid 12.03.2014 / 20:27
fonte

4 respostas

24

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

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

    
por 12.03.2014 / 20:34
fonte
10

Eu sinto que liberar várias correções nas proximidades reflete mal na empresa. Sempre me faz sentir como se eles não tivessem testado tão cedo, que os desenvolvedores são incompetentes ou que o gerenciamento não tem ideia do que estão fazendo.

Dito isto, 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 para seu produto e continua melhorando seu produto para o consumidor.

Eu estou mais inclinado a sentir que o primeiro é a maneira como a maioria vai olhar do ponto de vista do consumidor, mas falar diretamente com eles será (obviamente) a melhor escolha, mas também levantará a questão dentro da base de clientes que eles podem não ter tido conhecimento inicialmente.

    
por 12.03.2014 / 20:32
fonte
7

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

O pré-requisito para implementar ciclos curtos de lançamento é uma atualização indolor - no chrome, por exemplo, a atualização é feita sem intervenção do usuário na inicialização do aplicativo, e se o usuário mantiver seu aplicativo sempre ativo, ele recebe uma bandeira secundária avisando-o para reiniciar o aplicativo no momento conveniente, e o aplicativo se esforça para retorná-lo ao seu estado anterior após o reinício.

Esse método deixa o cliente feliz, pois ele não precisa estar ciente de todas as atualizações e, como os lançamentos de recursos são frequentes, as versões de correção de bugs serão bem-vindas.

Se, por outro lado, os patches vierem após bugs de show-stopper, e eles aparecerem em clusters, já que os anteriores falharam em corrigir o bug, ou criaram um bug maior - tenha certeza de que seus clientes irão sentir o cheiro. Isso definitivamente refletirá mal a reputação profissional do fornecedor e diminuirá os padrões de software percebidos pelo fornecedor. Entrega contínua depende muito de testes de unidade e testes de integração eficazes para garantir seu sucesso.

Na questão de não conversar com seus clientes para "deixar os cães adormecidos mentirem", 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 pode apenas garantir que eles são sua prioridade e que você é receptivo às críticas deles. Se você entregou lançamentos ruins algumas vezes, e você não os ouve reclamar - você deve definitivamente estar preocupado - não é que eles não tenham notado, mais provavelmente eles estão apenas ocupados encontrando um substituto para você ...

    
por 12.03.2014 / 21:38
fonte
2

Os patches especificamente para os clientes que detectaram um problema obviamente precisarão sair o mais rápido possível.

Tenho visto softwares em grandes empresas e, em seguida, tenho a abordagem de que outros clientes obterão esses patches como um service pack em intervalos regulares programados. Normalmente, porque os patches requerem algum esforço para instalar e testar no ambiente do cliente, mas no seu caso, ele poderia ser usado apenas para diminuir o possível impacto do efeito que você está preocupado.

Eu também já vi pessoas recomendando a colocação de correções em repositórios ou em sites onde 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, você precisa determinar exatamente qual código eles estão executando, mas com cuidado que pode ser rastreado. Você pode, então, forçar as pessoas a atualizar para um dos maiores 'pacotes' quando um é liberado que agrupa muitos patches.

A exceção são os patches de segurança. Uma grande empresa de software sediada em Washington é conhecida por entrar na água quente esperando pela terceira quinta-feira do mês antes de liberar os patches de segurança críticos e as informações sobre o hack vazaram e forçaram a mão deles a um embaraço ainda maior.

O Google Chrome contorna o problema com a atualização automática com muita frequência, eles também exigem que você faça o ciclo do programa (reinicie o cromo ou, no seu caso, efetue logout). Eles agora fizeram essa prática normal para os navegadores e as pessoas nem pensam mais nisso. Mas nem todo mundo pode ser o Google.

Os aplicativos SaaS lidam com todo o problema fazendo as atualizações em segundo plano.

No entanto, acima de tudo, a menos que você faça integração contínua ou atualização 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 encontrar seus clientes e falar sobre a frequência de correções de erros, você provavelmente 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ódigo de buggy desde muito cedo, contanto que você saiba que é o que é, mas acho que você precisa ter uma boa compreensão da sua qualidade conhecida, o que significa entender e manter sob controle seu tempo para conhecer a qualidade.

    
por 12.03.2014 / 21:15
fonte