Registro de problemas: o que é, como usar e a diferença para risco e mudança

Todo projeto acumula uma lista de coisas que deram errado e ainda não foram resolvidas. Em muitos times essa lista existe só na cabeça do gerente, ou espalhada em conversas paralelas — e o efeito é sempre o mesmo: o problema que trava a entrega aparece na reunião de acompanhamento como novidade, quando ele já tinha três semanas de idade. O registro de problemas existe para que isso não seja possível.

A ferramenta é uma tabela de acompanhamento, não um relatório. A diferença importa: relatório se lê, tabela se trabalha. Cada linha tem dono, prazo e encaminhamento, e a linha só sai da lista quando o problema for resolvido ou quando ele virar outra coisa — um pedido de mudança, uma decisão registrada, um desvio assumido.

Este texto trata do documento e do critério de entrada. Se o que você procura é como investigar a causa de um problema recorrente, isso é assunto dos 5 porquês e do diagrama de Ishikawa. Aqui o assunto é anterior: como garantir que o problema exista por escrito, com dono, antes de qualquer investigação.

Você vai ver o que entra e o que não entra, as colunas da ferramenta, a fronteira entre problema, risco e mudança, a data de detecção e por que ela é a mais reveladora, como impedir que a lista vire cemitério, como ler um registro alheio e os erros que aparecem sempre.

As linhas de exemplo deste artigo foram montadas a partir do formato da ferramenta M16 do Kit Gestão de Projetos da Voitto. São ilustrativas: mostram o preenchimento, não relatam projeto real.

O que é o registro de problemas

O registro de problemas é a lista de tudo que já aconteceu, está afetando o projeto e ainda não foi resolvido. A definição tem três partes e cada uma exclui alguma coisa: já aconteceu exclui risco; está afetando exclui o que é apenas incômodo; ainda não foi resolvido exclui histórico.

A ferramenta pertence à fase de monitoramento e trabalha em par com o status report. A relação é direta: todo desvio relatado no status report cita a referência que o sustenta, e boa parte dessas referências aponta para uma linha do registro de problemas. Sem o registro, o relatório de acompanhamento vira narrativa sem lastro.

O erro conceitual mais comum é tratar o registro como lista de tarefas difíceis. Não é. Tarefa difícil é trabalho previsto que exige esforço; problema é algo que não deveria estar acontecendo e está. A distinção parece filosófica e é prática: tarefa difícil tem lugar no cronograma, problema não tem — ele consome tempo que estava alocado para outra coisa.

Vale uma observação sobre o tamanho da lista. Registro com duas linhas em projeto de seis meses não significa projeto tranquilo: significa que o critério de entrada está alto demais ou que ninguém está registrando. Registro com sessenta linhas abertas significa que nada está sendo fechado. Os dois extremos são sintoma, e o segundo é mais comum.

As colunas da ferramenta

A coluna de efeito é a que separa o registro útil do inchado. Ela obriga a responder o que muda por causa disso, e a resposta honesta muitas vezes é nada — e aí o item não pertence à lista. Reservar a lista para o que produz efeito mensurável é o que mantém a leitura possível.

A coluna de situação tem quatro valores e o quarto costuma faltar nos formulários caseiros: convertido. Problema que vira pedido de mudança não foi resolvido, e marcá-lo como resolvido falseia a contagem. Convertido diz a verdade — ele saiu daqui e está sendo tratado em outro documento, com referência.

Problema, risco e mudança: a fronteira

Os três documentos parecem próximos e confundi-los é o erro que mais prejudica os três. A separação é temporal e causal, e cabe em uma frase: risco é o que pode acontecer, problema é o que já aconteceu, mudança é o que se decide fazer a respeito.

A passagem de risco para problema é o momento mais importante e o menos ritualizado. Quando um risco se materializa, ele deve sair da matriz — ou ser marcado como materializado — e entrar no registro de problemas com a referência ao risco de origem. Essa ligação é o que permite, no encerramento, contar quantos riscos identificados de fato aconteceram. Poucas organizações têm esse número, e ele é o único jeito honesto de calibrar a avaliação de risco.

No outro sentido, a passagem de problema para mudança encerra a linha do registro como convertida. O problema não desapareceu: ele foi absorvido por uma alteração formal de escopo, prazo ou custo. Manter os dois abertos em paralelo produz contagem dupla e a sensação de que o projeto tem mais frentes travadas do que realmente tem.

A data de detecção é a coluna mais reveladora

De todas as colunas, a data de detecção é a que mais gera desconforto e a que mais informa. Ela pergunta quando o problema foi percebido — não quando foi registrado, não quando foi levado à reunião, não quando virou crise.

A distância entre a data de detecção e a data de registro é uma medida direta da saúde da comunicação do projeto. Zero a dois dias indica que a equipe reporta naturalmente. Duas semanas indica que reportar problema tem custo social, e que o registro só recebe o que já não dá para esconder.

Essa medida não serve para punir quem demorou — serve exatamente para o contrário. Quando a distância é grande de forma consistente, o problema é do ambiente, não das pessoas: em algum momento reportar cedo foi respondido com cobrança, e a equipe aprendeu. A correção é de comportamento de quem recebe, não de quem reporta.

Há um efeito colateral útil. Quando a equipe sabe que a data de detecção será registrada, ela tende a reportar mais cedo — não por controle, mas porque a coluna torna visível o valor de reportar cedo. Problema detectado em 04/03 e registrado em 05/03 conta uma história boa sobre quem o detectou, e as pessoas percebem isso rápido.

O campo de encaminhamento impede o cemitério

Registro de problemas morre de um jeito característico: ele cresce, ninguém fecha nada, e em dois meses tem quarenta linhas abertas que todo mundo já parou de ler. A partir daí ele não serve mais para acompanhar — serve só para provar depois que o problema era conhecido, que é o pior uso possível de um documento de gestão.

A trava contra isso é o campo de encaminhamento, e ele precisa de uma regra de atualização obrigatória: toda linha aberta tem encaminhamento atualizado a cada ciclo de acompanhamento. Linha sem atualização há dois ciclos é sinalizada, e a sinalização é o que força a conversa — ou se trata, ou se aceita, ou se converte.

1. Trata: existe ação em curso, com dono e prazo. O encaminhamento descreve a ação e o próximo marco.
2. Aceita: o efeito é assumido e não haverá ação. A linha fecha como resolvida por aceitação, e o efeito vai para o relatório de acompanhamento como desvio.
3. Converte: a resolução exige alteração formal. A linha fecha como convertida, com referência ao pedido de mudança.
4. Escala: a resolução depende de decisão fora do alcance do projeto. O encaminhamento nomeia quem decide e desde quando o pedido está com essa pessoa.

A quarta opção é a menos usada e a mais necessária. Problema que depende de decisão alheia fica aberto no registro por meses sem que ninguém perceba que a bola não está com o projeto. O encaminhamento que nomeia o decisor e a data do pedido transforma esse item em algo cobrável — e é essa linha que costuma virar o desvio mais caro do encerramento.

Aceitar um problema é uma opção legítima e subutilizada. Nem todo problema compensa resolver, e a lista que só permite tratar acumula itens de baixo efeito que consomem a atenção dos importantes. Fechar por aceitação, com o efeito declarado, é uma decisão de gestão — e pertence também ao registro de decisões.

Como ler um registro de problemas alheio

Ler o registro de outro projeto é uma das leituras mais rápidas que existem para avaliar saúde de execução. Quatro medidas bastam, e nenhuma delas exige entender o conteúdo técnico dos itens.

1. Idade média dos itens abertos. Mediana acima de um ciclo e meio de acompanhamento indica que o registro está acumulando em vez de fechar.
2. Proporção de linhas sem prazo. Cada linha sem prazo é um item que nunca vai gerar alarme. Acima de um terço, o documento deixou de acompanhar.
3. Concentração de responsável. Quando uma pessoa aparece em mais de metade das linhas, o registro está medindo a agenda dessa pessoa, não o projeto.
4. Distância entre detecção e registro. Consistente e alta, revela ambiente em que reportar cedo tem custo.

A terceira medida é a que mais surpreende quem a faz pela primeira vez. É comum descobrir que o gerente do projeto é o responsável por setenta por cento dos problemas abertos — não porque ele os causou, mas porque ninguém mais foi nomeado. Um registro assim não distribui a resolução: ele documenta a fila de uma pessoa só, e essa fila nunca anda.

Uma quinta leitura, mais lenta e mais rica, é agrupar as descrições por tema. Quando cinco linhas diferentes falam da mesma frente, o registro está mostrando uma causa estrutural que nenhum item isolado revela. É o ponto de entrada natural para uma análise de causa — e a lista de problemas é a melhor matéria-prima que essa análise pode ter, porque ela é contemporânea aos fatos.

Exemplo ilustrativo de preenchimento

As linhas abaixo foram montadas para este artigo no formato da ferramenta. Repare que o efeito é sempre quantificado, ainda que de forma aproximada, e que o encaminhamento diz o próximo marco, não a intenção.

As três últimas linhas mostram os três finais possíveis que não são a resolução técnica: aceitação, conversão e escalada. Um registro em que todas as linhas fecham como resolvidas é suspeito — ele provavelmente está escondendo aceitações não declaradas, que são desvios silenciosos.

Como escrever a descrição de um problema

A descrição é a coluna que decide se a linha vai ser útil daqui a um mês. Ela tem uma exigência simples e difícil: ser verificável. Alguém que não estava presente precisa conseguir confirmar se o problema ainda existe, lendo só aquela frase.

A degeneração típica é a descrição por sentimento. "Integração com problemas", "equipe sobrecarregada", "comunicação ruim com o fornecedor". Nenhuma delas pode ser confirmada nem refutada, e por isso nenhuma pode ser fechada — a linha permanece aberta para sempre porque não existe estado do mundo que a resolva.

Repare que as versões verificáveis são mais longas, e isso é o custo real da coluna. Vale pagar: a frase curta economiza trinta segundos de quem escreve e custa uma conversa de quinze minutos por leitura, multiplicada por todas as leituras futuras.

Uma regra prática que resolve a maioria dos casos: a descrição deve conter pelo menos um número ou uma data. Não porque número seja sagrado, mas porque a exigência força a sair do adjetivo. Quando não há número possível, o problema provavelmente é um risco ou um incômodo — e nenhum dos dois pertence a esta lista.

A reunião de tratativa: como usar a lista sem virar reunião de status

O registro só funciona se houver um momento fixo em que ele é percorrido. Sem rito, ele vira arquivo. Com o rito errado, ele vira reunião de status disfarçada — cada responsável relatando o que fez, um a um, e a reunião consumindo uma hora para produzir nenhuma decisão.

A diferença entre as duas está no critério de entrada da pauta. Reunião de status percorre todas as linhas. Reunião de tratativa percorre só três categorias: o que venceu o prazo, o que está sem atualização há dois ciclos, e o que precisa de decisão que ninguém na sala pode tomar sozinho. O resto fica no documento.

1. Linhas com prazo vencido — nova data com justificativa, ou mudança de encaminhamento. Não vale repactuar prazo sem dizer o que mudou.
2. Linhas paradas há dois ciclos — decide-se entre tratar, aceitar, converter ou escalar. Sair da reunião ainda como "em tratamento" exige próximo marco datado.
3. Linhas que precisam de decisão coletiva — as únicas que justificam a presença de todo mundo na sala.
4. Linhas novas desde o último encontro — leitura rápida, só para atribuir responsável e prazo.

Trinta minutos bastam quando a pauta é essa. Uma hora indica que a reunião está percorrendo tudo, e percorrer tudo é o que faz a lista crescer sem fechar: se todas as linhas recebem atenção igual, nenhuma recebe atenção suficiente.

As decisões que saem dessa reunião pertencem ao registro de decisões, e a maior parte delas é de aceitação — assumir um efeito e seguir. São exatamente as decisões que ninguém lembra depois e que explicam metade dos desvios do encerramento.

Quando o mesmo problema volta

Há uma classe de item que fecha e reabre: a base que é atualizada e volta a ficar desatualizada, o ambiente que cai toda semana, o relatório que sai errado todo mês. Registrar de novo a cada ocorrência é tecnicamente correto e praticamente inútil — a lista enche de linhas idênticas e o padrão fica invisível.

O tratamento certo é mudar a natureza da linha. Depois da terceira ocorrência, o problema deixa de ser um evento e passa a ser uma condição, e condição não se resolve com ação pontual: ela se resolve com mudança de processo ou se aceita explicitamente como característica do ambiente.

A conversão para condição tem um efeito prático importante: ela tira o item da fila de tratamento e o coloca onde ele pode ser resolvido de verdade. Uma base que desatualiza toda semana não é problema do projeto — é falta de rotina de carga, e o dono disso está fora do projeto. Manter a linha aberta no registro dá a ilusão de que o projeto pode resolvê-la.

É também o gatilho natural para investigar causa. Três ocorrências do mesmo problema são amostra suficiente para valer uma análise, e a lista de problemas já traz o que a análise precisa: as datas, os efeitos e o que foi tentado. Levar isso para os 5 porquês custa meia hora e costuma encerrar a linha de vez.

Registro de problemas em times pequenos

A objeção mais frequente em equipes de três ou quatro pessoas é que todo mundo já sabe de tudo, e manter uma lista formal seria burocracia. A objeção é parcialmente verdadeira e leva a uma conclusão errada.

É verdade que em time pequeno a comunicação do problema não depende do documento — ele circula na conversa do dia. O que não circula é o resto: quando foi detectado, quanto tempo está aberto, o que já foi tentado, qual o efeito acumulado. Essas quatro informações desaparecem em qualquer tamanho de equipe, e são elas que o registro guarda.

O ajuste razoável é de formato, não de existência. Time pequeno pode manter o registro com quatro colunas — detecção, problema, dono, encaminhamento — e revisá-lo em cinco minutos na reunião semanal. O que não pode é não existir, porque a memória de equipe pequena é ainda mais frágil: quando uma pessoa sai, sai metade do histórico.

Há um ganho adicional que aparece rápido nesses times: a lista escrita separa o problema da pessoa. Em equipe pequena, problemas tendem a ser discutidos como características de quem os encontrou ou de quem os causou. O documento, com data e efeito, desloca a conversa para o fato — e isso vale mais que a organização que ele produz.

Erros comuns no registro de problemas

• Registrar risco como problema. Incha a lista com o que ainda não aconteceu e tira visibilidade do que está travando de fato.
• Data de registro no lugar da data de detecção. Apaga a única medida direta da qualidade da comunicação do projeto.
• Efeito em branco. Sem efeito, não há como priorizar, e a lista vira inventário de incômodos.
• Linha sem prazo. Item que nunca vai gerar alarme e vai envelhecer até o encerramento.
• Um responsável para quase tudo. Documenta a fila de uma pessoa, não o projeto.
• Fechar como resolvido o que foi aceito ou convertido. Falseia a contagem e esconde desvio assumido.
• Nunca usar a escalada. Problemas que dependem de decisão alheia ficam abertos por meses sem cobrança.
• Usar o registro como prova. Quando o documento serve para mostrar que o problema era conhecido, ele deixa de servir para resolvê-lo.

Há um erro de contexto que merece atenção especial em organizações com cultura de cobrança forte: usar a contagem de problemas abertos como indicador de desempenho do gerente. O efeito é imediato e previsível — a contagem cai, os problemas continuam, e a organização perde o instrumento. Contagem de problemas mede exposição do projeto, não competência de quem o conduz.

O que o registro devolve no encerramento

No fim do projeto, o registro de problemas é a fonte mais rica que existe para o termo de encerramento e para as lições aprendidas. Ele guarda, com data, tudo que atrapalhou — e guarda contemporaneamente aos fatos, o que nenhuma sessão de memória coletiva consegue reproduzir.

• Causas nomeadas para a tabela de desvios: cada desvio de prazo e custo deveria encontrar sua origem em uma ou mais linhas do registro.
• Contagem de riscos materializados: as linhas que vieram da matriz de riscos dão a taxa de acerto da avaliação inicial.
• Tempo médio de resolução: a diferença entre detecção e fechamento, por tipo de problema, diz onde a organização é lenta.
• Itens escalados e não decididos: a lista mais desconfortável e a mais útil, porque aponta gargalos de decisão fora do projeto.

O quarto item costuma ser o achado de maior valor de um encerramento bem feito. Projetos raramente atrasam por falta de competência técnica; atrasam esperando decisão. Quando o registro mostra três itens escalados com trinta, quarenta e sessenta dias de espera, a conversa deixa de ser sobre a execução do projeto e passa a ser sobre o processo decisório da empresa — que é onde o ganho está.

Nada disso funciona se o registro tiver sido preenchido no fim. A propriedade que torna esse documento valioso é ser contemporâneo: ele guarda o que se sabia na data, antes de o desfecho reorganizar a memória. Preenchido retroativamente, ele conta a história que o resultado sugere — e aí é mais honesto declarar a lacuna do que produzir a reconstrução.