Trabalho parado: onde a tarefa espera antes de ser entregue
Quando uma entrega atrasa, a primeira suspeita recai sobre quem estava executando. O time é lento, a estimativa foi otimista, faltou gente. Às vezes é isso. Mas, antes de concluir, vale olhar para o tempo em que ninguém estava trabalhando na tarefa.
Uma demanda passa por muitas mãos entre o pedido e a entrega, e entre uma mão e outra ela espera. Espera alguém detalhar, espera aprovação, espera a vez na fila de testes, espera a data de publicação. Essas esperas não aparecem em nenhuma estimativa, e por isso quase ninguém as mede.
Siga uma demanda de ponta a ponta
O exercício é parecido com acompanhar o rastreio de uma encomenda. Escolha uma entrega recente, de tamanho médio, e reconstrua o caminho dela com datas:
- Quando o pedido foi feito.
- Quando alguém começou a detalhar.
- Quando o desenvolvimento começou e quando terminou.
- Quando foi revisada e testada.
- Quando foi aprovada por quem pediu.
- Quando chegou ao usuário.
As datas estão no quadro de tarefas, no histórico do código e nas mensagens. Dá um pouco de trabalho, mas dá para juntar em uma tarde. Faça com três ou quatro entregas para não tirar conclusão de um caso isolado.
Depois, para cada intervalo, marque se havia alguém trabalhando na demanda ou se ela estava só aguardando.
Onde a espera costuma se esconder
Cada empresa tem as suas filas, mas algumas aparecem com frequência:
- Antes de começar. O pedido fica semanas aguardando priorização, e quando entra em desenvolvimento já é urgente.
- Dúvidas sem resposta. Quem desenvolve trava em uma pergunta de negócio, e quem sabe responder só tem agenda na quinta.
- Revisão de código. O trabalho fica pronto na segunda e é revisado na sexta, porque ninguém ficou responsável por revisar.
- Testes e homologação. Um ambiente só, disputado por várias entregas.
- Aprovação. A entrega está pronta e depende do aceite de alguém que não sabia que precisava aceitar.
- Publicação. Versões saem em data fixa, e o que ficou pronto um dia depois espera o ciclo seguinte.
Em nenhuma dessas filas alguém está trabalhando devagar. A demanda está parada entre uma pessoa e outra.
O que fazer com o que aparecer
O Lean chama de desperdício aquilo que consome tempo e não gera valor para quem recebe a entrega. A espera é um dos mais comuns, e o primeiro passo para reduzi-la é saber onde ela está. Com o mapa na mão, as ações tendem a ser simples.
Limite o que está em andamento. Um time que começa dez coisas ao mesmo tempo tem dez coisas esperando. Terminar antes de começar outra tende a encurtar a fila de revisão e de testes, sem ninguém trabalhar mais.
Dê dono às passagens. Se a revisão de código espera quatro dias, combine um prazo e um responsável por dia. Se a dúvida de negócio trava, defina quem responde e em quanto tempo.
Leve quem aprova para mais perto. Mostrar a entrega para quem pediu enquanto ela ainda está sendo feita evita a espera do aceite e o retrabalho que vem depois dele.
Revise as datas fixas. Uma publicação quinzenal fazia sentido quando publicar era arriscado. Se o processo amadureceu, talvez o intervalo possa diminuir.
Cuidado com a leitura apressada
O objetivo do exercício não é encontrar culpado nem cortar etapa. Uma revisão de código ou uma homologação existe por um motivo, e tirar a etapa para ganhar dois dias pode custar caro depois. O que vale conferir é quanto do tempo de cada etapa é trabalho e quanto é fila.
Onde a Jornada entra
Na consultoria da Jornada, quando o problema está no processo de desenvolvimento, usamos métodos ágeis e Lean para encontrar as etapas que não geram valor para quem recebe a entrega, sem ter o corte de custo como objetivo. Se as entregas do seu time demoram mais do que o trabalho justifica, o mapa de três ou quatro demandas já serve para começar a conversa.