Na minha opinião, uma métrica que é pouco aplicada e conhecida é a Eficiência do Processo ou Eficiência do Fluxo.
De forma bem genérica, podemos dizer que nem todo o tempo que um item de trabalho fica em progresso (Lead Time) é gasto com adição de valor. Em geral, uma boa parte do tempo é, na verdade, gasto esperando em filas.
Para dar um exemplo melhor: quando você liga pedindo uma pizza o atendente normalmente cria um pedido e o deixa disponível para o pizzaiolo começar a fazer. Durante todo esse tempo em que o pedido está esperando até que a pizza comece a ser produzida, nenhum valor está sendo adicionado. Essas esperas acontecem em muitas outras ocasiões até que a pizza esteja na sua casa.
Entendendo “Eficiência do Processo (ou do fluxo)”
“A maioria das empresas está no intervalo dos 10 a 15 porcento [de eficiência do processo], a não ser que tenham especificamente otimizado em relação a isso. Buscar otimizar esse número é uma ótima forma de descobrir e eliminar desperdícios.” Henrik Kniberg, falando de Eficiência do Processo no livro Lean from the Trenches
Quadro hipotético de um projeto.
Veja no quadro acima que existem três colunas de “espera” (marcadas em vermelho) a partir da entrada para o desenvolvimento, em que nenhum valor está sendo adicionado aos itens. Essas colunas, no exemplo acima, são “Pronto para desenvolvimento”, “Desenvolvimento (Pronto)”, “Qualidade (Aguardando Deploy)”. Elas representam filas dentro do sistema. Repare que na coluna de Qualidade há um item bloqueado, os tempos de bloqueio também são tempos em que não se está adicionando valor.
Só para entender melhor, imagine que o Lead Time médio de desenvolvimento seja de 10 dias. Veja uma possível distribuição desse tempo:
| Etapa | Dias | |
| Pronto para Desenvolvimento | 4 | |
| Desenvolvimento | Em andamento | 2 |
| Pronto | 1 | |
| Qualidade | Em andamento | 1 |
| Aguardando Deploy | 2 | |
Marquei em vermelho os tempos de fila (Queue Time) e em verde os tempos de adição de valor (TAV). O tempo de adição de valor costuma ser chamado de “Touch Time” em inglês.
A eficiência do processo (EP) é justamente o percentual do tempo total em relação ao tempo de adição de valor. Nesse exemplo, considerando apenas o Lead Time (LT) de desenvolvimento, temos 30% de eficiência do processo.
EP = TAV / LT
Colocando-se os valores e as unidades
EP = 3 dias / 10 dias
Ou seja, 30% de eficiência de processo.
Por que isso é importante?
O trecho abaixo, retirado do post Project Management with Kanban (part 3) – Forecasting de David J. Anderson, ajuda a explicar por que é importante entender essa métrica:
“… em ambientes de baixa eficiência de fluxo, podemos mudar as pessoas, alterar dramaticamente o método de capturar requisitos e mudar as práticas de desenvolvimento de software sem que o Lead Time observado seja afetado de forma significativa.”
Estimativas
Quando temos um cenário de eficiência do processo abaixo de ~60%, o tamanho dos itens de trabalho, segundo Rodrigo Yoshima, tem pouca influência nos Lead Times observados e no resultado final das projeções. Por isso é um desperdício fazer mais que simplesmente acompanhar o número de itens, ou seja, seria um desperdício gastar tempo estimando o tamanho deles.
“Imagine um processo cujo estudo da Eficiência do Processo evidencie que o Queue Time é de ~10 dias. Você tem 2 demandas. Uma X cujo esforço se configura em um Touch Time de 1 dia e outra Y cujo Touch Time é de 10 dias. Você pensa que por conta dessa diferença haverá 10x de variabilidade no Lead Time. O fato é que a X tem ~11 dias de Lead Time e a Y tem ~20 dias nesse sistema. Note, a variabilidade de 10x no esforço não reproduziu nem em 2x a variabilidade no Lead Time.”
Rodrigo Yoshima no post Gestão de Riscos e #NoEstimate — Agilistas brasileiros comentam
Colunas de fila
Existem controvérsias sobre o uso de colunas de fila na visualização do seu processo. Meu posicionamento é o seguinte: Meça seus tempos de fila e não “esconda” colunas de fila só para ter um número menor de colunas. As colunas, no final das contas, devem refletir a realidade do seu processo, certo? Uma vez que você tenha os dados pode descobrir se o tamanho dos itens de trabalho são importantes ou não. Só elimine as colunas de fila quando os tempos que elas consomem tornarem-se insignificantes.
Gargalos
Um gargalo é uma etapa que limita a vazão de todo o sistema. No desenvolvimento de software é um pouco complicado falar de gargalos, pois estes não são fixos. Não vou me aprofundar nesse ponto, qualquer dúvida, deixe um comentário ;-). De qualquer forma, é sempre bom estar atento aos gargalos.
Existem algumas práticas para o tratamento de gargalos, mas uma relacionada com nosso assunto é protegê-los com uma fila na frente, afinal, um gargalo não deveria correr o risco de ficar sem trabalho.
Lembre-se que protegendo o gargalo com uma fila você ajuda a manter a vazão constante e uma previsibilidade melhor do sistema, mas terá menos eficiência no seu processo. Para mim é um troca bastante justificada.
Referências:
- Lean from the Trenches: Managing Large-Scale Projects with Kanban — Henrik Kniberg
- Kanban: Successful Evolutionary Change for Your Technology Business — David J. Anderson
- Gestão de Riscos e #NoEstimate — Agilistas brasileiros comentam
- Project Management with Kanban (part 3) – Forecasting — David J. Anderson
- Theory of constraints