Como priorizar falhas / defeitos?

A Matriz GUT (Gravidade, Urgência e Tendência) é uma ferramenta utilizada na priorização das estratégias, tomadas de decisão e solução de problemas de organizações/projetos.

Gravidade: impacto do problema sobre coisas, pessoas, resultados, processos ou organizações e efeitos que surgirão, caso o problema não seja resolvido.

Urgência: relação com o tempo disponível ou necessário para resolver o problema.

Tendência: potencial de crescimento do problema, avaliação da tendência de crescimento, redução ou desaparecimento do problema.

A pontuação de 1 a 5, para cada dimensão da matriz, permite classificar em ordem decrescente de pontos os problemas a serem atacados na melhoria do processo.

Após atribuída a pontuação, deve ser multiplicado GxUxT e achar o resultado, priorizando em ordem decrescente, de acordo com os pontos obtidos.

Critérios GUT
Pontos	Gravidade	Urgência	Tendência
5	Prejuízo / Dificuldade é extremamente grave	Necessária ação imediata	Se nada for feito, agravamento será imediato
4	Muito grave	Com alguma urgência	Vai piorar em curto prazo
3	Grave	O mais cedo possível	Vai piorar em médio prazo
2	Pouco Grave	Pode esperar um pouco	Vai piorar em longo prazo
1	Sem Gravidade	Não tem pressa	Não vai piorar ou até pode melhorar

Matriz:

		Organização'
		Processo:
Problemas			G	U	T	Total	Priorização
1
2
3
4
5
6
7

A partir da matriz GUT pode ser desenvolvida uma nova matriz que contemple as necessidades de cada organização. Abaixo estarei mostrando outro exemplo na qual acredito que atenderá a boa parte dos casos:

Detectabilidade
Opções	Critérios de definição
1-Alta	Alto grau de certeza de que o erro será detectado pelo usuário durante a operação normal do sistema em suas funcionalidades mais elementares / usuais.
2-Moderada	O erro é percebido apenas em situações específicas ou funcionalidades não essenciais do produto.
3-Baixa	Erro detectado em situações extremamente específicas e que necessitam de uma rara combinação de fatores para que ocorra. O erro raramente será percebido pelo usuário.

Severidade
Opções	Critérios para Definição	Exemplos
1-Crítico	- Falha geral da aplicação. - Perda de dados. - Instabilidade da aplicação ou de seus serviços. - Impede a continuidade dos testes ou do uso da aplicação como um todo. - Build da aplicação corrompido. - Funcionalidades principais da aplicação seriamente comprometidas.	- O erro não permite a continuidade dos testes ou compromete severamente o resultado dos mesmos. - Erros de Java, PHP, SQL, etc. - “Fatal error”. - Funcionalidade desenvolvida em desacordo com os requisitos especificados (desvio significativo). - Problemas graves de desempenho. - Incompatibilidade com o browser ou outros itens de ambiente. - Links quebrados. - Loops infinitos. - Produtos cartesianos em consultas/relatórios.
2-Grave	- Sério comprometimento de funcionalidade (funcionalidade impossível de ser utilizado, sistema travando ou se comportando de maneira não prevista). - Bug em funcionalidade essencial do produto com workaround complexo. - Comprometimento moderado da continuidade dos testes.	- Funcionalidade desenvolvida em desacordo com os requisitos especificados (desvio moderado). - Problemas perceptíveis de desempenho com razoável impacto no uso normal da aplicação. - Regras de validação de campos não aplicadas corretamente (data inválida, valor fora da faixa, etc.).
3-Moderado	- Problemas moderados em funcionalidades do produto. - Existe um workaround simples. - Baixo impacto nos testes. - Ergonomia razoavelmente comprometida e com viabilidade de melhoria.	- Layout de tela/relatório fora dos padrões. - Layout de tela/relatório ergonomicamente inadequado. - Falta de valores padrões para campos quando aplicável. - Navegação fora de ordem entre os componentes da tela. - Teclas de atalho padrão não desenvolvidas corretamente. - Foco setado incorretamente. - Imagens não carregadas. - Erros de ordenação/quebra em consultas e relatórios. - Termos inadequados/fora do contexto.
4-Cosmético	- Não chegam a comprometer o objetivo final da funcionalidade. - Afetam a aparência na forma de erro, não de melhoria.	- Layout de tela/relatório esteticamente inadequado. - Erros de documentação. - Erros de ortografia/digitação. - Alinhamento de campos. - Falta de clareza em mensagens para o usuário.
5-Melhoria	- Não são erros, mas oportunidades de melhoria identificadas no uso do sistema durante a fase de inspeção. - Existe grande probabilidade de o cliente sugerir a mesma melhoria no futuro. - Ação pró-ativa.	- Telas/relatórios com layout adequado, mas com oportunidade de melhoria. - Sugestão de termos. - Cores.

			Prioridade
MATRIZ DE PRIORIZAÇÃO PARA CORREÇÃO						Detectabilidade
						Alta	Média	Baixa
Severidade				Crítico		P1	P1	P1
				Grave		P1	P1	P2
				Moderado		P2	P2	P3
				Cosmético		P3	P3	P4
				Melhoria		P4	P4	P4
Prioridade		Prazo Correção			Definição
P1		x Dias úteis (de acordo com seu SLA)			Resolver imediatamente Desenvolvimento posterior e/ou teste não pode ocorrer até que o defeito tenha sido reparado. O sistema não pode ser usado até que o reparo tenha sido efetuado.
P2		x Dias úteis (de acordo com seu SLA)			Dar alta prioridade O defeito deve ser resolvido o mais rápido possível porque está prejudicando as atividades de teste e/ou desenvolvimento. O sistema vai ser severamente afetado até que o defeito seja reparado.
P3		x Dias úteis (de acordo com seu SLA)			Fila normal O defeito deveria ser resolvido no curso normal das atividades de desenvolvimento. Ele pode esperar até que uma nova edição ou versão seja criada.
P4		x Dias úteis (de acordo com seu SLA)			O defeito pode ser postergado indefinidamente. Pode ser resolvido em uma revisão maior do sistema no futuro ou nem resolvida.