O Customer Lead Time mudou! Veja aqui a nova definição

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Compartilhe:

Pessoal, a definição de Customer Lead Time mudou. Ela deixou de contar do ponto de compromisso até a entrega e agora é do ponto de colocação do pedido até a entrega. Vamos falar dessa mudança.

O mapeamento do fluxo de trabalho. Começa com o Ponto de Recebimento da demanda, depois vem as etapas: Pedidos / Ideias, Análise de Viabilidade, Refinamento, Priorizados. Após isso, o Ponto de Comprometimento e na sequência: Comprometidos, Construção, Avaliação e Entrega. Finalmente o Ponto de Entrega e a última etapa: Entrega. O Customer Lead Time Atual vai do Ponto de Recebimento da Demanda até o Ponto de Entrega. O Customer Lead Time anterior vai do Ponto de Comprometimento até o Ponto de Entrega.
Definições atual e anterior do Customer Lead Time no Fluxo de Trabalho.

O que é um Lead Time?

A primeira coisa que precisamos entender é o que é um lead time. Em uma tradução direta, o lead time é o tempo de espera. O que faz sentido, afinal é um tempo em que alguém que precisa de algum serviço está aguardando receber o serviço. O Lead Time pode ser medido entre quaisquer dois pontos que você deseje.

O mesmo fluxo da imagem anterior, porém agora com exemplos de Lead Time. Lead Time de Análise começa do Ponto de Recebimento da Demanda e Termina quando o item chega em Analisado. Lead Time de Construção começa do Ponto de Comprometimento e Termina quando o item chega em Construído. Lead Time de Avaliação e Entrega começa quando o item chega no construído e termina no Ponto de Entrega. Além desses, tem o Upstream Lead Time começando no Ponto de Recebimento da Demanda e terminando no Ponto de Comprometimento e o Downstream Lead Time que começa no Ponto de Comprometimento e termina no Ponto de Entrega.
Exemplos de Lead Time ao longo do Fluxo de Trabalho.

Isso não seria o Cycle Time (Tempo de Ciclo)?

Pois é, veja bem. Na verdade, a definição de Cycle Time que é amplamente utilizada pelo mercado da agilidade e muitas ferramentas implementam, não segue a mesma definição que a manufatura / engenharia de produção.

Na agilidade o Cycle Time ganhou fama como sendo a medição de tempo decorrido entre as etapas do fluxo. Utilizando o mesmo quadro, poderíamos ter o Cycle Time da construção, o Cycle Time da Avaliação e o Cycle Time da Entrega, etc.

O Cycle Time é uma equação:

Cycle Time = Tempo líquido de produção (TLP) / Número de unidades produzidas

O Tempo Líquido de Produção (TLP) é o tempo em que de fato tem alguém mexendo no item. Se for um Quadro de Fluxo de Trabalho (Quadro Kanban), seria o tempo em que o item está em uma coluna de execução e com um avatar. Como uma etapa do fluxo pode conter itens: em execução, espera ou bloqueados, seria incorreto utilizar o termo para se referir a medição de tempo de etapas.

Mas e nas ferramentas?

Aí é que mora o perigo. Há muitas ferramentas utilizando conceitos distintos para Cycle Time e isso cria bastante confusão. Por exemplo, o Jira, IBM RTC, Kanbantool e Kanbanize utilizam esse nome para definir o antigo Customer Lead Time (em breve falaremos sobre isso). utiliza um conceito semelhante, mas não exatamente o mesmo. O software da IBM utiliza o nome Feature Cycle Time.Já o CollabNet VersionOne que mudou de nome para Digital.ai e o Microsoft Azzure Devops utilizam o conceito mais comum de cycle time como o tempo dentro de qualquer etapa que você defina.

Como podemos perceber, rola uma espécie de “Cycle Time é meu e defino ele o que eu quiser” nas ferramentas. Infelizmente não tem muito o que fazer, consulte a documentação da ferramenta que a sua empresa usa para não errar.

Mudança do Customer Lead Time

Até 7 de abril de 2023 tínhamos uma definição de Customer Lead Time. Era o tempo decorrido desde o Ponto de Comprometimento até o tempo de entrega.

Qual era a visão anterior?

Pedir é barato, na maioria dos lugares, pedir não custa nada. É só abrir um ticket, mandar um e-mail ou sugerir em uma reunião para que um serviço seja realizado. O ônus acaba recaindo nas costas das pessoas que irão prestar o serviço. É muito comum encontrarmos nas empresas times abarrotados de solicitações que já estão esperando a semanas, meses ou anos e eles não têm nenhuma previsão de quando começarão o trabalho.

O Customer Lead Time (Tempo de Espera do Consumidor do serviço) só começava a contar quando o item chegava no Ponto de Comprometimento. Este era um acordo entre as pessoas que prestavam o serviço e as pessoas que solicitavam o serviço, por isso o nome. É uma sinalização que o prestador (time, squad, unidade…) dava para o consumidor: “A partir desse ponto, você pode contar que estamos trabalhando na sua demanda.”

Qual é a nova definição do Customer Lead Time?

No dia 7 de Abril a Kanban University (KU) publicou o artigo What to Know About Lead Time and Why We Have Evolved Our Definition of Customer Lead Time no qual a KU publicou a nova definição. Ela ficou atrelada tanto ao próprio nome (Tempo de Espera do Consumidor) quanto a que outros mercados chamavam de Customer Lead Time, especialmente à definição da Investopedia. Agora é o tempo em que a demanda foi recebida até a entrega. 

A ideia é contar o tempo real de espera do cliente. Por exemplo, Imagine que você tem um problema com a sua internet. Você liga para a operadora. Qual é o ponto que você começa a contar a sua espera. O momento em que o atendente registra o problema e te dá um número de protocolo ou apenas o momento em que algum técnico da operadora se compromete a atender a sua demanda?

Ponto de Recebimento da Demanda

Essa nova definição também traz uma nova discussão. Afinal, em que ponto dizemos que recebemos o pedido do cliente? No artigo da Kanban University supracitado, há uma abertura para a conversa. 

Imagine a seguinte situação. Você está dormindo e seu filho acorda chorando dizendo que está sentindo muita dor de ouvido. Você acorda de madrugada e o leva até o hospital mais próximo. Chegando lá o hospital está lotado e há fila para todos os lados. A pergunta que faço para você é quando você começa a contar o seu tempo de espera?

  1. Assim que chega no hospital e aguarda na fila da recepção, mesmo que isso leve 1 hora.
  2. Quando o atendente da recepção cadastra o paciente e abre uma ordem de serviço para a triagem, desconsiderando a 1 hora que você ficou na fila da recepção.

Não tenho uma resposta pronta e cada caso é um caso.Há tipos de negócio que essa espera inicial é imperceptível, mas há outros que ela é significativa. O fato é que você precisa definir o Ponto de Recebimento da Demanda.

Qual foi o nome que ficou o antigo Customer Lead Time?

Nenhum. E isso me dá um frio na barriga. Daqui a alguns anos terão os nomes mais estapafúrdios possíveis. Por enquanto, vou chamando de Downstream Lead Time.

A opinião do Avelino

Deixo bem claro que essa é a minha opinião pessoal e não da KU ou da K21. Particularmente não gostei da mudança por alguns motivos que exponho abaixo.

Mudar conceitos já sedimentados não é impossível, mas é árduo. Milhares de pessoas já receberam a instrução de Customer Lead Time anterior e não estão acompanhando as evoluções da KU. Você pode ter no mesmo time, pessoas utilizando as duas definições sem saber. Isso pode provocar grandes distorções de análise de dados e tomada de decisões.

Outro motivo é que já havia um outro nome para abarcar a nova definição. No livro Essential Upstream Kanban mantido pela KU já havia o End-to-end Customer Lead Time (páginas 8, 11, 13, 14 e 15).

O fato do antigo Customer Lead Time não ter recebido um nome me dá um certo temor. Se a KU não define, alguém vai definir por ela e o resultado disso só perceberemos lá no futuro. Bom, vou deixar a minha sugestão: Downstream Lead Time. Tempo de Espera desde o Comprometimento.

Espero ter lançado mais luz do que trevas sobre a nova definição. Se ficou alguma dúvida pergunte aí embaixo. Se quiser saber mais sobre essa diferença e outras mudanças, veja nossos treinamentos de Kanban System Design (KSD) e Team Kanban Practitioner (TKP).

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Há algum tempo escrevemos o artigo sobre o Cemitério Mexicano. Ele fala sobre a importância de comemorar quando descartamos ideias ruins antes que elas entrem no nosso fluxo de trabalho como projetos, iniciativas, novos produtos ou serviços. Naquele artigo citamos…