Por que questionar a técnica dos 5 porquês?

Eu acredito que você já tenha ouvido falar algumas vezes da técnica dos 3 porquês, ou 5 porquês. Trata-se de uma técnica para descoberta de causa-raiz dos problemas.

A técnica consiste de questionarmos “por que” algumas vezes (alguns dizem 3, como Ricardo Semler, já a Toyota fala de 5), a alguma questão: um problema, o modo de fazer alguma coisa, enfim; até chegar a uma última resposta que supostamente seria a causa-raiz da questão e todos seus problemas decorrentes.

A ideia é excelente porque é sistêmica! Normalmente ficamos refletindo ou resolvendo problemas no nível de “sintomas”, ao invés de realmente refletirmos sobre o que os geram na raiz (desculpem a repetição), para definitivamente resolver o problema e ele não mais se repetir.

O primeiro exemplo bobo:

1 – Por que estou espirrando? (sintoma)

“Porque estou gripado.”

  • Normalmente é aqui que costumamos tomar alguma ação: no caso, tomamos algum remédio pra gripe.

2 – Por que estou gripado?

“Porque dormi no frio.”

3 – Por que dormi no frio?

“Porque o vidro da janela estava quebrado e deixou o vento frio entrar no quarto.”

Assim, pra eu nunca mais voltar a ficar gripado por essa razão, além de tomar o remédio, tenho que reparar o vidro da janela.

O segundo exemplo mais dentro da realidade (mas fugindo do clássico exemplo em que partimos de “Por que temos tantos bugs?” e chegamos a realização de testes automatizados):

1 – Por que a performance do sistema está ruim?

“Porque não havia especificação pra tempo de resposta.”

2 – Por que não havia especificação de tempo de resposta?

“Porque o cliente não tinha parâmetros pra definir isso.”

3 – Por que?

“Porque não havia um sistema similar antes para servir de base comparativa ou parâmetro justificável.”

 Qual seria sua sugestão de ação nesse ponto?

Que tal ir adiante com mais 2 porquês?

4 – Por que?

“Porque a organização nunca teve verba pra investir numa solução desse porte antes.”

5 – Por que?

“Porque não tinha resultados suficientes nas suas operações que permitissem tal investimento.” 

E agora? Ficou mais complicado, não? Será que ações visando aumento de resultados nas operações resolveriam o problema original de performance?

Você não ficou com vontade de perguntar outra coisa no meio do raciocínio, como por exemplo “Por que alguém do próprio time não teve o bom senso de definir um tempo de resposta razoável pra todo sistema e conseguir aprovação do cliente?”

E mais: será que se essas perguntas fossem feitas a outras pessoas ou grupos, as respostas (e consequentes linhas de raciocínio e de ação), seriam as mesmas?

E se a pessoa ou grupo respondente não tivesse conhecimento suficiente pra responder às perguntas?

E se uma resposta no meio do caminho não fosse tão acertada? E se houvesse mais de uma resposta possível? E se houvesse mais de uma causa-raiz?

Trabalhando num projeto para a aeronáutica, aprendi que os acidentes aéreos nunca acontecem por uma só razão. É sempre por um conjunto de fatores alinhados numa combinação particular num determinado momento que causam um acidente.

Os militares trabalham justamente para identificá-los e tomar alguma atitude para que os fatores nunca mais se repitam naquela combinação, por exemplo: acrescentar uma checagem em algum procedimento de vôo, como você já deve ter visto alguma vez (“Flap direito”, “check!”, “flap esquerdo”, “check!”…), ou algum mecanismo automático que evite que aquele alinhamento de fatores se repita.

Pois é, quando começamos usar essa técnica para questões mais complexas, encaramos esses tipos de efeitos.

Não que a técnica seja falha, ela é excelente e já chegou a resultados excepcionais! Mas acredito que tenhamos que acrescentar fatores de complexidade a ela. Trago aqui algumas ideias para você avaliar seu processo de análise de causas-raiz então, a partir da mesma técnica:

 1 – A primeira mudança é tentar encontrar mais de uma resposta para cada porquê.

Você pode levantar diversas respostas, mas será muito difícil trabalhar com todas, então sugiro priorizar de alguma forma (votação?) até o máximo de 3.

Este número tem uma razão: esses fatores se multiplicarão com o processo. Respostas de menos podem não explorar suficientemente a questão. Respostas demais serão inviáveis de se trabalhar. E pelo princípio de Paretto, você deve priorizar as respostas (e ações) que farão a maior parte da diferença.

2 – Encare cada resposta como uma hipótese, não como uma resposta definitiva, e tente validar cada hipótese até conseguir uma confirmação.

3 – A partir das confirmações das hipóteses, aí sim continue o processo de perguntar porquês.

Você não vai conseguir ir muito longe nesse processo, pois como disse anteriormente, cada linha de raciocínio vai se multiplicar em várias respostas, e consequentemente várias ações.

Se você partir de 1 questão com 3 respostas validadas, e cada uma delas tiver mais 2 respostas validadas, já seriam 6 respostas. Se cada uma tiver mais 2 respostas validadas, passamos para 12 ações a serem tomadas para resolverem a causa-raiz.

Você consegue tempo e dinheiro para as 12 ações? Você conseguiria recursos pra validar todas as hipóteses?

Normalmente não. Então, priorize! Combine!

Tente pensar em ações ou soluções que enderecem várias das questões de uma só vez. Isso será possível.

Não se preocupe com o que ficar de fora, pois provavelmente será impactado pelas outras ações. Tudo curiosamente estará relacionado e obedecerá à regra 80/20.

O mais importante é você agir.
O próprio modelo dos 5 porquês já propunha uma maneira de você visualizar e gerir suas respostas, com o diagrama de Ishikawa.

 

Você pode usar a mesma ideia ou qualquer ferramenta de mapas mentais para não perder as contas de suas perguntas, hipóteses e respostas.

 

Infelizmente essas ideias trazem um pouco mais de complexidade e trabalho à brilhante e simples ideia original da técnica.

Mas o pior ainda está por vir!

Sim… Estamos falando de sistemas complexos adaptáveis (CAS) – lembra do Management 3.0? Talvez aquela sua solução matadora brilhante para o problema num primeiro momento, deixe de fazer efeito em algum tempo. As pessoas podem abandonar ou se desmotivarem com uma prática. O problema pode ressurgir de outra maneira.

É como lidar com um vírus (E vírus são CAS!). É difícil achar cura definitiva para vírus porque a cada novo remédio, o vírus muda, se adapta e torna a se espalhar.

Talvez você chegue em questões cujas pessoas envolvidas não queiram lidar. Normalmente ocorre em questões mais profundas, por exemplo: imagine que a causa de um problema sejam os salários dos colaboradores? Será que iriam à frente com isso?

Às vezes só crises têm força suficiente para que esse tipo de mudanças ocorra num projeto, organização ou na própria pessoa. Por isso crises são grandes oportunidades (às vezes desperdiçadas justamente por isso!). Mas isso é assunto pra outra conversa.

Talvez só de encontrar um problema, a situação toda já mude! (Tem um nome bonito pra isso, pra você explicar pro chefe – “a discussão gerou awareness!).

E provavelmente essa técnica toda fique defasada assim que publicada. (Ansiamos por isso!)

O importante mesmo é manter o “movimento”, exatamente como num ciclo PDCA.

 

Nenhum comentário »

Categorias deste post

Agile, Coaching, Management 3.0

The Backlog Grooming Flow

Para as pessoas interessadas em entender melhor a prática de Backlog Grooming, segue uma espécie de BigPicture (estilo Visual Thinking)  sintetizando o funcionamento do conceito Grooming. Essa Big Picture sintetiza a aplicação da técnica para fazer o refinamento de Product Backlogs em times Scrum.

O post com o texto original (em inglês) está publicado aqui. Nesse texto você poderá entender melhor o funcionamento e os benefícios  da prática de Backlog Grooming para tornar os Backlogs mais Detalhados, Estimados, Emergentes e Priorizados. Em outras palavras, basicamente a intenção do Backlog Grooming é tornar os backlogs mais organizados e palatáveis para todo o ciclo de geração de valor do Scrum.

 

The Backlog Grooming Flow

Nenhum comentário »

Categorias deste post

Agile, Scrum

Posso mudar o tamanho de uma Sprint?

O Roberto Pereira, Product Owner, nos mandou a seguinte dúvida:

O timebox da Sprint pode variar no decorrer do projeto? Exemplo: Sprint1: 2 semanas, Sprint2: 3 semanas, Sprint3: 2 semanas e assim por diante…

Nossa Resposta

Caro Roberto,

Uma Sprint pode mudar de tamanho quando não iniciada, em alguns momentos isso é recomendável mas na maioria das vezes isso é danoso.

É interessante quando o time percebe que não consegue entregar incremento de software no tempo pré-determinado de uma Sprint. Desta maneira, o time aumenta o tamanho da próxima Sprint e segue assim por um bom tempo.

Todavia alterar o tamanho da Sprint possui como trade-offs a perda do referencial de timing e de velocidade de uma Sprint, e demorar mais para se adaptar as mudanças.

A perda de noção de timing de Sprint, ocorre quando o time perde a ideia de quando deve começar a fazer processos importantes dentro de uma Sprint, como quando deve implantar no ambiente de homologação master ou quando deve obter assinaturas que autorizam a subida em produção.

Já a perda de referencial de velocidade ocorre porque ao aumentar o tempo de Sprint em 1/3 não ocorre um aumento na produtividade de 1/3. Na prática a velocidade pode tanto aumentar como diminuir…

Ops, como assim diminuir?

A famosa síndrome de estudante pode atacar o seu time… Ou seja, o seu time pode operar como nos tempos de faculdade no qual deixava para fazer as atividades perto do prazo de entrega.

Aumentar o tamanho da Sprint também significa demorar mais para escutar o PO, e por consequência o software muda de maneira mais lenta. Isso pode ser mais danoso que os dois itens acima juntos.

Para finalizar, no coração do Scrum encontra-se o conceito de trabalhar com timebox… E o seu time deve aprender a trabalhar com uma timebox definida.

Se vocês acordarem que vai ter um incremento de software a cada duas semanas, todos vão ter que gastar massa cinzenta para conseguir este objetivo.

O time de desenvolvimento vai aprender a ser mais objetivo, o que envolve organizar melhor as tarefas, os processos, e a eliminar o desperdício com supérfluos técnicos.

O Product Owner vai aprender a granularidade correta das atividades para caber na Sprint. De início ele vai achar impossível quebrar as tarefas, mas depois de um tempo ele vai conseguir acertar a granularidade.

Não sei por qual motivo você quer mudar, mas agora que já sabe alguns trade-offs, você pode tomar uma decisão bem fundamentada.

Em caso de dúvidas sobre metodologias ágeis mande um sinal de fumaça ou envie sua dúvida por e-mail.

1 Comentário »

Categorias deste post

Adaptworks Responde, Product Owner, Scrum, Sprint, Timebox