Quando Falamos Em Riscos E Questões É Certo Dizer Que

A real conversa sobre riscos e questões

Acho que a maioria das pessoas começa errado porque trata risco e questão como a mesma coisa. Não são. Risco é algo que ainda pode acontecer. Questão é algo que já aconteceu ou está acontecendo agora. Quando falamos em riscos e questões é certo dizer que eles compartilham o mesmo processo de gestão, mas exigem tratamentos diferentes na prática. Eu já vi gente confundir essas duas até em projetos de cinco milhões de reais. O resultado sempre foi o mesmo: plano de resposta para um risco que nunca se materializou enquanto o problema real seguia sem ninguém responsável por ele. A distinção simples resolve isso na maior parte das vezes.

Quando falamos em riscos e questões é certo dizer que o registro único funciona melhor

Não precisa de dois sistemas separados. Um único log com uma coluna de status — "risco" ou "questão" — e outra coluna de origem funciona perfeitamente na maioria dos cenários. A parte que as pessoas esquecem é a coluna de trigger, o gatilho. É ali que você anota o sinal de que um risco tá prestes a virar questão. Sem isso, você perde o momento exato da transição. No meu caso, trabalhei num projeto de migração de dados onde tínhamos um risco mapeado de "atraso na entrega do fornecedor". O trigger era definido como "reunião mensal com o fornecedor sem avanço visível nos marcos". Na terceira reunião, o fornecedor não apareceu. A questão virou assunto interno por duas semanas antes de qualquer um registrar. Desde aí, qualquer trigger não resolvido em duas semanas vira questão automática, sem depender de ninguém lembrar de fazer a conversão.

O processo que funciona na prática

Comece com a identificação. Não tente analisar tudo de uma vez. Lista bruta primeiro, depois prioriza. Um erro comum é gastar tempo analisando riscos com probabilidade zero porque parecem importantes para o gestor que está na sala. Priorize pelo impacto real multiplicado pela probabilidade. Se o número é baixo, coloque numa fila de observação e segue em frente. Anotar é diferente de perseguir. Depois vem a análise qualitativa. Use escalas simples: baixo, médio, alto. Não invente escala numérica com vírgula decimal. A precisão falsa gera confiança errada nas pessoas. Quando fui questionado sobre aquela análise, respondo com os dados que tenho. O cenário de alta incerteza exige honestidade, não números bonitos.

A resposta é onde a maioria trava. Para riscos, as quatro opções clássicas são aceitar, mitigar, transferir ou evitar. Para questões, a lista é menor porque já virou realidade: conter, corrigir, escalar ou documentar como lição aprendida. A diferença de tom importa. Mitigar é ação preventiva. Conter é ação reativa. Misturar os verbos no mesmo documento confunde quem for ler depois. Um detalhe técnico que pouca gente considera: a interdependência entre riscos. Um risco pode ser trigger de outro. Num projeto de infraestrutura que acompanhei, o risco de chuva atrasando a obra era trigger do risco de aumento de custo de fretes. Se você tratar cada um isoladamente, perde a conexão. Faça uma análise de rede simples, mesmo que manualmente, antes de fechar o plano de resposta.

Armadilhas que eu vejo todo dia

A primeira armadilha é o arquivo morto. Todo mundo cria um registro de riscos bonito e depois nunca mais abre. A gestão de risco funciona só se tiver revisões agendadas. Coloque no calendário uma revisão quinzenal de vinte minutos no começo do projeto e mensal depois que estabilizar. Se não houver reunião, o registro vira papel de parede. A segunda armadilha é a ansiedade de resolução. Tem gente que acha que precisa fechar cada risco rapidamente. Risco não se fecha, se monitora. Fechar só acontece quando o trigger dispara e vira questão, ou quando o escopo é alterado e o risco deixa de existir. Tentar fechar risco sem motivo válido é desperdício de tempo que poderia ser usado em riscos reais.

A terceira, e talvez a mais perigosa, é a ilusão de controle. Anotar um risco não significa que você está protegido. A proteção real vem do plano de resposta executado, não do registro. Já vi gerente apresentar um log de cinquenta riscos para o conselho como se isso fosse garantia de sucesso. O conselho queria saber quantos daqueles cinquenta tinham plano de resposta com dono, prazo e orçamento definidos. Três tinham. Os outros quarenta e sete eram apenas esperança anotada.

Quando o método falha completamente

Registrar riscos funciona bem em ambientes estáveis com escopo conhecido. Quando o escopo muda toda semana e o time não tem mais que três meses de horizono visível, a gestão formal de riscos perde eficiência rapidamente. Nesse cenário, o que funciona melhor é a abordagem ágil: revisar o backlog a cada sprint, identificar ameaças nos planejamento sessions, e tratar como issues imediatas sem burocracia. Tentar manter um registro formal nessas condições só gera atrito e trabalho desperdiçado. Outro cenário onde o método quebra é em equipes pequenas sem proprietário definido para cada risco. Se não tem dono claro, a resposta nunca acontece. A solução é simples: antes de adicionar qualquer risco ao log, tenha certeza de que alguém aceitou assumir a responsabilidade. Se ninguém aceitar, não registre. Registrar sem dono cria a ilusão de gestão sem a gestão de fato.

Resumo prático

Diferencie risco de questão desde o início. Use um registro único. Defina triggers claros. Revisões regulares são obrigatórias, não opcionais. Dê dono a cada item. Aceite que nem tudo pode ser controlado e que alguns riscos simplesmente não merecem atenção até que se materializem. A qualidade da sua gestão de risco depende mais da disciplina de revisão do que da sofisticação da ferramenta que você escolheu.