APRENDER. PRATICAR. EVOLUIR.Escrever uma incerteza que possa ser analisada
“Problema no batch” é demasiado vago para orientar uma resposta. No exemplo fictício, o fornecedor ainda não confirmou o envio do ficheiro até às 03h00; se chegar tarde, a reconciliação pode ultrapassar o cut-off das 06h00. A condição conhecida, o acontecimento incerto e o objetivo afetado ficam separados. Não precisas de inventar uma probabilidade para registar a preocupação e pedir análise. Se o ficheiro já chegou tarde hoje, trata essa ocorrência como issue ou incidente; mantém um risco distinto de repetição futura se fizer sentido. Uma lista de causas sem eventos pode esconder o que é necessário decidir. Uma lista só de impactos também não mostra onde atuar.
Procurar nos pontos de passagem
Percorre o serviço desde a entrada do ficheiro até à confirmação do negócio. Em cada passagem, pergunta por dono, horário, versão, formato, acesso e condição de aceitação. Uma equipa conhece WebSphere; outra conhece o calendário do fornecedor e uma terceira fecha a posição de fundos. Se só a equipa de desenvolvimento participou, o registo pode não conter dependências de operação noturna. Confronta entrevistas com logs e documentação sem tratar uma única fonte como prova completa. Para assuntos sensíveis, contributos individuais antes da reunião podem revelar preocupações que não surgem diante de uma chefia. A facilitação deve permitir discordância fundamentada e registar o que continua por confirmar.
Testar pressupostos e distinguir restrições
A frase “o fornecedor estará disponível no domingo” é um pressuposto enquanto não tiver confirmação aplicável. O cut-off das 06h00 definido no exercício é uma restrição. O risco pode ser não conseguir recuperar antes desse limite se o apoio faltar. Regista para cada pressuposto a base, quem o valida, até quando e o efeito se for falso. Verifica cadeias: a equipa de base de dados pressupõe que rede terá terminado; rede pressupõe acesso aprovado por segurança. A aparente disponibilidade resulta de promessas circulares. Um mapa de dependências ajuda a encontrar o ponto ainda sem compromisso real. Não convertas uma data desejada em confirmação de capacidade.
Usar categorias sem substituir os eventos
A RBS organiza fontes como tecnologia, pessoas, fornecedores e ambiente externo. Usa-a para procurar lacunas e adaptar perguntas ao serviço; não é uma lista fechada que prova cobertura total. No registo, mantém o evento concreto e liga-o à categoria. Se três equipas registam a mesma falha de fornecedor com nomes diferentes, relaciona ou consolida as entradas preservando objetivos e donos; não somes automaticamente três vezes a mesma consequência. Um fornecedor pode gerar eventos distintos que não devem ser fundidos apenas por partilharem origem. Inclui oportunidades: uma alteração de calendário pode permitir ensaio adicional e reduzir incerteza, mas o benefício depende de confirmar acesso e capacidade.
Tornar o registo observável e revisável
Completa a entrada com dono, período de exposição, fonte, trigger e próximo passo. “Monitorizar o fornecedor” não identifica um sinal. No caso fictício, ausência de confirmação do ficheiro até às 02h30 desencadeia contacto com o responsável, antes da hora esperada de entrega; o tempo precisa de ser compatível com as respostas disponíveis. Se os logs mostram três envios atrasados mas omitem períodos sem telemetria, não concluas que só houve três problemas. Indica a lacuna e planeia obter dados. Entrega duas ameaças e uma oportunidade com pressupostos verificáveis e ligação ao objetivo. Faz a revisão novamente quando o desenho ou os intervenientes mudarem, mantendo o histórico de origem das entradas.
Oficina: transforma “risco de fornecedor” numa entrada com condição, evento, impacto, dono, sinal às 02h30 e validação pendente. Acrescenta uma oportunidade de ensaio numa janela libertada. Marca o atraso já observado como issue separado e liga o risco de recorrência.
Armadilhas comuns
Registar só categorias, tratar incidentes observados como hipóteses, aceitar pressupostos circulares, contar duplicados como exposições independentes ou confundir falta de logs com ausência de ocorrências.
Tópicos relacionados: Contexto, apetite e direitos de decisão · Organizar pessoas, cadência e recursos · Identificar eventos, pressupostos e oportunidades
Cada entrada deve permitir compreender o que pode acontecer, porquê, a que objetivo e com que evidência. A identificação continua ao longo do projeto; exemplos e horários são fictícios.
Referência: Risk identification · PMI-RMP five-domain ECO, updated-2024 public document