Como priorizar falhas / defeitos?
Autor: Anderson Tavares | Publicado: 2011-01-05T12:10:00-08:00


A Matriz GUT (Gravidade,&nbsp;Urgência e&nbsp;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.