Problemas sempre acontecem, e na área de TI eles são constantes. Desde falhas de segurança no sistema até falhas na comunicação interna.
E muitas vezes, passamos dias, meses e até anos só “apagando incêndios”, ou seja, só amenizando os efeitos dos problemas existentes. E neste momento, se a causa raiz dos nossos problemas fosse uma pessoa, ela estaria dando boas gargalhadas.
Mas não há nenhuma graça nessa história. A tarefa de “apagar incêndios” não pode entrar na nossa rotina. E para mudar essa história, precisamos descobrir a causa raiz dos nossos problemas.
Uma das técnicas mais básicas e importantes, em qualquer programa de melhoria da qualidade, pode nos auxiliar na busca da causa raiz: a Análise de Causa Raiz.
Introdução
A Análise de Causa Raiz, também conhecida como RCA (Root Cause Analysis) é uma maneira de identificar as causas de um problema, afinal os problemas são melhores resolvidos ao tentar corrigir ou eliminar as suas causas.
Ela é uma técnica usada nas mais variadas áreas, aliás, você já deve ter visto uma das formas de implementar ela: o famoso diagrama de Ishikawa, conhecido também como “Diagrama de Causa e Efeito” ou “Espinha-de-peixe” (fishbone), nas aulas de Administração na faculdade.
Como podemos implementar a Análise de Causa Raiz?
Há muitas técnicas, com as quais podemos implementar a Análise de Causa Raiz, entre as principais se encontram:
- Diagrama de Causa e Efeito: permite identificar, explorar e apresentar graficamente todas as possíveis causas, relacionadas a um único problema. Utilizando em equipe, criamos uma “foto” do conhecimento e consenso de todos os envolvidos, a respeito do problema.
- Cinco Porquês: desenvolvida por Sakichi Toyoda (fundador da Toyota), é baseada na realização de 5 iterações perguntando o porquê daquele problema, sempre questionando a causa anterior. E na prática não é necessário fazer 5 perguntas, pode ser mais ou menos, o importante é chegar à causa do problema.
- Reunião de Análise Causal: as causas do problema são levantadas em reuniões do tipo “Brainstorming”. As causas mais prováveis podem ser discutidas entre a equipe, e após descobrir as causas dos problemas, os participantes podem propor ações que ajudem na prevenção desses problemas no futuro.
É possível e até recomendado que se use mais de uma técnica ao mesmo tempo, por exemplo: na reunião de Análise Causal utilizar o Diagrama de Causa e Efeito.
Conclusão
A Análise de Causa Raiz é um importante elemento em qualquer área de TI, e pode ser usado em qualquer fase do projeto.
Um momento bom para ela ser usada, é durante a reunião de lições aprendidas. Pois nada melhor do que descobrimos a causa real dos problemas que enfrentamos no projeto, com todos envolvidos participando e opinando.
Ela também poder ser usada pelos desenvolvedores para encontrar a causa para o defeito, e desta maneira, além de poder corrigir tal defeito eles ainda poderão prevenir a sua ocorrência no futuro.
E para finalizar, acredito que é clara a necessidade de encontrar a causa raiz dos problemas que vivenciamos no dia-a-dia, e que essa é uma tarefa que deve ser feita em equipe, sempre que possível. Afinal, nem sempre a causa de um problema é tão visível ou fácil de ser encontrada, como por exemplo: problemas de performance, às vezes passamos até meses para descobrir, onde estava o gargalo da aplicação. Mas com certeza, é muito melhor gastar massa cefálica do que desperdiçar dinheiro comprando novos servidores, além é claro, da satisfação e benefícios de ter encontrado o real motivo do problema.
Fique por dentro das novidades, assine o feed do QualidadeBR.
Fonte:
Software Quality, Module 10: Effective Practices for Quality Analysis – Lesson 3: Root-Cause Analysis (AzIT)
5 Porquês – Luiz de Paiva



Opa Fabrício, tudo beleza?
Só para acrescentar…
Vale lembrar que tanto o time de teste quanto o time de desenvolvimento devem contribuir na momento da Análise de Causa Raiz. Desta forma, a causa raiz do problema será identificada muito mais rápida e com certeza os dois times irão ganhar com o conhecimento adquirido
!
Eu aconselho fazer a Análise de Causa Raiz antes da reunião de lições aprendidas (Lessons Learned), assim, é possível que outros problemas que poderiam ocorrer por causa da mesma causa raiz seja prevenido.
Muito bom o post!!!
Até+,
Quezada
Grande Gustavo!
Também acredito que o time de teste e de desenvolvimento devem discutir juntos, pois é uma excelente oportunidade de adquirir conhecimento (mesmo que a discussão acabe sendo técnica demais). Embora isso dependa muito do ambiente da empresa. Mas com certeza é uma boa prática!
Quanto ao momento de realizar a Análise de Causa Raiz, concordo contigo, principalmente se há apenas uma reunião de lições aprendidas e ela ocorra só no término do projeto (talvez possa ser muito tarde para discutir). É bom realizar a Análise de Causa Raiz assim que o problema ocorre, se ele for muito grave, ou de acordo com a necessidade e cronograma da equipe.
Obrigado pelo comentário!
Abraços!
Bom post.
Como muita gente não tem método para analisar problemas, acaba-se tomando o efeito pela causa e investindo tempo e dinheiro no lugar errado.
Vale acrescentar que, para nossa área, ela é aplicável tanto em bugs descobertos quanto para o próprio processo, seja ela desenvolvimento e testes.
Também vale salientar que na construção do diagrama uma causa pode ter várias subcausas, que pode ter um subcausa… e assim vai!!!
Sugestão: era legar ter um exemplinho junto! Quem sabe vira um prósimo post?
Abraços e Parabens!
Elias Nogueira
Primeiramente, obrigado pelos comentários Rodrigo e Elias!
Então Elias, fiz uma explicação básica de cada uma das principais técnicas para implementar a Análise de Causa Raiz. Mais para dá um norte para quem achou interessante é que saber como começar a utilizar a Análise de Causa Raiz.
Quanto a sua sugestão, é uma boa sim! Aliás, vou tentar fazer um post sobre cada das técnicas, num futuro próximo. Afinal, com exemplos fica muito mais fácil de entender.
Abraços!