Quando olhamos para um fluxo de trabalho, temos que buscar formas de torná-lo mais eficiente. Entretanto, muitas vezes podemos ficar parados, olhando para ele, sem saber o que deveríamos estar procurando. Por isso, é essencial saber quais aspectos analisar para melhorar o fluxo. Este artigo tem exatamente esse propósito: mostrar o que observar no seu fluxo de trabalho para torná-lo mais eficiente. Espero que ele te ajude a encontrar o problema e tratá-lo.
Vou categorizar os problemas em três tipos: 1) Técnicos; 2) Fluxo de trabalho; e 3) Produto
Problemas Técnicos
Defeitos
Um dos piores problemas enfrentados por times que desenvolvem projetos, produtos e serviços são os defeitos. Entenda um defeito como sendo algo que foi entregue para um cliente / consumidor, não funcionou conforme o esperado e essa pessoa reclamou. Os defeitos interrompem o fluxo de trabalho e atrapalham a previsibilidade das outras entregas, além de acabar com qualquer planejamento.
Não há mágica para resolver isso. É necessário investir na qualidade da entrega. Você pode até acrescentar uma etapa no seu fluxo para garantia da qualidade, porém o quão mais automatizado for essa garantia, melhor.
Outra ideia melhor ainda é que cada pessoa que trabalha em uma etapa do fluxo deve garantir a qualidade do produto, e as Definições de Transição (DoT) ajudam nisso. Isso torna a qualidade uma obrigação desde a concepção até a entrega.

Super processamento
Em um time de desenvolvimento de software por onde passei, as pessoas que cuidavam da etapa de testes e qualidade eram super minuciosas e testavam cada campo de um formulário à exaustão. Eles verificam se 30 de fevereiro era realmente uma data inválida, se o campo nome cabia o nome completo e D. Pedro I, burlavam as regras de negócio para testar exceções impossíveis e muitas coisas mais.
Em uma primeira olhada você pode pensar que é bom, pois a qualidade era muito alta. Infelizmente não era verdade. Como os itens ficavam muito tempo nessa etapa, as entregas atrasavam. Já que as entregas atrasavam, os clientes pressionavam. Como resultado, os gestores criavam urgências. No fim, a pressão aumentava tanto que a etapa de testes e qualidade era pulada. Isso gerava um efeito cascata.
Superprocessamento (over processing) é um desperdício que ocorre quando adicionamos complexidade. Consequentemente, isso não gera valor real para o cliente.
Para resolver isso, antes de tudo, é realmente necessário entender qual o trabalho necessário para que uma etapa seja concluída. As pessoas não devem fazer menos e nem mais do que o necessário. Siga a dica do Balu.

Falta de automação
Por fim, em tempos de Inteligência Artificial (IA), devemos pensar muitas vezes antes de usar humanos para trabalhos repetitivos. Imagine que em um fluxo exista uma etapa de teste e qualidade. Imagine também que o time esteja na Sprint 113 e a pessoa de teste e qualidade tem que avaliar o impacto de coisas que foram construídas e entregues na Sprint 1, há mais de um ano, e podem ter sido impactadas por coisas que entregaremos agora. Seria um trabalho hercúleo e provavelmente impossível. Por essa razão, existem Testes Automatizados.
Não importa a área do seu negócio, alguma etapa do processo provavelmente pode ser automatizada com outros produtos, software, robôs ou IA. Libere as pessoas para executar trabalho que realmente precise de pessoas.
Problemas no Fluxo de Trabalho
Está pronto, só falta…
Frase famosa que deveria ser abolida de qualquer time. Estar pronto é algo um tanto binário. Ou está ou não está. O está “pronto, só falta…” é normalmente uma tentativa de dizer que um item esteja entregue sem que ele esteja entregue. O problema acontece quando o item se move para a entrega. Como consequência, haverá o deslocamento obrigatório de pessoas para tentar concluir os itens. Essa etapa não está mapeada e todo o trabalho se torna trabalho escondido. As pessoas param o que estavam fazendo para resolver os problemas da entrega. Previsibilidade e planejamento sofrem significativamente com isso. Uma boa solução é que seu time não tenha um fluxo de trabalho mentiroso, ele deve ser um retrato fiel do trabalho necessário para que o item seja entregue para o cliente.
Há algum tempo atrás estive em um cliente que tinha um fluxo que era mais ou menos assim:

O problema é que, ao chegar na etapa “pronto”, o item ainda não estava realmente disponível para o cliente. Isso acontecia porque ele dependia de outro time (dependência externa) responsável pela implantação e disponibilização dos itens de trabalho. Como esses times não estavam sincronizados, a implantação não era imediata, gerando atrasos e retrabalho. Quando começava, e surgiam problemas, o fluxo de trabalho do time de desenvolvimento, não atendia esse “retorno” e as pessoas ficavam dando jeitinho para resolver os problemas que só apareciam na implantação.
A solução para esse caso envolve um espectro de possibilidades. A mais simples é o mapeamento completo do fluxo de trabalho, deixando claro que há uma dependência externa e que o fluxo de trabalho só se encerra quando essa dependência sinaliza que a entrega foi feita com sucesso. Aliás, foi o que fizemos. Além disso, é bom conversar com o outro time sobre como podemos deixar o trabalho dele mais leve aumentando a qualidade do trabalho antes de passar o item para a dependência externa. Também tomamos essa decisão.

Por fim, mas não é tão fácil, conversar com os dois times para que o trabalho se torne um tanto mais síncrono. Conversei sobre isso no artigo: Como lidar com dependências externas em times ágeis.
Superprodução
Acontece quando o seu time produz, produz, produz, as coisas estão de fato prontas, porém não são entregues para o cliente. Ficam em um estado permanente de espera. Você pode até pensar que não tem problema, afinal as coisas estão prontas. De fato, enquanto o cliente não utilizá-las tudo estará bem. O problema acontece quando o cliente utilizar. Como resultado, dezenas de pedidos de alteração das coisas que estavam “prontas” surgirão.
Ao escolher fazer entregas gigantes (big batches) em detrimento de diversas entregas pequenas, estamos abrindo caminho para uma tempestade de feedbacks que inundaram seu. Backlog durante os próximos meses. O problema é que todos serão “urgentes” e farão profundas mudanças no seu projeto, produto ou serviço.
Para evitar isso, o ideal é não aguardar muito tempo para realizar entregas. Se o seu produto não pode ser entregue diretamente ao cliente final por causa de alguma campanha ou evento futuro, então chame pessoas de fora do seu time para testá-lo.
Uma vez nós estávamos trabalhando com o Banco do Brasil e um time fez uma boa entrega, porém o serviço que eles estavam entregando fazia parte de algo maior e não poderia ser lançado para o público. Era um serviço para as pessoas que já eram clientes do banco. Para resolver isso, abrimos a porta de uma grande sala cheia de funcionários do banco e perguntamos: “Quem aqui é correntista do Banco do Brasil?” Em segundos tivemos dezenas de clientes para avaliar o serviço e fornecer feedbacks sobre a entrega.
Estoque de produto inacabado
Esse parece com os dois últimos, mas tem diferenças. Tanto na superprodução quanto no “está pronto só falta…” existe um sentimento de completude. Aqui não. As coisas ficam paradas em alguma ou algumas etapas do fluxo e nada é construído.
Há algum tempo trabalhei com alguns times de desenvolvimento de software de uma empresa de telefonia. Esses times tinham um desafio enorme de ter que lidar com o legado gigante do passado que remonta até os tempos em que essas empresas eram estatais. Os times eram supercompetentes, mas a realidade era cruel.
Eles tinham pessoas de Experiência do Usuário (User eXperience, UX) que eram fantásticas e produziam muitas telas que deveriam ser implementadas pelos desenvolvedores. O problema era que, devido ao legado, a eficiência do desenvolvimento era muito baixa. Chegou em um ponto que um dos times já tinha mais de 100 telas “prontas” pelos UXs sem que os desenvolvedores pudessem sequer parar para analisar como implementar.
Quando os desenvolvedores conseguiam pegar uma tela que já estava “pronta” começavam as dúvidas e discussões. Os UXs nem lembravam daquela tela, pois, depois dela, já tinham produzido outras 99. Era um caos.
Qualquer indústria sabe que o estoque de produtos inacabados é um problema. Até porque ele deprecia. A dica aqui é simples: pare! Inclusive, temos um lema:
Não adianta ficar começando coisas só para manter as pessoas ocupadas. Nosso objetivo primário é entregar valor e não manter pessoas ocupadas o tempo todo.
Etapas Desnecessárias
Uma vez estive em uma multinacional que desenvolvia software e lá havia duas regras que chamavam a atenção: “1) o manual do produto deve ser atualizado toda funcionalidade incluída, alterada ou excluída. 2) Todas as telas, botões e campos devem ser descritos no manual”. Era uma ferramenta de ERP (Enterprise Resource Planning – Planejamento de Recursos Empresariais) e se você já teve contato com alguma, já pode imaginar a quantidade absurda de telas, botões e campos. Isso atrasava horrores a entrega, pois a escrita e a reescrita do manual só começavam depois de tudo estar construído. Além disso, também era necessário incluir no manual a legislação que a funcionalidade impactava.
Pedimos para o time de desenvolvimento ver o resultado da taxa de acesso a ambos (contadores incrementos toda vez que o manual ou os itens de legislação são acessados). Não lembro exatamente dos números, mas a taxa de acesso ao manual era terrivelmente ínfima, quanto a legislação era alta.
Não sem lutas e alguns protestos conseguimos primeiro reduzir a carga de esforço no manual até remover essa etapa e dar ênfase à legislação. Esta era muito mais simples uma vez que já vem pronta. O time passou a apenas conectar a legislação às telas.
Excesso de burocracia
“Para concluir essa etapa é necessário que o chefe, do chefe, do chefe que está em Singapura aprove os itens”. Falta de acessos, aprovações de pessoas indisponíveis, “janelas” de release (entregas), trens que só partem de 3 em 3 meses 😈. Criamos regras, mas ninguém as revisa ou atualiza. Normalmente, essas regras surgem como resposta a um problema do passado que causou um trauma. Como reação, as pessoas criaram um batalhão de regras para evitar que o problema acontecesse novamente. Porém, como um pica-pau chato, ele sempre aparece novamente. Aí criam mais e mais regras para evitar que o problema volte a acontecer, porém ele volta e volta ainda pior.
Se você ainda não teve essa experiência, mais cedo ou mais tarde, terá. Algumas regras são tão limitantes que as empresas perdem clientes, mas não revisam processos que já deveriam ter sido concluídos há muito tempo. Vou contar dois casos que achei interessantes.
Uma empresa de seguros criou um papel de Business Owner (BO)para seus produtos digitais. Eles teriam a obrigação de participar do refinamento do produto e aprovar as entregas. As pessoas que assumiram esses papeis eram todos gerentes seniores da empresa. Eles eram responsáveis por muitas coisas, inclusive ser o BO dos produtos.
Pense bem. Você é um gerente sênior de uma empresa que tem zilhões de responsabilidades com áreas estratégicas. Quanto tempo você dedica ao seu novo papel? Zero. Na prática eles ficavam resolvendo problemas de suas áreas durante o refinamento, quando iam. Na hora de aprovar a entrega não estavam disponíveis.
Outro caso que eu passei foi na TI. Em uma determinada empresa, o time de Inteligência do Negócio avaliava tudo que os times de desenvolvimento entregavam. O problema era que só havia um time de Inteligência do Negócio para dezenas de times de desenvolvimento. Se eles realmente fizessem o trabalho deles, cada entrega demoraria meses, pois teriam que avaliar incremento por incremento. Na prática, eles aprovavam tudo sem olhar.
Perguntamos para eles, quando o trabalho deles era realmente necessário, eles utilizavam o resultado dessas avaliações. A resposta foi não. Então perguntamos por que havia uma etapa de avaliação que não avaliava nada e o resultado era irrelevante. A resposta foi porque estava escrito no processo de 2014. Já estávamos em 2019 e ninguém revisou o processo em 5 anos.
Se você está em uma situação de excesso de burocracia, saiba que ela foi provocada por algum trauma do passado ou um BDUF “genial”. No geral, é um problema de confiança. Entenda os motivos, mexa no fluxo para que as pessoas tenham maior confiança no trabalho realizado, demonstre que o excesso de burocracia não só dificulta a entrega de valor como também reduz o valor da entrega (perdas financeiras ou satisfação do cliente) e por fim, remova o excesso de burocracia.
Problemas de produto
Super Serviço
Você já superou as expectativas do seu cliente? Quanto você ganhou por isso? Ele gostou das coisas extras que recebeu?
Parecem perguntas antagônicas, mas nem sempre superar as expectativas do cliente será uma boa ideia. Podemos investir tempo, esforço e dinheiro em coisas que ele não quer e não precisa.
Há algum tempo atrás estávamos em um grande banco e alguém teve a ideia de criar um aplicativo interativo para gestão de investimentos agrários. O aplicativo seria uma fazendinha em que um avatar (bonequinho) ficaria passeando por ele e quando ele chegasse a determinados pontos indicado por animais ou plantações ele abriria as informações sobre investimentos, ativos, opções e tudo mais.
A ideia é bonitinha e se o objetivo fosse conversar com investimento para crianças, seria até uma boa ideia, porém o público-alvo eram adultos investidores e clientes agro.
Se eles tivessem implementado, teríamos as consequências comuns ao super serviço:
- Custo desnecessário – Recursos desperdiçados em desenvolvimento, manutenção e suporte de funcionalidades inúteis ou desvalorizadas.
- Complexidade desnecessária – Tornar o produto mais difícil de usar, reduzindo a adequação ao design.
- Saturação cognitiva – Muitas opções podem confundir o usuário e diminuir a satisfação.
- Diminuição da eficiência – O time de desenvolvimento pode perder foco em melhorias que realmente importam.
Evitar o super serviço é uma necessidade do pessoal de produto e o Fit for Purpose (F4P) pode ajudar a evitar tanto isso quanto o subserviço.
Alternância entre os itens de trabalho
Outro problema que reduz muito a eficiência é quando as pessoas ficam alternando entre os itens de trabalho que estão trabalhando.

Se isso já aconteceu com você, sabe o quão frustrante pode ser. Você começa o dia planejando trabalhar no Item A, mas, no meio do dia, alguém surge dizendo que o Item B é urgente. Então, você para tudo e começa a trabalhar nele. Antes mesmo de avançar, recebe uma ligação informando: “Esqueça tudo, agora o importante é o Item C”. Do nada, seu chefe entra na sala e pergunta sobre o Item A. É como se você estivesse em um grande show de Axé: 🎶🎵🎵 Todo mundo para o item A / todo mundo para o item C / vamos para o Item B 🎵🎵🎶.
Algumas causas disso podem ser: priorização irrelevante, múltiplas entradas no fluxo de trabalho, falta de transparência e ausência de acordos entre solicitantes e times, entre outros fatores.
Normalmente isso só se resolve com boa comunicação. Alguns passos concretos podem ser: definir um único (ou pouquíssimos) pontos de entrada no fluxo de trabalho; critérios de priorização que levem em consideração tanto a necessidade do negócio quanto questões técnicas; Acordos de Nível de Serviço claros por tipo de demanda; adoção de classes de serviço principalmente para tratar demandas urgentes; acordos para que as demandas sejam classificadas nas classes de serviço corretas.
Conclusão
Neste texto apresentei as causas que eu mais esbarrei que reduzem a eficiência de um fluxo de trabalho. Essa não é uma lista exaustiva, há outras coisas que não tratei, por exemplo: acúmulo de dívida técnica, excesso de dependências externas, estagnação de feedbacks, engenharia excessiva, entre outros.
Nenhum fluxo é perfeito, mas sempre há espaço para melhorias. Para avaliar a necessidade de melhorias, analise os gargalos, colete feedbacks regularmente e monitore métricas de desempenho. Ajuste e evolua continuamente. Seu trabalho não é deixar as pessoas ocupadas, mas gerar impacto para seu cliente e sua empresa!
Te aweró