Modelo de Log RAID Permalink

Traduzido por IA
· Ver em inglês

Use este Modelo para gerenciar um log RAID no Quire: mantenha riscos, premissas, problemas e dependências em um único lugar, classifique-os por impacto na Exibição de tabela e realize uma revisão semanalmente que realmente fecha as coisas.

Você pode visitar o projeto Log RAID e Duplicar para seu workspace, sem precisar construir tudo do zero.

Você também pode explorar mais modelos prontos para usar para acelerar seu fluxo de trabalho.

Entendendo os Logs RAID

RAID significa Risks, Assumptions, Issues and Dependencies (Riscos, Premissas, Problemas e Dependências). Um log RAID é o registro contínuo dos quatro: o que pode dar errado, no que você está apostando sem ter verificado, o que já deu errado e o que você precisa de pessoas de fora da equipe.

A maioria das equipes acompanha parte disso em algum lugar. Muito poucas guardam as quatro categorias em um único lugar, e é aí que está o valor. Um código orçamentário faltando parece um pequeno problema administrativo até você perceber que é por isso que o fornecedor não libera as credenciais, que é por isso que o acordo da semana de lançamento ainda está por assinar. Uma causa raiz, três listas separadas, ninguém as conectando.

O log está organizado em cinco seções, com um marco fixado no topo para que todas as datas abaixo sejam lidas em relação ao prazo que importa.

seções do Modelo de log RAID para riscos premissas problemas e dependências no Quire


Quatro seções contêm as próprias Categorias. A quinta, governança RAID, contém a cadência de revisão, que é a parte que decide se o log sobrevive além do segundo mês. Vinte e uma entradas de exemplo são fornecidas preenchidas, para que você possa ler o formato de uma boa entrada antes de substituí-las pelas suas.

Log RAID ou Registro de Riscos

O Quire inclui ambos, e eles respondem a perguntas diferentes. Um registro de riscos é um instrumento aprofundado para uma categoria: uma matriz 5x5, pontuações numéricas de risco, cinco estratégias formais de resposta e uma cadência de governança, tudo direcionado apenas ao risco. Um log RAID é um instrumento mais superficial para quatro categorias, avaliando o risco apenas com probabilidade e impacto, mas cobrindo as premissas e dependências que um registro não contempla.

Use o log quando quiser um único lugar para tudo que pode descarrilar o projeto. Use o registro quando a gestão de riscos é o trabalho principal e a avaliação precisa ser defensável. Usar os dois simultaneamente é comum, com o log como registro de trabalho e o registro como artefato formal.

O Modelo inclui um Documento que cobre a configuração, as regras de Categoria e os modos de falha a evitar.

como usar este Documento de log RAID dentro do Modelo do Quire


Um segundo documento contém a pauta de revisão semanalmente, para que quem conduz a reunião não esteja inventando a ordem de trabalhos na manhã do dia.

Distinguindo as Quatro Categorias

As categorias se confundem constantemente, e uma discussão sobre onde algo pertence é uma ótima forma de desperdiçar os primeiros dez minutos de uma revisão. Quatro testes resolvem quase tudo.

Categoria Tempo Pergunta que responde Teste
Risco Futuro, incerto O que pode dar errado? Você consegue escrever como “se X, então Y”?
Premissa Presente, não verificado Em que estamos apostando? Você ficaria surpreso se se revelasse falso?
Problema Presente, certo O que está dando errado agora? Já aconteceu?
Dependência Futuro, de outra pessoa O que precisamos de outros? A próxima ação está fora da sua equipe?

Três regras resolvem o resto.

  1. Um risco que se materializa deixa de ser um risco. Mova-o para Problemas e feche o risco com uma nota indicando para onde foi, em vez de deixá-lo aberto nos dois lugares.
  2. Uma premissa que se revela falsa não é apenas errada — ela tem uma consequência. Feche a premissa e registre essa consequência como um risco ou um problema.
  3. Uma dependência que você parou de perseguir é um risco. Reavalie-a na limpeza mensal.


A entrada de exemplo A-01 no modelo é o exemplo prático da segunda regra, conectada ao problema que produziu.

Lendo o Log na Exibição de Tabela

A Exibição de tabela está disponível apenas nos planos Professional, Premium e Enterprise. Mais informações estão disponíveis em nossa página de preços.

A Exibição de tabela é o log RAID propriamente dito. Ela coloca cada campo Personalizado ao lado da entrada, e ordenar por Impacto transforma o topo da lista na pauta da reunião.

log RAID na exibição de tabela do Quire mostrando as colunas de ID RAID, tipo, probabilidade, impacto e última revisão


Sete campos sustentam o log.

Campo O que faz
ID RAID Um identificador estável como R-01 ou D-05, para que as pessoas possam citar uma entrada em uma reunião sem ler o título. Nunca reutilize um número, mesmo depois de uma entrada ser fechada.
Tipo Duplica a seção de forma intencional. As seções organizam a lista; o Tipo é o que permite filtrar, agrupar ou extrair uma Categoria de um portfólio.
Probabilidade Apenas para riscos. Os problemas já aconteceram, então a coluna fica vazia para eles.
Impacto Aplica-se a tudo. É a coluna pela qual se ordena e a que decide o que é escalado.
Criado em Quando a entrada foi registrada.
Última Revisão O campo que expõe o descuido. Ordene por ele na limpeza mensal e trabalhe a partir dos mais antigos.
Depende de Identifica a equipe, o fornecedor ou a pessoa responsável. Usado principalmente em dependências, mas útil em qualquer entrada bloqueada fora do seu controle.

“Criado em” e “Última Revisão” parecem apenas burocracia. Uma entrada criada em março, revisada em abril e ainda aberta em setembro não está sendo gerenciada, e essas duas datas são a única forma de esse fato se tornar visível sem que alguém o perceba por acidente.

Nota: Se você se encontrar preenchendo a Probabilidade em um problema, provavelmente é um risco que não foi reclassificado. Os problemas já aconteceram, portanto sua probabilidade é de cem por cento.

Oito Tags atravessam todas as quatro categorias: Orçamento, Cronograma, Técnico, Escopo, Cliente, Fornecedor, Pessoas e Conformidade. Elas respondem a uma pergunta diferente do Tipo, que é de onde veio a entrada e não que tipo de coisa é.

Escrevendo uma Entrada que Vale a Pena Guardar

A diferença entre um log RAID útil e um artefato de conformidade está quase inteiramente em como as entradas são escritas. Cada entrada de exemplo no modelo segue a mesma estrutura em quatro partes.

uma entrada de risco do log RAID no Quire mostrando a declaração se-então, o impacto, a resposta e o gatilho


A descrição abre com uma declaração se X, então Y, depois enuncia o impacto se acontecer em unidades que alguém valoriza, depois nomeia a resposta e por fim indica o gatilho a observar. O trabalho de mitigação fica pendente da entrada como subtarefas, para que o plano e o registro fiquem no mesmo lugar.

Cinco regras fazem a diferença.

  • Escreva os riscos como causa e efeito. “Atraso do fornecedor” é uma preocupação. “Se o fornecedor perder 6 de agosto, os testes de autenticação começam sem credenciais de produção e os testes atrasam duas semanas” é algo sobre o qual uma equipe pode agir.
  • Dê um gatilho a cada risco. O ponto observável em que ele deixa de ser hipotético. Sem ele, a escalada acontece tarde e por intuição.
  • Nomeie a resposta. Evitar, mitigar, transferir ou aceitar. “Monitorar” não é uma resposta, é uma forma de escrever “ainda não decidimos”.
  • Escreva o impacto em unidades que alguém valoriza. semanas, dinheiro, clientes, reputação. “Alto impacto” não diz nada a um patrocinador.
  • Coloque uma data em tudo. Uma entrada sem Data limite nunca será trabalhada.


Atribua uma pessoa nomeada a cada entrada. Uma equipe nunca persegue nada, porque ninguém nela acredita que a perseguição é especificamente sua.

Acompanhando o Fluxo na Exibição de Quadro

A Exibição de Quadro agrupada por Estado mostra movimento em vez de inventário, o que é uma perspectiva diferente e mais honesta.

entradas do log RAID agrupadas por estado em um Quadro do Quire mostrando a coluna de escalado


Seis estados gerenciam o log.

Estado Use quando
Em aberto Registrado e com dono, ainda sem nada acontecendo.
Em andamento Alguém está trabalhando ativamente nisso.
Escalado Ultrapassou a equipe do projeto e precisa de uma decisão acima.
Aguardando resposta A bola está genuinamente no campo de outra pessoa.
Fechado Resolvido, encerrado ou não mais relevante.
Validado Uma premissa verificada e confirmada como verdadeira.

“Aguardando resposta” é o que ganha seu lugar. Sem ele, “Em andamento” tem que cobrir tanto “estou trabalhando nisso” quanto “mandei um e-mail há nove dias”, e esses dois precisam de acompanhamentos completamente diferentes.

Dica: Observe a coluna Escalado ao longo de algumas semanas em vez de lê-la uma vez. Se ela encher mais rápido do que esvazia, é um sinal de saúde mais confiável do que qualquer relatório de estado.

Obtendo Visões Transversais com Sublistas

No plano Free Subscription, você pode criar duas Sublistas por projeto, e este modelo inclui 4. Fique com as duas que sua equipe abre com mais frequência após Duplicar, ou atualize seu plano de assinatura para usar todas as quatro. Mais informações estão disponíveis em nossa página de preços.

As seções respondem à pergunta “que tipo de coisa é isso”. Quatro Sublistas respondem a perguntas que atravessam as quatro categorias de uma vez, que é onde manter um único log em vez de quatro começa a compensar.

  • Escalar agora reúne todas as entradas com impacto Crítico ainda abertas, independentemente da categoria. Este é o pacote para o comitê de diretoria. Se ultrapassar cerca de seis itens, o projeto está sendo observado e não gerenciado.
  • Aguardando outra pessoa é tudo cujo próximo movimento não é seu. Abra antes de cada chamada de estado e pressione os três primeiros.
  • Premissas não validadas é a lista que ninguém lê até ser tarde demais. Leia em voz alta uma vez por trimestre.
  • A cadeia do fornecedor é um exemplo prático em vez de um filtro.


Este último vale a pena abrir primeiro, porque mostra o argumento completo para um único log em quatro entradas.

a Sublista da cadeia do fornecedor rastreando uma causa raiz através de três categorias RAID no Quire


Uma ordem de compra não levantada é um problema. Ela bloqueia a aprovação do pedido pelas finanças, que é uma Dependência. Isso bloqueia a entrega de credenciais de produção pelo fornecedor, outra Dependência. E essa é a razão pela qual o acordo da semana de lançamento ainda está por assinar, registrado como um risco. Três categorias, uma causa raiz, visível apenas porque vivem no mesmo log. As entradas estão conectadas entre si com dependências de Tarefa reais, então a cadeia é imposta e não apenas descrita.

Mantendo o Log Honesto

Um log sem revisão é um Documento, não um processo. A Seção de governança contém quatro Tarefas recorrentes para que o ritmo fique no Cronograma em vez de depender de alguém se lembrar.

Cadência O que acontece
Semanalmente Uma revisão de 30 minutos ordenada por impacto. O topo da lista é a pauta.
Mensalmente Fechar entradas obsoletas e reavaliar os riscos em aberto. Um risco avaliado em março raramente está bem avaliado em julho.
Trimestralmente Revalidar as premissas. Esta é a revisão que todos pulam e a que captura mais problemas.
Conforme necessário Escalar os itens críticos para o comitê de diretoria.

Três modos de falha respondem pela maior parte dos logs RAID mortos, e vale a pena nomeá-los porque chegam silenciosamente.

  1. Vira um cemitério. Cinquenta entradas abertas, a maioria obsoletas, então as pessoas param de abri-lo. Uma entrada que ninguém tocou em dois meses ou não é real ou não tem dono.
  2. Tudo é de alto impacto. Se o log todo está vermelho, ele deixou de classificar qualquer coisa. Quatro entradas Críticas em vinte é um projeto plausível. Quatorze é um projeto em que ninguém pensou direito.
  3. Só é atualizado antes da reunião de diretoria. Nesse ponto se transformou de ferramenta de gestão em ferramenta de reporte.


Os três têm a mesma solução pouco glamorosa: uma breve revisão semanalmente e fechar entradas de forma agressiva.

Leia mais em nosso blog sobre como avaliar riscos e manter um registro vivo.


Perguntas Frequentes

O que é um log RAID?

Um log RAID é um único registro contínuo do que pode dar errado, no que você está apostando sem ter verificado, o que já deu errado e o que você precisa de pessoas de fora da equipe. Manter os quatro em um único lugar é o que permite ver que problemas aparentemente separados compartilham uma causa raiz.

O que significa a sigla RAID?

Risks, Assumptions, Issues and Dependencies (Riscos, Premissas, Problemas e Dependências). Também é expandida como Risks, Actions, Issues and Decisions, mais comum em trabalho de programa. O Modelo do Quire usa a primeira versão porque premissas e dependências são as duas Categorias que as equipes têm menos probabilidade de acompanhar em outro lugar.

Qual é a diferença entre um risco e um problema?

Tempo verbal e certeza. Um risco é futuro e incerto, escrito como “se X, então Y”. Um problema é presente e certo, porque já aconteceu. Quando um risco se materializa ele para de ser um risco, então mova-o para Problemas e feche o risco com uma nota indicando para onde foi.

Qual é a diferença entre um log RAID e um registro de riscos?

Um registro de riscos é um instrumento aprofundado para uma categoria, com uma matriz 5x5 e estratégias formais de resposta. Um log RAID é um instrumento mais superficial para quatro, e cobre as premissas e dependências que um registro não contempla. Muitas equipes usam os dois.

Quem é responsável pelo log RAID?

O gerente de projeto é responsável pelo próprio log, ou seja, pela cadência de revisão, pelo encerramento de entradas obsoletas e pelas escaladas. Cada entrada individual precisa de uma pessoa nomeada, nunca de uma equipe, porque uma equipe nunca persegue nada.

Com que frequência um log RAID deve ser revisado?

semanalmente para o log completo, cerca de 30 minutos ordenado por impacto. mensalmente para fechar entradas obsoletas e reavaliar riscos em aberto. Trimestralmente para revalidar premissas. O modelo contém as três como Tarefas recorrentes para que fiquem no Cronograma automaticamente.

O que deve conter uma entrada do log RAID?

Um ID estável como R-01, a categoria, uma classificação de impacto, um responsável nomeado, uma Data limite e uma resposta escrita. Os riscos também precisam de uma probabilidade e de um gatilho, que é o ponto observável em que o risco para de ser hipotético e alguém precisa agir.

Por que os logs RAID param de ser úteis?

Três modos de falha: o log vira um cemitério de entradas obsoletas, tudo fica marcado como alto impacto então nada é classificado, ou só é atualizado antes da reunião de diretoria. A solução para os três é uma breve revisão semanalmente e fechar entradas de forma agressiva.

Existe um Modelo de log RAID pronto para usar no Quire?

Sim. Visite o projeto Log RAID e Duplique para seu workspace e obtenha as quatro Seções de Categoria mais a governança, sete Campos Personalizados, seis estados, oito Tags, quatro Sublistas transversais e vinte e uma entradas de exemplo já configuradas.

Última Atualização em:

Por favor, entre em contato conosco se precisar de mais assistência.