Você usa o throughput estrategicamente? Simplesmente pare!

Neste post vamos tratar um assunto recorrente, principalmente nas empresas que desenvolvem software. Uma métrica muito famosa, principalmente no mundo Lean é o throughput, que trata a quantidade de “coisas” que vazam em uma unidade de tempo. Se a mangueira do meu jardim libera 2 litros de água por segundo, então o throughput desta mangueira é de 2 litros/segundo.

Como atualmente observamos que o valor flui através dos sistemas da empresa, é comum esbarrarmos com este tipo de métrica. No desenvolvimento de software, é comum medirmos demandas por unidade de tempo ou pontos por unidade de tempo, o que torna trabalhar com este tipo de métrica muito natural.

A armadilha do throughput

Agora enfrentamos outro tipo de problema. Como usar estas métricas? Este tipo de dúvida sempre existiu com todo tipo de método ou métrica. O mal uso destruiu (ou quase) alguns conceitos. O RUP sofreu com isso. O Scrum sofreu com isso. O Kanban sofreu com isso. No caso do throughput, um dos seus usos equivocados, é no suporte de decisões estratégicas/econômicas. Throughput é uma métrica tática. Ela é indispensável, mas dando suporte à tomadas de decisão táticas. Este assunto é tão importante que levou Don a fazer a seguinte citação em seu livro:

While this is true, we need a bit more sophistication when dealing with the stochastic bottlenecks of product development. Optimizing the economics of a process is very different than maximizing its throughput. The economics of a bottleneck process are usually dominated by the size of its queue. However, the size of this queue is affected by more than the operating rate of the bottleneck. tweet

Otimizar as variáveis econômicas de um processo é muito diferente de otimizar a sua vazão, afirma Reinertsen. Throughput é uma métrica que está diretamente relacionada com eficiência. Quando desenvolvemos softwares, devemos focar na eficácia. Precisamos cuidar do valor que estamos entregando. Isso envolve inteligência e muito trabalho sincronizado entre cliente e fornecedor desde os primeiros momentos do planejamento da execução de uma idéia. Algumas empresas estão inclusive criando restrições para seu funil de outsourcing, só aceitando projetos que estejam muito no início. Estas empresas querem participar do desenvolvimento da idéia, do produto e não se consideram mais apenas desenvolvedoras de software.

Um produto, um fluxo, um time, um esforço

Eu quero me aprofundar um pouco mais que os textos ordinários que já rodam por aí. Mesmo tendo a pretensão de ser um texto mais profundo, é necessário passar rapidamente pelo clichê. Não é possível separar completamente “trabalho de cliente” de “trabalho de fornecedor”. Todos os interessados no produto devem estar envolvidos com o projeto, tomando decisões estratégicas e táticas. Aprendendo e reagindo. Apenas a impossibilidade de separação entre os fluxos já invalidaria qualquer tentativa de levar o throughput para um nível mais estratégico. Olhar para o throughput como algo mais que uma métrica estritamente operacional pode ser até perigoso. Olhar com um nível exagerado de importância para tua eficiência operacional pode levar à decisões ruins, como uma contratação desnecessária, por exemplo.

E se o efeito não tiver uma causa?..

Vamos agora nos aprofundar um pouco mais. Don disse, “However, the size of this queue is affected by more than the operating rate of the bottleneck.“, nos dando uma pista de uma das naturezas dos sistemas complexos, a ausência de causalidade. Não existe relação direta entre causa e efeito. Normalmente é necessário mais de uma intervenção no sistema para conseguir o efeito desejado. A eficiência da sua empresa também é importante. Muito importante, na verdade. Mas na praia dela. Suportando as decisões que ela pode suportar, as decisões operacionais. Investir em teste automatizado ou não, contratar ou não aquele servidor de integração contínua na nuvem, investir em treinamento, dojos, carga horária, incentivar brown bags, contratar ou não mais pessoas para o time. Então, este foi o segundo motivo: relação nublada entre causa e efeito na análise do throughput no nível estratégico.

Mas eu não queria bananas!!

Outro ponto relevante, talvez o maior deles, é que valor em software não está relacionado à quantidade de coisas que você coloca em produção, mas pela quantidade certa de coisas que você colocou em produção, no momento certo. Esta é a cultura da eficácia. Mas por que ela é importante?

Em dois projetos para crowdfunding, no projeto A e B, temos 10 demandas do épico “Realizar transferência para a conta” e 5 demandas do épico “Cadastrar projeto para captar fundos”. Quem conhece este tipo de projeto, sabe que o dinheiro só pode ser transferido para a conta do dono do projeto depois de um determinado período, que muitas vezes é uma restrição do gateway de pagamento. Mesmo que não existisse essa restrição, o dinheiro só pode ir para a conta depois do projeto ter sido bem sucedido. Mas para o projeto ser bem sucedido, ele precisa existir no sistema. O projeto A começa pelo épico “Realizar transferência para a conta” e o projeto B começa por “Cadastrar projeto para captar fundos”. O projeto A entrega as 10 demandas e o projeto B entrega 3, deixando duas menos prioritárias de fora. Os dois épicos são considerados como entregue. O throughput do projeto A foi 3.33x maior que o do projeto B.

Hoje em dia, na maioria das empresas pequenas e médias e em todas as grandes as pessoas que “compõe o time” do projeto A seriam promovidos. Em algumas empresas grandes onde eu estive, formariam um “time de elite” com os integrantes do projeto A e de todos os outros “projetos que deram certo” para “aumentar as chances de sucesso” de um projeto maior e de alta complexidade. Preciso dizer aqui qual o resultado normal deste tipo de iniciativa? Não funciona. Além disso, temos uma série de decisões ruins, que se fundamentaram em erros grosseiros de análise. Este tipo de pensamento pode quebrar uma empresa, e vemos o status quo do mercado levando pós-graduados, PMPs, MBAs para esta armadilha.

Concluindo, o time do projeto B foi mais eficaz que o time do projeto A, mas muito mais mesmo. O cliente ou o analista de negócios priorizou certo, o time executou certo e as demandas foram entregues no momento certo, quando elas eram importante. O projeto A teve muito mais throughput que o projeto B, mas criou um monte de código que não é importante para aquele momento. O cliente não soube priorizar e o fornecedor não soube orienta-lo. No Lean chamamos isso de desperdício e no mercado atual temos muitas empresas onde times estão gerando lixo em vez de valor, e sendo promovidos por isso.

Para terminar, então se eu passar semanas sem entregar nada, não tem problema….

Não. Análise superficial novamente. A não ser que você esteja trabalhando com clientes que valorizam mais relatório que software, isso não é aceitável. Nas empresas grandes talvez seja, pois elas possuem uma camada gerencial só para convencer o cliente de que a não entrega é na verdade uma ótima entrega e de que o fornecedor precisa de um novo contrato, normalmente mais longos, para “entregar mais”. Mas em empresas que trabalham com ciclos curtos de feedbacks e não mantém uma camada gigante de gestão para convencer que a não entrega é na verdade uma entrega ótima, este tipo de comportamento as levariam a falência.

Se não entregar nada durante semanas, que valor você teria entregue? O throughput é necessário para entregar valor. Eficiência é importante, mas não para o suporte de decisões estratégicas.  A estratégia não lida com a quantidade de coisas entregues, mas com a quantidade de valor entregue.

Então o que eu devo usar para suporte de decisões estratégicas? Isso é assunto para um próximo artigo…