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

Gerenciamento de riscos: o que a prática mostra

A maioria dos times trata risco e questão como sinônimos, e isso gera problemas logo nos primeiros trimestres. Risco é algo que pode acontecer no futuro. Questão é algo que já aconteceu ou está acontecendo agora. Dito isso, quando falamos em riscos e questões é certo dizer que precisam de tratamentos diferentes, timelines diferentes e responsabilidades diferentes. Não é uma questão de semântica, é uma questão de quem vai responder quando o fogo apagar ou quando o bombeiro precisar ser chamado. No dia a dia, eu vejo isso errando de um jeito muito específico. Tenho um exemplo recente aqui. Trabalhávamos em uma migração de banco de dados para uma aplicação que tinha cerca de 40 tabelas transacionais. O registro de risco dizia que "a migração pode falhar" e o plano de mitigação era "fazer backup". Dois dias antes do cutover, a migração falhou mesmo, e aí o time ficou perguntando o que fazer como se estivesse lidando com um risco futuro. A resposta correta na hora era já estar executando o plano de contingência, não reavaliando o risco. O registro precisava ter convertido aquele item de risco para questão no momento em que os testes de integração falharam pela primeira vez, e não quando o erro atingiu produção. Aprendi isso na marra, depois de perder quase uma semana inteira remanejando pessoas entre o que era risco ativo e o que já era problema concreto.

quando falamos em riscos e questões é certo dizer que

é certo dizer que a distinção importa porque ela define o fluxo de decisão. Risco se gerencia com planejamento, monitoramento e reserva. Questão se gerencia com resposta, comunicação e correção. Misturar os dois faz com que você gaste tempo planejando o que já precisa ser resolvido, ou pior, tratou uma questão como risco e deixa ela evaporar na lista de acompanhamento sem ninguém assumindo ownership. Aqui vai um detalhe que poucos livros mencionam. Existe um estado intermediário que não é nem risco nem questão e as pessoas costumam classificar errado. Chama-se condição. Condição é um fato presente que ainda não gerou impacto, mas que aumenta a probabilidade de um risco se materializar. Se você tem uma dependência crítica com um fornecedor que está passando por reestruturação societária, isso não é um risco de atraso, não é uma questão de atraso. É uma condição. O risco seria "o fornecedor não entrega no prazo". A condição é o sinal de alerta que justifica eleviar a probabilidade daquele risco. Tratar condição como risco costuma inflar a lista de forma artificial. Tratar condição como questão gera pânico desnecessário. O lugar certo da condição é num campo separado dentro do registro, com trigger definido: quando a condição atingir um nível X, converte-se automaticamente para risco com probabilidade recalibrada. Outro ponto que todo mundo subestima é a taxa de conversão entre risco e questão. Em projetos de infraestrutura, observo algo em torno de 15 a 30 por cento dos riscos registrados virarem questões durante o ciclo de vida. Em projetos de software com alta dependência de terceiros, esse número pode passar de 40 por cento. Isso significa que sua taxa de abertura de questões vai corresponder diretamente à qualidade do seu registro de riscos. Se a lista está pequena e bonita, provavelmente você não está identificando riscos reais, está registrando wishes.

Eu uso uma abordagem bem prática para evitar confusão. Cada item no registro carrega três campos obrigatórios: probabilidade atual, impacto atual e status. Status tem quatro valores possíveis. Aberto significa risco identificado, mitigation em andamento. Em monitoring significa que o gatilho foi atingido, mas ainda não houve impacto mensurável. Em issue significa que o evento já ocorreu e o plano de resposta está sendo executado. Closed significa encerrado com lição aprendida documentada. Se você não tiver esses quatro status, vai acabar criando campos extras genéricos que ninguém lê. O problema que eu mais vejo sendo repetido em várias empresas que consultei é o seguinte: a pessoa que preenche o registro de risco é diferente da pessoa que executa. Isso gera risco registrado em linguagem corporativa que não ajuda ninguém no chão de obra. Eu resolvi isso exigindo que todo risco com probabilidade maior que 0,3 e impacto maior que três na escala do time passasse por uma validação com quem vai executar. Não é revisão de gerente. É uma conversa de cinco minutos onde a pessoa confirma se o gatilho que você escreveu faz sentido no contexto real. Na maioria das vezes, o gatilho escrito pela liderança não corresponde ao gatilho que realmente dispara o problema. Isso por si só já reduz o retrabalho em cerca de 20 por cento ao longo do projeto. Quanto a questões, o erro mais comum é deixar o registro virar um cemitério de itens encerrados sem feedback. Eu mantenho uma regra simples: qualquer questão que permaneça aberta por mais de 14 dias sem atualização deve ser escalada automaticamente para o próximo nível de responsabilidade. Sem exceção. Isso evita que coisa importante fique presa em caixinhas de e-mail ou planilhas que ninguém abre.

Uma ferramenta que funciona razoavelmente bem para isso é um registro básico em formato de tabela com colunas fixas. Eu recomendo o seguinte conjunto mínimo: ID, título, tipo, categoria, probabilidade, impacto, classificação, dono, gatilho, plano de mitigação, plano de contingência, status, data de criação, data de atualização, data de fechamento, link para evidência e nota de rodapé. Se a tabela tiver mais colunas do que isso, você vai ter campos que ninguém preenche e o registro vira lixo rapidamente. Não adianta nada ter uma ferramenta sofisticada se o processo de atualização não estiver claro. Eu defino um ritual mensal de revisão onde cada item com status opened ou in monitoring precisa ter pelo menos uma linha de atualização. Se não houver atualização, o item volta para o dono com um prazo de 48 horas. Isso parece burocrático, mas na prática reduz o tempo gasto com revisões porque você não precisa vasculhar a lista toda. Você foca apenas nos itens que precisam de atenção. Também é importante falar sobre métricas. As únicas que realmente importam são duas: taxa de conversão de risco para questão e tempo médio de fechamento de questão. Se a taxa de conversão estiver subindo ao longo do projeto, isso indica que seu registro estava subestimando a realidade. Se o tempo médio de fechamento de questão estiver crescendo, significa que seu fluxo de resposta está quebrado em algum ponto. Ambas as métricas devem ser revisadas trimestralmente, não apenas no encerramento do projeto.

Há uma limitação séria nesse modelo que as pessoas raramente mencionam. Ele funciona bem para riscos quantificáveis, ou seja, aqueles em que você consegue atribuir probabilidade e impacto com base em dados históricos ou estimativas técnicas. Riscos estratégicos, riscos de mercado, riscos regulatórios muitas vezes não se encaixam nessa estrutura porque a probabilidade é subjetiva demais e o impacto depende de variáveis externas que você não controla. Nesses casos, o registro vira um exercício de opinião disfarçado de análise. O workaround que eu uso é separar esses riscos em uma categoria distinta chamada macro riscos, com tratamento diferente: revisão semestral, dono de alto nível e foco em sinalização, não em plano de ação detalhado. Se você está começando agora e quer algo prático, comece com uma planilha simples. Não precisa de software caro. Precisa de disciplina. Preencha todos os campos obrigatórios desde o início. Não deixe campo vago. Atualize mensalmente. Quando algo der errado, converta o risco para questão imediatamente e documente o que aconteceu. No final, revise a taxa de conversão e o tempo de fechamento. Se os números não melhorarem após três ciclos de revisão, seu processo está quebrado e precisa de ajuste, não de mais ferramentas.