看板 — Tabuleta
Kanban (看板) é japonês. Os caracteres se dividem como: 看 (kan), ver, observar, & 板 (ban): tábu, prancha, sinal. Juntos: uma prancheta de sinal visual.
A palavra antecede o sistema de gestão em séculos. Toda loja no Japão do período Edo tinha um kanban: uma placa de madeira fora anunciando o que era vendido dentro. O sinal visual era o anúncio, o indicador de estoque & o gatilho de reordenação ao mesmo tempo.
A Insight de Supermercado de Taiichi Ohno
Na década de 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 empurrão , a produção corria conforme o agendado. Um prognóstico dizia "teremos necessidade de 500 unidades no próximo mês", então a fábrica fez 500 unidades & empurrou-as para uma prateleira. Se a demanda estava errada, a prateleira transbordava. Se a demanda excedeu o prognóstico, a prateleira estava vazia. De qualquer forma, alguém estava errado.
Supermercados funcionavam de forma diferente. As prateleiras mantinham uma quantidade fixa de cada item. Quando um cliente pegava a última lata de margarina, a vaga vazia era ela mesma o sinal de reordenação. Os funcionários de estoque não precisavam de um gerente para lhes dizer para reordenar: a prateleira lhes dizia. Este é o modelo de arrastar : sinais de demanda downstream determinam a reposição upstream.
Ohno levou esta insight de volta para a Toyota. A carta física (kanban) presa a um canto de peças se tornou o sinal: "este canto está vazio: produza mais". Necessitava de nenhum prognóstico. Necessitava de nenhum planeador central. O trabalho puxava-se para frente.
Empurrar vs. Puxar
A distinção empurrar/puxar é a base de tudo que segue.
Colunas como Estados
Uma prancheta Kanban torna o trabalho visível. Cada peça de trabalho é uma carta. As cartas se movem da esquerda para a direita através de colunas que representam estados.
As colunas clássicas são: Fila → Selecionado → Em Andamento → Revisão → Concluído
Mas as colunas exatas não importam. O que importa é que todo cartão tem exatamente um estado atual, e esse estado é visível a todos que trabalham nesse sistema.
O que uma carta representa
Uma carta representa uma unidade de trabalho que pode ser concluída independentemente. Não é um projeto. Não é um objetivo. É uma coisa específica, limitada com uma definição clara de conclusão.
Carta boa: Rotacionar chaves SSH nos servidores de produção: feito quando todos os servidores exibirem a nova chave em authorized_keys e a chave antiga for removida.
Carta ruim: Melhorar a segurança. (Isso é um projeto, não uma tarefa. Divida-o.)
Limites de WIP
A coluna Em Andamento na diagrama mostra um limite de WIP: 3. Isso significa que não mais do que três cartas podem estar em Andamento ao mesmo tempo. Se você quiser puxar uma quarta carta, deve concluí-la primeiro.
Isso parece como uma restrição. É: por design. Limites de WIP obrigam você a concluir o que começou antes de começar algo novo. Mais sobre por que isso importa em uma seção posterior.
Escopo de Cartas de Trabalho
A habilidade mais difícil no Kanban não é desenhar a prancheta. É o escopo das cartas. Muito grande e a carta fica em Andamento por semanas, bloqueando outros trabalhos. Muito pequeno e a prancheta fica cheia de ruído.
Alavancos Trabalham Bem
Qualquer operação com múltiplos discursos tem centros de trabalho funcionais: uma padaria tem doces, pão, saboroso e contração frontal. Um estúdio de produto tem design, conteúdo, construção e operações. Um projeto de construção tem embutidos, instalação de tubulações, eletricidade e acabamento. Esses centros existem por boas razões: a especialização profunda exige propriedade focada.
O Kanban não dissolve essas divisões. Ele torna as trocas de mão entre eles visíveis e explícitos.
A carta de transferência
Quando uma unidade de trabalho se move de um centro de trabalho para outro, por exemplo, um ativo de design que precisa de uma cópia escrita antes que o construtor possa montar a página, uma carta de transferência viaja com ele. O centro downstream vê a carta aparecer em seu Backlog. Eles a puxam quando têm capacidade. Nenhum e-mail é necessário. Nenhum encontro para coordenar. A carta é o sinal.
O que o diagrama mostra
O ★ ticket começa no Design (In Progress: visuais). Quando o Design termina sua parte, uma carta de transferência é criada e o ★ ticket aparece no Backlog do centro de construção. O Build o puxa. Então Ops o puxa. Cada centro tem sua própria tabuleta. Cada tabuleta mostra apenas a trabalho atual do centro. Mas o ★ viaja por todos eles e todos podem vê-lo.
Este é o insight da padaria aplicado a organizações: cada centro de trabalho é uma estante. As cartas abastecem apenas as estantes downstream quando o trabalho upstream é puxado e consumido.
Projeto de Transferência
A carta de transferência é o contrato entre os centros de trabalho. Deve conter o suficiente contexto para que a equipe receptoră possa agir sem uma reunião.
Parar de Iniciar. Comece a Concluir.
WIP significa Trabalho em Andamento. Um limite de WIP é um teto na quantidade de cartas que podem estar em uma coluna específica ao mesmo tempo.
Isso soa como uma restrição. É. Isso é o ponto.
Por que os limites ajudam
A cada vez que você começa uma nova tarefa sem terminar a anterior, você paga uma taxa de troca de contexto. Seu cérebro carrega o contexto da nova tarefa e descarrega parcialmente a velha. Quando você retorna à tarefa antiga, você a carrega novamente. Para o trabalho do conhecimento, escrever, depurar, desenhar, revisar, esse custo de recarregamento é medido em horas, não em segundos.
Limites de trabalho em andamento evitam a acumulação de trabalho incompleto. Eles também fazem algo ainda mais valioso: tornam visíveis gargalos.
Gargalos se tornam visíveis
Se a coluna de Revisão tiver um limite de trabalho em andamento de 2 e sempre estiver em 2, isso é um sinal: a revisão é mais lenta do que a produção. Mais trabalho está sendo concluído na Etapa de Progresso do que pode ser consumido pela Revisão. Sem um limite de trabalho em andamento, a tabela é preenchida com cartões 'concluídos, mas esperando revisão' e o gargalo é invisível. Com um limite de trabalho em andamento, a coluna de Etapa de Progresso não pode aceitar novos cartões, e todo o time vê a restrição.
Isso não é um fracasso. É informação. O sistema está te dizendo para corrigir a Revisão, contratar, programar, reduzir o tamanho do lote, em vez de empurrar mais trabalho automaticamente.
Lei de Little (informalmente)
Tempo médio de ciclo (tempo que um cartão leva para ser concluído, do início ao fim) = Trabalho em andamento ÷ Taxa de throughput (cartões concluídos por unidade de tempo). Se você quiser tempos de ciclo mais curtos sem contratar, reduza o trabalho em andamento. Menos coisas em andamento significa que cada coisa é concluída mais rapidamente.
R = (W × C) + T
Limites de trabalho em andamento protegem três variáveis. O consultor de eficiência Brian Tracy nomeou-as em 1986.
R = (W × C) + T
- R: Resultado: o resultado que você deseja
- W: Claridade do objetivo: quanto você sabe exatamente 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 e C multiplicam
Claridade e concentração não são independentes. Alta concentração em um objetivo vago produz rápido movimento na direção errada. Objetivo perfeitamente claro sem concentração produz nada. Eles interagem: é por isso que Tracy os escreveu como um produto, não como uma soma. Um 9/10 em cada um dá R = 81 + T. Um 3/10 em cada um dá R = 9 + T. A diferença não é aditiva.
Por que T soma
Cada hora sem distrações adiciona linearmente ao resultado. T não pode multiplicar W e C: ele pode apenas empilhar-se sobre o produto. Isso explica por que a primeira movimentação sempre é melhorar W e C, não trabalhar mais horas. Mais T em uma baixa (W × C) produto ainda é um resultado ruim.
O que o quadro Kanban faz para cada variável
- W: Um cartão bem escopo (título claro, critérios de aceitação mediáveis, proprietário único) aumenta W antes do trabalho começar. Cartões vagos reduzem automaticamente.
- C: Limites de trabalho em andamento forçam concentração. Um cartão na coluna Ativa significa atenção total em um único problema. Três cartões na coluna Ativa significa que a C é dividida em três partes.
- T: Blocos Pomodoro e proteção do calendário criam as horas sem distrações que o T mede. O cronômetro da mesa não é decoração: ele rastreia o T em tempo real.
Tracy afirmou que qualquer problema poderia ser resolvido em 30 minutos quando W, C, & T são otimizados. A mesa Kanban é o instrumento para otimizar os três simultaneamente.
Lendo a Mesa
Ajudar a ler gargalos a partir do estado da mesa.
Não Ágil. Não Cascata.
Ágil é uma metodologia. Cascata é uma metodologia. Kanban é um sistema.
As metodologias prescrevem como você trabalha. Os sistemas descrevem o que é verdade sobre o trabalho. O Kanban não diz para você ter sprints de duas semanas, reuniões diárias ou retrospectivas. Ele lhe diz uma coisa: torne o trabalho visível, limite WIP e puxe.
O problema com as metodologias
O Agile funciona bem para equipes que construem produtos iterativamente, softwares, na maioria das vezes. O Cascata funciona bem para projetos com requisitos fixos e conhecidos desconhecidos, construção, manufatura de hardware. Nenhum deles se mapeia de forma limpa para trabalho interdisciplinar onde uma tarefa de design e uma tarefa de atendimento têm ciclos de tempo completamente diferentes e definições de 'feito.'
Forçar um centro de design e um centro de operações 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 no trabalho de logística. Um ritual de pé de mesa construído para equipes co-localizadas cria sobreposição de trabalho para solitários independentes.
Encontre o terreno comum na obra a ser feita
A abordagem do un: encontre a obra que precisa ser feita. Encontre as pessoas ou parceiros melhor posicionados para fazê-la. Não imponha um processo em cima disso: deixe a obra surgir seu próprio processo através de um sistema de visibilidade compartilhada.
Isso não é a ausência de processo. É a quantidade certa de processo: o suficiente para coordenar, mas não o suficiente para criar sobrecarga de coordenação que excede o valor do trabalho.
Não construa o que pode ser comprado. Não compre o que pode crescer.
Antes de qualquer cartão de trabalho ser criado, pergunte: este deveria existir no máximo? Toda peça de trabalho que você construir, será de propriedade eterna. Toda SaaS a que você se inscreve, depende eternamente. Toda dependência de código-fonte aberto que você forque, manterá eternamente.
A árvore de decisão: Nós podemos crescer isso? Um processo, uma habilidade, uma relação que produz a capacidade de forma sustentável, prefira isso. Se o crescimento não for viável: Podemos comprar isso? Uma ferramenta de prateleira que resolve 80% do problema sem trabalho personalizado, prefira isso. Se a compra não for viável: Construa-o. E construa-o sabendo que agora é dele.
A maioria das organizações inverte esta ordem. Eles construem infraestrutura personalizada para problemas que ferramentas de comércio resolvem bem, então correm para manter o que construíram. O kanban torna isso visível: cada carta na sua Backlog é algo que você escolheu construir. A pergunta honesta é se deveria estar lá no máximo.
Build / Buy / Grow
Aplicar o framework de decisão.
Desenhe uma Tabuleiro
Ponha tudo junto. Você vai desenhar um sistema de kanban para um cenário cross-functional específico.
Cenário
Uma pequena estúdio está relançando seu produto com uma nova marca. O trabalho envolve quatro centros:
- Design: novo logotipo, identidade visual, fotografia do produto, layout de páginas
- Content: redescrições do produto reescritas, texto para página de landing, e-mail de anúncio
- Build: atualização do site, novo fluxo de checkout, redirecionamentos de URLs antigas
- Ops: configurações atualizadas do processador de pagamentos, briefing do parceiro de atendimento, reconfiguração de análise
A relançamento tem um prazo rigoroso: um feira de comércio em 45 dias onde a nova marca vai público.
Solos Ficam Silos
Na maioria das organizações, o Kanban existe para tornar o trabalho visível através de uma hierarquia de gestão. Os gerentes coordenam entre silos. O Kanban reduz a sobrecarga de coordenação.
No modelo un, não há gerentes. Há solos. Um solo opera uma empresa independentemente: um designer solo, um construtor solo, um escritor solo, um solo de operações. Cada solo é, por definição, um silo. Não há organograma os conectando. Nenhuma relação de relatório. Nenhum gerente para forçar a coordenação.
O Kanban se torna a camada de coordenação. Não ao nivelar os silos, os solos permanecem totalmente independentes, mas tornando as entregas entre eles visíveis e explícitas. Um solo não envia um e-mail ou agendar uma reunião para entregar o trabalho. Eles colocam um cartão em um tabuleiro compartilhado. O solo receptor puxa quando tiver capacidade.
Isso explica por que o Kanban se encaixa melhor no modelo un do que no ágil ou cascata: não requer nenhum ritmo compartilhado, nenhuma retrospectiva conjunta, nenhuma planificação sincronizada. Cada solo define seus próprios limites de trabalho em andamento, seus próprios ciclos de tempo, suas próprias definições de conclusão. A coordenação acontece no nível do cartão, não no nível do processo.