Termos usados no Kanban System

Acompanhe conosco o dicionário ubíquo sobre os termos usados no Kanban:

1. Conceitos de Negócio e Valor (O "Porquê")

• Iniciativa Estratégica: Um objetivo de negócio de alto nível, com duração de meses ou trimestres (ex: "Expandir para o mercado de Fintechs", "Reduzir o churn de clientes em 15%"). Uma Iniciativa gera um ou mais Projetos.

• Projeto/Produto: Um esforço concreto para atender a uma Iniciativa Estratégica ou um contrato de cliente. Possui um escopo e um time associado.

• Feature (Funcionalidade): Uma unidade de valor perceptível para o cliente ou usuário final. É grande demais para ser um único card no board de desenvolvimento, sendo quebrada em Itens de Trabalho menores. Ex: "Pagamento via Pix no checkout".

• Stakeholder (Parte Interessada): Qualquer pessoa com interesse no resultado de um Projeto, incluindo o cliente (Product Owner), usuários finais e patrocinadores.

2. Itens de Trabalho (O "Quê")

• Item de Trabalho (Work Item): A unidade fundamental de entrega que flui pelo nosso Kanban Board. É representado por um card. Existem diferentes tipos de Item de Trabalho:

• História de Usuário (User Story): Descreve uma necessidade do usuário, focada em valor. Formato: "Como um [ator], eu quero [ação], para que [benefício]".

• Tarefa Técnica (Technical Task): Uma atividade necessária que não entrega valor direto ao usuário, mas habilita outras funcionalidades (ex: "Configurar pipeline de CI/CD", "Atualizar biblioteca de segurança").

• Bug: Um comportamento incorreto do software em produção que precisa ser corrigido.

• Débito Técnico (Tech Debt): Um Item de Trabalho criado para corrigir atalhos ou design pobre no código, visando melhorar a manutenibilidade e a qualidade a longo prazo.

• Spike/Estudo: Um Item de Trabalho com tempo limitado (time-boxed) para pesquisa e prova de conceito, cujo objetivo é reduzir incertezas técnicas ou de negócio.

3. O Fluxo de Trabalho (O "Como")

Nosso fluxo é dividido em dois sistemas principais:

• Upstream Kanban (Fluxo de Descoberta): O processo de refinar ideias e prepará-las para o desenvolvimento.

• Funil de Ideias (Ideas Funnel): Repositório de todas as Features e ideias brutas.

• Análise (Analysis): Estágio onde uma Feature é avaliada quanto à sua viabilidade, impacto e risco.

• Backlog: Uma lista ordenada de Itens de Trabalho que já foram refinados e atendem à nossa Definição de Pronto. É daqui que o time de desenvolvimento puxa o trabalho.

• Downstream Kanban (Fluxo de Entrega): O processo de construir e entregar o Item de Trabalho.

• Pronto para Dev (Ready for Dev): Coluna de entrada do time de desenvolvimento. Itens aqui estão prontos para serem puxados.

• Em Desenvolvimento (In Development): O Item de Trabalho está sendo ativamente codificado e testes unitários estão sendo criados.

• Validação (Validation/QA): O Item de Trabalho está sendo validado pela equipe de qualidade ou por pares (testes de aceitação, testes exploratórios).

• Pronto para Deploy (Ready to Deploy): O Item de Trabalho foi integrado à base de código principal e está pronto para ser liberado em produção.

• Entregue (Done): O Item de Trabalho está em produção e disponível para os usuários.

4. Políticas do Sistema (As "Regras")

• Limites WIP (WIP Limits): O número máximo de Itens de Trabalho permitidos em cada coluna do Fluxo de Entrega. É a nossa principal ferramenta para evitar sobrecarga e promover o fluxo.

• Definição de Pronto (Definition of Ready - DoR): Um checklist que um Item de Trabalho deve cumprir para ser movido para a coluna Pronto para Dev. Garante que o time não comece a trabalhar em algo mal especificado.

• Definição de Feito (Definition of Done - DoD): Um checklist que um Item de Trabalho deve cumprir para ser considerado Entregue. Garante a qualidade e o alinhamento sobre o que significa "terminar".

• Classes de Serviço (Classes of Service): Categorias que usamos para priorizar Itens de Trabalho com base em seu custo de atraso.

• Urgente (Expedite): Problema crítico em produção. Passa na frente de tudo. Possui seu próprio limite WIP (geralmente 1).

• Data Fixa (Fixed Date): Possui uma data limite inadiável. Requer planejamento para ser entregue a tempo.

• Padrão (Standard): Itens de Trabalho normais, que são puxados conforme a capacidade.

• Intangível (Intangible): Itens importantes, mas sem um custo de atraso óbvio (ex: a maioria dos Débitos Técnicos).

5. Métricas de Fluxo (As "Medidas")

• Lead Time: O tempo total desde que um Item de Trabalho é movido para o Backlog até ser Entregue. É a nossa medida de previsibilidade para o cliente.

• Cycle Time: O tempo que um Item de Trabalho leva para atravessar o Fluxo de Entrega (de Pronto para Dev até Entregue). Mede a velocidade do nosso processo interno.

• Throughput (Vazão): O número de Itens de Trabalho entregues por unidade de tempo (ex: por semana). Mede a nossa capacidade.

• Idade do Trabalho (Work Item Age): O tempo que um Item de Trabalho está no seu estágio atual. Usamos para identificar itens bloqueados ou envelhecidos.

• Diagrama de Fluxo Cumulativo (CFD): Nosso principal gráfico para visualizar o WIP, o Lead Time aproximado e a Vazão ao longo do tempo, mostrando a saúde do nosso fluxo.

6. Cadências (As "Reuniões")

• Kanban Meeting (Daily): Reunião diária rápida, focada em gerenciar o fluxo. Caminhamos pelo board (da direita para a esquerda) e perguntamos: "O que podemos fazer para mover estes itens?", "O que está bloqueando este item?".

• Reunião de Reabastecimento (Replenishment Meeting): Reunião, geralmente semanal, para puxar Itens de Trabalho do Funil de Ideias para o Backlog, garantindo que eles atendam à Definição de Pronto.

• Revisão de Serviço (Service Delivery Review): Reunião com os Stakeholders para analisar as métricas de fluxo (Lead Time, Throughput) e discutir se estamos atendendo às suas expectativas. Foco no desempenho do serviço, não apenas na demonstração de Features.

• Revisão de Risco (Risk Review): Focada em analisar e mitigar os bloqueadores e dependências que afetam nosso fluxo.

A Diferença Crucial entre Outputs (Entregas) e Outcomes (Resultados)

A distinção entre Outputs (Entregas) e Outcomes (Resultados) é uma das mudanças de mentalidade mais importantes em uma software house moderna e se encaixa perfeitamente na filosofia de entrega de valor do Kanban.

Este documento esclarece dois dos termos mais fundamentais no desenvolvimento de produtos modernos. Compreender essa diferença é o que separa uma "fábrica de funcionalidades" de uma organização que gera impacto real.

1. Outputs (O Que Nós Fizemos)

Outputs são as coisas tangíveis e mensuráveis que produzimos. São os entregáveis, o resultado direto do nosso trabalho e esforço. Outputs respondem à pergunta: "O que nós construímos?".

• Foco: Atividade e entrega.

• Natureza: São concretos e fáceis de contar.

• Exemplos em uma Software House:

• Uma nova tela de login.

• Uma API de integração com um parceiro.

• A correção de 10 bugs.

• Um relatório de performance em PDF.

• O deployment de uma nova versão do software.

• O código escrito e enviado para o repositório.

Como são medidos: Métricas de processo e fluxo, como Throughput (vazão), Cycle Time, velocidade (velocity) e número de funcionalidades entregues por mês.

O Risco do Foco em Outputs: Uma equipe pode ter um Throughput altíssimo, entregando dezenas de Itens de Trabalho por semana, e ainda assim não gerar nenhum valor para o cliente ou para o negócio. Estar ocupado não significa ser eficaz.

2. Outcomes (A Diferença que Fizemos)

Outcomes são as mudanças mensuráveis no comportamento do usuário ou em métricas de negócio que ocorrem como resultado do uso dos nossos outputs. Outcomes respondem à pergunta: "Que impacto nossa entrega causou?".

• Foco: Valor e impacto.

• Natureza: São consequências, muitas vezes observadas ao longo do tempo.

• Exemplos (correspondentes aos outputs acima):

• Outcome: Redução de 30% nas solicitações de suporte por "esqueci minha senha" (mudança no comportamento do usuário).

• Outcome: Aumento de 15% em novos clientes vindos através da integração com o parceiro (métrica de negócio).

• Outcome: Aumento da nota de satisfação do cliente (CSAT) de 4.1 para 4.5.

• Outcome: Os diretores tomaram uma decisão de investimento mais rápida e informada (mudança de comportamento).

• Outcome: Aumento de 10% na taxa de retenção de usuários no primeiro mês.

Como são medidos: Indicadores Chave de Performance (KPIs), Objetivos e Resultados-Chave (OKRs), métricas de engajamento, taxas de conversão, satisfação do cliente (CSAT/NPS), redução de custos, aumento de receita.

A Meta Principal: O objetivo de uma equipe de produto/desenvolvimento moderna é gerar Outcomes. Os Outputs são apenas as hipóteses de como chegaremos lá.

Tabela Comparativa Rápida

Característica	Outputs (Entregas)	Outcomes (Resultados)
Foco	Atividade, "fazer coisas"	Impacto, "mudar coisas"
Responde à Pergunta	"O que nós fizemos?"	"Que diferença isso fez?"
Como é Medido	Quantidade, velocidade, vazão.	KPIs, OKRs, métricas de negócio.
Exemplo	Entregar um novo carrinho de compras.	Aumentar a taxa de conversão de vendas em 20%.
Risco	Ser uma "fábrica de funcionalidades".	Requer paciência e boa medição.
Quem Pede	Um stakeholder imaturo.	Um parceiro de negócio estratégico.

Como Isso se Conecta ao seu Kanban System?

A integração dessa mentalidade é o que torna um Kanban System verdadeiramente poderoso.

1. No Upstream Kanban (Fluxo de Descoberta):

2. Cada Feature ou Iniciativa que entra no sistema não deve ser apenas uma "ideia legal". Ela deve ser formulada como uma hipótese de outcome:"Nós acreditamos que construir [Output: um dashboard de métricas em tempo real] para os [Usuários: gerentes de vendas] resultará em [Outcome: redução do tempo gasto para criar relatórios semanais em 3 horas]."

3. Na Reunião de Reabastecimento (Replenishment):

4. A priorização dos Itens de Trabalho no Backlog deve ser baseada no potencial de gerar os outcomes mais valiosos, e não apenas na facilidade de implementação do output.

5. Na Revisão de Serviço (Service Delivery Review):

6. A conversa com os stakeholders evolui. Em vez de apenas dizer "Nesta semana entregamos 5 Itens de Trabalho", a conversa passa a ser:"Entregamos a funcionalidade X na semana passada. Já estamos medindo o seu impacto na taxa de engajamento Y. Os resultados iniciais são Z, e nossa próxima ação será..."

O Kanban System é o motor que produz os outputs de forma eficiente e previsível. A mentalidade de outcomes é o volante que garante que esse motor está nos levando na direção certa, gerando valor real para o negócio.