Desperdícios 3 e 4: Transferências e Espera

Toda vez que o trabalho passa de uma pessoa ou equipe para outra, o contexto é perdido.

O gerente de produto escreve os requisitos. Ele conhece a dor do usuário, as restrições do negócio, os trade-offs de prioridade. Ele entrega isso para um designer.

O designer lê os requisitos, faz perguntas de esclarecimento (algumas das quais o gerente de produto não consegue mais responder porque o contexto já desapareceu) e cria mockups. Ele entrega isso para os desenvolvedores.

Os desenvolvedores leem os requisitos e mockups, fazem perguntas de esclarecimento (algumas das quais nem o gerente de produto nem o designer conseguem mais responder) e constroem algo. Eles entregam para o QA.

O QA testa contra os requisitos, encontra problemas e devolve para os desenvolvedores.

A cada transferência, informação é perdida. Quando a funcionalidade chega aos usuários, ela mal se parece com o que o gerente de produto originalmente entendia sobre as necessidades do usuário. E cada transferência levou tempo—às vezes dias esperando em filas.

Transferências são onde o contexto vai morrer.

A maior parte do lead time é tempo de espera, não tempo de trabalho. Uma tarefa que leva 2 horas de trabalho ativo pode ter 2 semanas de lead time. Para onde vai o resto?

• Tempo de fila: Esperando em backlogs para priorização
• Esperando por revisão: PRs parados sem revisão
• Esperando por aprovação: Decisões presas na gestão
• Esperando por dependências: Bloqueado por outras equipes
• Esperando por ambientes: Não pode testar porque o staging está quebrado
• Esperando por informação: Perguntas sem resposta
• Esperando por agendamento: Reuniões que não podem acontecer até a próxima semana

Cada espera introduz atraso e frequentemente requer refamiliarização quando o trabalho é retomado. Você lê o código, entende o contexto, é interrompido e tem que reconstruir esse contexto depois.

Eficiência de fluxo mede o tempo de valor agregado como uma porcentagem do lead time. Na maioria das organizações de software, é de 5-15%. Isso significa que 85-95% do tempo, o trabalho está esperando, não sendo trabalhado.

Equipes multifuncionais: Traga todas as habilidades necessárias para entregar valor para uma equipe. Produto, design, desenvolvimento, testes—todos juntos. Transferências se tornam conversas.

Especialistas generalistas: Pessoas que têm expertise profunda em uma área, mas podem contribuir em outras. Quando o trabalho se acumula na revisão, desenvolvedores podem ajudar a revisar. Menos filas.

Programação em par e mob: Duas ou mais pessoas trabalhando juntas eliminam transferências dentro do trabalho. A revisão é integrada. A transferência de conhecimento é contínua.

Colaboração em tempo real: Substitua transferências assíncronas por colaboração síncrona. Em vez de escrever uma especificação, tenha uma conversa. Em vez de registrar um bug, vá até o desenvolvedor e mostre.

Elimine aprovações: A maioria das etapas de aprovação não agrega valor—são mecanismos de controle de ambientes de baixa confiança. Questione cada aprovação: Que valor isso agrega? Poderíamos obter o mesmo benefício de outra forma?

Automatize transferências: Se o trabalho precisa ser transferido, automatize a fila. Pipelines de CI/CD que fazem deploy automaticamente. Bots de PR que notificam revisores imediatamente. Integrações do Slack que destacam trabalho bloqueado.

O objetivo não é trabalhar mais rápido—é esperar menos. Ataque os 85%, não os 15%.