Processo Bom Nasce da Dor

"Não invente processo onde não tem dor."

Tem gestor que adora processo pelo processo. Cria fluxos cheios de setas, formulários de vinte campos, etapas de aprovação em cascata... tudo para tentar evitar problemas hipotéticos que nunca aconteceram na empresa. O resultado? Burocracia pesada que atrasa quem quer trabalhar sem proteger absolutamente nada.

Processo bom nasce de um jeito muito diferente. Nasce da dor real. Alguém sofreu na operação, o time parou para aprender com o tropeço e um combinado enxuto surgiu para prevenir que aquela mesma falha aconteça de novo. Quando a regra nasce para curar uma ferida aberta que toda a equipe sentiu na pele, ninguém precisa fiscalizar: o próprio time defende o processo porque sabe que ele protege o seu trabalho.

Sinais de processo artificial

Como descobrir se a sua área está rodando em cima de engenharia real ou de burocracia imaginária? Observe quatro sintomas clássicos no dia a dia:

• Ninguém sabe explicar por que existe: a resposta padrão para uma etapa obrigatória é "sempre fizemos assim desde que entrei".
• Sempre é contornado: para conseguir cumprir os prazos, os profissionais criam caminhos paralelos no chat e só preenchem o sistema formal depois que a entrega já foi ao ar.
• Gera mais formulário do que resultado: o tempo gasto documentando e pedindo carimbos supera o tempo dedicado a construir e testar a solução.
• Foi copiado de outro lugar sem adaptação: alguém leu sobre o modelo de uma gigante de tecnologia e tentou aplicar a mesma estrutura em uma equipe de dez pessoas com outra realidade de negócio.

O que Taiichi Ohno e Fred Brooks ensinam sobre burocracia

A diferença entre padronização útil e burocracia de escritório foi magistralmente explicada por Taiichi Ohno, pai do Sistema Toyota de Produção, no livro Toyota Production System: Beyond Large-Scale Production (1988). Para Ohno, qualquer padrão de trabalho só é legítimo quando nasce no Gemba (o local real onde o valor é criado) com o objetivo direto de eliminar Muda (desperdício, retrabalho ou sobrecarga). Quando um fluxo é desenhado longe da operação por pessoas que não executam a tarefa, ele não elimina o desperdício: ele próprio se torna o desperdício.

Na engenharia de software, Fred Brooks trouxe um alerta complementar no clássico The Mythical Man-Month (1975) e no ensaio No Silver Bullet (1986). Brooks dividiu os desafios técnicos em complexidade essencial (a dificuldade intrínseca do problema real do negócio) e complexidade acidental (o atrito que nós mesmos criamos com ferramentas mal escolhidas e rituais desnecessários). Não foi por acaso que os dezessete autores do Manifesto Ágil (2001) escolheram como primeiro valor fundamental: "Indivíduos e interações mais que processos e ferramentas". Processos devem reduzir a complexidade acidental, nunca multiplicá-la.

Como processo bom nasce na prática

Para criar combinados que aumentam a confiabilidade sem engessar a entrega, sigo um ciclo de cinco passos sempre que um incidente relevante acontece:

1. Problema real acontece

O cliente reclamou de um cálculo errado na fatura. Um bug crítico escapou para produção sem teste. Um deploy derrubou a integração na sexta-feira. Comece sempre por uma dor concreta e observável, nunca por uma suposição teórica.

2. Análise de causa no sistema

Pergunte o que causou a falha. Não "quem" errou, mas "o quê" falhou na engrenagem. Qual ausência de trava automática, de visibilidade ou de alinhamento permitiu que uma pessoa bem-intencionada cometesse aquele erro?

3. Solução proporcional ao risco

A proteção precisa custar muito menos do que o prejuízo que ela evita. Não adianta criar um processo manual de 10 etapas para todas as entregas do ano inteiro apenas para evitar um erro raro que custa 50 reais. Se puder automatizar a checagem no pipeline de código em vez de criar uma reunião humana, automatize sempre.

4. Test drive com prazo definido

Implemente o novo fluxo como piloto em um escopo pequeno por duas ou quatro semanas. Veja se realmente evita a dor original sem travar o ritmo. Ajuste o que ficou pesado antes de expandir para o resto da organização.

5. Revisão periódica contra fósseis

Processo que não é revisado vira fóssil corporativo. O contexto da empresa muda, a arquitetura evolui, o time amadurece. O processo deveria mudar junto ou ser aposentado quando o risco deixar de existir.

O equilíbrio e a documentação do "porquê"

Pouco processo gera caos e retrabalho constante. Muito processo gera paralisia e apatia. O ponto certo de maturidade operacional é simples: proteção rigorosa onde o erro é caro, liberdade total onde o time pode experimentar.

Para manter esse equilíbrio vivo, adote uma regra de ouro: todo processo interno deveria ter a primeira linha explicando por que ele existe e qual problema real resolveu quando foi criado. Assim, daqui a um ano, quando alguém questionar se aquela etapa ainda faz sentido ou pode ser eliminada, a decisão será informada por fatos.

Processo sem memória do problema que o gerou vira dogma. E, em tecnologia, dogma é o caminho mais curto para a irrelevância.

---

Referências e leituras verificáveis

• Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
• Brooks, F. P. (1975 / 1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
• Beck, K., et al. (2001). Manifesto para Desenvolvimento Ágil de Software. Agile Alliance.