ti-enxame.com

Como você responde a: "Desde a atualização ..." perguntas dos clientes?

Desde a atualização, as pessoas continuam ligando e dizendo "Desde a atualização X, Y e Z estão lentos, ruins e travando"

Isso tem acontecido desde o início das atualizações.

O que as pessoas esperam? Gamma vem depois do beta, e os testes gama sempre transformam nossos usuários em Incríveis Hulks ...

Talvez você nunca tenha ouvido isso de um cliente, talvez você esteja na faculdade ou um FLOSS Dev que pode espalhar a culpa por mais de 5 ou 6 caras, talvez você teste de unidade seu código, talvez você não esteja nessa situação interessante onde os clientes realmente ligam para você solicitando a hora exata do dia em que você lançará o patch de hoje (adoraria fazer isso com a Microsoft) ou talvez você seja um filho da puta como eu, que acabou de enviar um novo atualizar e foi para casa e está com medo de voltar a trabalhar amanhã.

De qualquer forma, vocês são mais espertos do que eu. Como você enfrenta críticas enquadradas em "Você deve ser um mau programador porque está piorando o seu software"?

19
Peter Turner

Se isso acontecer com você toda vez que você implantar, pode haver uma falha séria em seu processo de desenvolvimento. Eu suspeitaria de algumas coisas que estão causando os problemas.

  1. Você desenvolve em um banco de dados que é do mesmo tamanho (aproximadamente) da produção? Do contrário, você sempre terá esses problemas porque as consultas que são boas com conjuntos de dados pequenos geralmente são cães com conjuntos grandes.
  2. Você carrega o teste no controle de qualidade? O que funciona bem com um teste de usuário é muito diferente de como as coisas respondem com 1000 usuários tentando fazer as coisas ao mesmo tempo.
  3. Você presume que a percepção do usuário está errada e o trata como se fosse estúpido por reclamar? Nesse caso, sua atitude está causando mais reclamações, mas não diminuindo-as.
  4. Você está fazendo um bom trabalho de teste? Seus recursos de teste de regressão não mudaram para ver se eles são afetados pela mudança? Você se importa quanto tempo as coisas demoram até atingirem o estímulo?
  5. Você presta atenção em quando é um bom momento para os usuários ao implantar ou implanta alegremente uma mudança no sistema de contabilidade no dia em que a folha de pagamento é executada e se pergunta por que os usuários estão irritados com a lentidão?
  6. Você tem diferenças ambientais entre dev e prod. Às vezes, essas diferenças incômodas em sistemas operacionais ou versões de banco de dados também podem causar problemas como este. Muitas vezes, é uma boa ideia ter um ambiente de teste que seja exatamente como prod, algum equipamento mesmo sistema operacional, mesmo banco de dados com dat que seja o mais próximo possível dos dados de produto. Isso é usado para testar sua implantação. Execute-o primeiro neste servidor e peça a alguns usuários ou testadores que acessem e executem alguns testes.
  7. Quão bom é o seu processo de implantação, você costuma perder etapas? Ele pode ser executado por alguém que não seja o desenvolvedor porque está claro qual código vai no branch que você está implantando? Nós ficamos muito melhores na implantação de código quando tínhamos uma equipe de gerenciamento de configuração e ninguém tinha o direito de sentar-se com o prod e cuidar dele fazendo mudanças "oopsie". Automatizar sua construção pode ajudar tremendamente. Ninguém deve estar adivinhando o que precisa ser feito para estimular, pois deveria ter passado para o controle de qualidade e teste primeiro e quaisquer problemas de desenvolvimento resolvidos. O script de mudanças no banco de dados também é fundamental. Eles devem estar em scripts e no controle de origem, para que o processo de construção possa selecioná-los sem que alguém tenha que se lembrar, oh sim, precisamos alterar o comprimento na coluna B de 50 para 241. Acho que as pessoas muitas vezes se esquecem de tratar o banco de dados muda conforme o código prefere usar a GUI, o que é quase sempre uma má ideia no prod.
16
HLGEM

Como você enfrenta críticas enquadradas em "Você deve ser um mau programador porque está piorando o seu software"?

Mas essa crítica é justificada em grande parte. Uma nova versão não deve ser pior que a anterior, mas como sabemos, na realidade muitas vezes é, e a culpa é nossa porque a fizemos.

Cometer erros é humano e não faz de ninguém um "mau programador", então não leve as críticas para o lado pessoal (eu nunca levaria qualquer crítica profissional de um não-colega a sério). Agradeça ao cliente por relatar o problema e corrija-o assim que possível. É o seu trabalho como um bom programador.

13
Joonas Pulakka

Bem, no trabalho não interagimos muito diretamente com os clientes, então terei que responder a esta com um projeto pessoal de trabalho. Estou escrevendo um motor de jogo que as pessoas podem usar para construir seus próprios jogos. Ainda está em pré-alfa, mas tenho alguns usuários interessados ​​e às vezes recebo bugs.

Quando recebo um relatório como este de um usuário, tento usar o toque pessoal. Não tive a intenção de introduzir bugs e quero que eles tenham uma boa experiência com meu motor, então preciso fazê-los acreditar nisso. Primeiro, obtenha um identificador de mensagens instantâneas para que possamos conversar. Vou perguntar ao usuário sobre seu projeto e tentar obter uma cópia dele. Isso torna a reprodução muito mais fácil. Pergunte o que estavam fazendo quando a falha ocorreu. Enquanto isso, estou com o mecanismo aberto no depurador e estou analisando o problema enquanto conversamos.

Se for uma exceção, geralmente é muito simples. Reproduza o problema e o depurador o pega e leva você direto para o local do erro com um rastreamento de pilha completo, e é óbvio o que está acontecendo. Se for um desempenho lento ou comportamento incorreto, pode demorar um pouco mais. Mas, na maioria dos casos, consigo ter uma solução pronta nos primeiros 20 minutos, no máximo. Eu fecho e envio para eles testarem. "OK, acho que entendi. Vê se isso funciona no seu lado?"

A resposta é quase universalmente uma mistura de espanto e gratidão, porque a maioria dos desenvolvedores (leia-se: empresas de software) simplesmente não corrige bugs e relança tão rápido. E então, se for realmente consertado, transformei um crítico em potencial em um fã. É uma técnica muito boa; Eu só queria que mais desenvolvedores o adotassem.

9
Mason Wheeler

Eu pessoalmente encaro o problema de forma positiva. Eu interajo o tempo todo com muitos clientes e ainda codifico também.

Quando eles baixam um novo lançamento e me dizem algo assim, sempre digo algo assim:

Obrigado por me relatar esse bug. Talvez tenha sido introduzido junto com todos os novos recursos que adicionamos. Vamos consertar o mais rápido possível.

Na verdade, o cliente é seu verdadeiro chefe. Se a experiência com você for ruim, será ruim para você também.

Mesmo que ele não esteja certo, você como parte da empresa, você deve aproveitar esta oportunidade para:

  • aprenda com ele, coletando melhorias potenciais que você pode fazer no produto.
  • converter um cliente insatisfeito em um cliente feliz, tão feliz que ele falará sobre você (incluindo seu chefe)
  • tenha orgulho do que você está fazendo
6
user2567

Detalhes, detalhes, detalhes. Eu pergunto o que eles estavam fazendo e quando, seja específico. Pode ser alguma coisa ou pode ser apenas o vídeo do Justin Beaber lançado no youtube. Os arquivos de log são seus amigos em ambos os casos.

Também peço datas em que eles notaram. Às vezes, especialmente em lojas corporativas, os usuários não sabem quando uma versão é lançada, eles apenas sabem que algo leva muito tempo para ser concluído e agora estão reclamando disso.

Sombra do trabalho. Não posso enfatizar isso o suficiente. Se você tiver a sorte de ter usuários por perto, apenas observe-os trabalhar de vez em quando. Freqüentemente descubro que eles ignoram problemas evidentes e nunca os relatam. Freqüentemente, eles só reclamam quando sabem que algo é novo ou quando percebem um problema inicialmente.

4
Bill Leeper

A etapa 1 é que você deve ter uma mentalidade de que isso (a atualização quebra outras coisas) não é normal. Sua atualização não deve interromper ou deixar outras partes do aplicativo lentas. Não está ok, não é esperado, e não é culpa do usuário quando reclama. Você deve fazer o máximo de testes possível para tentar evitá-lo. Quando isso acontece, você tem um problema urgente.

O passo 2 é que você deve saber o que fez. Seu sistema de controle de origem pode ser capaz de ajudá-lo, ou algum tipo de sistema de rastreamento de trabalho, mas você deve ser capaz de dizer no minuto em que receber uma dessas reclamações "ok, adicionei uma coluna a esta tabela, alterei esta grade para calcular os novos impostos, acrescentou esses dois novos relatórios ... "e assim por diante.

A etapa 3 é que você deve ter experiência em encontrar problemas de desempenho e travamentos rapidamente, para saber quais tipos de coisas podem causá-los e pode resolver o problema imediatamente. Esta coisa foi ativada e você deve encontrar o problema rapidamente e obter um patch. A alteração de um relatório não pode diminuir a velocidade de uma parte do aplicativo que não usa o relatório. Você está no modo de emergência agora e precisa descobrir onde está o erro e o que fazer a respeito - sem quebrar outra parte do aplicativo no processo.

O passo 4 é para cada uma dessas misérias, você deve aprender uma lição que irá testar na próxima vez. Você se tornará "aquele cara" que se opõe a certas construções porque "isso será horrível quando houver 10.000 registros".

Um pouco mais na frente "isso é normal". Eu executo (entre todas as outras coisas que temos em andamento) um projeto ágil para um cliente externo. Temos lançado lançamentos aproximadamente a cada 6 semanas por dois ou três anos. E sim, o lançamento está agendado para o minuto. Acabamos de fazer um ontem às 8h. E aproximadamente a cada 4 ou 5 lançamentos (uma ou duas vezes por ano, em outras palavras) algo é interrompido ao vivo, e nós entramos em ação e fazemos tudo certo o mais rápido possível. Mesmo que testemos e testemos e testemos antes do lançamento. Então contamos a eles o que aconteceu. "Houve um pequeno bug na implantação de junho que deixou este campo em branco, mas nunca percebemos porque não estávamos usando o valor naquele momento. Então, nesta implantação, quando começamos a usar o campo, os que estavam em branco causaram aquela mensagem de erro que você viu. Corrigimos o bug para que eles não pudessem ficar em branco, colocamos valores nos registros inválidos e confirmamos que ele não explode mais. Nossas desculpas. " Ou "Aquela mudança de emergência que você implorou, apenas dois dias antes do lançamento, teve consequências nas quais não pensamos e não testamos. Lembra por que resistimos às mudanças de emergência?" Posso não ser um mau programador por piorar as coisas com a atualização, mas certamente fiz algo ruim. E eu preciso consertar isso.

3
Kate Gregory

Só para cobrir outro aspecto:

Mantemos uma lista de clientes que afirmam isso quando, na verdade, não foi assim. Embora o software tenha bugs, muitas vezes muitos bugs, muitos de nossos clientes alegarão "iniciaram com a atualização" para obter atenção imediata, não percebendo que isso acaba perdendo o tempo de todos, pois percorreremos os deltas para o recurso indicado procurando o problema. Se o cliente estiver dizendo a verdade, isso tende a ser encontrado rapidamente. Se o cliente estiver na lista falsa muitas vezes, não nos importamos, pois não gostamos de perder tempo.

Não consigo imaginar que tipo de mentalidade é necessária para pensar que dizer uma mentira aceleraria o processo. Essas pessoas são ou trabalham com médicos e devem saber muito bem o que acontece quando as pessoas mentem para os médicos. O mesmo princípio se aplica.

0
Joshua