Por Que Kanban Funciona — e Como Saber Se Sua Equipe Está Pronta Para Isso

A maioria das equipes adota Kanban porque alguém leu um artigo de blog. A pergunta mais inteligente é se os problemas que Kanban resolve são realmente os problemas que sua equipe tem.

Há um momento que a maioria das equipes reconhece, geralmente por volta do tempo em que têm mais de oito ou nove pessoas. O trabalho está sendo feito — e-mails são enviados, recursos são entregues, clientes são gerenciados — mas ninguém tem uma noção clara do que todo mundo está fazendo. Projetos se acumulam. Coisas são promessas e depois quietamente esquecidas. Você gasta vinte minutos antes de cada reunião para descobrir onde um trabalho realmente está. A resposta, geralmente, é "em algum lugar".

Esse é o problema que Kanban foi projetado para resolver. Não o problema de definir estratégia, ou contratar as pessoas certas, ou construir uma cultura — mas o problema operacional específico e desgastante de saber em que sua equipe está trabalhando e o que está atrapalhando.

É uma ferramenta surpreendentemente humilde para algo que atraiu tanta atenção. Kanban não afirma consertar sua organização. Ele apenas torna o trabalho visível. E acontece que a visibilidade, aplicada consistentemente, muda um número notável de coisas downstream.

De onde Kanban realmente veio

A palavra é japonesa — significa "quadro de avisos" ou "painel de anúncios" — e o sistema foi desenvolvido pela Toyota no final dos anos 1940 como uma forma de gerenciar o inventário em suas plantas de manufatura. A ideia era simples: em vez de produzir peças em um cronograma fixo, a fábrica as produziria apenas quando uma estação downstream sinalizasse que precisava delas. Um cartão físico — o kanban — viajaria para cima pela linha como um pedido. Nada era feito especulativamente. Nada se acumulava desnecessariamente.

O insight que a Toyota teve, e que as equipes de software depois tomaram emprestado, é que a maioria da ineficiência em um sistema não vem de pessoas trabalhando muito lentamente, mas de trabalho errado sendo feito no momento errado. Demasiadas coisas começadas ao mesmo tempo. Gargalos que ninguém percebe até ser tarde demais. Trabalho que está finalizado em um lugar enquanto o próximo passo está sobrecarregado em outro lugar.

Desenvolvedores de software, particularmente em empresas como Microsoft no início dos anos 2000, começaram a adaptar essas ideias para trabalho de conhecimento. Os cartões se tornaram tarefas. As estações da fábrica se tornaram estágios em um fluxo de trabalho. E o painel se tornou um quadro — físico a princípio, depois digital — onde qualquer um da equipe poderia ver, de relance, o que estava em andamento, o que estava esperando, e o que estava feito.

O que um quadro Kanban realmente mostra

Um quadro Kanban básico tem três colunas: A Fazer, Em Andamento, e Pronto. Isso é suficiente para muitas pequenas equipes e um bom lugar para começar. Mas o valor real emerge quando você começa a customizar essas etapas para combinar com como seu trabalho realmente flui — não como você deseja que ele fluísse.

Uma equipe de conteúdo pode usar: Ideia, Briefing, Em Rascunho, Em Revisão, Agendado, Publicado. Uma equipe de software pode quebrar "Em Andamento" em colunas separadas para desenvolvimento, revisão de código e QA. Uma equipe de consultoria pode rastrear Descoberta, Proposta, Ativa, Aguardando Cliente, e Fechada. As etapas devem refletir transferências reais e tempos de espera reais — lugares onde o trabalho muda de mãos, ou onde se senta até que algo mais aconteça.

Observe o cartão na coluna do meio — o relatório de auditoria do armazém, oito dias e marcado como bloqueado. Em um sistema sem um quadro, essa tarefa pode ficar por mais duas semanas antes de alguém perceber que não está se movendo. Alguém está esperando por um terceiro. Ou uma decisão é necessária de um gerente que não sabe que é o bloqueador. O quadro torna o bloqueio visível. Esse é a maioria do trabalho.

A regra que o faz funcionar: limites de WIP

Se há um conceito que separa equipes usando Kanban corretamente de equipes que têm apenas uma lista de tarefas mais bonita, é trabalho em progresso limites — limites WIP para abreviar. A ideia é que cada coluna tem um número máximo de itens que são permitidos estar lá de uma vez. Quando uma coluna está cheia, você não pode adicionar mais trabalho até que algo saia.

Isso parece contraintuativo. Certamente ser capaz de colocar mais tarefas em andamento significa mais está sendo feito? Não. O que realmente acontece quando as pessoas trabalham em demasiadas coisas simultaneamente é que tudo leva mais tempo. Mudança de contexto é cara. Trabalho semi-acabado cria overhead de coordenação. E quando dez coisas estão "em andamento," é muito difícil dizer quais realmente estão se movendo e quais estão apenas presas mas não marcadas.

Um limite de WIP de três em sua coluna Em Andamento significa que quando o quarto item chega à mesa de alguém, alguém da equipe tem que tomar uma decisão: qual tarefa existente é concluída primeiro? Força priorização. Força conversa. E tende a produzir conclusão mais rápida de itens individuais, mesmo que a taxa de início de novos itens diminua.

Kanban versus Scrum: a pergunta que as equipes sempre fazem

Se você passou algum tempo ao redor de equipes de software ou pensamento de operações modernas, você provavelmente encontrou Scrum — o framework que organiza trabalho em sprints fixos de duas semanas, com sessões de planejamento, retrospectivas, e funções definidas como Scrum Master e Product Owner. Muitas equipes tratam Scrum e Kanban como metodologias concorrentes e sentem que têm que escolher. A distinção é realmente mais simples que isso.

Muitas equipes — especialmente as que não são equipes puras de engenharia de software — acham a cerimônia de Scrum pesada e sua estrutura de sprint fixo desconfortável de aplicar ao trabalho operacional contínuo. Equipes de marketing, equipes de sucesso de cliente, equipes de operações, e fundadores gerenciando tudo de uma vez raramente têm trabalho que encaixa perfeitamente em ciclos de duas semanas. O modelo de fluxo contínuo de Kanban tende a se adequar melhor a eles.

Dito isto, muitas equipes combinam ambos. Eles usam ciclos de planejamento estilo sprint para desenvolvimento de produto enquanto executam um quadro Kanban para o trabalho operacional e de suporte que flui independentemente de qual sprint você está. Isso é um híbrido perfeitamente razoável.

As três perguntas que seu quadro deveria responder em trinta segundos

Um quadro Kanban é mais útil quando você pode observá-lo e, sem falar com ninguém, responder essas três perguntas rapidamente: Em que a equipe está trabalhando agora? Onde o trabalho está sendo travado? Há algo que deveria ser feito que não foi começado?

Se você não conseguir responder aos três dentro de trinta segundos de observar o quadro, provavelmente não está sendo mantido corretamente. O modo de falha mais comum é um quadro onde tarefas são criadas mas nunca se movem — se torna um cemitério de boas intenções em vez de um mapa vivo de trabalho real. Um quadro que não está atual é pior que nenhum quadro, porque cria uma falsa sensação de visibilidade.

A disciplina exigida para manter um quadro é real. Tarefas precisam se mover quando o trabalho se move. Itens bloqueados precisam ser sinalizados no momento em que travarem, não duas semanas depois. Cartões precisam ter proprietários claros, e proprietários precisam atualizar seus cartões. Nada disso requer muito tempo — uma prática Kanban bem executada pode levar cinco a dez minutos por pessoa por dia — mas requer consistência. As equipes que mais se beneficiam de Kanban são aquelas que tratam o quadro como a fonte de verdade, não como um exercício de manutenção de registros suplementar.

O que Kanban não faz

Kanban não é uma ferramenta de estratégia. Não vai ajudá-lo a descobrir em que trabalhar — apenas ajudá-lo a gerenciar o que você já decidiu trabalhar. Se sua organização tem um problema de priorização, ou um problema de mandato não claro, ou um problema de "começamos demasiados projetos antes de terminar os antigos" enraizado em comportamento de liderança em vez de processo, um quadro Kanban revelará esses problemas mas não os resolverá.

Também não é um substituto para uma boa gestão. Um quadro não substitui one-to-ones, ou delegação reflexiva, ou comunicação clara sobre por que certo trabalho importa. As equipes às vezes adotam ferramentas de processo esperando que o processo faça o trabalho relacional e organizacional que é realmente o trabalho do gerente. Não vai.

O que vai fazer é reduzir a incerteza ambiente que desacelera a maioria das equipes. As perguntas de "quem está trabalhando no quê," "isso está pronto," e "o que devo pegar em seguida" geram quantidades enormes de comunicação de baixo valor em organizações que não têm um sistema compartilhado e visível. Kanban elimina a maioria desse ruído. E para equipes onde esse ruído é o problema dominante, a diferença é significante.

Como começar — sem um workshop de três dias

As melhores implementações de Kanban que vi começaram pequeno e evoluíram. As piores envolveram um consultor, um retiro de dois dias, e um quadro belamente projetado que ninguém usava até a semana três.

Comece com sua equipe como realmente é, com o trabalho que você realmente tem. Crie três colunas: Backlog, Em Andamento, Pronto. Gaste trinta minutos com sua equipe colocando cada item de trabalho atual em um cartão. Concorde com uma regra: quando você começa algo, ele vai no quadro. Quando ele se move, você move o cartão. Não faça nada mais por duas semanas.

Após duas semanas, observe o quadro junto. Onde as coisas se acumularam? O que ficou em Backlog que todos disseram ser uma prioridade? O que se moveu mais rápido que o esperado? O que ficou preso e por quê? Use o que você observa para refinar as colunas e adicionar especificidade. Talvez "Em Andamento" precise se dividir em "Em Andamento" e "Esperando por Externo." Talvez você precise de uma coluna chamada "Em Revisão" porque esse passo continua sendo perdido. Deixe o quadro evoluir em resposta ao que seu trabalho real revela, não em resposta ao que um livro de metodologia diz que deveria parecer.

O jogo mais longo: métricas de fluxo

Uma vez que um sistema Kanban está em execução, ele gera dados que a maioria das equipes nunca usa. Tempo de lead — o tempo total desde quando uma tarefa é criada até quando é concluída — é o mais importante. Se seu tempo de lead médio para uma tarefa típica é doze dias, e você quer que seja cinco, você agora tem um número para trabalhar contra e um quadro que vai mostrar onde esses sete dias extras estão indo.

Tempo de ciclo mede apenas o período de trabalho ativo, excluindo o tempo que uma tarefa senta no backlog. Throughput mede quantos itens sua equipe completa por semana. Nenhuma dessas métricas requer software especial se você é disciplinado sobre anotar quando os cartões são criados e quando são fechados. E juntos, eles dão uma imagem muito mais honesta da capacidade de sua equipe que qualquer processo de planejamento baseado em estimativas pode.

A maioria das equipes pequenas e de médio porte nunca chega aqui. Eles usam Kanban como uma ferramenta de visibilidade — que é valiosa por si só — e não vão além. Está bem. Mas se você se encontra querendo fazer compromissos com stakeholders sobre quando algo será feito, ou querendo entender por que algum trabalho leva três vezes mais que o esperado, as métricas estão lá quando você precisa delas.