看板 — Placa de Sinalização
Kanban (看板) é uma palavra japonesa. Os caracteres se dividem em: 看 (kan), ver, observar, & 板 (ban): tábua, prancha, sinal. Juntos: uma placa de sinalização visual.
A palavra é anterior ao sistema de gestão por séculos. Toda loja na Edo-period Japan possuía um kanban: uma placa de madeira fora anunciando o que era vendido. O sinal visual era o anúncio, o indicador de inventário, & o gatilho de recompra tudo ao mesmo tempo.
O Insight de Supermercado de Taiichi Ohno
Nos anos 1950, o engenheiro da Toyota Taiichi Ohno visitou supermercados americanos. O que ele viu mudou a história da manufatura.
Em uma fábrica tradicional, o modelo de push, a produção corria em um cronograma. Uma previsão dizia "precisaremos de 500 unidades no próximo mês," então a fábrica fazia 500 unidades & as empurrava para uma prateleira. Se a demanda estava errada, a prateleira transbordava. Se a demanda excedia a previsão, a prateleira ficava vazia. De qualquer forma, alguém estava errado.
Supermercados funcionavam diferentemente. As prateleiras mantinham uma quantidade fixa de cada item. Quando um cliente levava o último pote de manteiga de amendoim, o espaço vazio era em si o sinal de recompra. Os funcionários de reposição não precisavam de um gerente lhes dizendo para reabastecer: a prateleira lhes dizia. Este é o modelo de pull: a demanda downstream sinaliza o reabastecimento upstream.
Ohno levou este insight de volta para a Toyota. O cartão físico (kanban) anexado a um bin de peças se tornou o sinal: "este bin está vazio: produza mais." Sem previsão. Sem planejador central. O trabalho se puxa para frente.
Push vs. Pull
A distinção push/pull é a fundação de tudo que segue.
Colunas como Estados
Um quadro kanban torna o trabalho visível. Cada pedaço de trabalho é um cartão. Os cartões se movem da esquerda para a direita através de colunas que representam estados.
As colunas clássicas são: Backlog → Selecionado → Em Progresso → Revisão → Concluído
Mas as colunas exatas não importam. O que importa é que cada cartão tem exatamente um estado atual, & esse estado é visível para todos que trabalham nesse sistema.
O que um cartão representa
Um cartão representa uma unidade de trabalho que pode ser completada independentemente. Não um projeto. Não um objetivo. Uma coisa específica & circunscrita com uma definição clara de concluído.
Bom cartão: Rodar chaves SSH em servidores prod: concluído quando todos os servidores mostram nova chave em authorized_keys & chave antiga foi removida.
Cartão ruim: Melhorar segurança. (Isso é um projeto, não uma tarefa. Divida.)
Limites WIP
A coluna Em Progresso no diagrama mostra um limite WIP: 3. Isso significa que não mais que três cartões podem estar Em Progresso ao mesmo tempo. Se você quer puxar um quarto cartão, deve terminar um primeiro.
Isso parece uma restrição. É: por design. Os limites WIP forçam você a terminar o que começou antes de começar algo novo. Mais sobre por que isso importa em uma seção posterior.
Escopo de Cartões de Trabalho
A habilidade mais difícil em kanban não é desenhar o quadro. É colocar escopo nos cartões. Muito grande & um cartão fica Em Progresso por semanas, bloqueando outro trabalho. Muito pequeno & o quadro se enche de ruído.
Silos Funcionam Bem
Qualquer operação multidisciplinar tem centros de trabalho funcionais: uma padaria tem pastelaria, pão, salgado, & balcão. Um estúdio de produtos tem design, conteúdo, build, & ops. Um canteiro de obras tem estrutura, encanamento, elétrica, & acabamento. Estes centros existem por boas razões: especialização profunda requer propriedade focada.
Kanban não dissolve estas divisões. Torna as passagens entre elas visíveis & explícitas.
O cartão de passagem
Quando uma unidade de trabalho se move de um centro de trabalho para outro, digamos, um asset de design que precisa de copy escrita antes do builder poder montar a página, um cartão de passagem viaja com ele. O centro downstream vê o cartão aparecer em seu Backlog. Eles o puxam quando têm capacidade. Nenhum email necessário. Nenhuma reunião para coordenar. O cartão é o sinal.
O que o diagrama mostra
O cartão ★ começa em Design (Em Progresso: assets visuais). Quando Design termina sua parte, um cartão de passagem é criado & o cartão ★ aparece no Backlog do centro Build. Build o puxa. Então Ops o puxa. Cada centro tem seu próprio quadro. Cada quadro mostra apenas o trabalho atual daquele centro. Mas o ★ viaja através de todos eles, & todos podem ver onde ele está.
Este é o insight do supermercado aplicado às organizações: cada centro de trabalho é uma prateleira. Os cartões reabastecem as prateleiras downstream apenas quando o trabalho upstream é puxado & consumido.
Projetando uma Passagem
O cartão de passagem é o contrato entre centros de trabalho. Deve conter contexto suficiente para que a equipe receptora aja sem uma reunião.
Pare de Começar. Comece a Terminar.
WIP significa Work In Progress. Um limite WIP é um limite em quantos cartões podem estar em uma coluna específica ao mesmo tempo.
Isso parece uma restrição. É. Esse é o ponto.
Por que os limites ajudam
Toda vez que você começa uma nova tarefa sem terminar a anterior, você paga um custo de troca de contexto. Seu cérebro carrega o contexto da nova tarefa & descarrega parcialmente a antiga. Quando você volta para a tarefa antiga, você a recarrega. Para trabalho de conhecimento, escrita, debugging, design, revisão, este custo de recarga é medido em horas, não segundos.
Os limites WIP impedem o acúmulo de trabalho inacabado. Eles também fazem algo mais valioso: eles trazem à superfície os gargalos.
Gargalos ficam visíveis
Se a coluna Revisão tem um limite WIP de 2 & está sempre em 2, é um sinal: revisão é mais lenta que a produção. Mais trabalho está completando Em Progresso do que pode ser consumido por Revisão. Sem um limite WIP, o quadro se enche com cartões 'concluído-mas-esperando-revisão' & o gargalo é invisível. Com um limite WIP, a coluna Em Progresso não pode aceitar novos cartões, & todo o time vê a restrição.
Isso não é uma falha. É informação. O sistema está lhe dizendo para corrigir Revisão, contratar, parear, reduzir o tamanho do lote, em vez de cegamente empurrar mais trabalho através.
Lei de Little (informalmente)
Lead time (quanto tempo um cartão leva do início ao fim) = Work In Progress ÷ Throughput (cartões completados por unidade de tempo). Se você quer tempos de lead mais curtos sem contratar, reduza WIP. Menos coisas em voo significa que cada coisa termina mais rápido.
R = (W × C) + T
Os limites WIP protegem três variáveis. O consultor de eficiência Brian Tracy as nomeou em 1986.
R = (W × C) + T
- R: Resultado: o resultado que você quer
- W: Clareza de objetivo: quão precisamente você sabe o que quer (0–10)
- C: Concentração: intensidade de esforço focado (0–10)
- T: Tempo trabalhado sem distrações (horas ininterruptas)
Por que W & C se multiplicam
Clareza & concentração não são independentes. Alta concentração em um objetivo vago produz movimento rápido na direção errada. Clareza perfeita de objetivo sem concentração produz nada. Eles interagem: é por isso que Tracy os escreveu como um produto, não uma soma. Um 9/10 em cada dá R = 81 + T. Um 3/10 em cada dá R = 9 + T. A diferença não é aditiva.
Por que T se soma
Cada hora sem distrações adiciona linearmente ao resultado. T não pode compor W & C: só pode se empilhar no topo do produto. Isto explica por que o primeiro movimento é sempre melhorar W & C, não trabalhar mais horas. Mais T em um produto baixo (W × C) ainda é um resultado pobre.
O que o quadro kanban faz para cada variável
- W: Um cartão bem escopo (título claro, critérios de aceitação mensuráveis, proprietário único) eleva W antes do trabalho começar. Cartões vagos o abaixam automaticamente.
- C: Os limites WIP forçam concentração. Um cartão em Active significa atenção total em um problema. Três cartões em Active significa que C é dividido em três.
- T: Blocos Pomodoro & proteção de calendário criam as horas ininterruptas que T mede. O timer do quadro não é decoração: rastreia T em tempo real.
Tracy afirmava que qualquer problema poderia ser resolvido em 30 minutos quando W, C, & T estão todos otimizados. O quadro kanban é o instrumento para otimizar todos os três simultaneamente.
Lendo o Quadro
Pratique lendo gargalos do estado do quadro.
Não é Agile. Não é Waterfall.
Agile é uma metodologia. Waterfall é uma metodologia. Kanban é um sistema.
Metodologias prescrevem como você trabalha. Sistemas descrevem o que é verdadeiro sobre o trabalho. Kanban não lhe diz para ter sprints de duas semanas, standups diários, ou retrospectivas. Ele diz uma coisa: torne o trabalho visível, limite WIP, & puxe.
O problema com metodologias
Agile funciona bem para equipes construindo produtos iterativamente, software, principalmente. Waterfall funciona bem para projetos com requisitos fixos & desconhecimentos conhecidos, construção, manufatura de hardware. Nenhum mapeia com limpeza para trabalho multidisciplinar onde uma tarefa de design & uma tarefa de fulfillment têm ciclos de tempo completamente diferentes & definições de 'concluído.'
Forçar um centro de design & um centro de ops no mesmo ritmo de sprint é um erro de categoria. Um sprint de duas semanas que funciona para criação de conteúdo produz urgência artificial em trabalho de logística. Um ritual de standup construído para equipes co-localizadas cria overhead para solos independentes.
Encontre terreno comum sobre o trabalho a ser feito
A abordagem un: encontre o trabalho que precisa ser feito. Encontre as pessoas ou parceiros mais bem posicionados para fazê-lo. Não imponha um processo no topo disso: deixe o trabalho trazer seu próprio processo através de um sistema de visibilidade compartilhada.
Isto não é a ausência de processo. É a quantidade certa de processo: o suficiente para coordenar, não o suficiente para criar overhead de coordenação que exceda o valor do trabalho.
Não construa o que você pode comprar. Não compre o que você pode crescer.
Antes de qualquer cartão de trabalho ser criado, pergunte: isso deveria existir? Cada pedaço de trabalho que você constrói, você o possui para sempre. Cada SaaS que você assina, você depende para sempre. Cada dependência de código aberto que você faz fork, você mantém para sempre.
A árvore de decisão: Conseguimos crescer isso? Um processo, uma habilidade, uma relação que produz a capacidade sustentavelmente, prefira isso. Se crescer não é viável: Conseguimos comprar isso? Uma ferramenta off-the-shelf que resolve 80% do problema sem trabalho customizado, prefira isso. Se comprar não é viável: Construa. & construa sabendo que você agora o possui.
A maioria das organizações inverte essa ordem. Eles constroem infraestrutura customizada para problemas que ferramentas commodity resolvem bem, depois se apressam para manter o que construíram. Kanban torna isso visível: cada cartão em seu Backlog é uma coisa que você escolheu construir. A questão honesta é se deveria estar lá.
Construir / Comprar / Crescer
Aplique o framework de decisão.
Desenhe um Quadro
Coloque tudo junto. Você vai desenhar um sistema kanban para um cenário multidisciplinar específico.
Cenário
Um pequeno estúdio está relançando seu produto com uma nova marca. O trabalho envolve quatro centros:
- Design: novo logo, identidade visual, fotografia de produtos, layouts de página
- Conteúdo: descrições de produtos reescritas, copy de página de destino, anúncio de email
- Build: website atualizado, novo fluxo de checkout, redirecionamentos de URLs antigas
- Ops: configurações atualizadas do processador de pagamento, briefing do parceiro de fulfillment, reconfiguração de analytics
O relançamento tem um deadline duro: uma feira comercial em 45 dias onde a nova marca vai ao público.
Solos Permanecem Silos
Na maioria das organizações, kanban existe para tornar o trabalho visível através de uma hierarquia de gestão. Gerentes coordenam entre silos. Kanban reduz o overhead de coordenação.
No modelo un, não há gerentes. Há solos. Um solo opera uma empresa independentemente: um designer solo, um builder solo, um escritor solo, um ops solo. Cada solo é, por definição, um silo. Não há organograma conectando-os. Nenhuma relação de reporte. Nenhum gerente para forçar coordenação.
Kanban se torna a camada de coordenação. Não por achatar silos, solos permanecem totalmente independentes, mas por tornar as passagens entre eles visíveis & explícitas. Um solo não envia um email ou agenda uma reunião para passar trabalho. Eles colocam um cartão em um quadro compartilhado. O solo receptor o puxa quando tem capacidade.
Isto explica por que kanban se encaixa melhor no modelo un do que agile ou waterfall: não requer cadência compartilhada, sem retros conjuntas, sem planejamento sincronizado. Cada solo define seus próprios limites WIP, seu próprio tempo de ciclo, sua própria definição de concluído. Coordenação acontece no nível do cartão, não no nível do processo.