Se repararmos por aí vamos perceber que existem muitas divergências conceituais entre as diferenças do que Lead Time e Cycle Time representam.
E no meio dessa discussão toda vemos que não existem certos e errados. Apenas definições com entendimentos vindos de vertentes literárias diferentes, onde cada uma deve possuir sua linha de pensamento e seus argumentos para tal.
Então, o mais importante nesse caso é escolhermos uma definição que melhor faça sentido e alinharmos ela dentro de casa. Uniformizar um conceito comum para todos da organização deve evitar vários problemas futuros, acredite! 😅
Mas, a definição que queremos compartilhar aqui como recomendação é a do conceito defendido pela comunidade Kanban. Sendo o mais amplamente adotado no mercado nos últimos anos, esse conceito define da seguinte forma:
Customer Lead Time
É o tempo que você leva para atender uma necessidade do seu cliente, desde o ponto de solicitação (request point) ainda no Upstream até a entrega final em produção, passando por todo seu fluxo de trabalho, de ponta a ponta. Ele tem a ver com sua velocidade de resposta ao mercado (time-to-market).
Importante mencionar que no ponto de Backlog desse exemplo consideramos que já exista um entendimento superficial prévio, onde minimamente se tem conhecimento da necessidade a ser resolvida; e não apenas pedidos despejados de qualquer forma ali.
Lead Time
É o tempo que você leva do seu ponto de compromisso (replenishment) até a entrega final. Então, se você trabalha com sprints, seu Lead Time provavelmente deve começar a contar ao final da Planning, que é onde acontece o reabastecimento e o compromisso de um novo lote de trabalho.
Também é importante mencionar que idealmente seu Lead Time deve contar até a entrega em produção (onde o cliente já pode usufruir daquilo que foi entregue). Porém, existem alguns casos onde a equipe não tem autonomia até essa etapa. Para esses casos, podemos considerar o ponto final como o momento onde se encerra o trabalho da equipe.
Cycle Time
É o tempo entre quaisquer outros dois pontos que você escolher medir, é customizável. Por exemplo, podemos entender que faz sentido mensurarmos o Cycle Time das etapas de desenvolvimento, ou de homologação, de testes etc.
Vale dizer que ambas as medições são sempre contabilizadas em dias corridos, prevalecendo a percepção do cliente e evitando várias complexidades desnecessárias também.
Se você leva seu carro na oficina na quarta-feira e ela te devolve na quarta-feira seguinte, sua percepção como cliente é que a oficina levou uma semana para resolver seu problema, não é?
Você sabia que pode extrair todas essas métricas muito facilmente? Nossa solução Team Care BRQ é uma ferramenta essencial para gerenciamento de métricas. Confira!
João Paulo Grabosque, Agile Coach na BRQ