O que é Kanban?

A palavra japonesa kanban se refere a sinal visual e tem raízes em sistemas de produção. O Método Kanban para trabalho do conhecimento foi desenvolvido por David J. Anderson e sistematizado no livro Kanban: Successful Evolutionary Change for Your Technology Business, de 2010. Ele aproveita ideias de fluxo e sistemas puxados, mas se destina a serviços em que o trabalho e o estoque são frequentemente intangíveis.

A Kanban University descreve princípios e práticas do Método Kanban, incluindo começar pelo modo de trabalho atual e evoluir com mudanças graduais. Outra referência, The Kanban Guide, tem formulação própria de práticas e métricas mínimas. As duas abordagens são próximas, mas não são o mesmo documento normativo. O verbete se ancora no Método Kanban de Anderson e aponta onde a outra referência ajuda a medir fluxo.

Kanban começa pela pergunta: como nosso serviço recebe trabalho e o transforma em algo útil para quem o solicita? A equipe observa o caminho real, torna visíveis decisões e esperas, limita a quantidade de itens iniciados e acompanha como o fluxo se comporta. Em vez de substituir todo o processo numa única mudança, o método ajuda a melhorá-lo de forma evolutiva. O foco é a capacidade do sistema de atender necessidades, não manter cada pessoa sempre ocupada.

Serviço e cliente. Defina qual serviço está sendo analisado, quem pede trabalho e o que considera entregue. Um time de suporte pode lidar com incidentes e dúvidas; uma equipe de produto, com hipóteses, mudanças e correções. Esses tipos têm urgências e critérios distintos. Sem um serviço definido, o quadro vira uma lista geral de tarefas e as métricas misturam coisas incomparáveis. Observe também que o cliente pode ser interno ou externo; em ambos os casos, a entrega precisa ter um significado claro.

Comece do que existe. O princípio de mudança evolutiva pede observar práticas, papéis e responsabilidades atuais. Isso não significa aceitar para sempre políticas que causam demora ou injustiça. Significa entender o sistema antes de alterá-lo e fazer mudanças cuja consequência possa ser observada. Uma equipe pode começar desenhando o fluxo de uma classe de demanda, descobrir esperas e decidir uma primeira melhoria. Depois, revê o desenho com pessoas afetadas.

Visualize o trabalho. Um quadro Kanban representa estados relevantes do fluxo, itens e bloqueios. Colunas devem ajudar a entender onde está o trabalho, e não apenas reproduzir nomes de departamentos. Pode haver uma parte anterior à escolha do trabalho e outra após a entrega, conforme o serviço. Especifique o que significa entrar e sair de cada estado. Se um cartão está "em revisão" enquanto ninguém o examina, talvez a espera mereça visibilidade própria. Um quadro digital ou físico serve se apoia decisões reais.

Defina pontos do fluxo. Escolha quando um item passa a ser compromisso do sistema e quando é considerado entregue. Para algumas demandas, há uma fila de opções antes do compromisso; para outras, a solicitação já chega como obrigação. Essas fronteiras afetam lead time, cycle time e expectativas do cliente. Não compare medidas sem conferir os marcos usados. A equipe também precisa saber o que conta como item: dividir uma demanda em dez cartões pequenos pode melhorar um número aparente sem melhorar a experiência de quem espera.

Limite trabalho em andamento. WIP é o trabalho iniciado e ainda não concluído. Um limite ajuda a equipe a terminar antes de puxar mais itens e expõe sobrecarga. Pode valer para o sistema inteiro ou para partes dele. O número não é uma lei universal: o time o ajusta com base na capacidade, na variabilidade e no serviço. Se o limite foi atingido, a resposta não é abrir uma coluna paralela para esconder excesso. Procure desbloquear, concluir ou revisar a política de entrada.

Puxe conforme capacidade. Num sistema puxado, uma etapa assume novo trabalho quando há capacidade e condições para avançá-lo. Isso difere de empurrar tudo o que chega para pessoas já sobrecarregadas. A política pode incluir prioridade, informação mínima e tratamento de urgências. Puxar não significa ignorar uma emergência: significa combinar como ela entra, que outro trabalho será pausado e que efeito a exceção pode ter nas promessas existentes.

Torne políticas explícitas. Regras implícitas produzem conflito: uma área acha que "pronto" significa revisado, outra entende como publicado. Registre critérios de entrada, conclusão, prioridade, tratamento de bloqueios e como alterar o limite de WIP. Políticas devem ser compreensíveis e revisáveis. Torná-las visíveis permite que o time perceba quando uma regra, e não uma pessoa, está atrasando o serviço. Uma política não precisa ser uma página longa; às vezes poucas frases no quadro bastam.

Gerencie o fluxo. Observe itens que envelhecem, filas que crescem, devoluções e pontos onde a demanda chega mais rápido do que sai. A equipe pode conversar diariamente sobre itens próximos da entrega e bloqueios, em vez de pedir relatório de cada pessoa. Uma reunião de reposição ajuda a decidir o que puxar depois; uma revisão de serviço examina se expectativas estão sendo atendidas. Essas cadências são ciclos de feedback com propósito. Se não produzem decisões, ajuste sua frequência ou formato.

Meça com contexto. O Kanban Guide de 2025 explicita quatro medidas mínimas para um sistema Kanban em sua formulação: WIP, throughput, idade do item e cycle time. A idade mostra quanto tempo um item iniciado já passou no fluxo; throughput conta itens concluídos por período; cycle time mede tempo decorrido entre início e fim, conforme marcos definidos. O Método Kanban também usa medidas de serviço e visualizações como CFD. Nenhuma métrica isolada explica a causa de uma espera. Combine números, tipos de demanda e conversa com quem trabalha.

Forme expectativas de serviço. Pessoas que solicitam trabalho precisam saber que prazo é plausível, não apenas ouvir promessas feitas por desejo. Uma Service Level Expectation usa dados históricos para expressar uma expectativa probabilística para um tipo de item. Ela não transforma toda entrega em garantia. Quando a demanda muda ou a política do fluxo é alterada, revise a previsão. Esse uso de dados ajuda a decidir quando intervir em um item que está envelhecendo.

Trate gargalos e dependências. Se uma etapa acumula trabalho de modo persistente, investigue a restrição real. Uma coluna cheia pode ser fila antes da etapa limitante, e um pico isolado pode não representar padrão. O verbete gargalo aprofunda essa análise. Dependências externas exigem acordos entre serviços; esconder que um cartão está esperando outra equipe não melhora o fluxo. Flight Levels pode ajudar quando a coordenação atravessa vários times e decisões estratégicas.

Melhore colaborativamente. Use o que o sistema revela para formular experimentos: reduzir tamanho de itens, mudar uma aprovação, treinar mais pessoas, rever limite, preparar melhor a entrada. Defina o efeito esperado e observe se tempo, qualidade e previsibilidade melhoram. Se uma intervenção apenas transfere a fila para a próxima etapa, não resolveu o serviço completo. A mudança pode ser pequena, mas deve ser revisada com quem é afetado.

Classes de serviço. Certas demandas têm custo de atraso ou prazo diferente. Classes de serviço tornam explícitas políticas de atendimento, sem transformar toda solicitação em urgente. Se uma classe de expedição é usada para quase tudo, ela deixa de proteger os casos raros e prejudica a previsibilidade das demais demandas. A política deve refletir necessidade real do serviço, não a influência de quem pede.

Qualidade. Kanban não prescreve uma Definition of Done do Scrum, mas o sistema precisa saber quando um item foi entregue com a qualidade adequada. Mover um cartão para "concluído" antes de teste, validação ou disponibilização cria uma métrica agradável e uma experiência ruim. Inclua retrabalho e falhas na inspeção do serviço. Um fluxo mais rápido que entrega defeitos não atende o objetivo.

Aplicações. O método pode apoiar software, suporte, marketing, RH e outras áreas de trabalho do conhecimento. O desenho depende do serviço. Um time de marketing pode ter etapas de proposta, produção, revisão e publicação; suporte pode separar triagem de resolução. Copiar o quadro de outra equipe tende a ocultar suas próprias esperas. Em escala, serviços conectados exigem coordenar prioridades, e não apenas somar cartões numa tela maior.

Kanban não é o nome de uma ferramenta nem uma promessa de que toda entrega ficará mais rápida. Tornar trabalho visível pode inicialmente revelar mais problemas do que o time esperava. Isso é informação útil. Quando políticas, capacidade e demanda passam a ser discutidas com transparência, a equipe pode escolher melhorias que protejam tanto quem faz quanto quem recebe o trabalho.

Software. Imagine um time hipotético que recebe correções e pequenas melhorias. Antes, cada pessoa inicia quatro itens e o quadro registra apenas "A fazer", "Fazendo" e "Feito". Em uma semana ilustrativa, há 16 itens em andamento e apenas 3 concluídos; testes e revisão ficam escondidos dentro de "Fazendo". O time redesenha o fluxo para mostrar desenvolvimento, revisão, verificação e entrega. Limita itens iniciados a 8 e combina que ninguém puxa uma nova tarefa enquanto há revisão bloqueada que pode ajudar a concluir. Após algumas semanas, observa 6 conclusões numa semana de cenário. Esses números são hipotéticos e não garantem ganho semelhante em outro contexto.

A mudança não consiste em obrigar qualquer pessoa a testar código sem preparo. A equipe aprende quais revisões exigem especialidade e onde pode compartilhar conhecimento. Também passa a medir tempo do compromisso até a entrega, não apenas horas de programação. Se o limite escolhido causa falta de trabalho pronto para uma etapa, ajusta-o. O objetivo é fluxo confiável, não cumprir o número 8 por fidelidade ao primeiro experimento.

Atendimento. Imagine um serviço que recebe dúvidas simples e incidentes críticos. Antes, todos entram na mesma fila e pessoas importantes conseguem furá-la por mensagem privada. O quadro torna visíveis tipos de pedido, idade e política de urgência. Uma classe de expedição reserva capacidade para incidentes realmente críticos, com critério público. Solicitações comuns deixam de desaparecer atrás de exceções informais. A equipe acompanha resolução e reabertura, pois fechar chamados depressa e receber o mesmo problema de novo não melhora o serviço.

A revisão mostra que pedidos passam dois dias esperando dados que poderiam ser colhidos na entrada. O serviço ajusta o formulário e conversa com solicitantes sobre campos indispensáveis. Não adiciona uma barreira enorme que impeça ajuda; escolhe informação suficiente para começar. Depois verifica se a fila caiu e se a satisfação de quem pede permaneceu adequada.

Marketing. Imagine uma equipe que produz campanhas para vários produtos. Design conclui peças depressa, mas aprovação jurídica chega em lotes e a publicação perde datas. O quadro revela uma fila antes da revisão, e a equipe combina reservar capacidade semanal de aprovação para itens prioritários. Também passa a envolver jurídico antes de produzir peças com risco alto. O fluxo atravessa áreas; otimizar apenas design ampliaria a fila.

Os três exemplos mostram que visualizar, limitar WIP e tornar políticas claras são meios para aprender sobre o serviço. O formato das colunas, limites e cadências muda conforme a demanda. Em cada caso, a equipe verifica resultado para clientes e qualidade, não só a quantidade de cartões movidos.

Os dois podem apoiar aprendizagem e entrega de valor. Scrum define um framework com responsabilidades, eventos e artefatos; o Método Kanban melhora um serviço a partir de seu fluxo existente. Eles podem ser combinados quando o time explicita como o trabalho se move e inspeciona resultados.

Cursos K21 recomendados