Um risco é algo que pode acontecer e prejudicaria o projeto se o fizesse. Gerenciamento de risco é identificar essas ameaças cedo e decidir o que fazer com elas antes que elas o atinjam. A percepção barata: os problemas são muito mais fáceis de lidar quando você pensou sobre eles com antecedência.
Uma ferramenta simples e amplamente utilizada para rastrear ameaças e itens do projeto:
R — RISKS → might happen, would cause harm (manage proactively)
A — ASSUMPTIONS → things we're taking as true (validate them)
I — ISSUES → risks that have already materialized (deal with now)
D — DEPENDENCIES → things we rely on from others (track them)
For each risk, score:
LIKELIHOOD (how probable?) × IMPACT (how bad?)
→ focus effort on high-likelihood, high-impact risks
AVOID → change the plan so the risk can't occur
MITIGATE → reduce its likelihood or impact
TRANSFER → shift it (insurance, vendor SLA)
ACCEPT → live with it, but have a fallback ready
Um projeto depende de uma API de terceiros que é nova e não comprovada. Risco: pode não ter desempenho. Probabilidade média, impacto alto. Mitigação: teste-a cedo, crie uma abstração para que você possa trocar provedores e tenha um plano de contingência. Agora uma incógnita é um risco gerenciado com um plano.
Tratar o gerenciamento de risco como uma lista de verificação única de inicialização. Os riscos evoluem — revise o registro RAID regularmente e adicione novos conforme surgem.
Os riscos não gerenciados se tornam crises, geralmente no pior momento possível próximo a um prazo.
O custo de lidar com um risco mais cedo é mínimo em comparação com combater um incêndio depois que ele nos atinge.
Nomear riscos em voz alta também constrói confiança — as partes interessadas preferem "aqui está o que poderia dar errado e nosso plano" em vez de silêncio confiante seguido por uma surpresa desagradável.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar