Kanban para Gestão de Projetos: fluxo, WIP e previsibilidade

Kanban como sistema de gestão de fluxo

Kanban é um sistema para gerenciar trabalho como um fluxo, do pedido até a entrega, com foco em visualizar como o trabalho realmente acontece, limitar o trabalho em progresso (WIP) para reduzir multitarefa e filas, e usar métricas para melhorar previsibilidade. Em gestão de projetos, isso ajuda a coordenar demandas contínuas (mudanças, correções, aprovações, entregas parciais) sem depender de “grandes lotes” e sem perder controle do prazo.

Princípios operacionais (o que faz Kanban funcionar)

• Visualizar o trabalho: tornar explícito o caminho do trabalho e onde ele fica parado.
• Limitar WIP: reduzir itens simultâneos para aumentar foco, diminuir filas e acelerar entregas.
• Gerenciar fluxo: observar gargalos, variabilidade e bloqueios; ajustar políticas e capacidade.
• Políticas explícitas: regras claras de entrada/saída de cada etapa, definição de pronto, prioridades e urgências.
• Cadências: rituais leves e frequentes para revisar fluxo, riscos e melhorias sem parar a operação.

Desenhando um quadro Kanban que represente o processo real

Um erro comum é desenhar um quadro “ideal” (como gostaríamos que fosse). O quadro precisa refletir o processo real para que as métricas e decisões sejam confiáveis.

Passo a passo: do processo ao quadro

1. Mapeie o caminho do trabalho (do pedido à entrega): liste as etapas reais pelas quais um item passa. Exemplo típico em projetos: Entrada → Análise → Pronto para Desenvolver → Em Desenvolvimento → Revisão/Testes → Pronto para Implantar → Implantado.
2. Identifique esperas e handoffs: onde o trabalho aguarda aprovação? onde troca de área? Essas esperas costumam ser a maior parte do lead time.
3. Defina colunas por estado, não por pessoa: colunas representam estados do trabalho. Evite colunas “João”, “Maria”.
4. Crie colunas de fila (buffer) quando necessário: separar “fazendo” de “pronto para” ajuda a enxergar filas. Exemplo: Em Desenvolvimento e Pronto para Revisão.
5. Inclua uma marca de compromisso (commitment point): onde o time assume que vai entregar. Ex.: ao mover de Entrada para Análise ou para Pronto para Desenvolver. Isso ajuda a medir previsibilidade do que foi realmente assumido.
6. Inclua uma marca de entrega (delivery point): onde o valor é considerado entregue (ex.: Implantado ou Entregue ao cliente).
7. Adicione “bloqueado” de forma explícita: use um sinal visual (tag/cor) e uma política: item bloqueado continua contando no WIP da coluna, para incentivar remoção de impedimentos.

Exemplo de quadro Kanban (modelo inicial)

Esse modelo é um ponto de partida. Ajuste para refletir seu contexto (ex.: incluir Aprovação Jurídica, Compra, Homologação, Treinamento).

WIP: como definir limites que melhoram fluxo e prazo

WIP (Work In Progress) é o trabalho iniciado e ainda não entregue. Quanto maior o WIP, maior a fila, maior o tempo de espera e menor a previsibilidade. Limites de WIP criam um “freio” saudável: antes de começar algo novo, termina-se o que já foi iniciado.

Onde colocar limites de WIP

• Por coluna: limite em Dev, Revisão/Testes, etc.
• Por faixa (swimlane): limites diferentes para urgências vs. trabalho padrão.
• Por classe de serviço: limitar quantos itens “Expedite” podem existir ao mesmo tempo (idealmente 1).

Passo a passo para definir WIP inicial

1. Comece simples: defina limites nas colunas onde há mais multitarefa (geralmente Dev e Revisão/Testes).
2. Use a capacidade real: se há 3 pessoas que fazem desenvolvimento, um limite inicial de Dev = 3 ou Dev = 4 costuma ser mais realista do que 10.
3. Proteja o gargalo: se Revisão/Testes é gargalo, limite o WIP antes dele para evitar “empurrar” trabalho e criar fila.
4. Defina a regra de puxar: só puxar novo item quando houver espaço no WIP e quando o item de entrada atender a política explícita.
5. Revise semanalmente: ajuste limites com base em dados (cycle time, bloqueios, filas).

Política prática quando o WIP estoura

• Parar de iniciar: ninguém puxa novo item para a coluna cheia.
• Swarm: o time se organiza para destravar e finalizar itens em andamento (ex.: ajudar testes, revisar PRs, remover bloqueios).
• Replanejar classes de serviço: se urgências estão consumindo tudo, limitar “Expedite” e renegociar prazos/escopo.

Políticas explícitas: regras que reduzem ambiguidade

Políticas explícitas são acordos visíveis que definem como o trabalho flui. Elas evitam discussões repetidas e tornam o sistema auditável.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Exemplos de políticas por coluna

• Análise: “Item só entra com objetivo claro, solicitante, impacto e critério de aceite mínimo.”
• Pronto p/ Dev: “História fatiada, dependências mapeadas, dados de teste disponíveis.”
• Dev: “Branch criada, testes unitários mínimos, revisão obrigatória antes de mover.”
• Revisão/Testes: “Checklist de regressão definido; se falhar, volta para Dev com causa registrada.”
• Pronto p/ Deploy: “Aprovações concluídas, janela de implantação definida, plano de rollback.”

Definições úteis

• Definition of Ready (DoR): o que precisa estar verdadeiro para iniciar.
• Definition of Done (DoD): o que precisa estar verdadeiro para considerar entregue no ponto de entrega.

Classes de serviço: como lidar com urgência sem destruir previsibilidade

Classes de serviço são categorias que definem regras de priorização e expectativa de prazo para diferentes tipos de demanda. Elas ajudam a equilibrar previsibilidade (trabalho padrão) com responsividade (urgências reais).

Classes de serviço comuns (com uso prático)

• Standard: trabalho normal. Regra: entra na fila e segue WIP. Meta: previsibilidade e estabilidade.
• Expedite: urgência crítica (incidente, risco alto). Regra: pode furar fila, mas limite rígido (idealmente 1 item). Exige registro do motivo e revisão posterior.
• Fixed Date: data fixa (evento regulatório, campanha). Regra: planejar “latest start date” com base em lead time histórico + margem; priorizar para cumprir a data.
• Intangible: melhorias que reduzem risco/tecnologia (refatoração, automação). Regra: reservar capacidade (ex.: 10–20% do throughput) para não virar “nunca”.

Passo a passo para implementar classes de serviço no quadro

1. Defina 3–4 classes no máximo para manter simples.
2. Crie uma legenda visível (cor/etiqueta) para cada classe.
3. Escreva políticas: quem pode declarar Expedite? o que caracteriza Fixed Date? qual o limite?
4. Crie swimlanes se necessário: uma faixa superior para Expedite/Fixed Date e outra para Standard/Intangible.
5. Monitore impacto: se Expedite aparece toda semana, não é exceção; é um problema de upstream, capacidade ou políticas.

Cadências Kanban: rituais leves para manter o sistema saudável

Cadências são reuniões curtas e regulares para inspecionar o fluxo e tomar decisões. O objetivo é manter o trabalho andando, não “prestar status”.

Cadências recomendadas (com objetivo e pauta)

• Replenishment (semanal ou 2x/semana): selecionar e preparar itens para entrar no sistema (antes do commitment point). Pauta: ordenar por valor/risco, checar DoR, dividir itens grandes.
• Daily Kanban (diária, 10–15 min): focar em bloqueios e envelhecimento de itens. Pauta: itens bloqueados, itens mais antigos, risco de estourar WIP, decisões de swarm.
• Service Delivery Review (quinzenal/mensal): revisar previsibilidade e desempenho do serviço. Pauta: lead time, throughput, itens por classe de serviço, causas de variação.
• Operations Review (mensal): alinhar dependências entre times/áreas e capacidade. Pauta: gargalos sistêmicos, políticas entre áreas, mudanças de capacidade.
• Risk Review (semanal/quinzenal): revisar riscos do fluxo (dependências, fornecedores, aprovações). Pauta: riscos por item, mitigação, prazos.

Métricas para previsibilidade: lead time, cycle time e throughput

Kanban usa métricas simples e operacionais para prever entregas com base no histórico do fluxo. O foco é medir o sistema, não “performance individual”.

Definições (com exemplo)

• Lead time: tempo do compromisso até a entrega. Ex.: do momento em que o item entra em Análise (commitment point) até Implantado.
• Cycle time: tempo em que o item está efetivamente em execução dentro do fluxo principal (muitas equipes medem de Dev até Implantado). Útil para enxergar eficiência da execução.
• Throughput: quantidade de itens entregues por unidade de tempo (ex.: 12 itens/semana). Base para previsões e planejamento de capacidade.

Como coletar (passo a passo)

1. Escolha pontos de início e fim (commitment e delivery) e mantenha consistência.
2. Registre datas automaticamente ao mover cartões (ou manualmente com disciplina).
3. Separe por classe de serviço: lead time de Expedite não deve “contaminar” Standard.
4. Use amostra mínima: comece analisando 20–30 itens concluídos para ter um histórico inicial.

Como usar as métricas para melhorar previsibilidade

• Previsão por percentis (SLE): defina uma expectativa de prazo baseada no histórico. Ex.: “85% dos itens Standard são entregues em até 12 dias”. Isso vira um Service Level Expectation (SLE) para orientar promessas.
• Controle de envelhecimento (aging): acompanhe itens que estão ficando “velhos” no fluxo. Regra prática: se um item ultrapassa o SLE parcial (ex.: 70% do prazo), ele vira prioridade de desbloqueio.
• Throughput para datas: se o throughput médio é 10 itens/semana e há 25 itens no compromisso, a ordem de grandeza é ~2,5 semanas (ajuste por variabilidade e classes de serviço).
• Identificar gargalos: se cycle time cresce em Revisão/Testes, o gargalo está ali; reduzir WIP antes e aumentar capacidade/automação pode estabilizar.

Tabela de exemplo: interpretando dados

Guia de implementação: começar com Kanban sem interromper a operação

Uma adoção bem-sucedida começa com o que já existe e melhora de forma incremental. O objetivo é ganhar controle do fluxo rapidamente, sem “parar para reorganizar tudo”.

Fase 1 — Inicial (1 a 5 dias): tornar o trabalho visível

1. Crie o quadro com o processo real (colunas e filas).
2. Cadastre todo o trabalho em andamento (WIP atual). Regra: se alguém está trabalhando, existe um cartão.
3. Marque bloqueios e registre causa (dependência, aprovação, ambiente, dúvida de requisito).
4. Defina um commitment point e pare de “assumir” trabalho fora dele.

Fase 2 — Estabilização (1 a 3 semanas): limitar WIP e puxar trabalho

1. Coloque limites de WIP nas 2–3 colunas mais críticas.
2. Implemente a regra de puxar: só iniciar com espaço no WIP e item pronto (DoR).
3. Daily Kanban focada em fluxo: itens bloqueados e mais antigos primeiro.
4. Comece a medir lead time e throughput com consistência.

Fase 3 — Previsibilidade (3 a 8 semanas): SLE e gestão por dados

1. Calcule percentis de lead time por classe de serviço e defina SLE.
2. Implemente aging: destaque itens que se aproximam de estourar o SLE.
3. Revise políticas onde há retrabalho (ex.: critérios de entrada em testes).
4. Faça Service Delivery Review para ajustar WIP, políticas e capacidade.

Melhoria contínua sem parar o fluxo (Kaizen no dia a dia)

Melhorar o sistema sem interromper a operação exige mudanças pequenas, testáveis e orientadas por evidências.

Rotina prática de melhoria contínua

1. Escolha um problema observável: fila crescendo em Revisão/Testes, muitos bloqueios por aprovação, itens grandes demais.
2. Formule uma hipótese: “Se limitarmos WIP em Dev e criarmos checklist de entrada em Testes, o cycle time reduzirá”.
3. Defina uma mudança pequena (1–2 semanas): ajustar WIP, adicionar coluna, criar política, automatizar um passo.
4. Meça antes e depois: lead time p85, throughput, % bloqueios, retrabalho.
5. Padronize se funcionou: transforme em política explícita e treine o time.
6. Reverta se piorou: Kanban favorece experimentos reversíveis.

Catálogo de melhorias comuns (com gatilho e ação)

• Gatilho: muitos itens “quase prontos” → Ação: reduzir WIP e adotar swarm para finalizar.
• Gatilho: fila antes de aprovações → Ação: criar coluna específica de aprovação, definir SLA de aprovadores, agendar cadência de aprovação.
• Gatilho: retrabalho em testes → Ação: política de DoR mais forte, checklist de qualidade, testes automatizados mínimos.
• Gatilho: itens grandes e imprevisíveis → Ação: fatiamento por valor/risco, limitar tamanho (ex.: política “até X dias de trabalho”).
• Gatilho: urgências frequentes → Ação: limitar Expedite, revisar causa raiz, reservar capacidade para incidentes.

Exemplo integrado: usando Kanban para prometer prazos com confiança

Imagine um projeto com demandas contínuas de evolução e correção. Após 6 semanas, o histórico mostra para itens Standard:

• Lead time p50: 7 dias
• Lead time p85: 12 dias
• Throughput médio: 10 itens/semana

Política de promessa: “Para itens Standard, comunicamos prazo com base no p85 (12 dias)”. Se entra um pedido Standard hoje no commitment point, a comunicação externa pode ser: previsão: até 12 dias úteis (ajuste para calendário). Se o item atingir 9 dias e ainda estiver em Dev, ele entra em aging e vira foco de desbloqueio/swarm. Se aparecer um Expedite, ele pode furar a fila, mas como há limite de 1, o impacto no throughput e no SLE é controlado e visível.