Análise de Causa Raiz

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

Publicidade

8 comentários sobre “Análise de Causa Raiz

  1. 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

    Responder
    • 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!

  2. 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

    Responder
  3. 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!

    Responder
  4. Pingback: Os números de 2010 « QualidadeBR

  5. Seria interessante se pudesse ser incluído nesse post ou apresentado em outros post os principais autores acadêmicos sobre análise de causa raiz. Estou realizando um pesquisa nesse tema, se você tiver alguma informação ajudaria bastante!

    Obrigada!

    Responder
  6. Pingback: Lista com todas as Práticas Ágeis | André Faria Gomes

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s