A vida vai bem; os itens de trabalho andam normalmente pelo fluxo, porém, de repente, um item para e não consegue prosseguir, pois está bloqueado. O que significa um item bloqueado e como podemos tratá-lo é o que veremos neste artigo. 

O que é o bloqueio

O primeiro ponto que devemos desfazer é que o bloqueio não é um erro. Na verdade, ele é uma informação muito valiosa. Na prática, ele ocorre quando um item em andamento no nosso fluxo,  por algum motivo, não pode prosseguir.

Pode ser algo que não foi pensado antes, uma surpresa. Por exemplo, no momento em que o time iria disponibilizar uma atualização do site da empresa, descobriu que o certificado digital do servidor havia expirado. Logo, a entrega não pode ser feita até resolver essa pendência. 

Pode ser algo previamente pensado, uma expectativa que não se concretiza. Eu presenciei a fabricação de hardware para a indústria. Era necessário que uma peça importada do Japão chegasse até uma data determinada para não impactar a construção do produto. Como ela não chegou na data prevista, houve um bloqueio, pois o item não poderia prosseguir sem aquela peça para as próximas etapas do fluxo.

No geral, são dependências de ações externas que impedem a continuidade do trabalho. Mais alguns exemplos:

• Dependência externa não atendida
• Falta de acesso
• Falta de aprovação
• Espera de terceiro
• Ambiente quebrado
• Decisões que não foram tomadas

O que não é bloqueio

Digamos que o seu time esteja atualizando uma aplicação disponível no site da empresa. Eles entregaram todas as histórias (itens de trabalho) e as disponibilizaram aos seus clientes. De repente, alguém percebe um erro (bug) na aplicação. Esse erro não é um bloqueio, afinal ,as histórias foram entregues. Ele é um novo item de trabalho que pode ser classificado como um tipo de demanda de erros e receber a classificação de urgência expedite.

Outro exemplo: digamos que o seu time fez a entrega e a disponibilizou ao cliente, e este pediu alterações nela. Isso também não é um bloqueio, pois o combinado inicial já foi entregue; o que o cliente quer deve ser entendido como uma nova demanda decorrente do feedback sobre a entrega.

O que é questionável se é ou não um bloqueio

Imagine um time que tem as seguintes etapas no fluxo de trabalho: Análise, Construção, Teste e Qualidade e Entrega. Digamos que, quando um item chegou à etapa de Teste e Qualidade, perceberam um erro antes de entregá-lo ao cliente. Muitos times tratam isso como um bloqueio, pois o item não pode avançar sem que o problema seja resolvido. Aqui é uma opinião pessoal; creio que não deva ser tratado como um bloqueio, pois faz parte do processo de trabalho. Depende apenas do time para resolvê-lo e são coisas que devem ser discutidas na hora em que se percebe o problema ou, na pior das hipóteses, na Reunião Diária.

Como encarar o bloqueio

A primeira coisa é deixá-lo explícito; o item não pode permanecer discretamente no fluxo de trabalho. Ele tem que ser visível. Quando utilizávamos post-its na parede, marcávamos com post-its vermelhos (ou rosa) para indicar que havia um problema ali. Hoje, com as ferramentas virtuais, é possível fazer diferentes tipos de apresentação da marcação.

Tem que chamar a atenção, pois o problema que não é visto jamais será resolvido.

Uma vez que demos visibilidade ao item, ele tem que ganhar prioridade. A pior coisa que pode acontecer com qualquer time é ter um quadro cheio de bloqueios e as pessoas se acostumarem a eles. Isso reduz muito a conscientização (awareness) sobre o problema, pois se o quadro está sempre com tudo “vermelho”, bloqueado e nada é feito, então ter itens marcados como bloqueados se torna normal.

Bloqueio não pode virar desculpa para: “Depois a gente olha pra isso”. Não! Pense que houve um trabalho de análise, refinamento, avaliação e priorização do item e que ele bloqueou. Se ele virar algo do tipo “depois a gente olha pra isso”, significa que todo o trabalho anterior foi em vão, pois os itens menos prioritários passarão à frente dele. Se o item está bloqueado, tem alguém (ou “alguens”) lutando para remover o bloqueio o quanto antes.

Um item parado aumenta o customer lead time, gera custos, filas e variabilidade, comprometendo a previsibilidade. Logo, destravar tem valor sistêmico.

De quem é o bloqueio?

Segue a ordem: ninguém, todos, alguém. O Kanban e o Scrum dizem que ninguém deve ser o culpado pelo bloqueio; afinal, normalmente, o problema do sistema e não da Maria ou do João. Então, é responsabilidade de todos os membros do time, pois impacta negativamente o trabalho e os resultados do time. Finalmente, se todos têm a responsabilidade, é possível que ninguém faça nada; logo, ter alguém responsável por resolver o bloqueio é uma estratégia inteligente para, de fato, removê-lo. Um CPF responsável costuma ser mais eficaz do que um “CNPJ”.

Bloqueios devem ser medidos

Conforme o time aumenta a maturidade na adoção de Kanban, é comum que eles passem a medir e avaliar os bloqueios. Mais especificamente, se você utiliza o KMM (Kanban Maturity Model), isso ocorre quando passamos dos níveis 2 a 4 de maturidade. Algumas métricas relevantes são:

Blocker Clustering (Agrupamento de Bloqueadores)

A ideia aqui é identificar os bloqueios, classificá-los por temas e medir o que está impactando as entregas. Por exemplo:

No último quadrimestre os bloqueios foram classificados assim:

Com essa informação, já sabemos que temos que tratar urgentemente os problemas de infraestrutura, pois são muito mais significativos do que quaisquer outros problemas.

Blocker Aging (Envelhecimento do Bloqueador)

É o tempo durante o qual os itens ficam bloqueados. Você pode utilizar a média. Por exemplo, um item fica bloqueado, em média, por 3 dias. Ou então, se estiver tentando gerir os riscos, você pode trabalhar com o percentil.

Percentual do tempo bloqueado sobre o customer lead time

Aqui você pode avaliar o impacto real do bloqueio. O Customer Lead Time é o tempo de ponta a ponta; portanto, você pode saber quanto o bloqueio impactou o atendimento à necessidade do cliente. A conta é simples: Tempo de Bloqueio ÷ Customer Lead Time × 100. Por exemplo, se um item levou 10 dias para cruzar todo o fluxo (customer lead time) e desse tempo ele ficou 3 dias bloqueado, nós temos:

% de tempo bloqueado = tempo de bloqueio ÷ customer lead time × 100

% de tempo bloqueado = 3 ÷ 10  × 100

% de Tempo bloqueado = 30%

Obviamente, você pode calcular a média do percentual de tempo em que os itens ficam bloqueados no seu fluxo.

Visualização e Gráficos de bloqueios

Alguns gráficos podem te ajudar a tratar esses bloqueios no seu fluxo de trabalho. Abaixo apresento três deles com propósitos distintos.

Blocker Run Chart (Gráfico de Execução dos Bloqueadores)

Esse é um gráfico interessante para demonstrar visualmente o impacto dos bloqueios nos itens de trabalho. O objetivo é visualizar o impacto de todos os bloqueios em cada item de trabalho e avaliar quanto cada um atrasou a entrega.

No eixo X, temos a passagem do tempo e, no eixo Y, há os diversos itens de trabalho. O Lead Time do item é a linha fina e os bloqueios são marcados com um bloco sobreposto à linha.

Neste exemplo, vemos três itens bloqueados. O item US 101 foi bloqueado duas vezes, a primeira entre os dias 4 e 7 e a segunda entre 1 e 11 do mesmo mês. Já o item US 137 ficou bloqueado por apenas um dia, o que não teve grande impacto. Já o item US 142 teve um impacto significativo na sua construção e na entrega.

Blocker Clustering Chart (Gráfico de agrupamento de bloqueadores)

Aqui, o objetivo é mais analítico, pois identificamos a origem de cada bloqueio, classificamos por temas e avaliamos a probabilidade de itens no fluxo de trabalho sofrerem bloqueios, o impacto desse bloqueio em cada item e o impacto desse bloqueio em todo o sistema.

É, na verdade, uma tabela em que, após agruparmos os bloqueadores por temas, podemos avaliar os impactos desses bloqueios. As duas primeiras colunas referem-se à quantidade e ao percentual que essa quantidade representa. Logo, dado que temos um novo item que está iniciando o fluxo, sabemos que ele tem maior probabilidade de sofrer com um determinado tipo de bloqueio. 

Nesse caso, a maior chance de bloqueio é a instabilidade da API externa. Entretanto, quando isso acontece, não é o pior problema, pois o bloqueio é de 5 dias. O maior tempo de espera ocorre quando o time depende de alguma resposta do fornecedor de serviços, que, embora ocorra pouco, quando ocorre, demora, em média, 32 dias para responder. Entretanto, se esse time tem um bloqueio que impacta significativamente seu trabalho, é a indisponibilidade do cliente para avaliação, pois ocorre com frequência e dura por muito tempo. 

Qual problema resolver? Depende: Se você quiser uma solução que impacte o sistema inteiro, o primeiro tema de bloqueio a resolver é a indisponibilidade do cliente. Se seu time faz reclamações constantes de que, para o tempo todo, isso está minando a satisfação dele, a instabilidade da API pode ser o seu alvo. Já se você sabe que dependerá muito dos fornecedores e que a quantidade desse bloqueio pode aumentar, esse pode ser o início do tratamento.

Gráfico de Pareto

Já o Pareto é um pouco mais sucinto. Seu objetivo é identificar as fontes de bloqueio que mais impactam na execução do trabalho e separá-las das que menos impactam.

 Lembrando que o Pareto também é conhecido como a Regra dos 80:20. Neste caso, indica que 80% do impacto causado pelos bloqueios corresponde a 20% das causas. Aplicando sobre o tempo total de bloqueio com os mesmos dados que utilizamos para o Blocker Clustering Chart, temos:

As barras representam o tempo total decorrido no tipo de bloqueio. A linha representa o percentual acumulado. Nesse gráfico, observamos que 80% do impacto é causado por apenas 3 tipos de bloqueio: indisponibilidade do cliente para avaliação; aguardar resposta do fornecedor; e instabilidade da API externa.

Como tratar o bloqueio

Além de visualizar, agrupar e analisar o bloqueio, também temos que resolvê-lo e, se possível, de forma sistêmica e definitiva. 

Solução Pontual

Infelizmente, nem sempre será possível; por exemplo, dada a urgência de um item, temos que resolver o bloqueio o quanto antes. Nesse caso não há muito o que fazer, apenas apagar o incêndio antes que se alastre.

Transformar o item em expedite

Quando um bloqueio vira uma ameaça real ao sistema (ou ao cliente), o time pode invocar Expedite. Todavia, há consequências, pois muda a prioridade do time inteiro e sacrifica a previsibilidade em troca de agilidade no fluxo. Afinal, na prática, Expedite é veneno, mas às vezes necessário.

Retrospectiva

Independentemente das suas ações no momento do problema, é muito mais importante levar o fato à retrospectiva, avaliar se ele pode voltar a ocorrer e, caso afirmativo, tomar as providências para que ele nunca mais ocorra.

Políticas Explícitas

Outra consequência da boa análise de bloqueios é atualizar as Políticas Explícitas do time e criar novas para tratar deles. Por exemplo:

• Se um item ficar bloqueado por mais de X dias, o gestor do time é acionado para auxiliar no desbloqueio.
• No caso de bloqueio por problema na infraestrutura, não abra um chamado; entre diretamente em contato com o time de infra no modo “linha vermelha”.
• Se um item permanecer bloqueado por mais de Y dias, ele deve ser removido do fluxo e repriorizado para avaliarmos se a sua entrega ainda é relevante.

Essas políticas reduzem o caos e aumentam a previsibilidade.

Bloqueios repetidos viram trabalho upstream

Caso seja recorrente que todos os itens, ao chegar a determinada etapa, fiquem bloqueados. Por exemplo: falta de informação do cliente, decisões que não foram tomadas em tempo oportuno, dependências externas fundamentais; é possível que a solução do “bloqueio” se torne uma etapa do upstream que deverá ser resolvida antes do item iniciar a construção.

Isso é resolver o problema onde ele nasce, não só onde ele aparece.

Conclusão

Bloqueios são inevitáveis em qualquer sistema de trabalho, do mais artesanal ao mais tecnológico. Eles fazem parte da vida real dos times e, longe de serem um sinal de fracasso, são indicadores valiosos sobre como o fluxo realmente se comporta diante da dureza do mundo real. A diferença entre times maduros e imaturos não está na ausência de bloqueios, mas na forma como lidam com eles.

Quando visualizamos um bloqueio com clareza, tratamos com prioridade, analisamos suas causas, compreendemos seu impacto sistêmico e adotamos políticas para preveni-lo no futuro, estamos elevando a maturidade do nosso sistema. Estamos dizendo, na prática, que respeitamos o fluxo, o cliente, a previsibilidade e, principalmente, a capacidade do time de aprender com sua própria operação.

No fim das contas, um bloqueio é um convite. Ele nos chama a investigar, ajustar e fortalecer o fluxo para que ele sirva melhor às pessoas que dele dependem. E, quando tratamos bloqueios assim, eles deixam de ser obstáculos e passam a ser oportunidades reais de evolução.