Série: Desenvolvimento de software e o impacto no faturamento do cliente

Thiago Borba
CWI Software
Published in
3 min readAug 14, 2018

Nesta série de artigos, vamos analisar o impacto que o desenvolvimento de software tem sobre o faturamento de uma empresa. Vamos analisar trechos de códigos e entender quanto eles valem financeiramente.

Quando você, desenvolvedor, recebe uma especificação técnica ou um bug para correção, você tem ideia de quanto o seu trabalho impacta financeiramente no cliente ou quanto a qualidade do seu código influencia nesse número?

Inúmeras vezes fiz essa pergunta, e raramente escutei uma resposta coerente para ela. Alguns respondem “Não sei”. Outros entendem que não há relação.

Para ilustrar essa relação neste primeiro post vamos estabelecer algumas premissas para efeitos de cálculos durante a série. Vamos utilizar informações financeiras públicas de uma grande empresa brasileira do ramo varejista, com atuação nacional e faturamento anual superior a R$ 1 bilhão.

Sobre o faturamento

Os valores abaixo representam o faturamento médio do último ano:

Sobre a metodologia

Para valoração, usaremos os valores absolutos encontrados na relação de faturamento anual dividido no tempo (dia, hora, minuto, segundo e milissegundos), sem considerar a variação de faturamento ou contabilidade da operação. Também não iremos considerar o número de vendedores ou cliente final.

Vamos considerar o impacto de forma linear, ou seja, quantidade da unidade de tempo multiplicado por valor da unidade de tempo. O objetivo é encontrar um valor mensurável e o mais próximo possível da realidade.

Dado uma tarefa qualquer, vamos considerar que:

  • Quando a tarefa levar mais tempo para ser executada, o cliente deixa de faturar (baseline);
  • Quando a tarefa for refatorada e levar um tempo menor para ser executada, o cliente fatura mais.

Exemplo

Considerando um cenário onde um ou mais usuários do sistema fiquem com sistema indisponível por 1 minuto, o cliente deixa de faturar BRL 2.093.

Considerando um cenário onde uma parada total de sistema interrompa as vendas por 1 hora — baseado na tabela de faturamento — o cliente deixa de faturar BRL 125.571.

O primeiro caso

Durante a investigação de performance em um cliente, encontrei esse código:

Esse código era chamado para solicitar o cálculo do preço de um produto. Nesse momento, vamos analisar apenas o Thread.Sleep (em um próximo post vamos falar do dynamic) :).

Esse trecho de código era chamado em várias páginas e, em alguns cenários, uma dezena de vezes. Numa análise inicial, o problema do código era o bloqueio de uma thread da aplicação por 1 minuto, o que por si só é um tempo absurdamente enorme. Porém, em um cenário onde o número de requisições era alto, o servidor parava de responder por não ter mais threads disponíveis, deixando usuários sem acesso ao sistema.

Considerando o cenário descrito, o cliente deixava de faturar até o equivalente a R$ 2.093!

Agora, se considerarmos que num período de 20 dias, pelo menos 1 vez ao dia o serviço ficava indisponível por aproximadamente 1 minuto, isso representa 20 minutos, logo R$ 41.860!

Durante o processo de refatoração, verifiquei que o Thread.Sleep era usado para aguardar a geração do preço e retorná-lo para o usuário. A geração de preço é feita no ERP, que executa o processamento com tarefas agendadas em background, podendo levar minutos para serem concluídas. Além disso, foi verificado com o cliente que o usuário não tem necessidade de ficar aguardando a geração do preço.

A estratégia utilizada foi executar uma Thread especializada para receber a solicitação de geração de preço e gerenciar a comunicação com a integração do ERP. Dessa forma, quando é necessário gerar um preço, um request é enviado para a Thread especializada e a requisição do usuário é finalizada; sem locks.

Conclusão

Essa é uma pequena amostra do que será essa série :). Nos próximos posts, vamos analisar mais códigos problemáticos, tentar entender a escolha da abordagem do desenvolvedor para resolver um problema e entender como uma tarefa pode ser refatorada para fazer o mesmo trabalho de forma mais rápida e performática. Até a próxima!

--

--