Riscos em projetos de software: os mais comuns e como tratar
Projetos de software parecem mais controláveis do que obras: não chove dentro do código e o fornecedor de cimento não atrasa. Na prática, a incerteza só muda de lugar. O requisito que o usuário descreve de um jeito e usa de outro, a interface de programação do banco que muda sem aviso, a carga de dados que funciona com mil registros e trava com dois milhões. Os riscos em projetos de software têm padrões conhecidos, e conhecê-los encurta muito a sessão de identificação.
O que segue organiza os riscos mais comuns em sete grupos, cada um com o sinal que costuma antecipá-lo e a resposta mais usada, e mostra a aplicação num projeto ilustrativo. A base do ciclo de riscos (escalas, matriz, respostas e reservas) está no guia de gestão de riscos em projetos; aqui o foco é o que muda quando o produto é software.
Formação relacionada
Gestão de Projetos 360° com PMBOK 8 e IA
Formação completa sobre o guia mais recente do PMI, com uso de inteligência artificial no dia a dia da gestão.
Por que software tem riscos próprios
Três características explicam boa parte dos riscos:
- O produto é invisível até funcionar. O usuário só entende o que pediu quando vê a tela. Por isso o risco de requisito é maior que em projetos com entregas físicas.
- Quase nada nasce isolado. Sistemas conversam com ERP, bancos, governo, meios de pagamento e outros sistemas internos. Cada integração é uma dependência de alguém de fora do projeto.
- O custo do erro cresce com o tempo. Um defeito de arquitetura descoberto na homologação custa muito mais do que o mesmo defeito discutido no desenho. A resposta a risco em software quase sempre é antecipar a descoberta.
Os riscos mais comuns em projetos de software, por grupo
| Grupo | Risco típico (causa, evento, efeito) | Sinal de alerta | Resposta mais usada |
|---|---|---|---|
| Requisitos e escopo | Porque as regras de negócio estão na cabeça de poucos usuários, os requisitos podem estar incompletos, o que geraria retrabalho na homologação | Histórias que voltam do refinamento sem critério de aceite | Mitigar: protótipo navegável e validação com usuários antes de desenvolver |
| Integração | Porque a interface do sistema do parceiro não está documentada, a integração pode falhar ou atrasar, o que travaria a entrada em produção | Ambiente de testes do parceiro indisponível ou sem dados | Mitigar: prova de conceito da integração na primeira iteração |
| Dados e migração | Porque o sistema antigo aceita cadastros sem validação, a migração pode encontrar dados inconsistentes, o que exigiria saneamento e nova carga | Primeira carga de teste com mais de 5% de rejeição | Mitigar: perfilamento dos dados e carga de teste cedo |
| Técnico e dívida técnica | Porque o módulo legado não tem testes automatizados, uma alteração pode quebrar funções existentes, o que causaria falha em produção | Correções que geram defeitos em outras telas | Mitigar: testes de regressão nas áreas tocadas e refatoração planejada |
| Segurança e dados pessoais | Porque o sistema trata dados pessoais de clientes, uma falha de controle de acesso pode expor dados, com sanções da Lei Geral de Proteção de Dados (LGPD) e dano à imagem | Perfis de acesso definidos só no fim | Mitigar: requisitos de segurança desde o início e teste de invasão antes da produção |
| Pessoas | Porque só um desenvolvedor conhece a plataforma, a saída dele pode parar a evolução, o que atrasaria entregas | Toda dúvida técnica vai para a mesma pessoa | Mitigar: programação em par, revisão de código e documentação mínima |
| Implantação e adoção | Porque os usuários usam planilhas há anos, eles podem resistir ao sistema novo, o que manteria o processo paralelo e anularia o benefício | Baixa presença nos treinamentos | Mitigar: usuários-chave no projeto desde o início e plano de mudança |
Fornecedores e contratos entram em quase todos os grupos. Se uma parte do desenvolvimento é terceirizada, cada risco acima tem uma versão "o fornecedor pode...", e a forma de contratar (escopo fechado, por hora, por entrega) muda quem absorve o impacto.
Dívida técnica: risco ou problema?
A dívida técnica que já existe é uma condição presente, então é um problema a administrar. O risco é o efeito incerto que ela pode provocar: uma mudança simples que vira semanas de trabalho, uma falha em produção, a impossibilidade de escalar no pico. Registre o risco pelo efeito, e não pela dívida em si. A diferença entre as duas listas está em risco ou problema.
Exemplo de aplicação: aplicativo de agendamento
O exemplo é ilustrativo. Uma rede de clínicas vai lançar um aplicativo de agendamento integrado ao sistema de prontuário, ao meio de pagamento e ao serviço de mensagens. O projeto tem quatro meses e o lançamento coincide com a campanha de vacinação, que concentra a procura.
Na primeira sessão, a equipe percorreu os sete grupos e registrou 22 riscos. Os cinco maiores, na escala de 1 a 5 da Projeto Diário (baixo de 1 a 4, médio de 5 a 9, alto de 10 a 16, crítico de 20 a 25):
| ID | Risco | P × I | Faixa | Estratégia e ação |
|---|---|---|---|---|
| R01 | A integração com o prontuário pode exigir mudanças do fornecedor que não estão no contrato | 4 × 5 = 20 | Crítico | Escalar ao patrocinador a negociação do aditivo; prova de conceito na Sprint 1 |
| R02 | O pico de acessos no início da campanha pode derrubar o agendamento | 3 × 5 = 15 | Alto | Mitigar: teste de carga duas semanas antes do lançamento |
| R03 | Dados de pacientes podem ficar expostos por falha de perfil de acesso | 2 × 5 = 10 | Alto | Mitigar: revisão de segurança e teste de invasão; transferir parte do impacto com seguro de responsabilidade cibernética, se a empresa já tiver |
| R04 | Recepcionistas podem continuar agendando por telefone e planilha | 3 × 4 = 12 | Alto | Mitigar: piloto em duas clínicas e treinamento em turnos |
| R05 | O meio de pagamento pode atrasar a homologação | 3 × 3 = 9 | Médio | Aceitar com contingência: lançar com pagamento na clínica se o gatilho disparar |
Duas decisões mostram como o tipo de projeto muda a resposta. O R01 não pode ser resolvido pelo time, porque depende de contrato com outra empresa: por isso foi escalado. E o R05 foi aceito porque existe um jeito barato de lançar sem ele. O gatilho combinado foi "homologação não concluída a 15 dias do lançamento". Outros exemplos de riscos, organizados por categoria e por tipo de projeto, estão em exemplos de riscos em projetos.
Como tratar os riscos no desenvolvimento ágil
Boa parte dos projetos de software roda em Sprints. A gestão de riscos continua existindo, mas mora no backlog:
- Respostas viram itens do backlog. O teste de carga e a prova de conceito da integração disputam prioridade com funcionalidades, e o Product Owner decide com a nota de risco à vista.
- Alto risco primeiro. Itens com muita incerteza técnica vão para as primeiras Sprints, enquanto ainda há tempo de mudar de rumo.
- Investigações curtas (spikes). Quando a dúvida é técnica, uma investigação com tempo limitado responde antes do compromisso.
- Definição de pronto que reduz risco. Incluir testes automatizados e revisão de código na definição de pronto diminui o acúmulo de dívida técnica a cada entrega.
- Exposição visível. O gráfico de risk burndown mostra, Sprint a Sprint, se a soma da exposição está caindo.
Em projetos híbridos, com contrato de prazo fixo e desenvolvimento em Sprints, mantenha um registro no nível do projeto para contrato, fornecedores e prazo legal, e trate os riscos técnicos no backlog.
Testes como resposta a risco
Testes são a resposta de mitigação mais usada em software, e ainda assim são cortados quando o prazo aperta. Planejar testes por risco (mais profundidade onde a nota é maior) dá ao gerente um argumento para defendê-los. O artigo sobre testes de software bem planejados na gestão de projetos mostra como encaixá-los no plano. Para funcionalidades críticas, uma análise de modos de falha e efeitos (FMEA) ajuda a decidir onde testar mais.
Sinais de que os riscos estão sendo ignorados
- O registro tem só riscos técnicos; nenhum de adoção, contrato ou dados.
- As integrações estão marcadas para o fim do cronograma.
- O ambiente de homologação ainda não existe na metade do projeto.
- A estimativa de migração de dados é "um fim de semana".
- Ninguém sabe dizer quantos defeitos abertos o sistema pode ter para entrar em produção.
Comece pela próxima Sprint ou fase
Reúna o time por uma hora, percorra os sete grupos da tabela e registre ao menos um risco por grupo no formato causa, evento e efeito. Pontue, escolha a resposta dos riscos altos e críticos e coloque cada resposta no backlog ou no cronograma, com dono. Para registrar, pontuar e ver o mapa de calor sem montar planilha, use a matriz de riscos gratuita da Projeto Diário, que calcula a reserva de contingência sugerida e exporta o registro para Excel.
