menu

Tolerância Zero: Uma abordagem para a qualidade

Por

No meu post que falava se o Agile estava entrando em um processo de dogmatização, eu trouxe a pauta o tema da busca por qualidade, também muito bem tratada pelo Hamilton em seu post “Um passo a frente ou o suficiente?“. Naquela ocasião, defendi que muitos agilistas vinham encarando o problema do esforço de qualidade com uma dose muito maior de dogma do que uma avaliação de custo-benefício.

Acontece que vemos, muitas vezes, o lado oposto da mesma moeda, ou seja, o esforço de qualidade estar abaixo ou muito abaixo do ideal.

Tolerância zero e segurança pública

Tolerância zero é um termo muito conhecido quando se fala de política de segurança pública. Quer dizer que se retira praticamente todo o poder de escolha dos agentes policiais em prol de uma política mais austera; os agentes policiais, assim, não podem mais “perdoar” um pequeno furto, ou uma pixação de uma parede, ou qualquer outro pequeno delito. A base do pensamento por trás dessa abordagem é que normalmente os criminosos começam com crimes de menor potencial ofensivo para “evoluir” até os crimes considerados mais graves, ou seja, evitando os “crimezinhos” seriam evitados também os “crimezões”.

Podemos argumentar que uma das causas dos crimes maiores é justamente a sensação de impunidade que vai se construindo na cabeça do criminoso. Aos poucos ele vai ficando mais certo de que o crime compensa. Quando se trata os crimes menores com vigor, na verdade está se interrompendo uma das causas-raizes dos crimes graves que é, como dito, a sensação de impunidade.

Tolerância zero na qualidade de software

O termo, quando aplicado à qualidade, ganha outros ares, não é tratar pequenos defeitos para evitar os maiores, como poderia fazer pensar. O que tem de semelhança é uma política que deixa pouca margem para as pessoas dentro do processo, ou seja, a ideia é que todo defeito seja tratado com o mesmo vigor, buscando-se sempre a causa-raiz. Afinal, os defeitos — mesmo os que muitas vezes são considerados de menor “potencial ofensivo” — podem ter uma causa-raiz não identificada que venha a provocar outros defeitos, inclusive mais graves.

Só para reforçar, quando se fala em tolerância zero como uma abordagem para qualidade, a ideia de nenhuma forma é manter um sistema absolutamente livre de defeitos, mas sim um em que todos os defeitos recebam um tratamento de identificação da causa-raiz. Os efeitos de se buscar uma mentalidade de defeitos zero (diferente de tolerância zero) seriam extremamente danosos para a motivação das pessoas e para a inovação.

Técnica dos cinco porquês

Há diversas técnicas para essa análise de cauza-raiz, sendo que uma das mais famosas é a técnica dos 5 porquês que, apesar das críticas, continua sendo muito útil, pois é de execução muito fácil e rápida com resultados bastante positivos.

Lembre-se, a ideia não é fazer uma caça às bruxas, e sim tentar resolver a real fonte dos problemas. Se for, por exemplo, falta de conhecimento de alguém da equipe, talvez a programação em pares, talvez um treinamento, possa solucionar o problema. Pode ainda ser o cansaço de uma equipe exposta a horas extras intermináveis que por fim tem causa-raiz em mau planejamento ou em uma visão deturpada de algum gestor sobre como conduzir um projeto.

Backlog de causas-raizes

Algo interessante a se fazer é um backlog de causas-raizes a se resolver, priorizar as maiores geradoras de problemas e atacá-las com coragem e determinação. Literalmente, é uma abordagem de se “cortar o mal pela raiz”.

O que você faz em relação à qualidade do seu sistema e do seu processo? Você tem utilizado alguma forma de levantamento de causas-raizes?

About the author: Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando com Agile e hoje trabalha na ThoughtWorks Brasil. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é advogado por formação (Universidade Presbiteriana Mackenzie).
LinkedIn
@leonardocampos

2 comments

  1. Rafael Buzon

    Bem legal o Post Leo.

    Talvez dê também para trazer aquela metáfora da janela trincada, que, se não consertada, abre precedente para que alguém venha e jogue mais uma pedrinha, trincando-a ainda mais.

    Vlw pelo post!

    Posted on julho 30, 2014
    • Leonardo Campos

      A famosa “teoria da janela quebrada”, que para quem não sabe, diz que algo é mantido em ordem até que alguma coisa, mesmo que pequena, seja deixada quebrada, como uma janela em um prédio, que se mantida quebrada, logo o prédio inteiro será depredado. (Ver o livro Pragmatic Programmer)

      Quando aplicada a defeitos, acredito que essa teoria poderia nos induzir a pensar mais em uma mentalidade de defeitos zero. Tipo, não deixo essa janela trincada para ninguém mais se sentir a vontade de vir e quebrar mais, certo?

      Só para exercitar o pensamento: Defeitos são dívidas técnicas? Acredito que não. Um dívida técnica faz o que tem que fazer (diferente do defeito), mas é um código mal escrito, que muito provavelmente dificulta a manutenibilidade e dá um ar de “sujo” ao código, ou seja, defeito tem efeito externo, dívida técnica, interno. Minha percepção é que a teoria da janela quebrada aplique-se muito bem a manter o código livre de dívidas técnicas, em contrapartida acredito que um desenvolvedor olhando para um código bem escrito (legível), não se sinta impelido a gerar mais código que não faça o que tem que fazer. Já para um código que tenha algo porco: É só mais um pouquinho de porquisse…
      Um último pensamento: se fizermos os cinco porquês para os defeitos, logo no primeiro ou segundo, deve surgir uma dívida técnica, aí é só seguir em frente: E por que temos essa dívida técnica???

      Posted on agosto 6, 2014

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top