O que é Kanban e por que um quadro não basta

Kanban é um método para gerenciar fluxo de trabalho, e ele se apoia em duas coisas: tornar o trabalho visível e limitar quanto pode estar em andamento ao mesmo tempo. A primeira parte quase toda organização tem. A segunda é a que faz o método funcionar, e é a que costuma ficar de fora.

Um quadro com colunas "a fazer, fazendo, pronto" e sem limite nenhum não é Kanban. É uma lista de tarefas mais organizada, o que já é melhor que nada, mas não resolve o problema que o Kanban existe para resolver.

O problema é começar mais coisa do que se consegue terminar.

De onde o método veio, e por que isso explica o cartão

Kanban vem do Sistema Toyota de Produção. Foi desenvolvido por Taiichi Ohno, que criou o sistema em 1953 e o testou na produção de automóveis; a Toyota o expandiu para toda a companhia em 1962.

A parte interessante é de onde veio a ideia. Em 1956, Ohno visitou os Estados Unidos e ficou impressionado com o funcionamento dos supermercados americanos. O que chamou a atenção dele não foi a variedade, foi a lógica de reposição: a prateleira só é reabastecida depois que o cliente leva o produto. Ninguém empurra mercadoria para uma prateleira cheia.

Ele levou essa lógica para a fábrica. Cada etapa da produção passou a sinalizar para a etapa anterior o que precisava ser reposto, em vez de receber empurrado o que a etapa anterior tinha produzido.

O sinal era um cartão. É daí que vem o nome: kanban é um termo japonês para sinalização visual, comumente traduzido como cartão ou letreiro.

Vale guardar isso, porque muda a leitura do quadro. O cartão não é o rótulo de uma tarefa. É um sinal de que existe capacidade para puxar trabalho. Quando o cartão vira apenas etiqueta, o método se perde e o quadro passa a acumular.

O quadro, as colunas e os cartões

Três elementos, e nenhum deles precisa de ferramenta.

O quadro é a superfície onde o trabalho fica visível para o time inteiro. Parede, vidro, quadro branco ou sistema. O critério é um: todo mundo consegue ver sem pedir para alguém.

As colunas representam as etapas do processo. Um Kanban mínimo tem três: a fazer, fazendo e pronto. Um time de software costuma precisar de mais, algo como a fazer, fazendo, teste, homologação e pronto.

Aqui vai a recomendação que mais evita quadro abandonado: copie o processo que existe, não o processo ideal. Se hoje o trabalho passa por uma aprovação chata e demorada, essa etapa vira coluna. Quadro que não descreve a realidade é abandonado em duas semanas, porque as pessoas percebem que ele mente.

Os cartões carregam a tarefa. Título é o mínimo. Responsável, data de início e produto envolvido ajudam. Cor funciona bem para prioridade, tipo de trabalho ou origem da demanda.

Cartão é instrumento de controle de fluxo, não repositório de especificação. Tarefa que precisa de detalhe fica documentada em outro lugar, e o cartão aponta para lá.

O limite de trabalho em progresso

Esta é a parte que separa o método do quadro.

Cada coluna de trabalho em andamento recebe um número: quantas tarefas podem estar ali ao mesmo tempo. Quando a coluna chega no limite, ninguém inicia tarefa nova. O time olha o que está travado e ajuda a terminar.

Parece uma restrição burocrática e é o contrário disso. É o que faz o gargalo aparecer.

Sem limite, o comportamento natural de um time pressionado é começar mais coisa. Todo mundo fica ocupado, o quadro enche, e nada termina. A sensação de produtividade sobe enquanto a entrega cai, porque trabalho pela metade não entrega valor nenhum e ainda consome atenção.

Com limite, quando a coluna de teste está cheia, fica evidente que o problema não é falta de esforço em desenvolvimento. É capacidade de teste. E aí a conversa deixa de ser sobre esforço individual e passa a ser sobre onde está o gargalo do sistema.

Na minha visão, é aqui que o Kanban encosta em liderança e não em ferramenta. Aceitar que uma coluna cheia significa parar de começar exige uma cultura em que ficar sem tarefa nova por meia hora não é sinônimo de estar sem fazer nada.

O que o quadro realmente entrega

O original desta lista, que escrevi há alguns anos, dizia que o quadro tira do funcionário a desculpa para ficar ocioso. Hoje eu não escreveria assim, e o motivo é o próprio Lean: o Sistema Toyota de Produção se apoia em valorizar quem faz o trabalho, não em vigiá-lo.

Quadro usado como painel de vigilância produz um efeito previsível: as pessoas otimizam a aparência do quadro em vez do fluxo. Cartão que não avança some, tarefa é fatiada para parecer progresso, e o quadro deixa de ser informação.

O que ele entrega quando é bem usado:

• Visibilidade do sistema, não das pessoas. Onde o trabalho para, quanto está em andamento, o que está esperando alguém.
• Conversa sobre capacidade. A coluna cheia é um dado, e dado muda decisão melhor que opinião.
• Coordenação sem reunião. Boa parte do que se pergunta em reunião de status está no quadro.
• Medição de fluxo. Quanto tempo um cartão leva de ponta a ponta, e quantos terminam por semana. São os números que permitem prometer prazo com alguma base.

Essa última é a que mais fica de fora. Um quadro que não mede tempo de ciclo continua sendo gestão visual, mas não vira previsibilidade.

Como implantar sem que morra em duas semanas

Mapeie o processo real primeiro. Antes de desenhar coluna, acompanhe o trabalho de verdade, do pedido até a entrega. Quase sempre existem etapas de espera que ninguém tinha nomeado, e são elas que explicam o prazo.

Comece com limite folgado. Limite muito apertado no início gera revolta e o time desiste do método. Comece próximo do que já acontece hoje e aperte depois, quando o time já viu o limite funcionando.

Explicite as regras. O que significa "pronto" em cada coluna, quem pode mover cartão, o que fazer quando algo trava. Regra implícita gera discussão recorrente.

Meça e ajuste. Kanban não é implantado, é evoluído. O quadro do terceiro mês não deve ser igual ao do primeiro.

Onde o Kanban se junta ao resto

Quase todo framework ágil usa algum quadro. No Scrum, quando o Sprint Backlog é criado, as tarefas aparecem como "a fazer" e caminham pelo quadro durante a Sprint.

Mas a combinação só rende quando o limite vem junto. Scrum com quadro e sem limite de WIP produz o padrão conhecido: uma Sprint que começa com quinze itens em andamento e termina com doze quase prontos.

Scrum organiza a cadência. Kanban organiza o fluxo. Uma Sprint com limite de trabalho em progresso costuma terminar com menos itens começados e mais itens realmente prontos.

Na sua organização, o quadro mostra o que está em andamento, ou mostra apenas o que foi distribuído?