Lean Thinking para desenvolvedores ocupados: a versão definitiva, agora também impressa

A versão 3.0 de "Lean Thinking per sviluppatori software impegnati" reescreve os capítulos 1 a 6 a partir do feedback dos leitores e leva a IA agêntica para dentro de todo o texto, não apenas para o capítulo dedicado a ela. E agora existe a edição impressa, 6x9 polegadas (15,24 x 22,86 cm), 316 páginas. O livro está escrito em italiano; a edição em inglês chega ainda este ano.

O Lean nasce na fábrica. Software não é uma fábrica. O livro partiu dessa frase, e é o motivo pelo qual a maioria dos livros Lean para desenvolvedores acaba numa gaveta: aplicam receitas da manufatura a um ofício cuja matéria-prima são requisitos ambíguos, não parafusos padronizados.

Hoje sai a versão que considero definitiva, e com ela a edição impressa. O papel estava previsto desde sempre, mas um livro vai para a gráfica quando está pronto, não enquanto você ainda o escreve. Agora está pronto, então ele está na Amazon também em papel.

O que eu vi nos times a quem ensinei Lean

O livro nasce dali, não de uma leitura. Faço consultoria e treinamento sobre esses princípios dentro de empresas de verdade, e a velocidade com que um time renasce quando para de brigar com o próprio processo continua me surpreendendo. Gente que na primeira reunião não abria a boca, dois meses depois te para no corredor para dizer como o board deveria mudar.

Depois vem a parte incômoda. Quando o fluxo de trabalho fica à vista de todos, quase sempre aparece que o gargalo não era o time. Eram as prioridades reescritas toda segunda-feira, as aprovações paradas por dias na mesa de alguém, o trabalho começado três vezes e nunca terminado. Muitas vezes foi a própria gestão a perceber primeiro, e a admitir que o problema a resolver era dela. É aí que as coisas começam a andar de verdade.

Software House de Pesadelo

Uma das analogias que mais uso me foi dada pela televisão. Se você nunca viu “Pesadelo na Cozinha”, o mecanismo é sempre o mesmo: um restaurante está prestes a fechar, o chef passa alguns dias lá, observa como as pessoas realmente trabalham durante o serviço, vira o lugar do avesso e vai embora deixando uma cozinha que funciona. Ninguém fala de produção nem de processos, e ainda assim quase tudo o que o chef impõe é Lean: corta um cardápio de oitenta pratos para dez bem feitos, esvazia câmaras cheias de mercadoria comprada meses atrás, organiza a cozinha porque movimento inútil se vê a olho nu, assiste ao serviço ao vivo em vez de ouvir as versões de quem trabalha ali, e antes de ir embora devolve a dignidade a uma brigada que tinha desistido. Redução de variedade, estoque, desperdício de movimento, ir ver no local, respeito pelas pessoas. São os mesmos capítulos.

Daria para gravar “Software House de Pesadelo” sem mudar uma vírgula do método. Muda o artefato: o prato vira uma release, a câmara fria vira um backlog de quatrocentos tickets que ninguém vai abrir, o serviço de sábado à noite vira o deploy de sexta-feira. Os princípios continuam onde estão.

Isso acontece porque são princípios e não regras, e é uma diferença que no nosso ofício escapa o tempo todo. O princípio aguenta a mudança de contexto: “torne visível o trabalho parado” vale numa cozinha, num chão de fábrica e num repositório. A regra não. A regra precisa ser reescrita toda vez que o contexto muda, porque tinha sido calibrada no anterior. E nós, em software, somos ótimos em escrever regras, com seus números e tudo: sprints de duas semanas, 80% de cobertura, limite de WIP em cinco, quatro cerimônias por semana. Depois muda o time, muda o produto, e a regra continua valendo por inércia enquanto do princípio que a gerou ninguém mais se lembra.

Por isso o livro explica cada princípio no seu contexto original, o da Toyota, e depois o reinventa para o software em vez de apenas transferi-lo. Se você entendeu o princípio, quando o contexto muda a regra você reescreve sozinho, que é a única coisa que importa de verdade.

“Pesadelo na Cozinha” é a adaptação brasileira do formato “Ramsay’s Kitchen Nightmares”, criado e produzido pela Optomen Television para o Channel 4 e distribuído internacionalmente pela All3Media International; Gordon Ramsay apresenta as edições britânica e americana, e o chef Érick Jacquin comanda a versão brasileira exibida pela Band. Títulos, formatos e marcas pertencem aos respectivos titulares: cito aqui apenas por analogia, sem qualquer relação com o programa ou com seus produtores.

O que tem dentro do livro

Os capítulos 1 a 6 foram reescritos a partir do feedback dos leitores: raciocínios mais conversados e cenários tirados do dia real de quem desenvolve, não de uma linha de montagem.

Os números estão ali para serem refeitos. A lei de Little na forma que serve de verdade, Lead Time = WIP / Throughput, e uma tabela de work in progress construída sobre premissas declaradas, um time de cinco pessoas e tarefas de oito dias-pessoa, para você conferir linha por linha o que acontece quando passa de três trabalhos em paralelo para um. Todas as citações voltam à fonte primária, e algumas reservam surpresas: a palavra “Lean” não foi cunhada por Womack e Jones em 1990, é de John Krafcik, num artigo de 1988 nascido da pesquisa dele no MIT.

Depois tem as páginas que eu mesmo uso primeiro: o cheat sheet final, a tabela dos 7+1 muda com a coluna de exemplos concretos, o checklist da code review Lean.

Os vinte e quatro diagramas servem para isso, mostrar numa figura o que em prosa ocupa duas páginas. Por exemplo os três pilares sobre os quais tudo o mais se apoia.

A IA agêntica não fica num capítulo só

Quando comecei a escrever, os assistentes de IA completavam linhas de código. Hoje abrem pull requests.

Existe um capítulo dedicado, mas trancar a IA ali dentro teria sido cômodo e falso. Os agentes deslocam os equilíbrios em todo lugar, então o assunto volta onde precisa: no fluxo, nas estimativas, nos limites de WIP, na code review, no jeito de olhar para a qualidade. Onde a IA não muda nada eu não falo dela, e onde muda algo eu falo no ponto em que o leitor já está se perguntando.

Tem uma objeção que ouço com frequência: se a IA escreve o código por mim, o Lean serve menos. É exatamente o contrário. Quando o custo de produzir código despenca, todo o resto continua onde estava: as esperas por aprovações, os ciclos de feedback de semanas, o tempo em que o trabalho fica parado numa fila. Se antes você escrevia uma funcionalidade em três dias e esperava sete pelo deploy, o desequilíbrio era tolerável. Agora que você a escreve em duas horas, esses sete dias ficam intoleráveis e escancarados.

Esse é o diagrama que no livro acompanha o capítulo sobre fluxo. Conte os dias: quase todos são espera, e nenhuma daquelas caixas encolhe porque um agente escreve o código no seu lugar.

No livro você encontra três desperdícios que no Toyota Production System não podiam existir.

O vibe coding: gerar código sem compreendê-lo, aceitando enquanto parecer funcionar. É o cargo cult técnico em versão moderna, adotam-se as formas externas (o código compila, as funções são chamadas) sem a substância. Cada linha aceita sem entender é dívida técnica que você não vê na hora de assinar e paga em cada manutenção.

Depois tem a sobrecapacidade generativa. A superprodução clássica nasce de um desenvolvedor que decide construir algo “já que estamos aqui”; aqui é o agente que constrói enquanto pensa: variantes que ninguém pediu, casos limite inventados, tratamento de erro para cenários que o sistema nem contempla. Coisas que alguém vai ter que manter do mesmo jeito.

O último é o verification overhead, ou seja o custo de reler criticamente o que o agente produz. Não é zero e não aparece em estimativa nenhuma. O agente não conhece as suas convenções de arquitetura, nem as regras de negócio implícitas que o time acumulou ao longo dos anos. Se você não conta esse tempo, a velocidade de geração parece produtividade e não é.

Por que o papel

Porque muitos de vocês pediram. Tem quem leia bem no digital e tem quem, num texto de consulta, prefira o papel: fica aberto ao lado do teclado, dá para anotar na margem, você acha a página que precisa sem abrir nada. É questão de gosto, e a 3.0 agora cobre os dois.

A edição impressa tem 6x9 polegadas, ou seja 15,24 x 22,86 cm, 316 páginas, papel creme. Os vinte e quatro diagramas eu refiz de propósito para a impressão, assim na página eles se leem como se leem na tela.

Para quem é, e para quem não é

Se o seu time escreve código mais rápido do que consegue colocar em produção, o gargalo não é o teclado. Este livro serve para encontrá-lo e removê-lo, com o que você já tem em casa: o board que vocês olham toda manhã, os números do fluxo de vocês, a code review de sexta à tarde. É escrito para desenvolvedores sênior, tech leads, arquitetos e CTOs de pequenas empresas técnicas, ou seja para quem escreve código de verdade e não tem tempo a perder com teoria. Os exemplos são em Python por legibilidade, mas os princípios valem em qualquer linguagem.

O livro não é para gestores em busca de slides motivacionais, nem para consultores em busca de um framework para revender. E não é um livro sobre o Toyota Production System: a Toyota é a premissa histórica, não o assunto.

Onde encontrar

As edições Kindle e impressa estão na Amazon: 9,99 euros o Kindle, 19,90 o impresso. No Leanpub continua a versão digital, com as atualizações incluídas como sempre para quem já comprou.

Um esclarecimento importante: o livro está escrito em italiano. A edição em inglês está prevista para este ano. Espanhol, português do Brasil e alemão dependem de quantas pessoas pedirem, então se você quer um desses idiomas me escreva em d.teti@bittime.it dizendo qual. Com pedidos suficientes, mando traduzir.

Se o livro te ajudou, a coisa mais útil que você pode fazer é deixar uma avaliação honesta. Para um livro técnico autopublicado, aquelas poucas linhas pesam mais do que qualquer campanha.