Custo de transação e custo de coordenação - Um exemplo simples

Vamos tratar aqui um exemplo simples para ilustrar o que é o custo de transação e custo de coordenação.

Existe um podcast que costumo usar para aprimoramento do meu inglês. Eles trabalhavam com um formato para o qual a minha rotina já estava ajustada: o episódio era liberado, semanalmente, com uma duração de cerca de 30m. Como eu estava com todos os episódios atrasados, eu os ouvia em sequência. Como sou adepto do transporte ativo e do transporte público, este formato estava encaixado na minha rotina de ida e volta do escritório. Entretanto, na série 3 deste podcast, eles mudaram o formato para cerca de 8 minutos por episódio.

Quais foram as consequências desta mudança:

Custo de transação

Como o aplicativo do podcast não passa automaticamente os episódios, eu precisei, agora de 8 em 8 minutos, pegar meu celular, desbloquea-lo, voltar do player do aplicativo para a lista das séries, baixar e tocar o próximo episódio, bloquear e guardar o celular. Parece pouco, mas eu precisei fazer este processo cerca de 4x a mais do que era feito antes. É chato. É muito chato. Numericamente, meu custo de transação para ouvir o podcast quadruplicou. Isso é muita coisa. Eu digo "pelo menos" porque ele não aumentou só pela quantidade de vezes a mais que eu preciso fazer as ações para mudar de episódio. Como o custo de transação deles é alto, esse aumento é exponencial.


O que é o custo de transação?

Pegar meu celular, desbloquea-lo, voltar do player do aplicativo para a lista das séries, baixar e tocar o próximo episódio, bloquear e guardar o celular. 

Então o custo de transação, neste exemplo dos podcasts, é o tempo e as atividades necessários para eu mudar de um episódio para outro.

Como diminuir este custo de transação? Seria só tocar automaticamente o próximo episódio da lista, até eu mandar parar. O iTunes faz isso. =)

Custo de coordenação

Além do custo de transação, o sistema do podcast tem um custo de coordenação alto. Este custo consiste na coordenação que preciso fazer, durante o tempo de transação, para eu não me perder na sequência dos episódios, eu preciso clicar no botão geral de edição, apagar o episódio e confirmar a exclusão. Esta ação faz com que o primeiro episódio baixado seja o próximo episódio a ouvir. Isso acontecia 4x menos, como vimos no custo de transação, no formato anterior.

O que é custo de coordenação?

clicar no botão geral de edição, apagar o episódio e confirmar a exclusão.

Então o custo de coordenação é todo custo usado para eu não me perder no sequenciamento dos meus podcasts, assim como a manutenção da bateria com carga suficiente para todo o meu trajeto, checklist para lembrar de levar o carregador (para a volta) e meu fone (para não incomodar as outras pessoas). Mas para esta análise, estamos considerando apenas o meu custo para eu não me perder no sequenciamento dos podcasts.

Como este custo poderia ser reduzido? Bastaria uma funcionalidade para marcar o episódio como "tocado" após o seu término. O iTunes faz isso. =)

Eu sei que você deve estar pensando: que aplicativo ruim você usa. Sim, já estou resolvendo isso, mas pelo menos serviu para este exemplo de mundo real de custos que vemos (quando vemos) muito em livros e palestras.

Conclusão

Aqui estamos analisando tamanho de lote. Um dos tamanhos do lote neste caso é o tamanho do episódio. Outro poderia ser o tamanho da minha fila de episódios para ouvir.

Muitos, até na gestão ágil, defendem o tamanho cada vez mais reduzido do lote para aumentar a fluidez do processo de trabalho. A princípio isso pode parecer uma certeza que todos devem buscar. Entretanto, como vimos, temos outros custos envolvidos nesta decisão: o custo de coordenação e o custo de transação.

Ahh Celso, então você está querendo me dizer que o tamanho de lote ideal para este sistema seriam episódios de 30 minutos? Não. Estou dizendo que com os custos atuais de transação e coordenação episódios maiores funcionam melhor que episódios menores. E como fazer para ter lotes menores, maior fluidez e melhor percepção de entrega? A Toyota já responde essa pergunta a mais de meio século: trabalhar para reduzir os custos de transação e coordenação. É este um dos papéis principais da gestão de fluxo. Nas subseções onde eu explico os dois custos, coloquei sugestões de como reduzir estes custos em um aplicativo de podcast. Ah é mais simples? Sim, ficou mais simples depois que eu esparramei os dados pelo post e o guiei para um pensamento e conclusão fora da caixa. O mesmo acontece dentro da sua empresa.

O problema é que a grande maioria das empresas não faz idéia do tamanho destes custos e tomam decisões completamente no escuro, com a convicção de que estão enxergando tudo, só porque vêem throughput e leadtime. Percebam que neste parágrafo abordamos apenas empresas que já estão no caminho da gestão moderna, que já estão a um passo de medir as coisas certas e de tomar decisões em cima de dados relevantes, de forma científica.

Outros, um pouco mais avançados, já tomam esta decisão em cima do custo de transação. Medem corretamente este custo e o levam para a mesa para discutir o tamanho dos lotes, repetindo isso frequentemente. E isso é lindo, pois permite aos decisores usar análise de dados relevantes e fatos para a tomada de decisão, como venho repetindo. Considero estas pessoas bem mais avançadas até que muita empresa ágil e de ótima cultura.

Entretanto, mesmo nestas empresas, o custo de coordenação pode ser negligenciado. Isso acontece por um problema de entendimento do que pode ser considerado custo de coordenação. No meu exemplo do podcast, meu custo de coordenação está embutido no custo de transação. Nem sempre isso acontece. E nem sempre esse custo é percebido.

O que você precisa fazer agora? Impossível adivinhar através de um post de blog. Medir, analisar e decidir sobre estas informações é algo muito sensível ao contexto. Não existe uma fórmula, diferente do já conhecido ciclo: observação, análise, experimentação, análise dos resultados, adaptação, observação...

Alguém reconhece esse ciclo em outro método, bem mais idoso?

Sim, está correto quem pensou no método científico.

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.

Transição - A cultura da liberdade

Todos os times, absolutamente todos, onde eu trabalhei a transição do modelo tradicional para o modelo ágil, se prenderam bastante na tal liberdade que os métodos ágeis prega para os trabalhadores do conhecimento. É comum você ouvir: não quero trabalhar neste work item, prefiro este. Estamos atrasados, mas isso não é problema meu.