Há três semanas, a pessoa responsável pelas inscrições relatou que o formulário de renovação estava pulando o segundo filho de uma família. Alguns dias depois veio a resposta: corrigido. Hoje à noite, um pai mandou mensagem para o clube dizendo que o formulário aceitou um filho e parou.
Então o mesmo voluntário passa por tudo de novo. Percebe o problema, descobre que é o mesmo de antes, procura o e-mail antigo, relata pela segunda vez e fica cobrando a resposta. O erro em si talvez tome uma tarde de um engenheiro. O custo real cai sobre o clube: a noite de um voluntário, uma família que agora se pergunta se o clube consegue manter um formulário funcionando e uma diretoria que deixa de acreditar na palavra "corrigido".
Todo clube que depende de software já viveu alguma versão disso. Este guia explica, em linguagem simples, por que erros corrigidos voltam, o que "corrigido" deveria significar, como uma plataforma pode reabrir sozinha um problema que voltou em vez de esperar uma segunda reclamação e o que a sua diretoria pode razoavelmente esperar e perguntar.
Por que erros corrigidos voltam
Um erro que volta depois de uma correção é comum, e raramente significa que alguém foi desonesto. A maioria das tarefas em um software pode ser feita por vários caminhos, e um relato de erro em geral descreve uma passagem por um deles. Quatro explicações cobrem quase tudo o que os clubes enfrentam.
A correção cobriu um caminho, e o problema tinha outros
Uma família pode renovar pelo site do clube, por um link em um e-mail ou pela página da própria conta. Pode estar no celular ou no notebook, entrando pela primeira vez ou voltando. Cada um desses caminhos pode passar por um código ligeiramente diferente. Se o relato descrevia o link do e-mail no celular, a correção pode ter consertado exatamente isso, enquanto a mesma falha continuava intacta no caminho da página da conta. Do lado do clube, o problema voltou. Do lado do engenheiro, acabou de aparecer uma segunda cópia dele.
A correção ainda não estava no ar
Uma correção é escrita, verificada e depois publicada como parte de uma atualização. Entre "corrigimos" e "a atualização chegou a todos" existe um intervalo, e a versão antiga continua funcionando durante esse intervalo. Se o tesoureiro tentar de novo naquela tarde, talvez ainda esteja usando a versão com o erro. Ele vê a mesma falha e conclui, com razão, que a correção não funcionou. Muitas vezes funcionou. Só ainda não tinha chegado.
Uma mudança posterior desfez a correção
O software está sempre mudando. Um novo recurso, uma limpeza de código antigo ou a correção de outro problema pode mexer na mesma parte do produto e reabrir, sem alarde, uma falha antiga. Os engenheiros chamam isso de regressão. É uma das falhas mais comuns em software, e é o motivo pelo qual um bom processo continua observando depois que uma correção é publicada.
Às vezes a mudança posterior nem está no software. Um novo membro da diretoria ajusta uma configuração, e aparece algo que parece exatamente o erro antigo. Vale a pena descartar isso primeiro. No ClubHelix, os administradores podem consultar o registro de auditoria, que registra as mudanças feitas por administradores e nas configurações, então a pergunta "o software mudou ou foi um de nós?" tem resposta.
O relato descrevia um sintoma com mais de uma causa
"Os pagamentos não estão funcionando" é um sintoma. Por trás dele pode haver uma finalização de compra que falha em um navegador, um pagamento que é concluído mas nunca aparece como pago e um e-mail de recibo que não é enviado. São três problemas separados com uma única descrição. Corrigir aquele que o engenheiro conseguiu reproduzir é um avanço real, e na próxima vez que um dos outros dois acontecer, o relato original parece verdadeiro de novo. É por isso que um relato preciso importa tanto. O nosso guia sobre como relatar um erro no sistema do seu clube mostra o que incluir.
O que "corrigido" deveria significar
Quando um fornecedor diz "corrigido", a diretoria entende "isso não vai acontecer de novo". Os engenheiros muitas vezes querem dizer algo mais restrito: "mudamos o código que causou o que vimos". As duas leituras são razoáveis, e a frustração mora no espaço entre elas.
Uma definição útil tem três partes:
- A causa foi encontrada e alterada. Algo foi de fato consertado. Uma solução provisória ou uma mensagem de erro mais amigável é outra coisa, e não há problema em ser informado sobre qual das duas você recebeu.
- A correção está no ar. Ela chegou à versão que as pessoas realmente estão usando.
- O problema parou de acontecer. Alguém confirmou, a partir do uso real, que a falha não está mais ocorrendo, e continua confirmando por um tempo depois disso.
A terceira parte é a que a maioria dos processos pula. Um chamado fechado no dia em que o código mudou é uma declaração de intenção. Um chamado que continua fechado porque a falha realmente parou é uma evidência. A diferença só aparece quando uma correção não se sustenta, e esses são os dias de que um clube se lembra.
Como o ClubHelix acompanha uma correção depois de publicada
Vamos usar o nosso próprio processo como exemplo, porque é o que conseguimos descrever com honestidade. Ele parte de um fato: no ClubHelix, as falhas se relatam sozinhas. Uma página que trava, uma requisição que falha nos bastidores ou uma tarefa em segundo plano que cai é registrada automaticamente e agrupada em um chamado para a nossa equipe, quer alguém escreva ou não. Uma plataforma só consegue perceber que um problema voltou se já estava percebendo o problema desde o início.
Veja o que acontece depois que um desses chamados foi corrigido.
A correção é marcada como resolvida para a próxima versão
Quando a nossa equipe corrige um problema, o chamado é marcado como resolvido para a próxima versão, em vez de resolvido na hora. Parece um detalhe técnico, e resolve o problema da "correção que ainda não estava no ar" descrito acima. Até a atualização ser publicada, a versão antiga continua funcionando e continua esbarrando no erro antigo. Essas repetições são esperadas, então, enquanto a atualização está a caminho, elas não disparam alarmes falsos.
Se acontecer de novo em uma versão mais nova, o chamado se reabre sozinho
Depois que a atualização é publicada, as regras ficam mais rígidas. Se o mesmo problema aparecer em uma versão mais nova, o chamado se reabre sozinho, marcado como um problema que voltou, e a nossa equipe é avisada. Isso não depende de alguém no clube notar a falha, reconhecê-la como o problema antigo, desenterrar o e-mail original ou argumentar que não é algo novo.
Se ainda estiver acontecendo um dia depois, ele se reabre de qualquer forma
Existe uma segunda regra, porque a primeira tem uma brecha. Uma falha antiga pode continuar chegando sem nunca aparecer em uma versão mais nova. Então, se um problema marcado como corrigido ainda estiver acontecendo um dia depois de ter sido marcado, o chamado se reabre de qualquer forma, seja qual for a versão de onde a falha veio. Uma correção que não funcionou não consegue ficar escondida atrás de um chamado fechado.
A regra peca pelo excesso de cautela. Se uma atualização realmente levar mais de um dia para ser publicada, uma correção certa também pode se reabrir. Ela então volta para a lista de chamados abertos e recebe um desfecho como qualquer outro. Preferimos olhar duas vezes para uma boa correção do que deixar passar uma ruim.
Os chamados guardam um registro da decisão
Cada chamado guarda um histórico do que foi decidido sobre ele, e todo chamado aberto é tratado até chegar a um de quatro desfechos: corrigido, já corrigido, ruído ou mudança de configuração. Quando um problema volta, quem o assume pode ler o que foi decidido da última vez, em vez de começar do zero.
A configuração está nessa lista por um motivo. Alguns problemas que parecem erros que voltaram são, na verdade, um serviço do qual a plataforma depende configurado de forma errada. Mudar o código não resolve esses casos, então eles são registrados como o que são.
Um relato feito na tela de erro entra no mesmo chamado
As pessoas continuam sendo a rede de segurança. Quando uma página quebra, a tela de erro informa que o problema foi relatado à nossa equipe, mostra uma referência e oferece Tentar novamente e Conte o que aconteceu, que abre o formulário de relato de erro. Quando uma pessoa conectada envia um relato por essa tela, ele é juntado ao mesmo chamado da falha que descreve, e a pessoa recebe uma referência para citar. Assim, se alguém do seu clube relatar um problema que voltou, as palavras dessa pessoa chegam ao chamado que já guarda o histórico dele, e ninguém precisa ligar à mão um caso novo a um antigo.
O que isso não promete
Nenhum processo deixa um software livre de erros, e o nosso não é exceção. Ele não consegue impedir que um erro volte algum dia. Ele foi feito para que um problema que volta retorne sozinho à lista da nossa equipe, sem esperar que a sua diretoria perceba. Os problemas são corrigidos o mais rápido que conseguimos e acompanhados até que continuem corrigidos. Como a nossa equipe encontra e corrige problemas está na nossa página sobre correção de erros, e o restante da nossa abordagem de confiabilidade, do monitoramento à página pública de status, está na nossa página de segurança e confiança.
O que a sua diretoria deve esperar
De qualquer plataforma, uma diretoria pode razoavelmente esperar três coisas depois que uma correção é anunciada.
Uma resposta direta sobre se ela está no ar. "Corrigido, e já está no ar" e "corrigido, e vai na próxima atualização" são duas respostas aceitáveis. Elas dizem coisas diferentes sobre se vale tentar de novo hoje à noite. Se tudo o que você ouvir for "corrigido", pergunte qual das duas é.
Nenhuma penalidade por relatar duas vezes. Se um problema que disseram estar corrigido acontecer de novo, relate outra vez e diga que é uma repetição. Cite a referência da primeira vez, se tiver. Um bom fornecedor trata o "voltou" como uma informação útil, e dizer isso nunca deveria soar como uma acusação.
Não ser o alarme. A sua diretoria não deveria ser o teste de regressão do fornecedor. Uma plataforma que registra as próprias falhas deveria descobrir pelos próprios registros que algo voltou, de preferência antes de qualquer pessoa no clube. Quando o processo de um fornecedor depende de um voluntário notar um erro que voltou e reclamar pela segunda vez, o clube está fazendo controle de qualidade sem receber por isso.
Perguntas a fazer a qualquer fornecedor
Estas perguntas cabem em qualquer avaliação de software, junto com o restante do nosso guia para escolher um sistema de gestão para clubes. Nenhuma delas exige conhecimento técnico.
- "Como vocês sabem que uma correção funcionou?" Preste atenção em algo que acontece depois da publicação. "Nós testamos" é um bom começo. "Acompanhamos se a falha para de acontecer" é a resposta que você quer.
- "O que acontece se o problema voltar?" A resposta forte é que o chamado original se reabre sozinho e alguém é avisado. A resposta fraca é "avisem a gente que vamos verificar", que devolve ao clube a tarefa de perceber.
- "Quando vocês dizem que algo está corrigido, já está no ar?" Um fornecedor que separa "corrigido" de "publicado" entende por que as correções às vezes parecem não funcionar.
- "Se relatarmos um problema que voltou, ele começa do zero?" Você quer ouvir que um relato repetido é juntado ao histórico original.
- "Como vocês registram o que decidiram sobre um problema?" Seja porque foi corrigido, porque era uma configuração ou porque se concluiu que não era uma falha, alguém deve conseguir ler a decisão depois.
Faça essas perguntas durante a demonstração de cada produto e trate respostas vagas como informação. Todo fornecedor já teve uma correção que não se sustentou. O que você está avaliando é se ele descobre isso pelos próprios sistemas ou por você.
Acompanhar sem transformar isso em tarefa de um voluntário
A pior reação a um erro que voltou é uma diretoria que nomeia alguém para testar o software de novo toda semana. Isso transforma um problema do fornecedor em uma função fixa de voluntário, e é um trabalho que uma boa plataforma já deveria estar fazendo.
Um jeito mais leve funciona melhor:
- Mantenha uma linha por problema relatado, em algum lugar que a diretoria já consulta. Anote a data, uma descrição curta, a referência, se você recebeu uma, e o que disseram ("corrigido, na próxima atualização"). Se o seu clube usa tarefas da diretoria, uma única tarefa com prazo para algumas semanas depois resolve, e ninguém precisa de uma planilha separada.
- Confira na próxima ocasião natural. Se o erro estava nas inscrições, a próxima noite de inscrições é o teste. Ninguém precisa sair procurando por ele no meio-tempo.
- Se voltou, relate a partir de onde quebrou. No ClubHelix, isso significa o botão Relatar um problema ao lado de Ajuda no painel ou na página da conta, ou Conte o que aconteceu na tela de erro. O relato leva automaticamente o endereço da página e os erros recentes daquela página, então uma ou duas frases suas bastam.
- Leve a lista para a sua revisão de renovação. Um erro que voltou em um ano diz pouco. Os mesmos poucos voltando de novo e de novo, cada um descoberto por um voluntário, dizem muito sobre o processo do fornecedor.
Perguntas frequentes
Disseram que um erro foi corrigido, mas ele aconteceu de novo no mesmo dia. Fomos enganados?
Provavelmente não. Muitas vezes o motivo é o momento: a correção foi feita, mas ainda não tinha chegado à versão que você estava usando. Outro motivo comum é que a correção consertou um caminho até o problema e você usou outro. Relate de novo, diga que é uma repetição e pergunte se a correção já está no ar. No ClubHelix, uma correção é marcada como resolvida para a próxima versão, para que as repetições vindas da versão antiga, antes de a atualização chegar, sejam esperadas em vez de confundidas com uma correção que falhou.
Um erro que volta significa que o fornecedor é descuidado?
Não por si só. Regressões acontecem em todo software, inclusive em produtos bem administrados. O que diferencia os fornecedores é como eles descobrem e o que fazem em seguida. Uma plataforma que reabre os próprios chamados quando uma falha volta está acompanhando as suas correções. Uma que precisa que você redescubra e reargumente cada falha que volta está deixando esse trabalho para você.
O ClubHelix percebe um problema que voltou se ninguém relatar?
Para as falhas que a plataforma registra automaticamente, é para isso que servem as regras de reabertura. Se a mesma falha acontecer de novo em uma versão mais nova, o chamado se reabre sozinho e a nossa equipe é avisada. Se um problema marcado como corrigido ainda estiver acontecendo um dia depois, ele se reabre de qualquer forma. Os relatos das pessoas continuam importando para tudo o que a plataforma não consegue ver sozinha, e é por isso que pessoas conectadas podem relatar um erro pelo painel, pela página da conta e pela tela de erro, onde o botão diz Conte o que aconteceu.
Como saber se um problema voltou ou se alguém mudou uma configuração?
Confira quem mudou o quê antes de relatar. No ClubHelix, o registro de auditoria registra as mudanças feitas por administradores e nas configurações, então um administrador consegue ver se alguma configuração foi alterada perto do momento em que o problema reapareceu. Se nada mudou do seu lado, relate como uma repetição.
Devemos continuar testando um erro corrigido para garantir que ele continue corrigido?
Não. Confira na próxima vez que você usaria naturalmente aquela parte do software e, fora isso, deixe quieto. Acompanhar uma correção ao longo do tempo é trabalho do fornecedor, e em uma plataforma que registra as próprias falhas, a maior parte desse acompanhamento acontece sem que ninguém no clube faça nada.
Onde podemos ver como o ClubHelix cuida da confiabilidade?
A página de segurança e confiança explica como as falhas são percebidas, relatadas e corrigidas, e tem um link para a página de status do serviço ao vivo. Se você quer uma plataforma que acompanha as próprias correções para que a sua diretoria não precise fazer isso, pode configurar o seu clube no ClubHelix quando quiser.
