.
Este artigo irá explicar uma abordagem científica para a resolução de problemas. Embora seja escrito para resolver problemas relacionados à Tecnologia da Informação, os conceitos também podem ser aplicáveis em outras disciplinas. Os métodos, conceitos e técnicas descritos aqui não são novidade, mas é chocante quantos “solucionadores de problemas” não conseguem usá-los. No meio vou incluir alguns exemplos da vida real.
Por que os solucionadores de problemas adivinham em vez de seguir uma abordagem científica para a solução de problemas? Talvez porque pareça mais rápido? Talvez a falta de experiência na solução eficiente de problemas? Ou talvez porque pareça um trabalho árduo fazê-lo cientificamente? Talvez enquanto você continua adivinhando e não realmente resolvendo, você gera mais renda e adiciona alguma segurança no emprego? Ou talvez porque você violou o primeiro princípio da resolução de problemas: entenda o problema.
Princípio #1. Entenda o problema *real*.
Não é óbvio que antes de resolver, você precisa entender o problema? Pode ser. Mas, na maioria das vezes, o solucionador começará a resolver sem conhecer o problema real. O que o cliente ou usuário descreve como “O Problema” normalmente é apenas o sintoma! “Meu computador não quer ligar” é o sintoma. O verdadeiro problema pode ser que todo o edifício está sem energia. “Toda vez que tento adicionar um novo produto, recebo uma mensagem de erro” é o sintoma. Aqui o problema real pode ser “Apenas os últimos 2 produtos que tentei adicionar deram um erro ‘Produto já existe’”. Outro exemplo clássico: “Nada está funcionando”…
Você começa sua investigação definindo o “problema real”. Isso implica fazer perguntas (e às vezes verificá-las) e fazer alguns testes básicos. Faça perguntas ao usuário como “quando foi a última vez que funcionou com sucesso?”, “Há quanto tempo você usa o sistema?”, “Funciona em outro PC ou outro usuário?”, “Qual é a mensagem de erro exata? ” etc. Peça uma impressão de tela do erro, se possível. Seu teste básico será para garantir que o equipamento de ponta a ponta esteja funcionando. Verifique o PC do usuário, a rede, o servidor Web, firewalls, o servidor de arquivos, o back-end do banco de dados, etc. Na melhor das hipóteses, você já identificará o problema. Na pior das hipóteses, você pode eliminar muitas áreas para a causa do problema.
Um exemplo da vida real. O sintoma de acordo com o usuário: “O sistema desliga em momentos aleatórios quando faço pedidos”. O ambiente: O usuário insere os detalhes do pedido em um formulário em um aplicativo de mainframe. Quando todos os detalhes forem preenchidos, o usuário irá sair do formulário. O mainframe então envia esses detalhes via software de comunicação para um sistema Oracle Client/Server na planta. O sistema Oracle fará o planejamento de capacidade e retornará um erro ou uma data de pedido esperada de volta ao sistema de mainframe. Este problema é bastante grave, pois você pode perder clientes se eles tentarem fazer pedidos e o sistema não os aceitar! Para tentar resolver esse problema, as pessoas começaram investigando: 1) A carga e a capacidade do hardware do mainframe 2) Monitorando a carga da rede entre o mainframe e o sistema Oracle 3) Contratando consultores para depurar o software de comunicação 4) Depurando a capacidade do Oracle sistema de planejamento Depois de passar alguns meses, eles não conseguiram resolver o problema.
O “Scientific Problem Solver” foi chamado. Demorou menos de um dia e o problema foi resolvido! Como? O solucionador passa o dia no usuário para ver qual era o “problema real”. Verificou-se que o problema ocorre apenas com pedidos de exportação. Ao investigar a tela de captura e as ações do usuário, verificou-se que com os pedidos de exportação o último campo do formulário sempre fica em branco e o usuário não desligou este campo. O sistema não estava travando, ele esperava que o usuário pressionasse “tab” outra vez. Problema resolvido. Pode-se notar que o “Scientific Problem Solver” tinha um conhecimento muito limitado do mainframe, do sistema de captura de pedidos, do software de comunicação e do sistema de planejamento de capacidade Oracle. E isso nos leva ao Princípio nº 2.
Princípio #2. Não tenha medo de iniciar o processo de resolução, mesmo que você não entenda o sistema.
Quantas vezes você já ouviu “não posso mexer nesse código, porque foi desenvolvido por outra pessoa!”, ou “não posso ajudar porque sou consultor de RH e isso é um problema financeiro”? Se sua máquina de lavar não quiser ligar, você não precisa ser um engenheiro eletricista, especialista em reparo de máquina de lavar, técnico ou qualquer outro especialista para fazer uma detecção básica de falhas. Verifique se o plugue está funcionando. Verifique o interruptor de disparo, etc. “Nunca vi este erro antes” não deve impedi-lo de tentar resolver. Com a mensagem de erro e um mecanismo de pesquisa na Internet, você pode obter muitos pontos de partida.
Em todo sistema complexo há alguns princípios básicos de funcionamento. O Sistema A que lê dados do Sistema B pode ser terrivelmente complexo (talvez um espectrômetro de laboratório que leia dados de um computador lógico programável por meio de uma porta RS-232). Mas, alguns princípios básicos para testar: Ambos os sistemas têm energia? Existe uma mensagem de erro no log de eventos em um desses sistemas? Você pode “pingar” ou rastrear um pacote de rede de um sistema para o outro? Experimente um cabo de comunicação diferente. Pesquise na internet pela mensagem de erro.
Depois de estabelecer qual é o problema, você precisa começar a resolvê-lo. Às vezes, a investigação inicial apontará diretamente para a solução (ligue a energia; substitua o cabo defeituoso, etc). Mas, às vezes, o problema real é complexo em si mesmo, então o próximo princípio é resolvê-lo de forma simples.
Princípio #3. Conquiste-o simples.
Vamos começar esta seção com um exemplo da vida real. Sob certas condições, um procedimento armazenado irá travar. O procedimento armazenado normalmente leva cerca de uma hora para ser executado (quando não está travando). Então, o desenvolvedor tentou depurar. Faça algumas alterações e aguarde mais uma hora para ver se o problema foi resolvido. Depois de alguns dias, o desenvolvedor desistiu e o “Problem Solver” assumiu. O “Problem Solver” tinha à sua disposição o conhecimento em que condições o procedimento armazenado iria travar. Portanto, foi um exercício simples fazer uma cópia do procedimento e, com essa cópia, retirar todo o código desnecessário. Todos os parâmetros foram alterados com valores codificados. Bits de código foram executados de cada vez e os conjuntos de resultados foram novamente codificados na cópia do procedimento. Em 3 horas o problema foi resolvido. Um loop infinito foi descoberto.
O que o “Problem Solver” fez foi replicar o problema e ao mesmo tempo tentar isolar o código que causou o problema. Ao fazer isso, o procedimento armazenado complexo (e demorado) tornou-se algo rápido e simples.
Se o problema estiver dentro de um aplicativo, crie um novo aplicativo e tente simular o problema dentro do novo aplicativo da forma mais simples possível. Se o problema ocorrer quando um determinado método para um determinado controle for chamado, tente incluir apenas esse controle no aplicativo vazio e chame esse método com valores codificados. Se o problema for com SQL embutido dentro de um aplicativo C#, tente simular o SQL dentro de uma ferramenta de consulta de banco de dados (como SQL*Plus para Oracle, Query Analyzer para SQL Server ou use o código no MS Excel via ODBC para o banco de dados ).
No momento em que você consegue replicar o problema de forma simples, você está mais de 80% no caminho para resolvê-lo.
Se você não souber onde está o problema no programa, use o DEBUG.
Princípio #4. Depurar.
A maioria das ferramentas de desenvolvimento de aplicativos vem com um depurador padrão. Se for Macromedia Flash, Microsoft Dot Net, Delphi, ou qualquer ambiente de desenvolvimento, haverá algum tipo de depurador. Se a ferramenta não vier padrão com um depurador, você poderá simular um.
A primeira coisa que você quer fazer com o depurador é determinar onde está o problema. Você faz isso adicionando pontos de interrupção em áreas-chave. Em seguida, você executa o programa em modo de depuração e saberá entre quais pontos de interrupção ocorreu o problema. Desça e você encontrará o local. Agora que você sabe onde está o problema, você pode “conquistá-lo de forma simples”
Outro bom recurso da maioria dos depuradores inclui a facilidade de observar variáveis, valores, parâmetros, etc. conforme você percorre o programa. Com esses valores conhecidos em determinadas etapas, você pode codificá-los em sua “versão simplificada” do programa
Se uma ferramenta de desenvolvimento não suportar depuração, você poderá simulá-la. Coloque as etapas no programa que gera valores de variáveis e mensagens “olá, estou aqui” na tela, em um arquivo de log ou em uma tabela de banco de dados. Lembre-se de retirá-los quando o problema for resolvido… você não quer que seu sistema de arquivos fique confuso ou cheio de arquivos de log!
Princípio #5. Há uma riqueza de informações no back-end do banco de dados que ajudará a resolver um problema.
O “Problem Solver” foi chamado para ajudar a resolver um problema muito complicado. Um projeto estava migrando o sistema de um mainframe para a tecnologia cliente-servidor. Tudo correu bem durante os testes, mas quando os sistemas entraram em operação, de repente havia algumas “Falhas de Proteção Geral” bastante aleatórias. (O erro GPF foi a armadilha de erro geral no Windows 95 e 98). Tentou-se simplificar o código, tentou-se depurar, mas foi impossível replicar. No ambiente LAB, o problema não ocorreria! A depuração de mensagens de rastreamento para arquivos de log indicou que o problema ocorreu de forma muito aleatória. Alguns usuários experimentaram mais do que outros, mas eventualmente todos os usuários os receberão! Problema interessante.
O “Problem Solver” resolveu isso depois que ele começou a analisar o back-end do banco de dados. Não tenho certeza se foi por acaso ou porque ele se moveu sistematicamente na direção certa por causa de uma abordagem científica. Ao rastrear o que está acontecendo no nível de back-end, descobriu-se que todos esses aplicativos estavam criando cada vez mais conexões com o banco de dados. Cada vez que um usuário inicia uma nova transação, outra conexão é estabelecida com o banco de dados. A soma total das conexões só foi liberada quando o aplicativo foi fechado. À medida que o usuário navega para novas janelas dentro do mesmo aplicativo, mais e mais conexões são abertas e, após um número específico de conexões, o aplicativo terá o suficiente e depois travará. Esta foi uma falha de programação em um modelo que foi usado por todos os desenvolvedores. A solução foi primeiro testar se um cursor para o banco de dados já está aberto, antes de abri-lo novamente.
Como você rastreia no banco de dados back-end o que está acontecendo? Os principais provedores de banco de dados têm ferramentas GUI que ajudam a rastrear ou analisar quais consultas são disparadas no banco de dados. Ele também mostrará quando as pessoas se conectarem, se desconectarem ou não puderem se conectar devido a violações de segurança. A maioria dos bancos de dados também inclui algumas tabelas de dicionário do sistema que podem ser consultadas para obter essas informações. Esses traços às vezes podem contar toda a história de por que algo está falhando. O código de consulta que você recupera do rastreamento pode ajudar a “simplificar a pesquisa”. Você pode ver no rastreamento se o programa faz contato bem-sucedido com o banco de dados. Você pode ver quanto tempo leva para uma consulta ser executada.
Para adicionar ao Princípio #2 (não tenha medo de começar…); você pode analisar essas informações de rastreamento, mesmo que não saiba nada sobre os detalhes do aplicativo.
Lembre-se, porém, de que esses rastreamentos de back-end podem sobrecarregar os recursos de back-end. Não os deixe funcionando por muito tempo desnecessário.
Princípio #6. Use olhos frescos.
Este é o último princípio. Não gaste muito tempo com o problema antes de pedir ajuda. A assistência não precisa ser de alguém mais sênior que você. O princípio é que você precisa de um par de olhos novos para uma nova perspectiva e, às vezes, um pouco de ar fresco fazendo uma pausa. A outra pessoa vai olhar e então fazer uma ou duas perguntas. Às vezes é algo muito óbvio que foi esquecido. Às vezes, apenas respondendo à pergunta, você pensa em novas direções. Além disso, se você passar horas olhando para o mesmo código, é muito fácil começar a analisar um erro bobo. Muitos problemas de equilíbrio financeiro são resolvidos com uma cerveja. Pode ser uma mudança de cenário e/ou a atmosfera descontraída que resultará na solução. Talvez seja o oxigênio fresco que foi para o cérebro enquanto caminhava para o pub. Talvez seja porque o problema foi discutido com outra pessoa.
Conclusão
Depois de ler este artigo, o autor espera que você tente isso na próxima vez que encontrar um problema para resolver. Espero que, ao aplicar esses seis princípios, você perceba as vantagens que eles trazem, em vez de “adivinhar” o caminho para uma solução.
.
