O que 改善 kaizen ensina sobre escrever software

Faz uns três anos que descobri kaizen (改善). E não foi por um livro de tecnologia — foi lendo Lean Thinking, do Womack e Jones. Um livro sobre a Toyota.

Cara, é um dos livros que mais mudou como eu penso. Ele conta como uma fábrica japonesa, no meio da escassez pós-guerra, inventou um jeito de fazer carros com menos defeito e menos desperdício que a General Motors — a gigante americana da época. Um jeito que ficou conhecido como Toyota Production System, e mais tarde deu origem à filosofia que eles chamam de 改善 kaizen.

O que me pegou não foi o lado industrial. Foi a cabeça por trás. Kaizen nasceu no chão de fábrica, mas é sobretudo um jeito de olhar pra qualquer processo repetitivo. E poucos processos são tão repetitivos, tão viciados em ansiedade e tão suscetíveis a erro quanto o de construir software.

Escrevi esse post porque acho que essa filosofia merece chegar em mais gente que constrói produto digital. Nada aqui é invenção minha — os conceitos vêm da Toyota, dos livros do Ohno, do Imai, dos Poppendieck. Meu papel é só destilar, com o contexto de quem passou três anos pensando nisso enquanto construía uma empresa.

Kaizen não é "continuous improvement" de PowerPoint

Existe uma versão do kaizen que virou coach empresarial. Aquela do slide corporativo — "vamos melhorar continuamente 1% ao dia, seremos 37x melhores em um ano". Perdoa a franqueza: essa versão é o oposto do que a Toyota criou.

Kaizen (改善) literalmente significa mudança pro melhor. Kai (改) = mudança. Zen (善) = bom. Simples assim, na etimologia. Mas no contexto da Toyota, tem um sentido bem mais duro que "melhoria contínua": o processo em si é o produto. O carro que sai da linha é resultado. O que interessa mesmo é como você chega no carro sem defeito, gastando o mínimo de material, com respeito por quem constrói.

Isso me pegou de jeito quando li. Porque é o contrário do que a maior parte da indústria de tecnologia ensina — a gente aprende a fazer software olhando pro produto, o processo vira ruído. Toyota inverte a lente. E, quando você olha bem, faz muito mais sentido.

No sistema Toyota, o operário na linha tem o direito de parar toda a produção puxando um cordão amarelo (o andon) se ele vê algo errado. Ninguém é punido. A pergunta que segue é: por que isso aconteceu? O que no processo permitiu isso? Taiichi Ohno, engenheiro-chefe do Toyota Production System

Essa é a virada de chave. Quando algo quebra em produção, a pergunta deixa de ser "qual usuário fez essa coisa estranha?" ou "qual dev empurrou esse commit?" — e passa a ser por que o processo permitiu que isso chegasse até aqui?. O foco sai da pessoa e vai pro sistema. Uma cultura inteira condensada numa pergunta só. Bonito de doer.

Os 3 M — o que kaizen combate

Toyota tem uma taxonomia bonita pro que kaizen ataca. Três palavrinhas japonesas que rimam, e que descrevem três formas diferentes de o processo falhar:

Quando você começa a olhar seu processo com essas três lentes, fica desconfortável. No bom sentido. Descobre que boa parte do que se produz numa semana de trabalho não é o produto em si — é muri, mura, muda. É o custo do jeito que você escolheu construir. E, diferente do produto, esse custo raramente é medido. Ninguém coloca "reunião desnecessária" na planilha do CFO.

Os 4 princípios que se traduzem pra software

Kaizen tem várias práticas concretas. Muitas dependem de contexto industrial — linhas físicas, estoques, fluxo de material. Mas quatro delas atravessam a fronteira e caem redondas na prática de construir software:

1 · Small batches · deploys pequenos e frequentes

O primeiro princípio, e o mais duro culturalmente: parar de juntar coisas pra "um release grande". Toyota descobriu, contraintuitivamente, que produzir muitos carros iguais de uma vez economiza aparentemente — mas o desperdício aparece quando o mercado muda e o estoque não presta mais. Quanto menor o lote, mais flexível o sistema.

Traduzindo pra software: deploys pequenos e frequentes. Terminou uma coisa, testa localmente, sobe pra produção. Se algo quebra, é uma coisa só — reverter é fácil, e você sabe exatamente o que causou. Não vira o desespero de "qual das 40 mudanças que subiram sexta quebrou o login segunda de manhã?".

É muito mais difícil do que parece. Mas não pela pipeline técnica — pela cultura. Exige disciplina pra resistir à tentação de "aproveitar" um deploy e empurrar mais uma coisinha que "tá quase pronta". Isso é a coisa mais humana do mundo. Todo mundo quer aproveitar. E é justamente aí que o kaizen sussurra: não aproveita, deploya sozinho.

Quem aplica com rigor relata sempre a mesma coisa: menos bug em produção que com o modelo de release grande. Não é milagre — é matemática. Cada mudança entra sozinha, é testada em contexto real, e a próxima corrige logo se precisou.

2 · ポカヨケ Poka-yoke · errar de propósito impossível

Poka-yoke (ポカヨケ) significa "à prova de erro". A ideia é linda: se um erro é possível, é uma questão de tempo até acontecer. Solução — não treinar mais nem escrever mais documentação. Projetar de forma que o erro simplesmente não seja possível.

Na fábrica é lindo de ver: uma peça que poderia ser montada em duas orientações? Nunca. A peça tem um encaixe assimétrico que só entra do jeito certo. O operário não precisa lembrar. O físico obriga. É um jiu-jitsu contra o próprio erro humano.

Traduzindo pra software: o app não deixa o usuário fazer coisa errada. Tentou apagar um board que tem cards com deadline no futuro? Aviso e confirmação dupla. Tentou mover um card pra "Concluído" sem preencher um campo obrigatório? Pausa e destaca o campo. Tentou desligar o backup em nuvem? O sistema obriga um backup local antes.

Cada regra dessas é um bug resolvido uma vez, no design. Não precisa treinar usuário. Não precisa escrever documentação avisando. O sistema não permite a besteira. Ponto.

É caro no começo — leva mais tempo pra projetar. Mas é barato infinitamente em suporte depois. Cada poka-yoke que entra é um ticket que nunca vai chegar. E ticket que não chega é ouro pra qualquer time.

3 · 反省 Hansei · retrospectiva honesta, toda semana

Hansei (反省) é a prática de reflexão crítica sobre o próprio trabalho. Não é retrospectiva ágil com post-it colorido e emoji de sol nascendo. É outra coisa. Mais duro. É olhar pro que se fez essa semana e perguntar honestamente: o que quebrou? Por que quebrou? O que muda semana que vem pra não quebrar de novo?

Na prática, a literatura sugere reservar 30 minutos, uma vez por semana (típico: sexta à tarde), pra escrever:

• O que foi entregue essa semana — versão honesta, sem inflar
• O que quebrou — bug em produção, feature que ninguém usou, decisão que voltou atrás
• Por que quebrou — a causa raiz, não o culpado
• O que muda na próxima semana — 1 coisa, no máximo 2

Não é longo. Toma 30 minutos. Mas é a hora em que kaizen acontece de verdade. Sem hansei, os mesmos erros se repetem meses a fio e ninguém percebe. Com hansei, o sistema fica ~1% melhor por semana. Isso compõe de um jeito absurdo com o tempo.

Um sinal ruim: se o hansei da última sexta parece igual ao de duas semanas atrás, o aprendizado parou. Ficou só o cansaço. E aí é hora de dar um passo pra trás e olhar mais alto.

4 · 現場 Genba · ir ver com o próprio olho

Genba (現場) significa "o lugar real onde a coisa acontece". Na Toyota, isso é o chão de fábrica. Se um engenheiro quer entender um problema de produção, ele não lê relatório. Ele desce até a linha, fica lá, olha o operário trabalhar, entende como o problema se manifesta na prática. Genba, na minha leitura, é o princípio mais bonito de todos. E o que mais falta na maior parte dos produtos digitais que a gente usa hoje em dia.

Genba se traduz pra software em duas caras:

Dogfooding de verdade. Não é usar o app pra bater papo no Slack interno da empresa. É rodar o CRM comercial, o kanban de features, os OKRs trimestrais — tudo — dentro do próprio produto. Se algo é chato pra usar, você sente na pele antes do cliente. Se algo trava, você tem que consertar antes de conseguir trabalhar. É a única forma de honestidade de produto que não mente.

Conversa com usuário real. Não entrevista de "qual sua feature preferida?", que ninguém responde de verdade. É "compartilha a tela e me mostra como você usa". Você vê pessoas fazendo coisas que nunca imaginou, e usando o produto de jeitos que quebram sua hipótese inicial. Isso é genba puro — sair do escritório mental, ir ver.

A armadilha do kaizen mal aplicado

Um alerta que aparece em quase toda literatura séria sobre kaizen — e que raramente chega no discurso corporativo happy path: kaizen mal aplicado vira burnout com boas intenções.

Como todo aprendizado depende de reflexão sobre o próprio trabalho, é fácil deslizar de "o sistema tem que ficar melhor" pra "eu tenho que ficar melhor". O primeiro leva a mudanças de processo. O segundo leva ao esgotamento. E é uma linha muito fina.

Toyota inventou kaizen num contexto muito específico: fábrica com centenas de pessoas, sindicatos, escala, regras. Kaizen ali é coletivo por natureza — a responsabilidade se dissolve no sistema. Kaizen aplicado a um dev solo, ou a um time de 3 pessoas, precisa de cuidado redobrado. Sem essa dissolução coletiva, o peso da melhoria cai inteiro sobre indivíduos. E aí a filosofia mais bonita vira uma dor nova.

Um antídoto que aparece na literatura, e que faz muito sentido pra mim: ligar hansei a métricas objetivas, não a sensação. Se o tempo de resposta a bug caiu, o sistema tá melhor. Se o volume de tickets de suporte por 100 usuários caiu, o sistema tá melhor. Se só a sensação melhorou, é auto-engano. Kaizen é mudança pro melhor — e "melhor" precisa ter uma medida, mesmo que qualitativa.

O que quem aplica bem relata

Times e produtos que aplicam kaizen com disciplina — dos Poppendieck aos livros mais recentes de DevOps e continuous delivery — relatam três padrões em comum. Não são promessa de vendedor de curso. São padrão observado, em setores diferentes, décadas seguidas:

Deploys deixam de ser eventos. Deixam de ser aquela ansiedade programada, sexta à noite, dedo cruzado, torcida. Viram sussurro — múltiplas vezes ao dia, sem cerimônia, quase invisível. Se algo quebra, é pequeno, e a reversão é questão de minutos. Não é milagre. É lote pequeno.

Bug em produção cai drasticamente. Não porque as pessoas viraram melhores programadoras da noite pro dia. Porque cada mudança que entra é pequena o suficiente pra ser testada de verdade — tanto no ambiente local quanto em produção logo em seguida. Muri, mura e muda caem juntos, e o bug cai atrás.

O time consegue dormir. Essa é a parte que ninguém acredita até experimentar. Quando o sistema é enxuto, ninguém carrega o peso do "e se algo quebrar essa noite?" pra dentro do sono. Foi feito o suficiente. Se algo quebrar, dá pra consertar amanhã. O sistema aguenta. Isso não é pouco.

O próximo movimento

Se você constrói software — sozinho, num time pequeno, ou numa empresa grande — kaizen vale a leitura. Te digo mais: vale a releitura, uns 6 meses depois. Porque a primeira leva é o wow filosófico. A segunda é quando você começa a ver de verdade onde encaixa no seu dia a dia.

Não é framework de startup. É filosofia de como você se relaciona com o próprio trabalho. Pra mim é isso que faz kaizen bonito: não vende curso, não vende ferramenta, não vende metodologia registrada. Vende uma forma de estar no ofício. E, sinceramente, esse tipo de coisa é raro em qualquer campo hoje.

Se você vai começar por algum lugar, começa pelos deploys pequenos. É o ponto de entrada mais fácil, e o que produz resultado visível mais rápido. Se hoje sua equipe faz deploy 1x por semana, tenta 3x. Se hoje é 3x, tenta 1x por dia. Cada barreira que aparecer é muri, mura ou muda esperando pra ser vista.

E se quiser um produto construído sob essa filosofia — o Synkan foi pensado com kaizen em vista desde o começo. Small batches no jeito como o app é entregue. Poka-yoke em cada interação sensível. Genba de verdade — quem construiu usa o produto todo dia pra rodar o próprio negócio, e ajusta o que incomoda antes do cliente sentir. É um produto pra quem valoriza esse tipo de rigor silencioso.

Referências e leituras

As 4 fontes que sustentam a base desse post (em ordem cronológica). Se ler só uma, sugiro o Womack — foi por onde eu entrei:

• Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. Livro fundador escrito pelo engenheiro-chefe que criou o TPS na Toyota nos anos 50-70. Cru e direto.
• Imai, M. (1986). Kaizen: The Key to Japan's Competitive Success. McGraw-Hill. A obra que apresentou o conceito de kaizen ao mundo ocidental de forma sistematizada.
• Womack, J. P., & Jones, D. T. (1996). Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Simon & Schuster. A leitura que traduz o TPS pra fora do chão de fábrica. Foi a minha porta de entrada.
• Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley. Ponte direta entre lean/kaizen e prática de desenvolvimento de software.

Os quatro princípios apresentados aqui (small batches, poka-yoke, hansei, genba) foram selecionados dessa literatura por serem os que melhor atravessam a fronteira do chão de fábrica pro mundo digital. A ordem, os exemplos e a leitura são recorte editorial — o conteúdo é dos autores acima.

— Anderson, fundador do Synkan. Escreve esse blog uma vez por mês, no cruzamento entre filosofia japonesa e produto digital — dois mundos que não deveriam se encontrar, mas se encontram muito bem. Se ficou alguma dúvida, se você é fã de Ohno e quer trocar ideia sobre kaizen, ou se quer indicar uma leitura pra próxima — manda email pra contato@synkan.com.br. Respondo a mão, um por um.