BT

Falhou, e agora? Aprendizado em face dos erros

por Vikas Hazrati , traduzido por Fernando Ultremare em 02 Jul 2011 |

Erros geralmente resultam em frustração, desentendimentos e caça às bruxas. E são desperdiçados quando não aprendemos com eles. Como as equipe ágeis transformam os erros em algo proveitoso?

James Shore, no lugar de se exaltar com a equipe, recomenda:

Em vez de culpar as pessoas, coloco a culpa no processo. O que na forma de trabalhar permitiu que o erro ocorresse? Como mudar a forma de trabalho de modo a tornar mais difícil que algo saia errado? Isso é a análise da causa-raiz.

Segundo Shore, uma das maneiras mais eficazes de realizar a análise da causa-raiz, em caso de erro técnico, é o método dos cinco porquês, que tem suas origens no estilo "enxuto" (lean) de manufatura. De acordo com esse método, a causa-raiz é encontrada através da identificação de um sintoma, seguido da repetição de "por quê?" cinco vezes. Geralmente, observa-se que a solução torna-se evidente após as cinco etapas.

Outra técnica usada por algumas equipes ágeis é o diagrama de “espinha de peixe”, que permite visualizar em alto nível os contornos do problema. Outra técnica relacionada, sugerida por Joel Spolsky, é o método "Corrija Duas Vezes", em que se deve encontrar uma solução rápida para corrigir o problema, permitindo com isso que a equipe continue avançando, e só mais tarde realizar uma correção mais elaborada, para impedir que o erro ocorra novamente.

Qual seria então a melhor maneira de se conduzir uma análise da causa-raiz?

Jim Bird sugere fazer o seguinte:

  • Envolver as pessoas certas e criar um ambiente propício para resolver o problema sem realizar uma busca por culpados
  • Não parar até que os verdadeiros problemas e soluções sejam identificados
  • Não ficar satisfeito com uma única causa. As situações, na sua grande, maioria são mais complexas que isso
  • Apenas erro humano não é uma boa causa

De maneira similar, Gojko Adzic cita Douglas Squirrel ao sugerir que, depois de reunir todas as partes afetadas, deve haver uma pesquisa para identificar os problemas. Uma vez que os problemas são identificados, deve-se seguir a técnica dos cinco porquês até que seja gerado algum desconforto. Se não houver um verdadeiro incômodo, o processo ainda precisa ser melhorado. Uma vez que os problemas sejam identificados, é muito importante que as ações definidas sejam proporcionais ao problema.

Não exagere "treinando novamente a sua equipe de desenvolvimento por causa de cinco minutos de inatividade do sistema", diz Squirrel, "defina tarefas que sejam proporcionais à dimensão do problema". "O objetivo não é resolver problemas, mas sim progredir". Em vez de buscar soluções extremamente elaboradas, ele sugere agir rapidamente. Soluções que demoram muito tempo tendem nunca a ser concluídas; dessa forma, a sugestão de Squirrel refere-se àquilo que pode ser feito em uma semana ou até mesmo em uma hora, para somente construir uma solução definitiva da próxima vez em que acontecer o problema.

Voltando a Jim Bird, ele sugere que o verdadeiro trabalho começa quando a análise de causa-raiz é finalizada. É comum acontecer de os desenvolvedores voltarem ao "modo de entrega" e se esquecerem das falhas. No entanto, as tarefas decididas ao fazer a análise de causa-raiz precisam ser gerenciadas ativamente e monitoradas através do backlog. Além disso, é necessário o coletar métricas e conscientizar os desenvolvedores da maneira correta de se trabalhar.

Será preciso utilizar métricas e informações sobre custos de modo a orientar o comportamento adequado, para impulsionar a mudança e decidir quanto e com que frequência pressionar. Você está fazendo muitas mudanças com muita frequência, deixando as coisas soltas? Ou mudar é muito caro e você está exagerando?

As falhas, portanto, são melhor utilizadas como bases para o aprendizado. O mais importante é identificar a causa-raiz dessas falhas e acompanhar as tarefas, de maneira proporcional ao problema, até a sua eliminação.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Aprendizado e Desenvolvimento Evolutivo by Fabio Santos

É claro que é importante entender o por que erramos, e isto gera aprendizado. O mais importante para mim, no entanto, é criarmos um ambiente onde seja aceitável errar e onde tenhamos flexibilidade para corrigirmos os erros cometidos. Existem, no entanto, entraves para esta flexibilidade. Por exemplo, a flexibilidade que temos com nossos erros perante nossos colegas de trabalho será sempre maior do que a que teremos com nossos gestores, que será sempre maior que a que teremos com os nossos clientes.

Por exemplo, no projeto em que estou trabalhando atualmente, temos bastante flexibilidade na equipe para admitir os erros, mas pouca flexibilidade para corrigí-los. Isso ocorre basicamente por que grande parte das decisões de correção passam pelo gestor responsável e todas as nossas atividades são diretamente reportadas e negociadas com o nosso cliente. Esta estrutura faz com que a correção de pequenos desvios no caminho tenha que ser negociada em múltiplas camadas, aumentando a burocracia e diminuindo a agilidade da evolução do nosso modelo.

É claro que, para o cliente, o importante são as funcionalidades aplicadas ao seu negócio, resolvendo o seu dia-a-dia. Mas para o bem estar da equipe também são necessários ajustes no caminho que garantam a satisfação e orgulho do trabalho desenvolvido, garantindo maior comprometimento e responsabilidade.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

1 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT