8 min leitura • Guide 584 of 877
Gestão de Riscos para Projetos de Software
Todo projeto de software carrega riscos—incógnitas técnicas, restrições de recursos, requisitos mudando e dependências externas. GitScrum ajuda times rastrear e visualizar riscos do projeto junto com tarefas regulares, garantindo que mitigação de riscos seja parte do sprint planning ao invés de algo pensado depois. A chave é identificação proativa e monitoramento contínuo, não apenas esperar que problemas não aconteçam.
Categorias de Risco
| Categoria | Exemplos | Mitigação Típica |
|---|---|---|
| Técnico | Complexidade, integração, performance | Spikes, protótipos |
| Recursos | Gaps de skill, disponibilidade, turnover | Cross-training, buffer |
| Cronograma | Dependências, erros de estimativa | Tempo de buffer, faseamento |
| Escopo | Creep, requisitos não claros | Processo de mudança |
| Externo | Vendors, regulações, mercado | Monitoramento, alternativas |
Registro de Riscos
REGISTRO DE RISCOS DO PROJETO
TEMPLATE DE REGISTRO:
┌─────────────────────────────────────────────────────────────────────────────┐
│ ID Risco Prob Impacto Score Owner Mitigação Status │
│ ────────────────────────────────────────────────────────────────────── │
│ R1 Atraso vendor API Alto Alto 9 @alex Vendor alt Ativo │
│ R2 Dev chave sai Médio Alto 6 @mgr Cross-train Ativo │
│ R3 Scope creep Alto Médio 6 @pm Proc mudança Ativo │
│ R4 Problema de perf Médio Médio 4 @lead Teste cedo Monitor│
│ R5 Vuln segurança Baixo Alto 3 @sec Auditoria Monitor│
└─────────────────────────────────────────────────────────────────────────────┘
SCORING:
┌─────────────────────────────────────────────────┐
│ Probabilidade: Impacto: │
│ Alto = 3 Alto = 3 │
│ Médio = 2 Médio = 2 │
│ Baixo = 1 Baixo = 1 │
│ │
│ Score = Probabilidade × Impacto │
│ 7-9: Crítico (mitigação ativa requerida) │
│ 4-6: Significativo (monitorar de perto) │
│ 1-3: Menor (rastrear, pode aceitar) │
└─────────────────────────────────────────────────┘
Identificação de Riscos
MÉTODOS DE IDENTIFICAÇÃO DE RISCOS
DESCOBERTA SISTEMÁTICA:
┌─────────────────────────────────────────────────┐
│ No Início do Projeto: │
│ ├── Revisar lições de projetos similares │
│ ├── Sessão de brainstorm de riscos com time │
│ ├── Checar checklist de riscos comuns │
│ └── Entrevistar stakeholders chave │
│ │
│ Durante o Projeto: │
│ ├── Revisão semanal em reuniões de time │
│ ├── Ouvir "estou preocupado com..." │
│ ├── Monitorar bloqueios e atrasos │
│ └── Rastrear erros de estimativa │
│ │
│ Retrospectivas: │
│ ├── O que quase deu errado? │
│ ├── O que nos surpreendeu? │
│ └── O que vigiaríamos na próxima? │
└─────────────────────────────────────────────────┘
CHECKLIST DE RISCOS COMUNS:
┌─────────────────────────────────────────────────┐
│ Técnicos: │
│ ☐ Nova tecnologia que não usamos antes │
│ ☐ Integração com sistemas externos │
│ ☐ Requisitos de performance não claros │
│ ☐ Funcionalidade sensível à segurança │
│ ☐ Migração de dados complexa │
│ │
│ Time: │
│ ☐ Dependência de pessoa-chave (bus factor) │
│ ☐ Gaps de skill para trabalho requerido │
│ ☐ Disponibilidade de membros do time │
│ ☐ Desafios remotos/distribuídos │
│ │
│ Processo: │
│ ☐ Requisitos não claros ou mudando │
│ ☐ Múltiplos stakeholders com conflitos │
│ ☐ Dependências externas │
│ ☐ Requisitos regulatórios/compliance │
│ │
│ Cronograma: │
│ ☐ Deadline fixo (regulatório, evento) │
│ ☐ Cronograma agressivo │
│ ☐ Dependências de outros times │
│ ☐ Escopo desconhecido │
└─────────────────────────────────────────────────┘
Avaliação de Riscos
FRAMEWORK DE AVALIAÇÃO DE RISCOS
ANÁLISE DETALHADA DE RISCO:
┌─────────────────────────────────────────────────┐
│ Risco: Atrasos do vendor de API terceiro │
│ │
│ Descrição: │
│ Migração da API v3 do processador de pagamento │
│ pode não estar pronta pela nossa data alvo. │
│ │
│ Probabilidade: ALTA │
│ ├── Vendor tem histórico de atrasos │
│ ├── Timeline deles é 2 semanas antes do nosso │
│ └── Sem compromisso contratual │
│ │
│ Impacto: ALTO │
│ ├── Bloqueia feature de pagamento inteiramente │
│ ├── R$500K receita em risco │
│ └── Atraso de lançamento de 4-6 semanas │
│ │
│ Score de Risco: 9 (Crítico) │
│ │
│ Sinais de Alerta Antecipados: │
│ ├── Sem acesso beta até 15 Fev │
│ ├── Documentação não completa até 1 Fev │
│ └── Vendor para de responder prontamente │
└─────────────────────────────────────────────────┘
AVALIAÇÃO DE IMPACTO:
┌─────────────────────────────────────────────────┐
│ Tipo Impacto Baixo Médio Alto │
│ ────────────────────────────────────────── │
│ Cronograma <1 semana 1-4 sem >4 sem │
│ Budget <R$10K R$10-50K >R$50K │
│ Qualidade Bugs menor Features Major │
│ Cliente Poucos Alguns Muitos │
│ Reputação Interno Local Público│
└─────────────────────────────────────────────────┘
Estratégias de Mitigação
ABORDAGENS DE MITIGAÇÃO
OPÇÕES DE ESTRATÉGIA:
┌─────────────────────────────────────────────────┐
│ EVITAR: │
│ └── Eliminar risco não fazendo a coisa │
│ Exemplo: Não usar tecnologia não provada │
│ │
│ MITIGAR: │
│ └── Reduzir probabilidade ou impacto │
│ Exemplo: Mais testes para pegar issues │
│ │
│ TRANSFERIR: │
│ └── Passar risco para outra parte │
│ Exemplo: Seguro, SLAs de vendor │
│ │
│ ACEITAR: │
│ └── Reconhecer e planejar para consequência │
│ Exemplo: Risco pequeno com impacto mínimo │
└─────────────────────────────────────────────────┘
EXEMPLOS DE MITIGAÇÃO:
┌─────────────────────────────────────────────────┐
│ Risco: Desenvolvedor chave sai │
│ │
│ Mitigações: │
│ ├── Cross-train segunda pessoa em área crítica │
│ ├── Documentar conhecimento tribal │
│ ├── Code reviews regulares para compartilhar │
│ └── Discussão de retenção com gestão │
│ │
│ Owner: @engineering_manager │
│ Status: Em progresso (cross-training iniciado) │
│ Due: Fim do sprint 5 │
└─────────────────────────────────────────────────┘
MITIGAÇÃO PARA RISCO TÉCNICO:
┌─────────────────────────────────────────────────┐
│ Risco: Nova tecnologia pode não performar │
│ │
│ Plano de Mitigação: │
│ 1. Sprint 1: Spike para avaliar (2 dias) │
│ 2. Sprint 2: Protótipo com carga realista │
│ 3. Ponto de decisão: Go/No-Go fim do sprint 2 │
│ 4. Fallback: Usar alternativa provada │
│ │
│ Critérios de Sucesso: │
│ ├── Processar 1000 req/seg │
│ ├── Latência < 100ms p99 │
│ └── Time confortável com tecnologia │
└─────────────────────────────────────────────────┘
Monitoramento de Riscos
PROCESSO DE MONITORAMENTO
REVISÃO SEMANAL DE RISCOS:
┌─────────────────────────────────────────────────┐
│ Reunião: Standup semanal do projeto (5 min) │
│ │
│ Revisar cada risco ativo: │
│ ├── Probabilidade mudou? │
│ ├── Impacto mudou? │
│ ├── Update de progresso da mitigação │
│ ├── Sinais de alerta observados? │
│ └── Novos riscos identificados esta semana? │
│ │
│ Ações: │
│ ├── Atualizar registro de riscos │
│ ├── Escalar se necessário │
│ └── Atribuir action items │
└─────────────────────────────────────────────────┘
INDICADORES DE ALERTA ANTECIPADO:
┌─────────────────────────────────────────────────┐
│ Indicadores de Risco de Cronograma: │
│ ├── Velocidade tendendo para baixo │
│ ├── Mais trabalho descoberto que esperado │
│ ├── Dependências escorregando │
│ └── Time fazendo hora extra │
│ │
│ Indicadores de Risco Técnico: │
│ ├── Mais bugs que usual │
│ ├── Problemas de integração aparecendo │
│ ├── Problemas de performance em testes │
│ └── Dívida técnica aumentando │
│ │
│ Indicadores de Risco de Time: │
│ ├── Moral ou engajamento baixo │
│ ├── Conflitos aumentando │
│ ├── Conhecimento concentrado em poucos │
│ └── Alto turnover ou sinais de turnover │
└─────────────────────────────────────────────────┘
Melhores Práticas
Para Gestão de Riscos
- Proativo — Identificar antes de acontecer
- Visível — Registro acessível a todos
- Quantificado — Probabilidade × Impacto
- Owned — Responsável definido
- Monitorado — Revisão semanal
Anti-Padrões
ERROS DE GESTÃO DE RISCOS:
✗ Esperar problemas acontecerem
✗ Registro escondido ou desatualizado
✗ Sem owners definidos
✗ Mitigações vagas
✗ Escalar tarde demais
✗ Ignorar sinais de alerta
✗ Não documentar lições aprendidas
✗ Tratar riscos só no início