O Custo Médio por Demanda

Há algumas semanas, coloquei em prática uma iniciativa que me martelava desde que li a primeira página do livro do Don Reinertsen - The Principles of Product Development Flow: Second Generation Lean Product Development - O Custo Médio Por Demanda.

O conceito em si é muito simples.

TL;DR: Defina o que você precisa medir de custo por semana (incluindo sempre o custo do time de desenvolvimento) e divida pela quantidade de demandas entregues naquela semana.

CMD = $ Semana / TH da Semana
$ Semana == Custo da Semana
TH da Semana == throughput == entregas na semana

Simples, hein?

Nos preparar para o estado em que calcular este valor se torna simples é onde reside a dificuldade. Outra dificuldade que costumo encontrar é mostrar às pessoas como usar essa ferramenta de forma eficiente.

Para chegarmos no estado em que essa fórmula será útil para a sua empresa, precisamos aprender e compreender a teoria dos sistemas, a teoria das restrições e, talvez o mais difícil, passar a olhar e metrificar as coisas certas, no momento certo. Infelizmente, no mundo corporativo de hoje, as pessoas teimam em dar maior foco a controle e a metrificar grandes batches, aka, requisitos funcionais. Vamos ver o que podemos fazer com relação a isso.

Don Reinertsen criou e evoluiu um excelente framework econômico no livro citado no início desse artigo. Ao nos presentear com essa obra ele nos diz: vamos parar de usar métricas proxy como pontos de alavancagem ou como justificativa para esses pontos de alavancagem no sistema. O que são métricas proxy? Lead time, cycle time e throughput. Métricas essas super valorizadas, de forma justa, pelo pessoal do Lean (faço parte "desse pessoal"). E pelo que pudemos observar no início deste post, que fala sobre uma métrica final, elas são muito importantes. A fórmula usa diretamente o throughput. O que está errado então no que as empresas Lean já fazem hoje? Parar no throughput.

E sobre as métricas da gestão 1.0? Não servem para nada aqui. Controle de horas e uma grande entrega em grandes lotes no final de grandes ciclos não nos ajudam em nada, não nos mostram pontos de alavancagem, não nos mostram oportunidades de otimização. Assim como o Gantt Chart, que também é inútil aqui. Chega no final do projeto, todos os gestores tradicionais ajoelham no milho com o cliente sobre os atrasos, sobre os bugs, sobre o que ficou para trás. Mandam um grande "UFA" depois dessa reunião e fazem uma festa para comemorar o "sucesso" do projeto. Isso geralmente dá certo, porque nesses casos, o cliente não está muito preocupado com o sucesso do produto, mas apenas em encontrar uma forma de mascarar os números e obter uma promoção ou aumento. E o ciclo vicioso recomeça no projeto seguinte.

Isso pode funcionar em grandes empresas, com diversas camadas de gestão, que pouco se importam com o resultado final. Empresas em que o grande objetivo é ser promovido e "crescer" na carreira. Mas isso é fatal para as empresas que precisam do resultado e que, principalmente, querem o resultado. Querem um produto de qualidade entregue, se possível antes do prazo. Querem estar dentro do processo e não apenas passar para frente e lavar as mãos. Empresas em que sua sobrevivência depende do produto e não onde o produto (ou números mascarados) servem apenas como alavanca pessoal. Se você está em uma empresa onde controle de horas, chicote e Gantt Chart são as ferramentas principais, definitivamente esse post e essa ferramenta não é para você. Peço desculpas por apenas agora ter dito isso. Um bom resto de dia para você.

Aos que ficaram, por que está errado parar no throughput? Por que medir lead time e throughput não é suficiente?

Agora é que a diversão começa.

Vamos começar pelo gráfico de uma das empresas onde eu já implantei o CMD.

Uma observação: Forjei essa ferramenta com o nome de Ticket Médio, fazendo um paralelo com a indústria do entretenimento, que foi de onde eu tirei a idéia. Apesar de dias depois tentar entrar com o nome mais compatível, Custo Médio por Demanda, o nome Ticket Médio já tinha pego com muita força e as minhas tentativas de mudar foram em vão. Então o mercado vai decidir esse nome. O conceito é mais importante, mas precisamos comunicar a ideia corretamente. Vamos decidir juntos se Ticket Medio é tão ruim assim. =)

Chega de bla bla bla.

Este gráfico mostra a variação do TM em uma das empresas onde foi implantado. A linha azul representa o TM por demanda. A linha vermelha é o TM por story points. O TM foi implantado na semana do dia 14/09. Como tínhamos os dados passados, fiz também um cálculo retroativo. Observem a forma errática das séries até a semana do dia 07. O gráfico acima é de um produto.

Nessa empresa, o impacto da visibilidade do nosso custo semanal foi imediato. Na apresentação da métrica, que ocorreu em uma quarta de uma semana com TH baixo, precisei explicar pouco as consequências de um alto TM. Isso criou um ponto de alavancagem de imediato e que se mostrou extremamente eficiente: o time passou a tomar melhores decisões no dia a dia. Aquele refactoring que no final vai agradar apenas ao desenvolvedor, passou a ficar para depois. Aquela tomada de decisão que levava dias, passou a ser realizada na dimensão de minutos. Agora, quando um desenvolvedor está a muito tempo em uma tarefa, com as ideias bloqueadas, ele quase imediatamente chama o time, em vez de esperar 1 ou 2 dias. Essa mudança de comportamento, nas decisões do dia a dia, no minuto a minuto, tiveram um impacto estrondoso na "quantidade de demandas entregues X dinheiro que está sendo investido". Muito mais que o ganho financeiro nos custos, teremos o nosso produto pronto muito mais rápido, reduzindo nosso custo de atraso e fazendo com que a empresa ganhe dinheiro mais rápido.

É possível perceber a teoria dos sistemas em seu estado mais puro aqui? Derivamos algumas fórmulas, falamos de custo e chegamos no lucro como objetivo principal. Como eu disse, nessa empresa não foi necessário discorrer por longos minutos sobre os impactos de um alto TM, e muito menos falamos algo parecido com: precisamos aumentar e estabilizar nosso throughput. Simplesmente aconteceu.

Outra característica que achei muito interessante nessa iniciativa foi que quase todos os números já estavam disponíveis. Os que não estavam, poderiam ser perguntados, como eu fiz para começar esse trabalho. Mas eles estavam invisíveis, portanto, eram inúteis.

Mas o que fazer quando a empresa não reage positivamente às primeiras explicações sobre as implicações financeiras das más decisões? Bem, nesse caso, precisamos nos aprofundar mais nos impactos.

Em outra empresa, outra iniciativa, outro contexto, o impacto não foi imediato. Tivemos uma semana de entrega ZERO e outra com o nível bem baixo. Como também sou pago para pensar problemas, depois de bastante reflexão, percebi que precisaria ir mais a fundo nos impactos. O time de desenvolvimento ainda não estava tomando boas decisões no dia a dia, no minuto a minuto. Desenvolvedores ainda estavam viajando em refactorings e generalização de soluções que não precisavam ser generalizadas. Ainda juntávamos grandes lotes em homologação, trocando transaction cost por holding cost. Ficou claro que a mensagem de fazer nossos clientes ganharem dinheiro rápido e fazer com que nós gastemos pouco não ficou clara. Isso não é demérito. Pessoas diferentes reagem de formas diferentes. Sistemas diferentes reagem de formas diferentes.

A solução imediata foi fazer uma reunião emergencial para nos aprofundar nos números. Vou pegar como exemplo o número de uma das semanas, onde o nosso TM bateu 2.500,00/demanda.

A reunião foi iniciada da seguinte forma: Pessoal, será que temos a noção do que significa 2.500,00/demanda? Vamos fazer uma conta rápida? Esse TM significa que custa para a empresa R$ 25.0000,00 para fazermos 10 demandas. Custa. Continuando, para o nosso comercial nos vender, ele vai precisar colocar 30% em cima destes números. O que nos faria custar R$ 32.500,00 para completar 10 demandas. O que conseguimos fazer com 10 demandas no nosso contexto? Vocês pagariam R$ 32.500,00 para uma empresa desenvolver 10 demandas? Todos disseram que daria para entregar pouca coisa com isso.

Infelizmente, como nosso fluxo de caixa era muito baixo, um dos impactos demonstrados seria iniciar um processo de demissão. Esse processo de demissão teria dois objetivos: a redução imediata do TM com o corte de custos do time e a oxigenação do mindset para o mindset financeiro.

O impacto foi imediato. Imediato!

Quais os resultados e as características que emergiram, que na verdade compõem a pedra fundamental dessa iniciativa?

1. Nas semanas seguintes, nosso TM baixou para a casa do 600.00 e não tivemos mais semanas zeradas. 
2. Passamos a ver pareamentos constantes (comprovando cientificamente o valor do pareamento);
3. Passamos a ter timeboxes bem definidos para as viagens de refactoring ou generalizações ou para as soluções de pedestal de praça pública; 
4. Aumentou o peer-pressure. As pessoas que já estavam dentro do mindset financeiro, ganharam uma ferramenta muito eficiente para realizarem auto-cobrança e cobrarem seus pares;
5. Ganhamos uma ferramenta eficiente de definição de metas. Definimos uma meta para o TM e acima dela estamos no vermelho e abaixo dela no verde. Não é incomum ouvir agora nessa empresa: quando estivermos no verde, faremos isso;
6. Ganhamos uma ferramenta de priorização: como implantamos o fluxo único - cinco projetos, um fluxo -, nós priorizávamos as demandas sem uma base sólida. Agora temos uma ferramenta financeira para definir essa priorização e ajudar na tomada de decisão do nosso Analista de Negócios.

Acho que não é pouca coisa. Acho que economizar dinheiro não é pouca coisa.

Voltando para a gestão 1.0, se fosse possível calcular o TM com grandes lotes, do que vai adiantar essa métrica a cada 6 meses? A cada 1 ano? Para o próximo projeto? Comparar dois projetos é como comparar banana com maçã. Ou pêra com maçã quando são parecidos. O importante é notar que ao comparar dois projetos, você nunca estará comparando maçã com maçã. Nunca.

O que é preciso?

• Medir o TH de forma prática, eficiente e estável;
• Para isso precisamos garantir a homogeneidade entre as demandas e que as coisas grandes sejam realmente excessões no fluxo;
• Se usa story points, meça o TM absoluto (por demanda) e o TM dos pontos. Coloque os dois no mesmo gráfico e acompanhe a evolução. Se a evolução das duas linhas estiver próxima, talvez seja um indício para remoção das story points. TM ajudando em uma tomada de decisão, mais uma vez de forma científica;
• Tenha os dados de cada semana como em uma fotografia semanal. Não perca os dados de outra semana. Não remova as informações pertinentes àquela semana. O motivo está nos dois próximos pontos;
• Mantenha estável a sua lógica para o cálculo do custo semanal até o fim do projeto. Isso quer dizer que se você considera só o salário dos desenvolvedores, mantenha assim até o final. Se você considera os custos completos (github, code climate, luz, água, telefone, gás...) faça assim até o final. Não vai fazer diferença para o propósito do TM se você considera essas dimensões ou não, porque o que importa é o fator comparativo entre as semanas. Se começou de um jeito, vá assim até o final;
• Considere sempre a variação no time. Em uma semana, entrou um novo dev em um dos times de uma das empresas (vago huh? =) ). Ele entrou na quinta, assim adicionei na planilha 2/5 do custo semanal dele. Na semana seguinte, o custo total semanal foi considerado.

E o propósito dessa ferramenta?

Ajudar as pessoas envolvidas em processo de desenvolvimento de software (ainda não sei se dá para portar para outras áreas) a tomar melhores decisões no dia a dia, da hora em que levanta a hora que vai se deitar. Uma consequência direta de melhores decisões, mais que entregar mais, é a estabilização do sistema. É impressionante como todas as decisões que emergiram dos desenvolvedores a partir da implantação fizeram o sistema caminhar para essa estabilização (vide o gráfico de exemplo). Isso eu pude perceber nas duas iniciativas usadas aqui como exemplo. Uma mais cedo e a outra um pouco mais tarde.

EDIT: Também emergiram decisões interessantes por toda a empresa, mas como possuem impactos de longo prazo, ainda estamos estudando os efeitos.

E estabilização traz previsibilidade.

Uma consequência inesperada foi o transporte do uso do TM para outras áreas de uma das empresas. Essa experiência se encontra ainda em estado embrionário e poderá ajudar na resposta se podemos ou não portar para outras áreas. Mas já adianto que parece que isso ajudou muito no comercial, fazendo as pessoas focarem nas vendas certas e reduzir a perda de dinheiro com clientes que não valiam a pena. Nada como a visibilidade do taxímetro. =)

Mas ainda existem dois propósitos secundários: Usar uma forma científica de encontrar pontos de alavancagem e extinguir o determinismo da gestão, a trazendo para o lado científico da coisa.

Celso, quando posso usar essa parada?

Assim que você achar necessário. Só deixe-me saber como está e como está evoluindo. Também pode gritar em caso de dúvidas. Estou estruturando consultoria em cima disso, então caso tenha interesse, me contacte também. Bora tornar o desenvolvimento de software no Brasil mais eficiente. Chega das rodas enferrujadas da engrenagem da gestão antiga.

Estarei no AgileBrazil na próxima semana e o meu propósito com esse post é fundamentar um monte de conversas que já estão marcadas para Porto de Galinhas. Se você estiver por lá, não deixe de me chamar para bater um papo. Vou adorar. =)

Essa é a primeira versão estruturada dessa ferramenta, portanto aceito feedbacks e debates. O que eu não vi? O que estou perdendo? Como podemos evoluir isso?

Há muito tempo, um grande amigo de olho puxado me disse: "Gestores dizendo que as coisas não fluem porque as pessoas não se esforçam é um diagnóstico simplista, preguiçoso e fora da realidade."

O nome desse amigo é Rodrigo Yoshima.

Essa frase está ultrapassando a barreira do tempo e continua muito válida hoje em dia.

Amplie suas capacidades de visão e de análise. Você não vai se arrepender e o sistema "Sua Empresa" colherá rapidamente os benefícios dessa mudança de mindset.

No exemplo que dei do TM alto, não era esforço que faltava, mas melhores decisões.

Saia do determinismo e entenda o seu sistema.