Padronizar é um alívio para uns e uma ameaça para outros. Na análise de Rolando Bonaccorsi, especialista em gestão de operações de TI e excelência em serviços, a diferença entre os dois efeitos está menos no volume de regras e mais em quais decisões elas tiram da cabeça das pessoas e quais deixam com elas. Uma operação de tecnologia que padroniza o que é repetitivo ganha previsibilidade, e a que padroniza também o que exige julgamento perde justamente quem sabe julgar.
Primeiro: padronize o que se repete, não o que surpreende
O primeiro critério é a frequência. Em operações de TI, tarefas que se repetem toda semana, como abrir um acesso, reiniciar um serviço travado ou registrar uma mudança, ganham muito com um roteiro único, porque o roteiro elimina variações que só geram erro e retrabalho. Já a investigação de uma falha inédita não cabe em roteiro algum, e tentar encaixá-la num passo a passo rígido faz a equipe seguir a lista enquanto o problema cresce fora dela.
Como reforça Rolando Bonaccorsi, o teste prático é perguntar se duas pessoas diferentes, diante da mesma situação, deveriam chegar ao mesmo resultado. Se a resposta for sim, o processo pede padrão. Se a resposta depender de contexto, experiência e leitura da situação, o que se padroniza é o objetivo e o registro do que foi feito, nunca cada gesto no caminho.
Uma consequência desse critério é que o padrão deixa de ser um bloco único e passa a ter camadas. Na camada de cima ficam princípios curtos, como o que precisa ser comunicado e a quem. Na camada de baixo ficam os roteiros detalhados das tarefas rotineiras. Entre as duas, a equipe tem espaço para decidir.
Segundo: quem usa o processo ajuda a desenhá-lo
Padrão escrito por quem não executa a tarefa costuma nascer bonito e morrer na primeira semana. O motivo é simples: quem opera o sistema conhece os atalhos que existem por uma boa razão, os passos que parecem inúteis no papel e as exceções que aparecem no meio da madrugada. Ignorar esse conhecimento produz documentos que ninguém abre, e a equipe volta a trabalhar do jeito antigo, só que agora com uma camada de burocracia por cima.
Como observa Rolando Bonaccorsi, vale envolver as pessoas que executam a tarefa já na escrita do processo, e não apenas na hora de treiná-las. O envolvimento tem um efeito prático: o profissional que ajudou a desenhar o roteiro entende o motivo de cada passo, e quem entende o motivo sabe quando pode adaptar e quando não pode.
Aqui entra uma distinção que costuma passar despercebida. Um passo obrigatório, como o registro de uma mudança antes de ela entrar em produção, precisa vir acompanhado da razão de existir. Um passo recomendado, como a ordem em que se verificam os serviços, pode ser ajustado conforme o caso. Misturar as duas categorias na mesma lista é o caminho mais curto para a equipe tratar tudo como formalidade.
Poucas regras bem explicadas valem mais do que muitas regras sem justificativa, e a razão é simples: quem entende o motivo de um passo consegue adaptá-lo quando a situação foge do previsto, enquanto quem apenas obedece trava diante do primeiro imprevisto. Por isso, cada regra de um processo precisa carregar consigo o problema que quer evitar, escrito em linguagem que qualquer pessoa da equipe consiga repetir.
Terceiro: sinais de padrão saudável
Um padrão saudável se reconhece por três sinais. O primeiro é que ele é revisado com regularidade, porque a tecnologia, as ferramentas e a própria equipe mudam, e um roteiro parado no tempo deixa de descrever o trabalho real. O segundo é que existe um caminho claro para propor mudanças, de modo que a pessoa que encontra um passo ruim consegue corrigi-lo sem abrir um pedido que leva semanas. O terceiro é que o desvio é tratado como informação, não como falta.
O último sinal merece atenção. Quando alguém foge do roteiro e o resultado sai bem, a pergunta útil é se o roteiro está errado. Quando foge e o resultado sai mal, a pergunta útil é o que faltou no roteiro para a pessoa não precisar fugir. Em ambos os casos, o desvio alimenta a melhoria do processo, e punir quem o registra apenas ensina a equipe a esconder o que faz.
Segundo Rolando Bonaccorsi, também ajuda medir o efeito da padronização com indicadores que a própria equipe reconheça como justos. Se o único número acompanhado for a aderência ao roteiro, as pessoas passam a cumprir a lista para agradar o painel. Se o número observado for a qualidade do serviço entregue, o roteiro volta a ser o que deveria ser, um meio de chegar a um bom resultado.
Quando o padrão vira jaula, e como sair dela
Há sinais claros de que a padronização passou do ponto. Os profissionais mais experientes deixam de propor melhorias, as exceções se acumulam fora do sistema, e a conversa da equipe gira em torno de qual formulário preencher, não de como resolver o problema. Nessa situação, o remédio raramente é abolir as regras. Costuma ser enxugá-las, remover os passos que ninguém consegue justificar e devolver à equipe as decisões que dependem de leitura do contexto.
Outro cuidado é a ordem das mudanças. Em operações de TI, introduzir muitos padrões ao mesmo tempo sobrecarrega a equipe e dificulta saber qual deles funcionou. Começar por um processo de alto volume e baixo risco, medir o efeito, ajustar e só então avançar para o seguinte dá à equipe a chance de enxergar o benefício antes de enfrentar o próximo custo.
Como observa Rolando Bonaccorsi, o objetivo final da padronização é liberar atenção. Quando as tarefas repetitivas seguem um caminho conhecido, as pessoas gastam menos energia com o que é rotina e mais com o que exige criatividade, como investigar a causa de um problema ou desenhar uma solução melhor. Uma equipe que sente isso na prática tende a defender o padrão, em vez de contorná-lo.
