← PMI-RMP: gerir incerteza do projeto à produção
15 / 19 · 75 MIN

Dossiê de decisão e passagem a APS

Constrói um dossiê de risco utilizável no go-live, com evidência delimitada, responsabilidades e condições de reavaliação.

Separar intenção, evidência e autorização

Uma resposta aprovada ainda pode não estar implementada; uma resposta implementada pode não ter sido testada; um teste aprovado pode não cobrir o âmbito atual. Mantém estes estados separados no dossiê. Para cada condição obrigatória, indica a evidência, o ambiente, a versão, a data, o resultado e a pessoa que validou a sua aplicabilidade. Uma exceção de risco deve identificar a autoridade, o âmbito, as condições e a validade. Um parecer de terça-feira para uma configuração não cobre automaticamente uma alteração feita na sexta-feira. Quando a evidência está ausente, marca desconhecido ou pendente, não sucesso. O relatório deve mostrar qual decisão continua bloqueada, quem pode resolver a lacuna e até quando a informação é necessária.

Avaliar a operação completa

A passagem a APS inclui mais do que acesso ao runbook. Confirma quem recebe o alerta, quem pode executar recuperação, que fornecedor responde na janela e como se prova a reconciliação depois da mudança. Se a desativação de um componente elimina a alternativa de recuperação, essa dependência precisa de ser avaliada antes da desativação. Uma poupança de infraestrutura pode criar uma exposição diferente durante a estabilização. Não confundas aceitação da entrega com eliminação de risco operacional. Liga o registo do projeto ao responsável que acompanha a exposição remanescente e identifica o evento que permite encerrar essa ligação. Define condições de reabertura: alteração de versão, perda de cobertura ou falha de teste podem exigir nova decisão mesmo depois de um marco aprovado.

Usar uma verificação didática limitada

O exemplo de código verifica apenas cinco condições fictícias: âmbito confirmado, recuperação ensaiada, reconciliação confirmada, suporte preparado e autoridade registada. Exige valores booleanos verdadeiros, não textos como “sim”, e uma validade estritamente posterior ao momento indicado. O resultado hold lista condições pendentes; ready-for-review significa apenas que o pacote sintético passou estas verificações. Não autoriza produção, não substitui especialistas e não valida que uma prova é verdadeira. No exercício, muda uma condição, omite outra e coloca a validade no limite. Explica por que cada resultado muda. Um validador pode detetar um campo ausente e continuar incapaz de detetar um teste pouco representativo. A revisão humana precisa de verificar conteúdo, contexto e autoridade real.

Entregar uma decisão que outra equipa consegue usar

Conclui a oficina com uma página de decisão e um anexo de evidência. A página deve indicar objetivo, restrições, exposição atual, alternativas admissíveis, recomendação condicionada, decisão pedida e prazo. O anexo liga cada afirmação ao seu suporte e assinala lacunas. Mantém ações, donos, triggers e datas de revisão acessíveis à equipa de operação. Usa um exercício de passagem: uma pessoa que não escreveu o dossiê explica o que faria perante um trigger e onde encontra autorização e contactos. Uma resposta diferente da intenção revela uma lacuna a corrigir. A conclusão da oficina exige revisão do artefacto, não apenas acertar nas perguntas. Na plataforma, a avaliação automática treina decisões; a execução dessa revisão prática e a validação especializada continuam pendentes.

// Original synthetic workshop. No production action or real authorization.
function assess(packet) {
  const fields = ['scopeMatched', 'restorationTest', 'reconciliation', 'supportReady', 'authority'];
  const pending = fields.filter(key => packet[key] !== true);
  if (!Number.isFinite(packet.now) || !Number.isFinite(packet.expiresAt) || packet.expiresAt <= packet.now) pending.push('validity');
  return { state: pending.length ? 'hold' : 'ready-for-review', pending };
}
const packet = { scopeMatched: false, restorationTest: true, reconciliation: true, supportReady: true, authority: true, now: 100, expiresAt: 130 };
console.log(JSON.stringify({ missingScope: assess(packet), ready: assess({...packet, scopeMatched: true}), expired: assess({...packet, scopeMatched: true, now: 130}) }));
NA PRÁTICA

Às 100 unidades de tempo do exercício, o pacote vence às 130. Recuperação, reconciliação, suporte e autoridade estão confirmados, mas o âmbito é desconhecido: o resultado é hold. Confirmar âmbito permite ready-for-review; chegar exatamente a 130 volta a impedir esse resultado.

Armadilhas comuns

Tratar campos preenchidos como prova verdadeira, prolongar uma exceção sem autoridade, encerrar risco ao fechar o ticket ou retirar recuperação antes de validar dependências.

Tópicos relacionados: Triggers, dados e dependências comuns · Decisões quantitativas e valor da informação · Evidência de eficácia e passagem para APS

Leva esta ideia contigo

Uma passagem útil combina evidência aplicável, limites de autorização e capacidade de execução. O estado automático apoia a revisão, mas não concede autorização de produção.

Criar conta

Referência: Collaborative tools and techniques to build the project risk plan · PMI-RMP five-domain ECO, updated-2024 public document

PMI-RMP® é uma marca registada de Project Management Institute, Inc. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por PMI. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.