WTF-Brasil

Publicado em March 18, 2008 – 2:03 am | por GraveHeart |

Semanas atrás, meu superior me ligou, perguntando se eu estava sabendo de um problema que estava rolando no sistema, com relação a títulos enviados para o banco. Respondi que não, e imediatamente fui ‘escalado’ para resolver um problema que já durava há mais de dois meses: alguns títulos não eram reconhecidos pelo banco. E eu tinha que descobrir a causa do problema em menos de um dia, pois alguns desses títulos já estavam para vencer.

Explicando: nosso sistema (assim como qualquer outro, imagino), logo após emitir nota fiscal dos produtos vendidos, também permite a emissão de boletos para que o cliente efetue o pagamento. Esses boletos possuem uma identificação, e para facilitar todo o processo de pagamento e reconhecimento pelo banco, o mesmo exige que seja enviado diariamente um arquivo com informações dos boletos (ou títulos, como preferir), utilizando um software próprio (cada banco usa um sistema diferente). Esse arquivo é gerado pelo sistema, contendo todas as informações referentes aos boletos emitidos. Mas, de uma hora pra outra, alguns títulos enviados acabavam sendo rejeitados pelo banco, o que trazia uma série de problemas, até mesmo na hora de identificar se o cliente realmente havia pago o boleto.

E o problema se alastrava há dois meses. E eu tinha um dia pra descascar esse abacaxi.

Normalmente, é aqui que os funcionários de TI ficam loucos e começam a correr atrás de soluções bizarras ou explicações malucas para tentar explicar o bug. Mas, acostumado a sofrer com problemas malucos e prazos apertados, me acostumei a utilizar um sistema conhecido como análise da causa raiz, muito utilizado em empresas que possuam certificação ISO. Com a análise da causa raiz, o que é necessário é entender o erro, listar algumas possíveis causas para o mesmo, e testar essas causas, até que uma se mostre a ‘verdadeira’.

No caso, após conversar com os usuários que estavam tratando do problema (e em nenhum momento tiveram a idéia de usar um pouco de raciocínio ou ao menos vieram falar comigo, vejam bem), pude perceber que tudo o que tinha de concreto era uma série de emails enviados tanto para o suporte do sistema quanto para o banco, a maioria com ameaças, e retornos dos mesmos, a maioria com comentários como “está tudo OK aqui, favor verificar com o sistema / banco, o problema é lá“. Ou seja, nada de muito útil. Era hora de tentar entender o problema. Com isso, cheguei às conclusões:

• Apenas alguns títulos davam problema, não todos;
• Os títulos rejeitados eram sempre dos mesmos clientes;
• O mesmo cliente não tinha títulos aceitos e outros rejeitados;
• Não havia qualquer relação entre os clientes, ou seja, detalhes que pudessem fazer pensar que o problema estava no tipo de cadastro deles;
• Tentar re-enviar o arquivo não resolvia; (usuário pensa que se não deu certo na primeira, tenta de novo, e assim vai, até funcionar);

Com isso, já dava para entender alguma coisa, e formular que a causa raiz poderia estar em três pontos:

• No momento da geração do título, alguma informação para esses clientes estava sendo gerada de forma errada ou incompleta (falha no sistema);
• No momento do recebimento do arquivo, o mesmo não estava reconhecendo alguma informação, e dando o título como rejeitado (falha no banco);
• Usuário errou em algum ponto (falha ao nascer);
• Algum outro problema, ainda desconhecido;

Com minha experiência, havia uma certeza de que o problema estava na 3ª alternativa, mas por obrigações contratuais eu era obrigado a provar minha teoria. Perguntei à responsável pelo Financeiro se havia como saber através do contato no banco qual havia sido o motivo da rejeição (percebam que, em dois meses, ninguém havia pensado nisso). Enquanto a mesma procurava obter essa informação, parti para outra linha de frente: investigar algum problema visível no arquivo enviado para o banco. O arquivo na verdade era até bem simples: um arquivo de texto puro, várias linhas, cada linha correspondia a um título, e as informações tinha ‘colunas’ certas para estarem dispostas. Mais ou menos assim:

nomedocliente CNPJInscriçãoEstadual Valoretc.

Claro, era bem mais complicado do que isso, e em uma primeira olhada, o arquivo não trazia nenhum erro visível. Como eu não tinha uma tabela mostrando o que cada ‘coluna’ do arquivo significava, era difícil chegar à alguma conclusão. Mas eu já sabia que, se fosse algo na geração do arquivo, seria alguma informação de cadastro. Nesse meio tempo, a resposta do banco chegou: todos os títulos rejeitados traziam o mesmo erro: ‘CEP incorreto”. E a responsável pelo Faturamento (que deixei sem qualquer atividade nesse período, ela seria mais útil assim) começou a armar a maior confusão, dizendo que havia revisado todos os cadastros, que ela nunca iria deixar um cadastro com o endereço incorreto, e etc. Mas era o que o banco havia informado, valia uma investigação. Nesse momento, nenhuma das possíveis causas apontadas era a ‘preferida’, mas já sabíamos que:

• O banco, por alguma razão, rejeitava alguns títulos de clientes específicos, alegando que o CEP estava incorreto

E qual a melhor forma de descobrir se isso era causado pelo sistema? Comparando um título que havia sido enviado corretamente, com outro que tivesse sido rejeitado. Abrindo o cadastro de um cliente que estava OK, copiei o CEP, fiz uma busca no arquivo de texto, e encontrei em qual coluna estava a informação. Procurando na linha referente ao título rejeitado, tinhamos ‘00000000′. Zero.

Nova explosão da responsável pelo Faturamento. Frases como “Eu não estou louca! Eu não estou louca! Esse sistema está trazendo informação errada! O cadastro está correto!” preenchiam a minha sala. E, realmente, o cadastro do cliente estava correto. O cadastro principal dele.

Explico novamente: é muito comum existirem clientes cuja empresa reside em um endereço, mas a entrega do produto ou dos títulos a pagar é em um ou mais endereços diferentes. E o nosso sistema trata isso possibilitando a criação de endereços alternativos, tanto de Entrega quanto de Cobrança. Caso alguma dessas informações esteja cadastrada, o sistema pergunta qual o endereço de entrega, ou qual o endereço para o qual deve ser feita a cobrança. E essas informações aparecem na Nota Fiscal E no Boleto gerado. Agora, advinhem QUAL desses endereços estava SEM o CEP……

Exato. Por algum motivo, a responsável pelo faturamento havia pensado que, se já havia sido cadastrado todas as informações de um endereço, todos os outros endereços poderiam ser cadastrados com o mínimo de detalhes, já que tudo seria ‘puxado’ do endereço principal (mesmo que o endereço fosse diferente).

Estava resolvido, em menos de três horas (sendo que dessas, uma hora foi o tempo que o banco levou para responder sobre o erro nos títulos), chegamos à verdadeira causa raiz:

• O usuário não havia cadastrado o CEP no endereço de cobrança, fazendo com que o título fosse gerado sem essa informação, causando assim, erro no banco.

E, lembrando, isso já vinha ocorrendo há dois meses….

(esse post faz parte da “blogagem inédita“)

Technorati Tags sistema, software, Suporte, usuário, Usuários