Um lançamento de solução SaaS entra em operação na noite de sexta-feira. Na manhã de sábado, os clientes não conseguem fazer login, a fila de suporte dispara e a página de status do fornecedor indica uma interrupção parcial. O patrocinador do projeto questiona por que a gestão de riscos não detectou isso.
Antes de atualizar o registro de riscos, é preciso responder a uma pergunta mais difícil: houve um sinal de risco real sobre o qual se poderia ter agido, ou você está transformando a análise a posteriori em atribuição de culpa? Esta lição estabelece uma abordagem alinhada à governança para distinguir sinais previsíveis de surpresas reais, classificar as descobertas e definir onde a IA pode ajudar, sem permitir que ela assuma o papel de tomadora de decisões.
Para começar, analise o incidente como uma linha do tempo, e não como uma conclusão. Identifique quais informações estavam disponíveis na ocasião, quem as detinha e o que um gerente de projetos competente poderia ter feito com elas.
Um erro comum é rotular qualquer resultado negativo como previsível. Isso passa uma sensação de responsabilidade, mas leva as equipes a documentar excessivamente riscos de baixo valor e a ignorar os poucos sinais que realmente importam.
Durante uma interrupção de serviço, quatro tipos diferentes de declarações tendem a se misturar, e as respostas da IA também as misturarão, a menos que você imponha regras.
Um risco é um evento futuro incerto que, se ocorrer, afeta os objetivos. Exemplo: Limites de taxa (rate limits) do serviço de autenticação de um fornecedor sob carga de pico durante o fim de semana de lançamento.
Um problema (issue) é uma questão atual que já ocorreu. Exemplo: Usuários estão recebendo erros 500 ao tentar fazer login agora.
Uma premissa é algo que você trata como verdadeiro para fins de planejamento, mas que pode ser falso. Exemplo: O fornecedor manterá os níveis atuais de capacidade ao longo do trimestre.
Uma dependência é uma entrega ou condição externa de que seu projeto necessita. Exemplo: O fornecedor concluir a janela de manutenção planejada antes da sua migração final (cutover).
Pergunta de previsão: Qual classificação incorreta causa o pior atraso no escalonamento durante uma interrupção de serviço?
Agora, pratique a aplicação correta desses rótulos, uma vez que seu processo de governança depende de uma classificação consistente antes da priorização.
Um instinto equivocado é classificar tudo como risco, pois isso mantém as opções em aberto. A consequência é que problemas reais não são assumidos nem resolvidos, e premissas nunca são validadas.
Se a sua prática de gestão de riscos precisa passar por auditorias, você não pode depender de uma lista informal em um chat. Você precisa de artefatos que demonstrem um raciocínio consistente e o histórico de decisões.
Uma taxonomia de riscos é um conjunto estruturado de categorias usado para agrupar riscos, garantindo a consistência dos relatórios entre projetos. Isso mitiga problemas como, por exemplo, um gerente de projeto registrar “risco de fornecedor” enquanto outro registra “confiabilidade de terceiros”, impedindo a consolidação de tendências.
Um registro de riscos é a lista controlada de riscos identificados e seus respectivos dados de gestão. A governança geralmente exige campos específicos, como ID do Risco, Descrição do Risco, Causa, Evento, Impacto, Probabilidade, Pontuação de Impacto, Exposição, Responsável pelo Risco, Estratégia de Resposta, Ações de Resposta, Data Prevista, Status, Gatilhos e Última Revisão. O rastro de auditoria é obtido ao demonstrar o que foi alterado, quando e por quem.
Pergunta para reflexão: qual campo ausente no registro torna mais difícil provar que você realmente gerenciou o risco, em vez de apenas registrá-lo?
Compare o que uma lista informal não consegue comprovar com o que um registro sob governança é capaz de demonstrar.