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