Gerenciamento de riscos do projeto: registro, análise e estratégias de resposta

Todo projeto é um conjunto de decisões tomadas sem informação completa, o que significa que a incerteza não é uma característica infeliz de projetos mal conduzidos: ela é a matéria-prima do trabalho. O gerenciamento de riscos é o que transforma essa incerteza, que de outro modo simplesmente acontece com você, em algo que você já avaliou, precificou e atribuiu a alguém.

A maioria das organizações faz isso mal, e de um jeito específico e fácil de reconhecer. Um registro é produzido na iniciação, preenchido com vinte riscos plausíveis, apresentado uma vez e nunca mais aberto, até que um deles acontece e alguém observa que ele estava na lista. Isso é documentação, não gerenciamento. Este guia trata da versão que muda decisões: o que identificar, como analisar com rigor suficiente para dimensionar uma reserva, que respostas existem e como manter tudo vivo.

Risco, problema, premissa, dependência

Quatro palavras são usadas como sinônimos, mas significam coisas diferentes, e cada uma exige uma ação diferente.

A distinção importa porque um registro que mistura essas categorias gera revisões confusas. O hábito mais valioso é tratar premissas como riscos não gerenciados: toda premissa de planejamento escrita em um termo de abertura deveria ter uma ação de validação, porque uma premissa não validada é um risco que você ainda não pontuou.

Uma disciplina útil para redigir os enunciados de risco é o formato causa-evento-efeito. “A integração pode falhar” não permite nenhuma ação. “Como a fila de certificação do provedor de pagamentos está hoje em seis semanas, existe o risco de que a certificação seja concluída depois da data de lançamento planejada, o que atrasaria a entrada em produção e a receita em até dois meses” nomeia algo sobre o qual se pode agir, fornece um gatilho para monitorar e declara um impacto que pode ser dimensionado.

Identificando riscos

É na identificação que se define a qualidade de tudo o que vem depois, e um workshop com cinco pessoas listando o que as preocupa vai encontrar, com certeza, os riscos óbvios e deixar passar os caros. Combine várias técnicas.

• Checklists estruturados, baseados em projetos anteriores e no registro de lições aprendidas da organização. A fonte mais barata de bons riscos é o que deu errado da última vez.
• Análise de premissas. Percorra o termo de abertura e o plano, liste cada premissa e pergunte o que acontece se ela for falsa.
• Decomposição. Percorra a estrutura analítica do projeto (EAP) e a arquitetura e pergunte, em cada nó, o que pode dar errado ali.
• Entrevistas com pessoas de fora da equipe. O pessoal de operações, o suporte, quem operava o sistema anterior, os engenheiros do fornecedor. Eles conhecem modos de falha que a equipe de entrega nunca viu.
• Pre-mortem. Peça à equipe para imaginar que se passou um ano e que o projeto fracassou de forma retumbante, e depois para contar como isso aconteceu. A técnica revela, com segurança, riscos que ninguém levantaria em uma reunião normal, porque levantá-los soa como deslealdade.
• Categorias. Técnica, externa, organizacional, comercial, regulatória, pessoas, dados. As categorias impedem que uma equipe técnica produza vinte riscos técnicos e nenhum outro.

Mire em cobertura, não em volume. Quarenta riscos que ninguém revisa são piores do que doze examinados todo mês.

O registro

Um registro justifica sua existência quando todas as colunas são usadas. Estes campos são o mínimo para funcionar.

Três desses campos costumam ser omitidos, e são justamente os que tornam o registro operacional. O responsável deve ser uma pessoa com autoridade para agir: um risco cujo responsável é “a equipe de entrega” não é de ninguém. O gatilho é a condição observável que indica que o risco está se materializando, e defini-lo com antecedência é o que permite iniciar a resposta a tempo, e não depois do estrago. E o risco residual obriga você a declarar o que sobra depois da resposta, que é o número que deveria orientar a reserva.

Análise qualitativa

A análise qualitativa prioriza os riscos rapidamente por meio de pontuações relativas. Probabilidade e impacto são avaliados, cada um, em uma escala (cinco níveis é o mais comum) e combinados em uma pontuação que direciona a atenção.

Duas regras mantêm o exercício honesto. Defina as escalas nos termos da organização antes de pontuar: “impacto alto” deve significar uma faixa definida de dinheiro, um número definido de semanas ou uma categoria nomeada de dano à reputação, e não uma impressão. E pontue o impacto separadamente para cada objetivo quando eles divergirem: um risco que custa pouco, mas atrasa o lançamento em um mês, não é o mesmo que um que custa muito caro e não atrasa nada.

A matriz é uma ferramenta de triagem, não uma resposta. Sua fraqueza conhecida é apagar a diferença entre uma catástrofe pouco provável e um incômodo muito provável que por acaso têm a mesma pontuação; por isso, trate todo risco de impacto muito alto como algo que exige resposta, diga a aritmética o que disser.

Análise quantitativa

Quando a decisão precisa de um número (quanto manter de reserva, se vale aceitar uma proposta a preço fixo, se uma mitigação compensa o custo), as técnicas quantitativas colocam dinheiro na mesa.

O valor monetário esperado (EMV, expected monetary value) é a probabilidade multiplicada pelo impacto, somada para todos os riscos. Ameaças entram como custos positivos e oportunidades como custos negativos.

ID   Risk                                  P      Impact     EMV
R-07 Certification later than planned     0.40   120,000    48,000
R-11 Migration data quality worse         0.50    90,000    45,000
R-14 Performance target missed            0.15   200,000    30,000
R-02 Lead engineer unavailable            0.20    60,000    12,000
O-03 Reuse of existing auth component     0.60   -40,000   -24,000
                                                            -------
Total expected monetary value                               111,000

Esse total é um ponto de partida defensável para uma reserva de contingência dentro da linha de base de custos, muito melhor do que um percentual fixo, porque pode ser rastreado até riscos específicos e diminui à medida que eles são eliminados. Também é uma ferramenta de decisão: uma mitigação que custa 20.000 e reduz pela metade a probabilidade de R-11 elimina 22.500 de valor esperado e vale a pena; uma que custa 60.000 não vale.

A análise de sensibilidade classifica as incertezas por importância. Varie cada entrada dentro de sua faixa plausível mantendo as demais fixas e represente o efeito sobre o resultado em um gráfico de barras horizontais ordenado por tamanho: o diagrama de tornado. Seu valor está em mostrar que, de trinta entradas incertas, três respondem pela maior parte da variância, e é ali que o esforço de análise deve ficar.

A simulação de Monte Carlo modela o projeto inteiro de forma probabilística. Atribua a cada atividade uma faixa de duração e a cada item de custo uma distribuição, rode milhares de simulações e leia o resultado em percentis: 80% de chance de terminar até determinada data, 90% de chance de ficar abaixo de determinado custo. É muito mais informativo do que um plano com valor único e expõe um efeito que o cronograma determinístico esconde: onde vários caminhos paralelos convergem, a probabilidade de todos estarem no prazo é bem menor do que a de qualquer um deles estar, de modo que os pontos de convergência são sistematicamente mais arriscados do que sugere um cálculo do caminho crítico.

Respostas

Depois de pontuar um risco, escolha uma estratégia. Cinco se aplicam a ameaças, e outras cinco as espelham para oportunidades.

Toda resposta traz duas consequências. O risco residual é o que sobra depois, e precisa ser registrado e aceito explicitamente por alguém: uma mitigação que reduz a probabilidade de 40% para 15% não eliminou o risco. O risco secundário é o que a própria resposta cria: transferir trabalho para um fornecedor introduz risco de fornecedor; adicionar um cache para resolver um problema de desempenho introduz defeitos de dados desatualizados. Os dois devem entrar no registro.

Prefira mitigações que produzam evidências. Um risco técnico sobre uma integração não comprovada é mais bem tratado com um spike com prazo fixo, que funciona ou não, do que com um parágrafo de boas intenções; é a mesma abordagem que sustenta uma boa estratégia de automação de testes, em que a cobertura automatizada é uma mitigação permanente contra o risco de regressão.

Monitoramento e risco na entrega iterativa

O monitoramento é a parte que se deteriora. Mantenha-o barato o suficiente para sobreviver: uma revisão curta ao fim de cada iteração ou todo mês, em que cada risco aberto é confirmado, repontuado se algo mudou e encerrado se não puder mais ocorrer. Acompanhe os gatilhos, e não os riscos: um gatilho disparado significa que a resposta começa hoje. Novos riscos chegam continuamente, vindos de solicitações de mudança, notícias de fornecedores e descobertas técnicas, então o registro cresce e encolhe em vez de ser escrito uma única vez.

A entrega iterativa muda mais a forma do gerenciamento de riscos do que sua essência. Iterações curtas já são, em si, uma mitigação: limitam a quantidade de trabalho que pode ser construída sobre uma premissa errada e geram evidências a cada duas semanas, e não só no fim. Ordenar o backlog por risco, construindo a integração incerta na primeira iteração e não na última, converte cedo incerteza em conhecimento; é por isso que itens arquiteturalmente significativos devem ser antecipados mesmo quando seu valor de negócio é baixo. O framework Scrum não oferece nenhum artefato de risco, então as equipes que precisam de um costumam manter um registro leve ao lado do backlog e revisá-lo no refinamento.

O que não muda é a necessidade de responsabilidade explícita e de uma conversa honesta sobre o que pode dar errado. Uma equipe que trata cada problema só quando ele aparece não está sendo ágil; está apenas despreparada, com um ciclo de feedback mais curto.

Principais pontos

• Separe riscos, problemas, premissas e dependências: cada um exige uma ação diferente, e premissas não validadas são simplesmente riscos não pontuados.
• Escreva os enunciados no formato causa-evento-efeito, para que cada entrada traga um gatilho a monitorar e um impacto que possa ser dimensionado.
• Um registro funciona quando tem um responsável individual, um gatilho definido e um risco residual declarado; sem esses três elementos, é só documentação.
• A pontuação qualitativa serve para triagem, mas defina antes as escalas em dinheiro e semanas, e nunca deixe a matriz rebaixar uma catástrofe pouco provável.
• O valor monetário esperado fornece um valor de contingência rastreável e mostra quais mitigações compensam o custo; Monte Carlo revela o risco nos pontos de convergência que um plano determinístico esconde.
• Toda resposta deixa um risco residual e costuma criar um secundário; registre os dois e prefira mitigações que produzam evidências, não intenções.