Registro de problemas: o que é, como preencher e modelo em Excel
Como anotar o problema, a data de identificação, os dias em aberto, a origem, a ação corretiva e o status, com o caso de uma rede de farmácias em que quatro problemas vinham das mesmas mudanças de escopo
Por dois anos eu coordenei operações da MRS Logística em Lafaiete. Eu chefiava os inspetores, e cada inspetor chefiava um grupo de maquinistas. Numa ferrovia, problema de operação não espera reunião, e alguém precisa decidir na hora. O registro de problemas é a ferramenta que guarda o que fica depois dessa decisão.
Numa cadeia de três degraus, a informação sobe resumida. O maquinista conta ao inspetor, o inspetor conta ao coordenador, e a cada degrau o relato perde a data, a causa e o que já foi tentado. Sobra o efeito. Foi na MRS que eu vi o desdobramento de metas sair do presidente e chegar ao coordenador, e o caminho de volta, do problema até quem decide, pede a mesma disciplina no sentido contrário.
Projeto sofre do mesmo jeito, com uma diferença: ele tem data para acabar. Um problema que fica três semanas sem dono numa operação contínua custa três semanas. Num projeto de seis meses, pode custar o prazo final.
A ferramenta deste artigo é o M16 do Kit de Ferramentas para Gestão de Projetos, uma planilha da fase de monitoramento. Uma linha por problema real, já acontecido, com a data em que ele foi identificado, os dias em aberto calculados contra uma data de referência única, o impacto, a origem relacionada, a ação corretiva, o responsável e o status.
No kit, quem dá vida à planilha é uma rede de farmácias trocando de sistema de gestão. O registro de problemas dela tem 5 linhas em 18/08/2026, e 4 delas apontam para mudanças de escopo que entraram por fora do comitê. A mais antiga estava aberta havia 105 dias.
Daqui para a frente vêm as nove colunas, a fronteira entre problema, risco e mudança, a conta dos dias em aberto, a origem que guarda o rastro da causa, quatro folhas preenchidas com PDF e o M16 vazio para baixar. Uma nota de procedência antes: a rede de farmácias é um caso que a gente criou, na Voitto, para o kit. As três folhas restantes foram montadas para este artigo, e são igualmente ilustrativas.
O que é o registro de problemas
O registro de problemas é a planilha do projeto com uma linha para cada problema que já aconteceu. Ela guarda a data de identificação, o impacto, a origem em mudança ou risco, a correção, quem cuida dela e o status, e calcula os dias em aberto contra uma data de referência única.
A primeira instrução do M16 define o que entra por exclusão: problema real, já acontecido, e não risco nem mudança de escopo. Risco é o que pode acontecer, e mora na matriz de riscos. Mudança é o que se decidiu alterar no escopo, e mora no controle de mudanças. O registro de problemas fica com o que sobra: o efeito que já está atrapalhando a execução.
No kit, a folha pertence à fase de monitoramento, ao lado do status report, da curva S e do painel de indicadores do projeto. O guia do kit resume a fase como a leitura de como o projeto está indo de verdade, e diz que é ali que o efeito das mudanças fora do rito aparece primeiro. O painel mostra o desvio em número. O registro de problemas mostra o fato que explica o número.
Vale separar de uma coisa parecida. Tarefa difícil é trabalho previsto que exige esforço, e tem lugar no cronograma. Problema é o que não deveria estar acontecendo e está, e consome um tempo que estava reservado para outra coisa. A American Society for Quality descreve a solução de problemas a partir dessa separação entre sintoma e causa, e a folha do kit leva a mesma ideia para a rotina do projeto.
As nove colunas do registro de problemas no M16
A folha tem quatro instruções no topo e uma tabela de nove colunas. Seis você preenche. Uma, a dos dias em aberto, a planilha calcula. A tabela abaixo diz o que vai em cada uma e o erro que ela previne.
| Coluna | O que entra | O erro que ela previne |
|---|---|---|
| Problema | O fato, numa frase que outra pessoa consegue conferir | Linha que só faz sentido para quem viveu o episódio |
| Data de identificação | O dia em que o problema foi percebido | Problema que chega à reunião com semanas de idade escondidas |
| Data de referência | A data do relatório, preenchida só na 1ª linha | Cada linha contando dias até uma data diferente |
| Dias em aberto | Calculado: data de referência menos data de identificação | Idade estimada de cabeça |
| Impacto | Alto, Médio ou Baixo | Lista em que tudo parece igualmente urgente |
| Origem relacionada | O código E12 ou P07 de onde o problema veio | Perder o rastro da causa |
| Ação corretiva | O que está sendo feito para remover a causa | Problema registrado e esquecido |
| Responsável | Quem conduz a ação | Problema que todo mundo conhece e ninguém trata |
| Status | Aberto, Em tratamento ou Resolvido | Contagem de abertos que não corresponde ao que acontece |
Duas colunas merecem atenção desde a primeira linha. A data de identificação pede o dia da percepção, e não o dia em que alguém achou tempo de anotar. Se o registro só é atualizado na véspera da reunião, as duas datas se confundem e a idade real do problema some.
A outra é a origem relacionada. Ela é a coluna que o guia do kit nomeia no erro comum da ferramenta: registrar o problema sem citar a mudança de escopo ou o risco que o originou, perdendo o rastro da causa. Sem ela, o registro de problemas vira uma lista de queixas. Com ela, cada linha aponta para o documento onde a causa foi decidida ou prevista.
Problema, risco e mudança: onde cada coisa entra
Confundir os três documentos prejudica os três. A separação cabe numa frase: risco é o que pode acontecer, mudança é o que se decide alterar no escopo, e problema é o efeito que já aconteceu. O registro de problemas recebe dos outros dois pela coluna de origem.
Na prática, a dúvida aparece nas bordas. A tabela abaixo traz cinco situações do mesmo tipo de projeto e o lugar de cada uma.
| Situação | Onde entra | Por quê |
|---|---|---|
| O fornecedor pode não entregar a integração no prazo | Matriz de riscos | Ainda não aconteceu; tem probabilidade e impacto |
| A integração não foi entregue e o teste parou | Registro de problemas | Já aconteceu e está atrapalhando |
| Incluir um módulo excluído no termo de abertura | Controle de mudanças | É decisão sobre o escopo |
| O módulo incluído atrasou a entrega | Registro de problemas, com origem na mudança | É o efeito da decisão |
| Pode faltar gente se a rotatividade continuar | Matriz de riscos | É projeção, não fato |
A passagem de risco para problema é o momento mais importante e o menos ritualizado. Quando um risco se materializa, ele entra no registro de problemas com o código do risco na origem. Essa ligação permite contar, no encerramento, quantos riscos previstos de fato aconteceram. É o único jeito honesto de calibrar a gestão de riscos do próximo projeto.
No sentido contrário, um problema pode pedir mudança. Se a ação corretiva exige alterar escopo, prazo ou custo, ela passa pelo controle de mudanças, e a escolha fica no registro de decisões. O problema continua no registro até resolver, agora com a ação apontando para a mudança aprovada.
Dias em aberto e a data de referência única
A segunda instrução do M16 é a mais mecânica e a mais esperta: na data de referência do relatório, preencha só a primeira linha. Ela vira a data-base de todos os dias em aberto da tabela. A fórmula da coluna subtrai a data de identificação de cada linha dessa célula única.
O rodapé da folha explica o motivo: os dias em aberto leem da data de referência e não usam HOJE(). Parece detalhe técnico. Só que é dessa célula que depende a planilha e o relatório contarem a mesma história. Com HOJE(), o mesmo arquivo mostra números diferentes para quem abre na segunda e para quem abre na sexta, e o status report do dia 18 deixa de bater com a planilha anexada a ele. Com a data fixa, o registro de problemas vira uma fotografia datada, que pode ser comparada com a da semana anterior.
Há um efeito colateral da fórmula que a folha não avisa. Ela conta os dias de toda linha que tem data de identificação, inclusive as que já estão com status Resolvido. No caso do kit, uma linha resolvida aparece com 90 dias em aberto. O número diz há quanto tempo o problema foi identificado, e não quanto tempo ele ficou aberto.
Duas saídas funcionam. A simples é ler a coluna só nas linhas Aberto e Em tratamento, que é o que as folhas ilustrativas mais abaixo fazem no quadro de conferência. A completa é acrescentar uma coluna de data de encerramento e trocar a fórmula para parar nela. A segunda dá o tempo real de resolução, que é a medida que as lições aprendidas vão querer no fim.
Origem relacionada: o rastro da causa
A terceira instrução pede que a origem relacionada cite o código da mudança (E12) ou do risco (P07) que causou o problema, quando existir. O “quando existir” importa. Nem todo problema tem origem mapeada, e a linha que fica sem ela também tem algo a dizer.
Uma origem em branco diz que o problema não foi previsto na matriz de riscos nem nasceu de uma mudança registrada. Duas ou três linhas assim no mesmo tema pedem uma revisão da matriz, porque o projeto está levando golpes de um lado que ninguém mapeou. Nas folhas ilustrativas deste artigo, toda linha sem origem aparece escrita assim, sem origem mapeada, em vez de vazia.
A origem também mostra quando a lista inteira tem uma causa só. É o que acontece no caso do kit: quatro dos cinco problemas citam as mesmas mudanças, que trouxeram para dentro o que o termo de abertura deixava de fora. Lidas uma a uma, as linhas parecem falhas de execução, cada uma com a sua ação corretiva. Lidas pela origem, são o mesmo problema de governança aparecendo em quatro lugares.
A pergunta de controle da fase, no guia do kit, é exatamente essa: todo problema aberto cita a mudança ou o risco que o originou? Se a resposta é não, o status report vai explicar o atraso pela velocidade da equipe, e a armadilha da fase, segundo o mesmo guia, é procurar a causa ali sem olhar antes o histórico de mudanças de escopo do período.
Ação corretiva e status: quando o problema só foi sentido
A frase mais forte da folha está na quarta instrução: problema Aberto há muito tempo sem ação corretiva é sinal de que a causa raiz ainda não foi endereçada, só sentida. O registro de problemas não pede que tudo esteja resolvido. Pede que nada envelheça sem ação.
Meu livro, o Guia Prático Lean Seis Sigma Black Belt (Atlas), trata disso no capítulo “Relatório A3”. Na página 136, ao descrever a análise de causa raiz, eu escrevi que “se o problema for enfrentado imediatamente, somente serão tratados os sintomas”. O registro de problemas é onde essa diferença fica visível: uma ação corretiva que só contém o efeito deixa a linha voltando, semana após semana.
Por isso vale separar dois tipos de ação na mesma coluna. A contenção segura o efeito agora: reetiquetar a caixa na doca, mandar um plantonista para o turno da noite. A correção remove a causa: o fornecedor ajusta a etiqueta, a escala muda. Uma linha pode começar com contenção, mas só deveria ir para Resolvido quando a correção chegou. Quando a causa não é óbvia, os 5 porquês e o relatório A3 são o passo seguinte, e a correção ganha prazo e dono num plano de ação.
O livro volta ao tema no capítulo “Ferramentas de Controle”, na página 477, falando de ferramentas que permitem “responder proativamente a problemas antes que eles se tornem críticos”. O livro não trata da folha M16 em si, e eu não vou fingir que trata. O que ele sustenta é a lógica dela: registrar cedo, com dono e ação, para que o problema não chegue grande demais à reunião.
O caso do kit: cinco problemas, quatro com a mesma origem
A folha preenchida do kit é a da troca de ERP numa rede de farmácias, o mesmo projeto que atravessa todas as ferramentas do kit. A data de referência é 18/08/2026. São 5 problemas: 1 Aberto, 1 Em tratamento e 3 Resolvido, o que bate com a caixa do guia do kit, que fala em 2 ainda não resolvidos.
Leia a figura pela distância entre o círculo vazio e o cheio. O e-commerce entrou no escopo em 02/04, pela mudança CM-01, e o atraso só virou linha em 05/05: 33 dias depois. As 2 lojas novas levaram 12 dias da mudança ao problema, e os convênios, 13. Em nenhum dos três casos o problema foi antecipado no dia em que a mudança foi executada.
A quarta linha é a de maior impacto. O rollout da Onda 1, primeira etapa de um cronograma por ondas, previsto para 07/08, não foi concluído, e o problema foi identificado no dia seguinte, 08/08. A origem relacionada não aponta uma falha da equipe: aponta as três mudanças acumuladas, de CM-01 a CM-03. É a linha que o registro de problemas existe para produzir, porque ela leva a conversa para onde a causa está.
A quinta linha mostra o outro tipo de origem. A rotatividade de operadores de caixa exigiu novo treinamento em 3 lojas do piloto, e a origem é a matriz de riscos, no risco de pessoas. A ação corretiva foi um reforço de treinamento presencial nos primeiros 5 dias de operação, a mesma resposta que a matriz já tinha planejado. Risco previsto, resposta pronta, linha resolvida.
Há uma lacuna também, e para mim é o trecho mais legal da folha. As quatro linhas de escopo citam o controle de mudanças, mas nenhuma cita o risco de escopo da matriz, o de score 25, o maior do projeto. O risco mais grave previsto no planejamento se materializou quatro vezes e não aparece como origem em nenhuma linha. Se eu fosse revisar este registro de problemas, começaria acrescentando esse código.
Como ler o registro de problemas de outra pessoa
Já pegou um projeto andando e teve uma tarde para entender onde ele travou? Ler o registro de problemas de outro projeto é uma das avaliações mais rápidas de saúde de execução que existem. Você não precisa entender o conteúdo técnico de cada linha. Faça cinco passadas, nesta ordem.
- Confira a data de referência. Se ela é antiga, o registro está parado, e os dias em aberto estão menores do que deveriam.
- Separe os não resolvidos e leia a idade deles. A linha mais velha entre Aberto e Em tratamento é a primeira pergunta da reunião.
- Procure Aberto sem ação corretiva. É o sinal da quarta instrução: causa sentida e não endereçada.
- Agrupe pela origem. Três linhas com a mesma mudança ou o mesmo risco são uma causa só, e pedem uma conversa só.
- Conte os responsáveis. Um nome em mais da metade das linhas do registro de problemas mostra a fila de uma pessoa, e não a distribuição do trabalho.
Aplique as cinco no caso do kit e o diagnóstico sai em poucos minutos. A data de referência é de 10 dias depois da linha mais nova. Entre os não resolvidos, o e-commerce tem 105 dias. Não há linha Aberta sem ação. A origem concentra quatro linhas nas mesmas mudanças. E o PMO é responsável por duas das cinco, as duas que seguem abertas.
De todas, a passada pela origem é a que mais se pula. E é ela que mostra quando três ou quatro linhas são uma causa só, e o projeto está tratando sintoma. A conversa certa sai do registro e vai para o comitê, com o registro de decisões aberto ao lado.
Exemplos de registro de problemas preenchido
Seguem quatro folhas preenchidas, cada uma com o próprio PDF. A da rede de farmácias é a do kit. As outras três a gente preparou para este texto, nas mesmas nove colunas do M16, e elas tiram o registro de problemas do mundo dos sistemas: um centro de distribuição, um hospital e uma parada de manutenção.
Cada folha ilustrativa traz um quadro de conferência calculado: quantos problemas por status e por impacto, os dias em aberto só dos não resolvidos, as linhas Abertas sem ação corretiva e quantas linhas têm origem mapeada. Comece por esse quadro, e depois leia as linhas.
1. Rede de farmácias: cinco problemas, quatro com origem no escopo (caso do kit)
A folha tem data de referência 18/08/2026 e 5 linhas, identificadas entre maio e agosto, durante a execução do ERP novo da rede de farmácias.
Para entender as linhas, vale lembrar duas folhas que vieram antes. No termo de abertura, o e-commerce da rede ficava fora do escopo, por escrito. E a matriz de riscos tinha como risco mais grave o escopo crescer sem passar pelo comitê, com resposta planejada e dono.
A primeira linha, identificada em 05/05, é o atraso na entrega do módulo de e-commerce incluído fora do escopo original. Impacto Alto, origem E12, CM-01, status Em tratamento. A ação corretiva tem duas partes: renegociar prazo com o fornecedor e criar uma squad dedicada ao módulo.
As duas linhas seguintes têm o mesmo desenho. O retrabalho de parametrização fiscal das 2 lojas novas vem da CM-02 e foi resolvido replanejando o pacote 5.1. A integração de convênios corporativos não testada a tempo do piloto vem da CM-03 e foi resolvida estendendo o piloto em 1 semana.
A quarta linha, de 08/08, é a de maior peso: a Onda 1 do rollout, que não fechou em 07/08, com a origem nas três mudanças acumuladas. A ação é revisar o cronograma das Ondas 2 e 3 e formalizar novo prazo final com a Diretoria. É a única linha com status Aberto.
Na revisão desta folha, eu mexeria em duas coisas. Acrescentaria o código do risco de escopo da matriz às quatro linhas que vêm das mudanças. E leria os 90 e 54 dias das linhas resolvidas com cuidado, porque a fórmula segue contando depois do Resolvido.
2. Centro de distribuição: WMS novo e uma linha sem ação (exemplo ilustrativo)
Um centro de distribuição de 18.000 m² troca o sistema de armazém sem parar a operação. A folha é ilustrativa, montada para este artigo, com go-live em 28/07/2025, 3 transportadoras e cerca de 9.000 pedidos por dia. O registro é lido na reunião semanal, com data de referência 30/09/2025.
Eu conheço essa pressão da ferrovia, onde a operação também não parava para esperar ninguém. Num centro de distribuição é igual: o sistema novo entra com a doca funcionando. Cada problema aparece com caminhão na doca. A primeira linha mostra isso: leitura de etiqueta falhando em 6% das caixas da doca 3, com origem no risco R-04, etiqueta de fornecedor fora do padrão. A ação é reetiquetar na entrada até o fornecedor corrigir, ou seja, contenção. Por isso a linha segue Em tratamento, com 57 dias.
Duas linhas não têm origem mapeada. Uma delas, a do coletor novo que o turno da noite não conseguia usar, foi resolvida com o cadastro de 14 operadores e com a inclusão do risco na matriz. É o uso certo da origem vazia: o problema ensinou algo à matriz.
A linha que a reunião tem de abrir primeiro é a de 11/09. A separação da linha de cosméticos está 22% mais lenta que o previsto, impacto Alto, origem na mudança CM-03 de endereçamento por família de produto, status Aberto e ação corretiva em branco há 19 dias. É o sinal exato da quarta instrução do M16.
3. Hospital: prontuário eletrônico e o problema que voltou (exemplo ilustrativo)
Também ilustrativa, a segunda folha acompanha um hospital geral de 180 leitos que troca o prontuário em papel pelo eletrônico, setor a setor, entre janeiro e abril de 2025. Pronto-socorro, UTI e internação entram na primeira onda, e o comitê de implantação revisa o registro a cada 15 dias.
Em hospital, o impacto Alto é comum, porque quase todo problema toca o paciente. Aqui são 4 de 5 linhas. A coluna de impacto sozinha não ordena a reunião. O que ordena são os dias em aberto dos não resolvidos: 61, 33 e 12.
A linha de 27/01 mostra uma origem em mudança, e não em risco. A integração com o sistema de imagem foi antecipada pela CM-01, e o laudo deixou de chegar ao prontuário em 1 de cada 9 exames. A fila de reenvio automático com conferência diária resolveu.
O centro da folha são as linhas de 13/01 e 03/03, o mesmo problema voltando na troca de escala. A segunda linha cita a mesma origem, o risco R-05 de adesão do corpo clínico, e não repete a ação da primeira. Ela leva o caso para a diretoria clínica investigar a causa, e o responsável muda de nível junto.
4. Parada de manutenção: o registro lido todo dia às 7h (exemplo ilustrativo)
A última folha, ilustrativa como as duas anteriores, vem de uma fábrica de papel na parada geral anual de 18 dias, de 09/06 a 26/06/2025, com 41 frentes de serviço e cerca de 600 pessoas de empresas contratadas. O registro é lido todo dia às 7h, e esta é a folha do 12º dia, com data de referência 20/06.
Numa parada, a escala de tempo muda. O problema mais antigo tem 11 dias: o guindaste de 220 t que chegou 2 dias depois do contrato, resolvido com as frentes da caldeira resequenciadas para o turno da noite. A origem estava prevista na matriz, como risco de logística de equipamento pesado.
A trinca na tubulação de vapor, achada na inspeção, mostra um problema que pediu mudança. O reparo entrou no escopo pela CM-05, e a linha fica Em tratamento enquanto a equipe extra de soldadores trabalha em 3 turnos.
A linha que preocupa é a de 16/06: a peça de reposição do redutor da secadora veio com o modelo errado. Impacto Alto, nenhuma ação escrita e 4 dias de idade, com a partida marcada para 26/06. Num projeto de seis meses, 4 dias seriam pouco. Numa parada de 18 dias, é o item que decide a data da partida.
Nas quatro folhas, o que separa um registro útil de um registro decorativo é a coluna de origem. No caso do kit ela mostrou que quatro problemas tinham a mesma causa. Nas ilustrativas, as linhas sem origem mapeada mostraram o que a matriz de riscos não tinha previsto.
A reunião de tratativa: como usar a lista sem virar reunião de status
O registro de problemas só funciona se houver um momento fixo em que ele é percorrido. Sem rito, vira arquivo. Com o rito errado, vira reunião de status disfarçada, cada responsável relatando o que fez, um a um, e uma hora gasta sem nenhuma decisão.
A diferença está na pauta. Reunião de status percorre todas as linhas. Reunião de tratativa percorre só quatro grupos, e o resto fica no documento:
- Aberto sem ação corretiva: sai da reunião com ação e responsável, ou com a decisão de subir para quem pode decidir.
- Os não resolvidos mais velhos: o que mudou desde a semana passada? Se nada mudou, a ação atual não está atacando a causa.
- Origens repetidas: três linhas da mesma mudança vão juntas para o comitê, com o efeito somado.
- Linhas novas: leitura rápida, só para conferir origem, impacto e responsável.
Trinta minutos bastam com essa pauta. No caso do kit, o status report cobre de 01/08 a 18/08/2026, e fecha no mesmo dia da data de referência do registro. A ordem que funciona é ler o registro de problemas ao lado do painel de indicadores: o painel mostra onde o projeto desviou, e o registro mostra qual problema em aberto explica o desvio. Lido sozinho, o painel aponta o desvio e deixa a reunião chutando o motivo.
Na parada de manutenção dos exemplos, o rito é diário, às 7h, porque o projeto inteiro dura 18 dias. Num projeto de sistema de seis meses, semanal costuma bastar. A frequência acompanha o custo de um dia perdido. Num projeto curto e presencial, imprimir a folha num quadro de gestão à vista poupa a abertura do arquivo.
Quando o mesmo problema volta
Há uma classe de linha no registro de problemas que fecha e reabre: a base que é atualizada e volta a ficar desatualizada, o ambiente que cai toda semana, o plantão que volta ao papel. Registrar de novo a cada ocorrência está certo, mas não basta. A lista enche de linhas parecidas e o padrão fica invisível.
O exemplo do hospital, uma implantação de prontuário eletrônico, mostra o tratamento. A linha de 13/01 registra os médicos do pronto-socorro voltando ao papel no plantão noturno, com um plantonista de apoio como ação. Em 03/03, na troca de escala, o problema volta. A segunda linha não repete a ação da primeira: ela cita a mesma origem e sobe a recorrência para análise de causa com a diretoria clínica.
Depois da segunda ou terceira ocorrência, o problema deixa de ser um evento e passa a ser uma condição. Condição não se resolve com ação pontual. Ela pede mudança de processo, e muitas vezes o dono dessa mudança está fora do projeto. Manter a linha voltando no registro de problemas dá a falsa impressão de que a equipe do projeto consegue resolvê-la sozinha.
É também o gatilho natural para uma análise de causa mais estruturada, como a do diagrama de Ishikawa ou a da metodologia MASP. O registro já traz o que essa análise precisa: as datas, o impacto e o que foi tentado em cada vez.
Registro de problemas em times pequenos e em projetos ágeis
A objeção mais comum em equipe de três ou quatro pessoas é que todo mundo já sabe de tudo. É meia verdade. O problema circula na conversa do dia. O que não circula é o resto: quando foi identificado, há quantos dias está aberto, de onde veio e o que já foi tentado. Essas quatro informações somem em qualquer tamanho de equipe, e são elas que a folha guarda.
O ajuste razoável é de formato. Time pequeno pode manter só problema, data de identificação, origem, ação e status, e revisar em cinco minutos na reunião semanal. A data de referência única continua valendo, porque é ela que permite comparar uma semana com a outra.
Em projeto ágil, o impedimento levantado na daily tem vida curta, e o quadro da sprint resolve a maior parte deles. O registro de problemas entra para o que atravessa sprints: o impedimento que voltou três vezes, o que depende de uma área de fora do time, o que nasceu de uma mudança de escopo pedida pelo dono do produto. Esses são os itens que a retrospectiva deveria ler com data e origem, e não de memória.
Como o registro de problemas conversa com os outros documentos
Sozinho, o registro de problemas explica pouco. Ligado ao resto do kit, ele vira a ponte entre a causa e o desvio: recebe de dois documentos e entrega para três.
| Documento | O que passa para o registro de problemas, ou sai dele | Sem o vínculo |
|---|---|---|
| Matriz de riscos (P07) | Risco que se materializa vira linha, com o código na origem | Ninguém sabe quantos riscos previstos aconteceram |
| Controle de mudanças (E12) | Mudança cujo efeito atrapalha a execução vira linha | O atraso é atribuído à equipe, e não à mudança |
| Status report (M13) | Cita os problemas abertos que explicam o farol | O farol é justificado por impressão |
| Painel de indicadores (M15) | Mostra o desvio que o registro explica | Indicador em crítico sem causa nomeada |
| Termo de encerramento (F17) | Usa o registro para explicar cada desvio contra o planejado | O desvio vira opinião no fechamento |
Dos cinco vínculos, o que mais se perde é o da matriz de riscos. No caso do kit, a matriz previa o risco de escopo com resposta e dono, e o controle de mudanças, na quarta instrução, manda revisar a matriz no mesmo dia em que uma mudança passa sem o comitê. O registro de problemas é a terceira peça: ele mostra o custo de não ter feito essa revisão.
Na outra ponta, o termo de encerramento do caso fecha com 49 dias de atraso, 7 semanas, a soma do efeito das três mudanças que entraram sem passar pelo comitê. Cada uma dessas semanas tem uma linha no registro de problemas, com data. Sem ela, o fechamento compararia números sem conseguir dizer de onde veio a diferença.
Erros comuns no registro de problemas
No registro de problemas, o guia do kit nomeia o primeiro erro da lista abaixo como o erro comum da ferramenta. Os outros aparecem com frequência, e quase todos saem baratos se forem pegos nas primeiras semanas.
- Registrar o problema sem a origem. A mudança ou o risco que o causou se perde, e a lista vira coleção de efeitos.
- Misturar risco e problema. O que ainda não aconteceu incha a lista e esconde o que já está travando.
- Usar HOJE() nos dias em aberto. O arquivo muda de número sozinho e deixa de bater com o status report que o anexou.
- Ler os dias em aberto das linhas resolvidas. A fórmula conta desde a identificação, e o número não é o tempo de resolução.
- Deixar uma linha Aberta e a coluna da ação vazia. Pela quarta instrução, a causa foi sentida e ninguém foi atrás dela.
- Marcar Resolvido quando só houve contenção. A linha volta semanas depois, com outra data.
- Descrever por sentimento. “Integração com problemas” não pode ser conferida, e por isso nunca fecha.
Há um erro de contexto que merece atenção em empresa com cultura de cobrança forte: usar a contagem de problemas abertos como indicador de desempenho do gerente do projeto. O efeito é previsível. A contagem cai, os problemas continuam, e a organização perde o instrumento. O guia PMBOK do Project Management Institute trata o registro de questões como artefato de acompanhamento do projeto, e não como métrica de quem o conduz.
A frase do problema: uma que outra pessoa consiga conferir
A primeira coluna decide se a linha vai ser útil daqui a um mês. A exigência parece fácil até a primeira tentativa: alguém que não estava presente precisa conseguir confirmar, lendo só a frase, se o problema ainda existe.
| Frase que não funciona | Por quê | Versão que se confere |
|---|---|---|
| Integração com problemas | Não diz o que falha nem quando | Integração com a transportadora derruba pedidos acima de 40 itens |
| Equipe sobrecarregada | Estado difuso, sem critério de saída | Operadores do turno da noite sem acesso ao coletor novo |
| Atraso no rollout | Não diz o quê nem desde quando | Rollout da Onda 1 não concluído na data prevista, 07/08 |
| Fornecedor não colabora | Atribui intenção | Guindaste de 220 t chegou 2 dias depois da data do contrato |
As versões da direita saíram das folhas deste artigo. Todas têm um número ou uma data, e isso não é acaso: a exigência força a frase a sair do adjetivo. Quando não há número possível, vale perguntar se aquilo é problema mesmo, ou se é risco, ou incômodo.
Modelo de registro de problemas em branco para baixar (XLSX)
A planilha vazia abre logo abaixo. É a do kit, com as quatro instruções, as nove colunas e a fórmula dos dias em aberto já pronta, lendo da data de referência da primeira linha.
No arquivo está a folha do registro de problemas com as quatro instruções de preenchimento, a tabela de nove colunas e a fórmula dos dias em aberto.
Abrir e baixar o M16 em branco (XLSX)
Dentro do kit, a sequência que funciona é: matriz de riscos, controle de mudanças, registro de problemas e status report. As duas primeiras dão os códigos que a coluna de origem vai citar. Para quem está montando a estrutura de acompanhamento do zero, o PMO é quem costuma cuidar da cadeia inteira.
Se este registro de problemas te deu gás para ir além da planilha, fica o meu convite: a Academia de Certificação da Voitto ensina o acompanhamento de projeto inteiro, do termo de abertura ao fechamento. O gerenciamento de projetos fica bem mais leve quando cada problema tem data, origem e dono.
