Na manhã de terça-feira, o gerente de produto avisa que a data de lançamento está em risco. Perto do almoço, o líder de integração informa que o fornecedor alterou a API e a equipe precisará refazer parte do trabalho. No fim do dia, a equipe de QA pergunta quais testes podem ser descartados, já que o cronograma foi comprimido. O analista de segurança acrescenta que a janela reduzida de testes provavelmente fará com que as descobertas surjam após o congelamento do código (code freeze). Você é o gerente do projeto e precisa decidir entre manter o escopo, adiar a data ou aceitar uma redução na qualidade. A cada hora de espera, o custo da decisão final aumenta, pois as equipes continuam trabalhando com premissas diferentes.
Antes de preparar um slide de status, você precisa de uma distinção clara. Um risco é um evento futuro incerto que pode afetar os objetivos. Um problema (issue) é uma situação atual que já está ocorrendo. A alteração da API pelo fornecedor torna-se um problema assim que ocorre; a possibilidade de que isso acontecesse era, anteriormente, um risco. Este curso desenvolve o discernimento e os artefatos necessários para manter essa distinção clara e útil, utilizando um registro de riscos funcional, uma definição em página única de objetivos e apetite ao risco, declarações de risco claras com gatilhos e um monitoramento ágil, permitindo identificar incertezas cedo o suficiente para agir.
Para começar, analise a sequência de eventos e identifique o momento em que o projeto passou da incerteza para a realidade.
Quando as equipes discutem se algo é um risco que vale a pena monitorar, muitas vezes estão discutindo outra coisa. Elas estão discutindo o que o projeto visa otimizar, quais premissas podem ser mantidas e quais restrições são inalteráveis. Se esses pontos não estiverem claros, qualquer conversa sobre riscos terminará com conselhos vagos, como “fique de olho nisso”.
Uma estrutura prática cabe em uma única página e começa pelos objetivos. O objetivo de cronograma pode ser lançar o projeto até o final do trimestre. O objetivo de custo pode ser manter-se dentro de um orçamento fixo de fornecedor. O objetivo de qualidade pode ser não apresentar nenhuma falha crítica de segurança no lançamento. A partir daí, você lista as premissas que está considerando verdadeiras para o planejamento — como a manutenção da compatibilidade retroativa da API do fornecedor — e as restrições inegociáveis, como um prazo regulatório. Em seguida, você define o apetite ao risco, que é o nível de variação que o patrocinador tolera antes de esperar uma escalada do problema e uma decisão. Apetite não é o mesmo que otimismo; é um limite para a ação.
Um erro comum: o instinto equivocado de definir um apetite único e genérico, como “temos baixo risco”. Isso passa uma sensação de decisão firme. A consequência são concessões ocultas, nas quais a equipe protege o cronograma cortando testes sem a aprovação do patrocinador, ou protege a qualidade adiando a data de entrega sem informar a área de vendas.
Escolha níveis de apetite que condigam com o contexto do projeto, e não com suas preferências pessoais.