Filas: 5 pontos que você deve ficar atento para aumentar a eficiência do seu time

Compartilhe:

Filas são comuns todos já estivemos em alguma delas. Seja em uma ida ao supermercado, no embarque / desembarque de algum meio de transporte, na porta de um restaurante ou até mesmo no mundo digital, elas existem. Se elas existem, temos que tratá-las. No trabalho do comércio nós não pensamos muito nelas, mas elas existem, não são poucas e causam um grande impacto no desenvolvimento de produtos e serviços. Logo, temos que tratá-las.

A Teoria das Filas

A primeira pessoa a sistematizar filas foi o matemático Agner K. Erlang em 1909. Resumindo bastante seus achados, ele percebeu que o fenômeno acontece quando há imprevisibilidade na chegada do trabalho e na duração dele. Quando o tempo de chegada de novos itens for menor do que o tempo de processamento dos itens no sistema, você terá a formação de fila.

Uma fila com 10 post its na frente de uma porta de entrada e uma taxa de chegada de 1 item por dia. Do lado direito da porta uma roldana indicando processamento do trabalho com 2 post its informando que o tempo médio de trabalho é de 10 dias. A direita uma porta de saída com um item apenas indicando a taxa de entrega de 1 item por semana.
Olhando o causador das filas

O artigo original está em inglês aqui (na verdade, quase o original, pois o primeiro foi escrito em dinamarquês). 

Por que as filas importam?

A incontrolável chegada de novos pedidos

Muitas das vezes tentamos controlar a chegada de novos pedidos (demanda) a ferro e fogo. Times tentam bloquear a chegada de trabalho através de políticas, restrições, sistemas de solicitações etc. Tal tentativa é frustrante uma vez que grande parte dos times não possuem cacife político que faça com que esses bloqueios se tornem eficazes. Na maioria das vezes é como criar uma cerca de barbantes na expectativa de que ela impeça um búfalo de 500kg de atravessá-la. 

Gosto de trazer analogias para tentar tangibilizar o problema. Imagine um hospital, ele pode determinar o número de pessoas que chegarão até ele? Não, pois ele não pode impedir que as pessoas adoeçam ou que acidentes aconteçam. Assim também no trabalho do conhecimento, não conseguimos controlar a chegada das demandas: ideias, nova legislação, solicitações, bugs e erros, dívidas técnicas, pedidos urgentes, pedidos do dono etc.

Você pode pensar: “mas assim eu não consigo atender toda minha demanda”. Em relação a isso, Rodrigo de Toledo propõe um axioma: 

Mal do século XXI para todo trabalhador do conhecimento: A demanda é muito maior do que a capacidade da entrega

Rodrigo de Toledo

Em outras palavras, impedir a chegada de novos pedidos na expectativa de que um dia você irá “zerar” o seu backlog é irreal.

A incontrolável duração do trabalho.

Voltando à analogia do hospital, ele também não consegue pré-determinar quanto tempo cada paciente passará em cada etapa do fluxo de atendimento: recepção, triagem, clínico geral, especialista, medicação, internação, cirurgia e tudo mais que for necessário até a alta. Pelo mais que os médicos e sistemas tenham registro histórico e possam até mesmo estimar a duração do atendimento, predições são impossíveis.

O mesmo se aplica ao trabalho do conhecimento. Além de não conseguirmos controlar a chegada da demanda, também não conseguimos definir com exatidão a duração futura do trabalho.

A incontrolável urgência do pedido

Por fim, o hospital também não consegue controlar a chegada da gravidade dos pacientes. Não há nada como: só podem chegar pessoas em emergência a cada duas horas. Elas simplesmente acontecem.

Idem no nosso trabalho. O que o seu concorrente lançará amanhã? O governo promulgará alguma legislação nova esta semana? O dono da sua empresa acordará tão inspirado na segunda-feira e com uma ideia brilhante e urgente? Não temos como saber. O trabalho intempestivo acontece e temos que atendê-lo.

Se os textos supracitados expressam fatos, então o que podemos fazer? O que a Disney, o Beto Carrero e a sua pizzaria favorita fazem muito bem. Temos que administrar as filas, pois são inevitáveis. Pelo melhor que seja o método que você está utilizando para gestão do trabalho, Scrum, Kanban, XP, baseado no PMBOK, saber gerir filas é fundamental. 

Uma placa dizendo que o tempo de fila para andar na Madagascar Crazy River Adventure no Beto Carreiro World é de 160 minutos.
Tempo de fila para andar na Madagascar Crazy River Adventure no Beto Carreiro World.

Visibilidade das Filas

Conforme dito por Donald (Don) Reinertsen em seu livro The Principles of Product Development Flow

… porque as filas são invisíveis, não há predadores naturais para mantê-las sob controle

Don Reinertsen, The Principles of Product Development Flow, p. 56

O que não é visto não pode ser tratado. Don Reinertsen apresenta 16 princípios de gestão de filas. O primeiro, no desenvolvimento de produtos, o inventário é fisicamente e financeiramente invisível, e o segundo, filas são a causa raiz da maioria do desperdício econômico no desenvolvimento de produtos, são relacionados à falta de visibilidade. 

A forma mais simples de dar visibilidade ao trabalho é através da apresentação do seu fluxo. 

Um quadro de fluxo de trabalho. Começa com o Ponto de recebimento da demanda com uma quantidade grande de itens de trabalho. Após isso segue o fluxo do trabalho nas etapas Pedidos / ideias, Análise de viabilidade (4 itens), Refinamento (3 itens), Priorização (7 itens), Ponto de Comprometimento, Comprometidos (3 itens), Construção (3 itens), Avaliação (2 itens), Entrega (2 itens), Ponto de Entrega e Entregue com 5 itens.
Visibilidade do fluxo de trabalho. 

Na imagem acima, tiramos o trabalho do conhecimento da nossa cabeça e o concretizamos. Pode ser com post its na parede ou então em quadros virtuais. 

Já estamos vendo o tamanho da fila de chegada e o resultado na saída, porém ainda não vemos as filas no meio do processamento. Essa é a segunda parte da exibição. Separar o que está sendo feito daquilo que está parado. 

O mesmo quadro anterior, porém com filas internas. O quadro agora sim está: Começa com o Ponto de recebimento da demanda com uma quantidade grande de itens de trabalho. Após isso segue o fluxo do trabalho nas etapas Pedidos / ideias, Análise de viabilidade com Analisando (1 item) e Analisado (3 itens), Refinamento com refinando (2 itens) e refinado (1 item), Priorização com priorizando (3 itens) e priorizado (4 itens), Ponto de Comprometimento, Comprometidos (3 itens), Construção com construindo (2 itens) e construído (1 item), Avaliação com avaliando (1 item) e avaliado (1 item), Entrega (2 itens), Ponto de Entrega e Entregue com 5 itens.
Visibilidade do fluxo com as filas de esperas internas.

Agora no nosso quadro temos bem separadas as colunas de ação, que normalmente são nomeadas no gerúndio (analisando, refinando, priorizando, construindo, avaliando) e as etapas de espera que estão no particípio (analisado, refinado, priorizado, construído e avaliado). Essas etapas de espera são filas que indicam que não há processamento de trabalho. Todos os itens que estão nelas estão esperando o início da execução (ação).

Reduza a ocupação das filas

Você já deve ter ouvido algumas vezes sobre a limitação do WIP (Work in Progress, Trabalho em Progresso, algumas vezes traduzido para Work in Process, trabalho em processamento). A função básica dessa limitação é reduzir o tamanho das filas. 

Vamos voltar para o nosso exemplo do hospital. Imagine que há apenas um cardiologista disponível por plantão e os clínicos gerais estão atendendo sem uma avaliação adequada e despacham quase todos os pacientes para o cardiologista o mais rápido que eles conseguem. Em minutos esse especialista estará com 100% do tempo dele ocupado. Se vivêssemos em um mundo linear você poderia até fazer uma conta do tipo 1 cardiologista leva 5 minutos para atender um paciente e há 30 pacientes na fila, logo o tempo de espera do próximo paciente a chegar na fila será de 5 x 30 = 150 minutos = 1h30m. Infelizmente isso não é verdade, pois você não consegue precisar quanto tempo cada paciente ficará com o cardiologista. Alguns ficarão durante cinco minutos e outros durante uma hora. Cada variação deixará as pessoas esperando mais e mais tempo pelo cardiologista. Você ainda tem que colocar na equação as pessoas que vão “furar a fila” devido ao caso dela requer atenção imediata. Logo, aquela famosa pergunta: “Quanto tempo falta?” é, portanto, irrelevante.

Nesse caso, algumas das possíveis soluções seriam: 1) os clínicos só mandariam para o cardiologista casos que realmente precisam dele reduzindo assim a fila do especialista; 2) aumentar a quantidade de cardiologistas. A solução 1 é mais atraente porque ela reduz a fila do servidor especializado. Ele ficará ocioso durante algum tempo e isso é bom, pois esse tempo ocioso será precioso para reduzir o impacto da variabilidade do tempo de atendimento.

No trabalho do conhecimento acontece a mesma coisa. Vejamos a imagem abaixo sobre ocupação e tempo de ciclo. Perceba que a duração aumentará de forma exponencial quanto mais as pessoas estiverem ocupadas. Quanto mais próximas as pessoas estiverem do 100% ocupadas, a duração do ciclo tenderá ao infinito.

Um gráfico com o eixo X % de ocupação e no eixo Y o Cycle time. Dentro dele 3 linhas que crescem de forma exponencial. Large batches, sobe mais rápido do que medium batches e small batches é a mais lenta de todas.
Efeito da utilização de recursos (pessoas) e o tamanho do lote e seu impacto na duração do ciclo. Imagem retirada do livro Lean Software Development: An Agile Toolkit: An Agile Toolkit escrito por  Mary Poppendieck e Tom Poppendieck, página 80.

O casal Poppendieck também acrescenta a variável tamanho do lote. Quanto maior o lote de trabalho, mais lenta será a duração do ciclo. Um lote pode ser um projeto inteiro, ou uma funcionalidade, uma fatia de um produto, uma parte de um serviço etc. Lotes imensos com pessoas totalmente ocupadas terá um tempo de entrega igualmente imenso. 

O limite de WIP serve justamente para criar um “corte” e impedir que essas filas cresçam descontroladamente. 

O mesmo quadro de fluxo das outras imagens, agora com a limitação de WIP por etapa. Análise de Viabilidade: 6 itens, Refinamento: 4 itens, Priorizado: 7 itens, Comprometidos: 3 itens, Construção: 4 itens, Avaliação: 2 itens, Entrega: 3 itens.
Limitação do WIP para reduzir a ocupação das filas

Entenda como as filas são atendidas

Don Reinertsen apresenta três formas para estruturar filas

A descrição da imagem sobre atendimento de filas aparece no parágrafo abaixo.
Tipos de filas

Cada pessoa é chamada de servidor. No primeiro formato, uma fila por servidor, temos cada pessoa com uma fila de trabalho pré-alocada a ela. Esse tipo de fila você encontra em supermercados (caixas comuns) e pedágios que não são pagos de forma automática. A vantagem desse formato é que você já sabe quem será o responsável por executar o trabalho antes dele começar. A desvantagem é que a variabilidade poderá ter um impacto significativo. Por exemplo, se a primeira pessoa na imagem estiver executando uma atividade que demora muito tempo, os outros quatro itens que estão na fila dela, ficam ali esperando, mesmo que as demais pessoas se encontrem disponíveis para realizar o trabalho. No trabalho do conhecimento, geralmente, não queremos esse tipo de fila, pois sabemos que a variabilidade é alta. Elas aparecem nos caixas de supermercado e pedágios por uma questão de espaço físico e não de eficiência.

O segundo formato, fila única com múltiplos servidores, é, normalmente, o mais indicado, pois se o próximo item tiver uma duração longa, o fato de terem mais pessoas pegando trabalho na mesma fila, isso reduzirá o impacto no tempo de espera e respectivamente na duração do trabalho. Esse é o formato da fila em caixas-rápido dos supermercados e filas digitais de atendimento ao cliente.

O último formato de fila apresentado pelo Don Reinertsen é Fila única com servidor de alta capacidade. Segundo o autor esse seria o melhor possível, pois você tem uma pessoa supereficiente atendendo à demanda de trabalho. Os problemas que podem acontecer aqui estão relacionados à fila, quando um item mais demorado chegar à pessoa e o outro está relacionado à pessoa, pois o que faremos caso ela esteja indisponível? Cuidado, se você tem uma pessoa que é a única pessoa que pode atender aquela etapa do serviço, não significa que você tem uma fila única com servidor de alta capacidade. Pode ser uma fila por servidor, sendo que você possui apenas um servidor. A alta capacidade é fundamental para essa classificação.

O mesmo quadro de fluxo das outras imagens, agora com a indicação do tipo de fila. Pedidos / ideias: uma fila por servidor, Analisado: Fila única com servidor de alta capacidade, Refinado: fila única com múltiplos servidores, Priorizado: Fila única com servidor de alta capacidade, Comprometido, Construído e Avaliado todos com fila única com múltiplos servidores.
Fluxo com os tipos de atendimento de fila em cada etapa

Meça as filas e gerencie-as

Nível de Ocupação do Fluxo

Uma vez que você já conhece seu fluxo, seu trabalho, suas filas, está na hora de medí-las. A primeira coisa é saber quantos itens estão nas suas filas? Conta simples de somar mesmo. Todavia esse não é um número para você medir uma vez e pronto. A medição deve ser constante. O objetivo desta medição é ver se seu time trabalha ou ultrapassa a capacidade dele.

Voltando ao exemplo da imagem acima. Podemos somar os limites de WIP e ver a capacidade desse time. No caso, Análise de Viabilidade (6 itens) + Refinamento (4 itens) + Priorizado (7 itens) + Comprometidos (3 itens) + Construção (4 itens + Avaliação (2 itens) + Entrega (3 itens) = Capacidade total do time = 29 itens. Caso esse quadro de mapeamento do fluxo possua 29 itens em progresso, podemos dizer que o sistema está sob stress. Caso suja uma demanda urgente, ele é incapaz de atendê-la. Se tentar atendê-la, o sistema entra em sobrecarga. Utilizando a analogia do hospital novamente, agora as pessoas estão sendo atendidas no corredor, pacientes deitados no chão, um caos.

O ideal é trabalhar com uma folga desejada. Um número X abaixo da capacidade máxima. No nosso exemplo, digamos que trabalhamos com no máximo 26 itens em progresso no fluxo. Caso aconteça alguma emergência, conseguiremos atendê-la sem grandes problemas. Você pode criar também um limite inferior para evitar a morte do time por inanição (falta de trabalho). Por exemplo, se o fluxo tiver 10 itens ou menos. Claro, como boa prática, você pode criar entre a folga desejada e a inanição um alerta de excesso de folga justamente para evitar essa inanição.

Não adianta também ver apenas o nível de ocupação do fluxo, você deve controlá-los também nas etapas do fluxo, principalmente naquelas que tendem a “engargalar” o trabalho. Se ela estiver sobrecarregada, teremos atrasos na entrega.

Conseguimos entregar tudo o que pedem?

Outro número importante é quantos itens chegam no seu fluxo por um período. Essa é a taxa de chegada. Por exemplo, em média chegam 10 itens por semana. A outra ponta do fluxo também deve ser medida é a sua taxa de entrega. Um exemplo, entregamos 8 itens por semana. A relação entre a taxa de chegada e taxa de entrega deve dizer se qual é a capacidade do seu time de atender à demanda. 

Capacidade de atender à demanda = Taxa de entrega / Taxa de chegada. 

No nosso exemplo 

Capacidade de atender à demanda = 8 / 10 = 80%

Geralmente, conseguimos atender 80% da demanda que chega até nós. 

É um número interessante de ter e se for baixo, tipo 5% ou 10% com certeza devemos rever nossos processos. Entretanto cuidado para não tentar torná-lo 100%. Falo por experiência própria de quem já tentou tal loucura e como dizia Ariano Suassuna

Toda história que é ruim de viver é boa de contar

Ariano Suassuna

Enquanto gerente de times já tive a ideia de tornar o time 100% eficiente e capaz de atender a toda demanda que chegava. Investimos pesado em automação de testes, verificações de segurança e entrega. Os times estavam motivados e ficaram empolgados com a ideia. Os problemas: 1) a incontrolável chegada de novos pedidos; 2) a incontrolável duração do trabalho; e 3) a incontrolável urgência do pedido. Quanto mais atendemos aos pedidos, mais pedidos chegavam e mais elaborados eles eram. Ao ponto de que os desenvolvedores aumentaram a jornada de trabalho para tentar atender 100% das demandas no mês. Ficou exaustivo fazer isso e combinamos em reduzir essa meta. Hoje ela está dentro de uma faixa que vai de 60% até 80% dos pedidos realizados no mês. 

“Puxa Avelino, mas assim você deixa de atender até 40% dos pedidos?” Sim, uma boa parte dos pedidos que chegam até os meus times são irrelevantes para os nossos produtos. Relatórios de tiro único (usados uma vez e nunca mais), funcionalidades que só uma pessoa de um universo de milhares vê alguma utilidade, pedidos mal definidos, pedidos feitos com excesso de antecedência, pedidos que precisam de autorizações e não foram autorizados, pedidos de epifania que a pessoa ainda não consegue explicar. Tudo isso, se entrar no fluxo, irá consumir a nossa capacidade e não consegue demonstrar valor, logo no meu caso, não é problema não atender 40% do que é pedido. Lembre-se do 10º princípio da agilidade: 

Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial.

Manifesto Ágil

Controle o tempo de duração do trabalho

Quanto tempo leva desde que o seu cliente te pede algo até o momento em que você entrega para ele? O Customer Lead Time é fundamental para você fazer uma gestão de expectativa com a pessoa que está solicitando o seu serviço. Além disso, ele é importante para saber se você consegue ou não atender uma demanda urgentíssima. Por exemplo, se chega um item urgentíssimo e que precisa ser entregue em 5 dias e, você olha para o seu histórico e vê que em 95% dos casos o seu Customer Lead Time para esse tipo de item nunca foi menor do que 8 dias, temos um grande problema para resolver. O que fazer com essa demanda urgentíssima. Cortar escopo, trabalhar por mais horas, não aceitar? Decisões precisam ser tomadas.

Conclusão 

A gestão de filas é o fundamento da gestão. Infelizmente não nos ensinam isso seja na faculdade ou nos MBAs. Você precisa dar visibilidade a elas e tratá-las para criar um time eficiente e capaz de atender demandas da melhor forma possível. 

Ainda há muito conteúdo para explorarmos sobre gestão de filas. Recomendo a leitura do livro do Don Reinertsen, The Principles of Product Development Flow. É um livro pesado que requer algum conhecimento de estatística, mas é bem completo. Recomendo muito que você ouça o podcast Segue o Flow com Luiz (Lula) Rodrigues, Danilo Garcia e Guilherme Guitte. Eles resumem a obra do Don Reinertsen com maestria. Outra obra que recomendo a leitura e essa tem em português é: A Meta de Goldratt. Para essa, infelizmente, não conheço um podcast.

Quer saber mais sobre gestão de fluxo, veja os nossos treinamentos de:

Team Kanban Practitioner (TKP)

Kanban System Design (KSD)

Kanban Systems Improvement (KSI)

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

Nas discussões e workshops sobre OKRs que fazemos nas empresas, um conceito sempre aparece: Estão faltando métricas de guard rail para equilibrar esses OKRs! As Métricas de saúde (ou Guard Rails) ajudam a liderança e as equipes a manterem um…

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

O que é gargalo Quando falamos sobre Kanban um dos nossos principais objetivos é identificar onde está o gargalo do nosso fluxo. O gargalo é a etapa em que os itens permanecem por mais tempo. É fundamental resolver os gargalos…

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

Seja em treinamentos, consultoria ou até mesmo com meus times de desenvolvimento. Uma coisa fácil de perceber é o desconforto causado quando comento sobre a necessidade de limitação de WIP. É algo que me causa estranheza. Por que as pessoas…

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

No artigo anterior, comentamos sobre o que era o Kanban, qual problema ele resolve e os princípios que norteiam esse método de gestão de trabalho. Este artigo é um complemento ao primeiro e nele quero tratar as práticas que o…