Urgências estão destruindo seus resultados. E você provavelmente não cobra o suficiente por elas.
É muito comum um sistema de trabalho ter que lidar com demandas urgentes. Pode ser um problema grave com um cliente, uma grande oportunidade de mercado, um gerente de produto que “esqueceu” alguma coisa importante ou, às vezes, gestores chamam as coisas de “urgentes” para criar um desconforto na equipe.
Respondendo ao apelo popular, vamos explorar este tema neste episódio do Flow Digest e, como sempre, buscamos uma resposta orientada a dados e embasada na ciência. Já adianto que o resultado me surpreendeu. Será que um sistema que aceita e trata urgências é fiável economicamente?
Descobertas deste estudo (Resumo): Urgências em um processo podem aumentar o Lead Time médio em 11%, diminuir a vazão em 9% e ferir os Resultados em 20%, o que se deve em grande parte ao custo cognitivo oculto das pessoas trocarem de tarefas. Um processo otimizado pode não precisar de urgências.
Se você quer saber mais sobre Ciência do Fluxo, entre na nossa lista exclusiva. Em breve teremos alguns conteúdos exclusivos para assinantes:
https://aspercom.com.br/flow-science
O Experimento de Fluxo
Para a tese de fluxo deste episódio, usei como base o fluxo final do episódio #2, aumentando o período da simulação para 12 meses para se ter uma amostra maior para análise. Rodei três cenários distintos para medir o impacto econômico das urgências:
- Baseline: Sem urgências, só demandas normais (valor da demanda: $5K)
- Cenário 1: Com urgências que valem o mesmo que as demandas normais (não urgentes)
- Cenário 2: Com urgências que valem 50% a mais que as normais
- Cenário 3: Com urgências que valem o DOBRO das normais
Premissas da Simulação
As urgências no simulador seguem comportamentos realistas observados em empresas:
- Surge uma a cada 4 dias
- A natureza e esforço é semelhante a uma demanda normal
- Podem estourar os limites WIP estabelecidos
- Não param em filas — vão direto para execução
- Pessoas interrompem o trabalho atual para atendê-las
- Cada interrupção gera um custo de troca de contexto de aproximadamente 24 minutos, alinhado com as descobertas de Mark, Gonzalez e Harris (2005, University of California)1.
No mundo real, seria como se eu pegasse o cenário baseline e simplesmente dissesse a cada 4 dias que um dos itens de trabalho da fila de entrada é urgente – ararinhas azuis vão morrer se não for entregue rápido. O mesmo efeito acontece se você disser para a equipe que essa demanda foi solicitada pela esposa do CEO.

Urgências te deixam mais Ágil, mais Produtivo e mais Lucrativo?
Primeiramente, quero deixar um desafio para você. Veja abaixo o histograma de Lead Time do Baseline (fluxo sem urgências). Tente analisá-lo. Você pode voltar ao episódio #1 se quiser entender o básico deste gráfico, ou pode jogá-lo na sua LLM preferida pedindo uma análise curta – quase sempre funciona, mas ela especula bastante.

Vamos ver o que acontece se introduzirmos urgências neste fluxo, mantendo todas as outras variáveis iguais (algo possível somente com um simulador de fluxos determinista). Abaixo, temos o histograma combinado: itens normais em verde e itens urgentes em vermelho. Antes de prosseguir a leitura, tente também analisá-lo. Coloque-se no lugar do cliente/demandante que tem a opção de pedir uma demanda urgente a cada 4 dias, contrastando com o gráfico do baseline.

Vamos analisar o Lead Time dos cenários isoladamente e por Classe de Serviço:
Baseline (sem Urgências) | Todas as Simulações com Urgências | ||
Normais | Normais | Urgentes | |
Amplitude | 4-28 | 4-72 ▲ 44 (+183%) | 4-27 ▼ -1 (-4,2%) |
Moda | 10 | 9 ▼ 1 (-10%) | 6 ▼ 4 (40%) |
Média | 13.5 | 16.6 ▲ 3.1 (+23%) | 11 ▼ 2.5 (-19%) |
p85 | 19 | 23 ▲ 4 (+21%) | 16 ▼ 3 (-16%) |
WIP (μ) | 9.36 itens | 9.65 itens ▲ 0.29 (+3.1%) | |
Vazão | 195 itens 3.74 por semana | 177 items ▼ 18 (-9.2%) 3.39 por semana | |
52 itens (29%) 1 por semana | 125 itens (71%) 2,39 por semana |
A Ciência do Fluxo é sobre Trade-offs
Antes de mais nada, um alerta: os resultados no seu ambiente podem ser diferentes. Usamos aqui uma simulação de fluxo que retrata uma realidade virtual bem completa, mas que não leva em consideração todos os fatores do mundo real ou do seu negócio.
Mesmo assim, podemos usar a Ciência do Fluxo para analisar trade-offs. O quadro acima nos mostra que ao introduzir uma classe de serviço “Expedite” (termo do Método Kanban para demandas urgentes) neste fluxo estaríamos “tirando energia” de um tipo de item de trabalho (verdes) em favor de outro (vermelhos), sofrendo com os custos de troca de contexto.
Olhando para os dados, parece que os ganhos não são tão vantajosos se comparados com o cenário baseline (sem urgências). Se você enxergou isso, parabéns, você não estaria errado. O benefício das urgências estaria somente em uma “cauda” mais curta de Lead Time (relação entre a moda e o percentil 95, assunto que trataremos em episódios futuros) e média/p85 mais baixos.
Isso se deve ao fato de que o fluxo baseline já é bem otimizado: tinha uma eficiência alta (acima de 40%). “Expedites” costumam ter um efeito mais vantajoso em processos piores, onde o impacto das filas é maior. Já vi muitas vezes urgências serem introduzidas em um processo para compensar, desesperadamente, um fluxo ruim.
Optar por este trade-off é uma decisão de negócios. Você ofereceria ao cliente ou demandante uma “via rápida”, como uma ambulância de sirene ligada no trânsito que seria 20% mais veloz e um pouco mais previsível. Entretanto, a avenida tem capacidade limitada, logo, todos os outros veículos (demandas normais) ficariam 23% mais lentos e muito mais imprevisíveis. A vazão da avenida cairia 9%. Isso nos leva à pergunta: o cliente pagaria mais por isso?
Emergências, quer pagar quanto?
Quanto vale a vida da pessoa na ambulância? Imagine na simulação sem urgências, o baseline (ver gráfico acima), se em todas as “viagens” que passassem de 16 dias, o paciente morresse? Seriam aproximadamente 30% delas. Logicamente, não é aceitável!
Trazendo para um cenário corporativo, imagine que para certas demandas do cliente (não todas), 16 dias de prazo são muito além do aceitável. Ele quer que a maioria delas, uns 85% delas, seja de 16 dias ou menos. Neste caso, implementar a classe de serviço de urgência pode fazer sentido. Mas é caro. Seguem os resultados financeiros de cada cenário simulado:
Sem Urgências | Com Urgências | |||
Baseline | Cenário 1 | Cenário 2 (50%+) | Cenário 3 (2x) | |
Valor por Demanda | $5.000 | $5.000 | $7.500 | $10.000 |
Resultados Financeiros | $457K | $367K ▼ –20% | 496K ▲ +8% | $627K ▲ +20% |
Conclusão
Trabalhamos há mais de 20 anos com métodos ágeis e há mais de 15 anos com gestão de fluxo – tais impactos me impressionaram. A simulação refuta muitas práticas do mercado. Alguns aprendizados ricos e reflexões tiramos deste experimento simulado:
- Urgências tem um alto impacto na Vazão e Resultados – implemente com cuidado;
- Custo com pessoas trocando tarefas, mesmo só 24 minutos por interrupção, é caro – existe também o aspecto do estresse, não simulado neste experimento;
- Urgências podem ser mais úteis em processos pouco otimizados, com muitas etapas e longas filas – neste caso as urgências ficariam muito mais rápidas que o baseline – talvez um experimento para um próximo Flow Digest? Neste caso, será que não é melhor melhorar o processo, encurtar o Lead Time total do que usar urgências?
- Se em um sistema com somente duas classes de serviço (urgentes e normais) já temos impacto, não faz sentido ter vários níveis de urgência no processo (como urgente, muito urgente, urgentíssimo). Mais níveis podem ter o efeito: “se tudo é urgente, nada é urgente”. Deixe o sistema simples.
Sua organização sofre com urgências? Você cobra mais por elas? Deixe seu comentário! E não se esqueçam de assinar a lista exclusiva deste assunto. Teremos um conteúdo especial em breve, somente para assinantes. O que teremos no Flow Digest #5?
Referências
- MARK, G.; GONZALEZ, V. M.; HARRIS, J. No task left behind? Examining the nature of fragmented work. In: PROCEEDINGS OF THE SIGCHI CONFERENCE ON HUMAN FACTORS IN COMPUTING SYSTEMS, 2005, Portland. Anais… New York: ACM, 2005. p. 321-330. ↩︎