Prioridade é impacto, não cargo

A pergunta mais difícil de responder numa empresa pequena não é quanto se gasta. É onde foi o dia.

Todo mundo trabalhou. Ninguém parou. E ainda assim, no fim do mês, não existe uma frase que explique o que foi feito — só a sensação de que se correu bastante.

Isso não é falta de esforço, e quase nunca é falta de gente. É que o trabalho entrou por lugares que não guardam registro: a mensagem no celular, o "só uma coisinha rápida" no corredor, o pedido feito na porta da sala. Cada um deles é pequeno. Juntos, são o dia inteiro.

O pedido que não vira registro

Um pedido que não é anotado em lugar nenhum tem uma propriedade curiosa: para a empresa, ele não aconteceu.

Ninguém sabe quantos existem, quanto tempo consumiram, ou quantas vezes o mesmo problema voltou. Quem atendeu sabe, e mais ninguém.

E há um efeito que ninguém antecipa: quem é bom de atender vira o mais interrompido. Não porque decidiram assim, mas porque o caminho mais curto até resolver alguma coisa é falar com ele. A recompensa por ser eficiente é ser interrompido mais vezes.

A esteira única não é burocracia

A correção é mais simples do que parece, e cabe numa frase: todo pedido entra por um lugar só. Um portal de chamados, uma caixa de entrada, o que for — a ferramenta importa pouco.

O que costuma travar essa mudança é a leitura de que ela é burocracia. Não é:

O propósito real da disciplina: governança sobre o tempo da empresa. O portal não é burocracia — é o instrumento que torna visível onde o tempo de TI é investido, e portanto governável.

Repare no que muda: você não passa a controlar as pessoas. Você passa a enxergar para onde o tempo foi, que é uma informação que hoje simplesmente não existe na empresa.

A regra que incomoda no começo

Com a fila montada, aparece a pergunta que ela obriga a responder: quem vem primeiro?

Regra de ouro: prioridade se define pelo impacto no negócio, não pelo cargo de quem pede. O que chega por fora é registrado por quem atende — sem exceção.

Essa é a parte que exige decisão do dono, e não da equipe técnica. Sem ela, a fila vira um enfeite: continua existindo, mas quem grita mais alto — ou tem o cargo mais alto — continua passando na frente, e a pessoa que atende fica no meio de uma disputa que não é dela.

E vale reparar no fim da frase, que é a metade mais fácil de esquecer: o que chega por fora não é recusado, é registrado. Ninguém precisa dizer não para o dono. Só precisa anotar antes de resolver.

Três tipos, e por que a diferença importa

Vale separar o que entra em três, pela relação com o que já existe:

Projeto é algo novo, que ainda não existe. Incidente é algo já entregue que apresentou problema. Requisição é um ajuste ou melhoria em algo já entregue.

Parece classificação de manual, e é a coisa mais reveladora da lista. Sem ela, tudo é "demanda", e uma equipe que passa o mês inteiro apagando incêndio parece uma equipe ocupada e produtiva. Com ela, fica visível que ninguém construiu nada — e isso muda o que se decide no mês seguinte.

O número que só aparece depois

Quando os pedidos passam a ser registrados e separados, surge de graça um número que o dono entende sem tradução: a proporção entre incêndio e construção.

Quanto do mês foi consertar o que quebrou, e quanto foi construir o que ainda não existia. É a medida de saúde mais honesta que uma operação de tecnologia tem, e ela não pede ferramenta nova nenhuma — pede que os pedidos existam por escrito.

O teste

Pense no mês passado, e responda sem consultar ninguém:

Quanto do tempo da sua equipe foi apagar incêndio, e quanto foi construir?

Se a resposta for uma estimativa, não é que a operação esteja mal. É que ela ainda é invisível — e operação invisível não melhora de propósito. Melhora por sorte.