Fundamentos
Kanban e limites de WIP para colocar IA em produção
Kanban não é quadro de post-it: é limitar trabalho em progresso para o valor fluir. Como usar WIP limits na fila de experimentos e agentes de IA em produção.
Todo time que começa a colocar IA em produção descobre o mesmo problema por conta própria, sempre tarde: não falta ideia, sobra ideia pela metade. Há um piloto de atendimento parado esperando aprovação, um experimento de resumo que ninguém decidiu se promove ou mata, dois agentes que foram para produção e viraram órfãos, e mais três provas de conceito na fila. Nada está pronto, tudo está começado. É exatamente o problema que o Kanban resolve, e resolve com uma ideia que quase todo mundo que usa a palavra "kanban" ignora.
Kanban não é o quadro, é o limite
Kanban, no sentido que David J. Anderson formalizou para trabalho de conhecimento no livro de 2010, não é sinônimo de quadro com post-it. O quadro é a parte visível e a menos importante. O coração do método é limitar explicitamente o trabalho em progresso, o WIP (work in progress), e puxar trabalho novo apenas quando abre espaço. Você define, para cada etapa do fluxo, quantos itens podem estar ali ao mesmo tempo. Bateu o limite, ninguém começa nada novo até algo sair.
Parece uma restrição boba. É a coisa mais poderosa do método. Sem limite de WIP, um quadro Kanban é só um mural decorado: as mesmas dez tarefas abertas de sempre, agora em colunas coloridas. Com limite de WIP, o sistema te força a terminar antes de começar, e é essa obrigação que muda o comportamento do time.
Por que menos trabalho aberto termina mais rápido
A justificativa não é opinião, é a Lei de Little, um resultado de teoria de filas. Numa forma simples: o tempo médio para um item atravessar o sistema é igual à quantidade de itens em progresso dividida pela vazão. Traduzindo, quanto mais coisa você mantém aberta ao mesmo tempo, mais lento cada item individual fica para terminar. Não é que o time trabalha menos; é que a atenção se fragmenta, o custo de troca de contexto explode e tudo caminha junto, devagar.
Começar trabalho não entrega valor. Terminar trabalho entrega valor. O Kanban é a disciplina de lembrar disso quando a tentação de abrir mais um piloto aperta.
Para um time de IA, o efeito é direto. Cinco experimentos rodando em paralelo com uma pessoa dividida entre todos demoram mais para gerar aprendizado do que dois experimentos por vez, terminados de verdade antes de começar os próximos. A pressa de abrir tudo é o que atrasa a chegada de qualquer coisa à produção.
Puxar em vez de empurrar
O mecanismo prático do Kanban é o sistema puxado. No modelo empurrado, comum na maioria das áreas, o trabalho é jogado para dentro do time conforme aparece: mais uma ideia de IA do diretor, mais um pedido, mais um piloto. A fila só cresce. No modelo puxado, um item novo só entra quando outro sai. A capacidade do sistema, e não o apetite de quem pede, define quanto entra.
Aplicado a IA, isso significa uma regra desconfortável e saudável: uma nova prova de conceito só começa quando uma anterior for concluída, e concluída aqui tem duas saídas honestas, promover para produção ou matar com a lição registrada. "Encostar para ver depois" não conta como saída. Essa disciplina resolve o mal crônico dos times de IA, o cemitério de experimentos que nunca morreram nem viraram nada, drenando atenção só por continuarem tecnicamente abertos. É a mesma lógica de tratar cada ideia como hipótese que precisa ser validada ou descartada, agora com um limite físico que impede a fila de inchar.
Classes de serviço: o urgente não pode afogar o importante
O Kanban traz uma ferramenta que cai como uma luva na operação de IA: as classes de serviço. Nem todo item tem a mesma urgência nem o mesmo custo de atraso, então você os separa em classes com políticas diferentes. Um agente crítico já em produção, que quando quebra para o negócio, pertence a uma classe de resposta rápida, com prioridade sobre a fila. Um experimento exploratório, cujo atraso não machuca ninguém hoje, pertence a uma classe de fluxo normal. Uma correção de conformidade com prazo regulatório tem data fixa e política própria.
Sem essa separação, acontece o de sempre: o experimento barulhento do momento consome a atenção que deveria ir para o agente em produção que está degradando em silêncio. Classes de serviço tornam explícito o que na maioria dos times é decidido no grito, e conectam bem com a ideia de mapear onde o valor realmente flui, que já tratamos no service blueprint para IA em produção.
Como começar sem transformar tudo num projeto
A beleza do Kanban é que ele não pede reorganização. Você começa do jeito que o trabalho já é e evolui a partir dali. Um caminho enxuto para um time de IA:
Primeiro, visualize o fluxo real dos seus itens de IA, das ideias aos agentes em produção, com as etapas que existem de verdade, não as que o processo ideal diz existir. Segundo, meça quantos itens estão em cada etapa hoje; você quase certamente vai se assustar com a coluna "em progresso". Terceiro, imponha um limite de WIP modesto e um pouco incômodo, por exemplo no máximo dois experimentos ativos por pessoa, e segure a mão quando bater vontade de abrir o terceiro. Quarto, defina as saídas honestas de cada item, promover ou matar, e proíba o "encostar". Quinto, separe em pelo menos duas classes, produção crítica e exploração, com prioridades diferentes.
Nenhum desses passos exige ferramenta cara nem reunião nova. Exige a coisa mais difícil de todas, que é dizer "não vamos começar isso agora, porque ainda não terminamos aquilo". É a mesma coragem que separa quem redesenha o trabalho de quem só distribui licença de IA.
No fim, Kanban entrega para a operação de IA o que ela mais precisa e menos pratica: foco. Limitar o trabalho em progresso não é burocracia, é a forma mais barata de fazer o valor fluir num contexto em que a tentação de começar mais um piloto empolgante é infinita. O time que termina dois experimentos por mês vence o que começa dez e conclui nenhum, e o quadro só serve para tornar essa verdade impossível de ignorar.
Se o seu time tem mais experimentos de IA abertos do que consegue terminar, fale com a gente no WhatsApp para desenhar um fluxo com limite de WIP e classes de serviço que fazem a IA chegar à produção.
Perguntas frequentes
Kanban é só um quadro com colunas 'a fazer, fazendo, feito'?
Não, e essa confusão é a razão de a maioria dos times não colher o benefício. O quadro é só a parte visível. O motor do Kanban é limitar explicitamente quantos itens podem estar em cada etapa ao mesmo tempo (o WIP limit) e puxar trabalho novo só quando abre espaço. Sem limite de WIP, você tem um quadro bonito e a mesma bagunça de antes, agora colorida. Com limite, o sistema te obriga a terminar antes de começar, que é onde o ganho de fluxo aparece.
Como o Kanban ajuda um time que está colocando IA em produção?
Times de IA acumulam trabalho em progresso: muitos pilotos abertos, vários experimentos pela metade, agentes que foram para produção mas ninguém monitora. Kanban ataca isso limitando quantos experimentos podem rodar ao mesmo tempo, forçando a decisão de promover ou matar cada um, e separando por classe de serviço o que é crítico do que é exploratório. O resultado é menos coisa aberta, ciclos mais curtos e clareza sobre o que de fato está em produção versus o que só está encostado.