5 min leitura • Guide 307 of 877
Gestão de Riscos em Projetos
Todo projeto tem riscos—coisas que podem dar errado. Os melhores times não ignoram riscos; eles identificam cedo, avaliam seu impacto e planejam mitigações. Gestão de riscos proativa previne surpresas e mantém projetos no trilho.
Categorias de Risco
| Categoria | Exemplos | Foco de Mitigação |
|---|---|---|
| Técnico | Tech desconhecida, integração | Spikes, protótipos |
| Recursos | Pessoa-chave sai, capacidade | Cross-training, buffer |
| Externo | Atrasos de vendor, mudanças de API | Contratos, alternativas |
| Escopo | Requisitos mudam | Processo claro, buffer |
| Cronograma | Pressão de deadline | Estimativas realistas |
Identificação de Riscos
Encontrando Riscos
PROCESSO DE IDENTIFICAÇÃO DE RISCOS
═══════════════════════════════════
BRAINSTORM DO TIME:
─────────────────────────────────────
Na sessão de planejamento, pergunte:
├── "O que pode dar errado?"
├── "Sobre o que estamos incertos?"
├── "Com o que lutamos antes?"
├── "O que depende de outros?"
├── "O que é novo para nós?"
└── Todos contribuem
CATEGORIAS PARA EXPLORAR:
─────────────────────────────────────
Técnico:
├── Tecnologias desconhecidas
├── Complexidade de integração
├── Preocupações de performance
├── Requisitos de segurança
├── Desafios de escala
└── "Isso vai funcionar?"
Pessoas:
├── Disponibilidade de pessoa-chave
├── Gaps de habilidade
├── Capacidade do time
├── Disponibilidade de stakeholders
├── Dependências cross-team
└── "Temos as pessoas certas?"
Externo:
├── Vendors terceiros
├── Dependências de API
├── Requisitos regulatórios
├── Timing de mercado
├── Disponibilidade de cliente
└── "O que está fora do nosso controle?"
Escopo:
├── Requisitos não claros
├── Probabilidade de scope creep
├── Mudanças de stakeholder
├── Prioridades competindo
└── "Escopo vai ficar estável?"
DOCUMENTE CADA RISCO:
─────────────────────────────────────
Risco: [Descrição]
Categoria: [Técnico/Pessoas/Externo/Escopo]
Probabilidade: [Alta/Média/Baixa]
Impacto: [Alto/Médio/Baixo]
Mitigação: [Ação para reduzir risco]
Owner: [Quem monitora isso]
Status: [Aberto/Mitigando/Fechado]
Avaliação de Riscos
Probabilidade × Impacto
MATRIZ DE RISCOS
════════════════
IMPACTO
Baixo Médio Alto
┌────────┬────────┬────────┐
Alto │ Médio │ Alto │Crítico │
├────────┼────────┼────────┤ P
Médio│ Baixo │ Médio │ Alto │ R
├────────┼────────┼────────┤ O
Baixo│Aceitar │ Baixo │ Médio │ B
└────────┴────────┴────────┘
PRIORIDADE BASEADA EM SCORE:
─────────────────────────────────────
Crítico: Mitigação imediata requerida
Alto: Plano de mitigação, monitoramento ativo
Médio: Plano de mitigação, revisão regular
Baixo: Aceitar, check periódico
Aceitar: Anotar mas não gerenciar ativamente
EXEMPLO DE AVALIAÇÃO:
─────────────────────────────────────
Risco Prob Impacto Score
────────────────────────────────────────────────
Provedor API muda termos Médio Alto ALTO
Dev chave sai Baixo Alto MÉDIO
Requisitos não claros Alto Médio ALTO
Problemas de performance Médio Médio MÉDIO
Bug em nova feature Alto Baixo MÉDIO
Foco em: API e Requisitos (ALTO)
Planejar para: Outros (MÉDIO)
Estratégias de Mitigação
Tipos de Resposta
ESTRATÉGIAS DE RESPOSTA A RISCOS
════════════════════════════════
EVITAR:
─────────────────────────────────────
Eliminar o risco inteiramente.
Exemplo:
Risco: "Novo banco pode não escalar"
Evitar: Usar banco provado que sabemos escala
Quando: Possível e prático
MITIGAR:
─────────────────────────────────────
Reduzir probabilidade ou impacto.
Exemplo:
Risco: "Dev chave pode sair"
Mitigar: Cross-train time, documentar conhecimento
Quando: Não pode evitar mas pode reduzir
TRANSFERIR:
─────────────────────────────────────
Passar risco para outra parte.
Exemplo:
Risco: "Infraestrutura pode falhar"
Transferir: Usar provedor cloud com SLA
Quando: Alguém pode gerenciar melhor
ACEITAR:
─────────────────────────────────────
Reconhecer e prosseguir.
Exemplo:
Risco: "Bug menor de UI pode ocorrer"
Aceitar: Corrigirá se acontecer, não vale prevenir
Quando: Baixo impacto, alto custo para mitigar
Monitoramento
Acompanhamento de Riscos
PROCESSO DE MONITORAMENTO
═════════════════════════
REVISÃO SEMANAL:
─────────────────────────────────────
Em reunião de projeto:
├── Revisar cada risco ativo
├── Probabilidade mudou?
├── Impacto mudou?
├── Mitigação progredindo?
├── Novos riscos surgiram?
└── Atualizar registro
SINAIS DE ALERTA:
─────────────────────────────────────
├── Bloqueios aumentando
├── Velocidade caindo
├── Comunicação deteriorando
├── Scope mudando frequente
├── Moral do time baixo
└── Escalar se necessário
ESCALAÇÃO:
─────────────────────────────────────
Escale quando:
├── Risco excede autoridade do time
├── Mitigação requer budget extra
├── Impacto afeta compromissos
├── Outros times são impactados
└── Escale cedo com soluções propostas
Melhores Práticas
Para Gestão de Riscos
- Identificar cedo — Não esperar problemas
- Quantificar — Probabilidade × Impacto
- Atribuir owners — Responsabilidade clara
- Mitigar proativamente — Não apenas monitorar
- Revisar regularmente — Semanal no mínimo
Anti-Padrões
ERROS DE GESTÃO DE RISCOS:
✗ Ignorar riscos ("vai dar certo")
✗ Identificar sem mitigar
✗ Sem owners definidos
✗ Registro desatualizado
✗ Escalar tarde demais
✗ Tratar riscos e issues igual
✗ Parar após início do projeto
✗ Riscos escondidos de stakeholders