Como elaborar fluxos eficientes para escalar os resultados do seu time tech?
“Gerencie o FLUXO, não as pessoas”.
Esta é uma adaptação usando as palavras de Jurgen Appelo “Gerencie o sistema, não as pessoas” sobre Management 3.0, que encaixa perfeitamente com a proposta deste artigo, onde irei me aprofundar em uma das dimensões de KPIs, descritas em linhas gerais no meu artigo anterior, e compartilhar com vocês boas práticas de gestão de fluxos de trabalho e o porquê isso é mais importante do que gerenciar pessoas individualmente.
No meu último artigo sobre KPIs de Tecnologia, mencionei algumas perguntas que normalmente nós, pessoas gestoras, e nossos times de tecnologia fazemos e/ou recebemos quando falamos do fluxo de entregas:
“(...)
- Estou entregando features e produtos em uma cadência regular?
- Ao ser perguntado sobre “previsão de entrega de uma atividade”, consigo passar uma visão de probabilidade de prazo de maneira assertiva? (e nunca uma data específica!)
- Existe algum fator que está bloqueando o fluxo de entrega?
(...)”
E é para responder da melhor maneira esses e outros questionamentos semelhantes que seguiremos juntos nas próximas seções sobre as principais métricas de gestão de fluxo utilizadas no mercado.
Mas primeiro, vamos entender melhor o que é gestão de fluxo de entrega de valor.
Definindo fluxo de valor e Lead Time
Fluxo de Valor é a execução de atividades ou tarefas ao longo de uma cadeia de valor para que um produto passe por todas fases desde a sua concepção até chegar nas mãos do cliente. Marco Mendes, uma das referências de Kanban, trouxe uma representação semelhante à exibida abaixo para ilustrar um fluxo de valor:
Seguindo os princípios do Lean, precisamos sempre atuar para eliminar desperdícios em nosso fluxo, de forma a reduzir o tempo entre o pedido e a entrega de valor, o Lead Time (uma das métricas das quais que falaremos muito aqui). Outra forma de vermos essa situação é matemática, através da fórmula de Eficiência de Fluxo do Lean:
Onde, o “touch time” significa o tempo que o trabalho está de fato sendo executado (células verdes da figura acima). Logo, se temos por exemplo um fluxo cujo lead time é de 10 dias, porém apenas 3 dias foi de fato de execução de tarefas, podemos dizer que a eficiência desse fluxo é de 30%. Já os outros 70% são considerados “tempos de fila” (células em vermelho), desperdícios, e é nesse percentual que estão nossas oportunidades de melhoria! Segundo Marco, geralmente caímos na armadilha de tentar melhorar o tempo de agregação de valor ao invés de atacar o que gera desperdício.
Para tangibilizar ainda mais os conceitos acima descritos e seguindo uma das propriedades fundamentais do Kanban, a “Visualize o Fluxo de Trabalho”, vamos analisar um quadro kanban com raias muito comuns ao nosso dia-a-dia de desenvolvimento:
No quadro kanban acima podemos dizer que o Lead Time é o tempo decorrido desde o momento de comprometimento do time com a atividade, quando ela sai da raia de “Backlog” e vai para a “Selecionado para Desenv.” (por exemplo em uma reunião de Planning quando o time decide priorizar a demanda para ser desenvolvida) até o momento em que ela é implantada em produção ou seja, está nas mãos do cliente.
Ao longo dessa jornada, a atividade passa por momentos/raias de fila (em vermelho) e momentos em que de fato alguém está executando um trabalho (em verde). Logo, um de nossos objetivos como time é buscar formas de reduzir o tempo em que nosso card permanece nas raias vermelhas, reduzindo o lead time e consequentemente aumentando nossa eficiência de fluxo.
WIP, THROUGHPUT, LEAD TIME E A LEI DE LITTLE
Conforme dito na seção anterior, uma das formas de reduzirmos o Lead Time em busca de um fluxo mais eficiente é diminuirmos o tempo em que um item fica em espera. Isso pode acontecer de forma mais pontual no fluxo, por exemplo, quando temos um cenário com muitas pessoas desenvolvendo código e poucas testando, gerando assim um “gargalo” com vários itens ficando “estacionados” na coluna “Aguardando Testes”.
Mas essa situação pode ser mais drástica, em um cenário em que o time tem o mau hábito de assumir mais trabalho do que consegue entregar, colocando todo o fluxo de trabalho em colapso. Essa situação é evidenciada através da métrica WIP, Work in Progress, que mede todas as atividades que estão em diferentes raias do fluxo em um dado momento, ou seja, mede o trabalho iniciado, porém ainda não concluído. E o impacto desse cenário no Lead Time foi explicitado de forma matemática no que ficou conhecida como a “Lei de Little”:
Ou seja, fica claro que quanto maior o volume de demandas em andamento, maior será o Lead Time do fluxo. E mais, surgiu aí na fórmula a nossa terceira métrica foco neste artigo: o Throughput (vazão), que representa a quantidade de itens entregues (de acordo com a definição de “pronto” do time) em um determinado período de tempo. Opa! Então temos algo bastante provocador que esta fórmula está nos dizendo: ao contrário do que muita gente acha, quanto mais tarefas eu puxo para fazer ao mesmo tempo, MENOS eu entrego! É o famoso lema que seguramente muitos de vocês já ouviram de, se você quer ter um fluxo eficiente de entregas, pare de começar e comece a terminar! O objetivo é sempre mantermos um fluxo consistente de entregas.
Bom, entendo que neste momento vocês já sabem o porquê existem essas métricas. Agora vamos então falar um pouco mais sobre como medi-las e analisá-las. Importante aqui dar os devidos créditos ao Raphael Albino, com quem tive a oportunidade de atualizar recentemente meus conhecimentos sobre essas métricas e cujos ensinamentos servirão de base em vários pontos das próximas seções. Além disso, ressalto que serei “agnóstico” em relação às ferramentas, uma vez que os gráficos que serão apresentados a seguir normalmente estão disponíveis nas principais ferramentas de gestão do mercado, seja de forma nativa ou através de plugins.
Como medir e analisar o Lead Time?
Reforçando o conceito, Lead Time é o tempo decorrido entre o momento em que o time se comprometeu a realizar uma atividade até a sua entrega. Ele pode ser medido apenas focando no fluxo do time de desenvolvimento, o “Lead Time do Sistema” ou “do Downstream” que se inicia no momento em que o time “puxou o card” para iniciar a codificação até a tarefa estar “pronta” (de acordo com os critérios previamente definidos pelo time).
Porém, em equipes mais maduras mede-se também o “Lead Time de Descoberta” ou “do Upstream”, do fluxo imediatamente anterior a esse, que se inicia no momento em que se priorizou o detalhamento de uma ideia de feature/melhoria/produto, passa por todo seu refinamento, até a demanda estar “preparada” (também de acordo com os critérios previamente definidos) para ser “puxada” pelas pessoas desenvolvedoras em uma Reunião de Planning. Por último e como uma consequência das duas métricas anteriores, têm-se o “Lead Time do Cliente”, correspondendo a essas duas jornadas juntas, conforme exemplo na figura abaixo:
Uma boa forma de analisar eventuais distorções do Lead Time é criar um gráfico de dispersão plotando esses valores ao longo do tempo. No eixo x temos o período analisado e no y, o lead time. Pontos maiores indicam que um número maior de cards concluídos naquela data e que tiveram o mesmo valor de lead time. A partir desses valores podemos analisar pontos de distorção sob a ótica de média (linha vermelha) ou mesmo da média móvel (linha azul, calculada levando-se em conta por exemplo os últimos 5 dias a partir de cada ponto).
Histogramas também são uma boa forma de analisar e fazer projeções de lead time, para tentarmos responder melhor a famosa pergunta “quando vai ficar pronto”? Vejam o exemplo abaixo, extraído de um material de autoria do Raphael Albino:
Então agora, se alguém lhe perguntar “Quando a próxima demanda ficará pronta?”, ao invés de você “chutar” uma data específica baseada no feeling e depois “correr atrás” para tentar entregar, você pode fazer uso do gráfico acima e dizer: “Olha, o prazo que entregamos um card com mais frequência é 1 dia, porém em média levamos 3 dias. Mas se você quer uma data com 95% de certeza, eu diria que seria 6 dias. Daí, se a pessoa disser: “Faça em 3 dias” avise a ela que estatisticamente esse pedido tem um percentual menor de chances de se concretizar e que existem grandes chances de se perder o nível de qualidade adequado. ;)
Como medir e analisar o THROUGHPUT?
Conforme falado anteriormente, o Throughput é uma métrica que mostra a quantidade de itens entregues em um dado período, nos ajudando a entender se o time está com uma cadência consistente de entregas. É claro que é importante que esse ritmo de entregas se torne maior, porém mais do que isso que ele se mantenha consistente. De nada adianta termos semanas de uma “enxurrada” de entregas seguidas por outras de nenhuma entrega de valor. No exemplo abaixo, temos um fluxo que preocupa dado a quantidade de semanas sem entregas e a alta variabilidade de volume nas que tiveram itens entregues.
Outra visão bastante interessante baseada em throughput é segregar o gráfico por tipos de entrega:
Essa visão traz uma análise bastante interessante para saber se o time está mais focado em entrega de valor: histórias ou melhorias (sim, melhorias técnicas é entrega de valor!) ou em correções: bugs ou vulnerabilidades. Caso seja o segundo cenário, vale entender a causa raiz e trabalhar em cima de refatorações, melhorias de testes de qualidade, segurança, etc.
Por último trago uma nova visão apresentada pelo Raphael Albino que traz um comparativo entre Receita e Entregas, o que faz total sentido como uma forma de medir não o volume, mas o resultado que essas entregas estão trazendo:
Como medir e analisar o WIP (Work In Progress)?
Como já sabemos, o WIP - trabalho em progresso - demonstra todo o trabalho iniciado e ainda não concluído pelo time em um dado momento e ele tem total relação com o Lead Time e a eficiência do fluxo. Um WIP crescente indica normalmente problemas de priorização, com o time trocando de prioridades e puxando novas tarefas sem ter concluído outras iniciadas previamente.
Uma das formas de identificarmos grandes variações de WIP é um gráfico que mostra Net Flow ou seja, diferenças entre itens iniciados x itens entregues:
Percebam que este é um fluxo que demanda intervenção, uma vez que normalmente são iniciadas mais tarefas do que concluídas, com uma linha de tendência de crescimento do WIP.
Outra maneira de se analisar o WIP para identificar melhorias no fluxo é mapear o Aging (idade) dos itens que estão em andamento no fluxo como um todo ou em uma determinada fase, em busca de distorções. O gráfico abaixo mostra um exemplo de uma “fotografia” de um fluxo. Nela podemos notar que um grande vilão do Lead Time são os itens “envelhecidos”, aguardando homologação.
Para finalizar, segue um artigo muito interessante do Cleiton Mafra sobre uma forma mais avançada de se acompanhar o WIP dos fluxos, onde ele estabelece o conceito da métrica “Aging WIP”. No texto ele traz também um ponto muito importante em relação ao WIP que vale reforçar: ao contrário do Lead Time e do Throughput, que são muito focados em analisar o passado, a análise do WIP nos ajuda em tempo real a identificar oportunidades de melhoria sem ter que aguardar sua conclusão para analisar os efeitos no Lead Time.
Como descobrir o que está atrapalhando a eficiência do seu time tech?
Uma ótima ferramenta para nos ajudar a visualizar potenciais ofensores da eficiência de nosso fluxo é o gráfico CFD, Cumulative Flow Diagram exibido na figura abaixo, adaptado de um material de autoria do Marco Mendes:
Vejam que em uma única visão podemos ter uma série de informações:
- O backlog se mantém crescendo a uma taxa constante;
- Não existem grandes filas de itens se formando nos status de “Em Andamento” e “Testes” (o tamanho das faixas dessas cores se mantém mais ou menos constante);
- Os principais momentos de gargalo ocorreram nos status “Pronto” e “Aprovado” (pontos sinalizados com barras verticais no gráfico)
- Os gargalos nos pontos anteriores culminaram em um aumento abrupto de itens sendo entregues em produção nas últimas semanas.
Além disso, através dele você pode extrair as próprias métricas que estamos tratando neste artigo ou seja:
- O Lead Time é a diferença entre datas em uma determinada linha do gráfico traçada desde o ponto de comprometimento (“Em andamento” até a conclusão “Em produção”);
- O WIP é a diferença da quantidade de itens quando se traça uma linha vertical a partir do status “Em andamento” até o final do status “Aprovado”;
- Throughput é a diferença entre a quantidade de itens ao traçarmos uma linha de um ponto a outra da faixa “Em produção” (no desenho exibido como “Taxa de Saída”)
Então, como melhorar o fluxo de trabalho do seu time tech?
Uma vez que já entendemos os problemas que queremos resolver, como gerar análises para nos ajudar a evidenciá-los, seguem abaixo algumas boas práticas para melhorarmos o nosso fluxo de entrega de valor:
- Evite trabalhar com cards (histórias, bugs, etc) muito grandes ou muito pequenos. Não que eles precisem ser do mesmo tamanho/esforço, mas você tendo o cuidado de não colocar no fluxo outliers irá facilitar a ter métricas mais consistentes;
- Organize seus cards em tipos, as “classes de serviço” do Kanban, por exemplo: “Funcionalidades”, “Demandas Regulárias”, “Melhorias”, etc. Isso facilitará a análise de todas as métricas descritas aqui, ajudando a entender se um determinado problema de alto Lead Time, baixo throughput, etc está setorizado em um tipo de demanda específico. Ah! E não se esqueça de criar um tipo para aquelas famigeradas demandas urgentes que furam toda a priorização. É super importante entender o volume e o impacto que elas estão causando no fluxo;
- Analise cards com Aging WIP muito grandes e tente entender o que está evitando que eles sejam concluídos (normalmente dependências ou troca de prioridades). Avalie inclusive a possibilidade de descartá-los. O WIP do sistema deve ser constante;
- Analise cards que tiveram alto Lead Time e tente identificar um padrão de momento do fluxo em que eles permaneceram por mais tempo, ou seja, possíveis gargalos;
- Incentive o time a trabalhar em um “sistema puxado” de entregas, focando sempre em atuar para que um item que já está em andamento seja concluído antes de puxar um novo. Além disso, estabeleça “Políticas de WIP” definindo limites máximos de itens que podem estar em determinado pontos de gargalo no fluxo, de forma a “obrigar” que eles sejam resolvidos antes que um novo item chegue naquela raia (reforçando aqui o “pare de começar e comece a terminar”);
- Procure garantir que a taxa de entrada média de itens no fluxo seja igual à taxa de saída;
- Retrospectivas são um ótimo momento para analisar métricas referentes às últimas entregas, outliers e coletar lições aprendidas para as próximas;
- Utilize ferramentas estatísticas para realizar projeções de entregas, como a Simulação de Monte Carlo, bem detalhada neste artigo aqui do Lucas Colucci.
Ótimo, então com essas métricas vou conseguir distinguir entre pessoas e times bons e ruins?
Definitivamente: NÃO! Esse não é o objetivo aqui. Trazendo novamente algumas excelentes reflexões do Raphael Albino, é um grande perigo começar a medir individualmente e comparar pessoas e times. Não apenas pelo fato de que existe um contexto e momento de cada time/pessoa. Mas, principalmente porque introduzimos no ambiente uma cultura orientada à competição de que “quem entrega mais é melhor”, corremos um grande risco de incentivar as equipes a entregarem mais rápido a qualquer preço, abrindo mão de qualidade e de impacto para o cliente.
Além disso, segundo Albino, em ambientes onde a entrega é incentivada, as pessoas se deslocam rapidamente para a próxima tarefa a ser feita, sem ter tido o cuidado de avaliar o impacto do que foi entregue. É o famoso “diga-me como me medes que eu te direi como me comporto”. Sendo assim, reforço aqui algumas frases sobre essa questão:
- “Métricas devem ser usadas para evoluir fluxos e não para gerar cobranças e comparações destrutivas”. Raphael Albino;
- “Números sem contexto são perigosos.” Raphael Albino;
- “Onde existe medo, existem números errados”. William Deming;
- “Medição individual estimula a competição e reduz cooperação” Ana G. Soares.
- “GERENCIE O SISTEMA, NÃO AS PESSOAS” Jurgen Appelo.
E, por último, a premissa que a IFTL mais bate:
Só conhecimento técnico não garante senioridade. Líderes técnicos precisam ser estratégicos e entender de pessoas.
Com a Mentoria CTO do IFTL, você tem acesso a playbooks editáveis e templates para te ajudar nos principais processos de TI, inclusive em todo o ciclo de desenvolvimento de pessoas, desde atração até plano de carreira e desligamento.
Espero que tenham gostado. Conecte-se comigo nas minhas redes sociais e vamos bater um papo sobre o assunto.
Embaixador
Luis Batista
Head de Engenharia de Software especializado em produtos digitais. Graduado em Ciência da Computação (UFMG), com experiência em liderança de pessoas em diversas áreas de TI, como engenharia e arquitetura de software, infraestrutura cloud, business intelligence, governança de TI, segurança da informação dentre outras. Além de startups, empresas públicas e privadas de variados portes/segmentos, nacionais e multinacionais. Tem interesse em assuntos relacionados a liderança e desenvolvimento de pessoas, gestão, tecnologia, música, esportes e viagens.