Existe desperdício em Desenvolvimento de Software?

Estima-se que 2/3 de alimentos são jogados fora todos os anos no mundo inteiro. Isso equivale a 1,3 bilhões de toneladas de produtos que não serão utilizados por nenhum ser humano. Para alarmar ainda mais, isso equivale à 1 trilhão de dólares jogados no lixo anualmente.[1]

Quando citamos estes números, estamos falando em números absolutos focando estritamente nos alimentos, mas existem outros desperdícios durante toda a cadeia de produção destes alimentos. E a água que foi utilizada? A energia elétrica? Os adubos? Tudo isso torna-se desperdiçado também, haja vista que o propósito para a qual foram utilizados, não serviu para ninguém.

O desperdício mencionado no exemplo dos alimentos, pode muito bem ser aplicado também ao desenvolvimento de software, pois quando entregamos software que não será utilizado em 100%, gastamos tempo de funcionários, infra estrutura, esforço, e principalmente o dinheiro do cliente. Enquanto o desperdício de alimento gera revolta, o desperdício em desenvolvimento de software gera prejuízo.

Frederick Winslow Taylor, em 1911 escreveu que “No passado, o homem estava em primeiro lugar; no futuro, o sistema terá primazia”.[2] Em seu escrito, o que Taylor está dizendo, é que construiríamos ferramentas poderosas que aumentariam exponencialmente nosso poder de produção. Hoje existe uma grande facilidade de se criar software, as ferramentas cada vez mais robustas, permitem que se construa um sistema com uma velocidade extraordinária, comparada à poucos anos atrás, dá-se a isso o nome de Eficiência.

Mas onde estão os desperdícios na construção de Software?

Como definir o que realmente é desperdício no desenvolvimento de Software? Baseado nos 7 desperdícios dentro do conceitos Lean de Produção, Mary e Tom Poppendieck desdobraram isso para Desenvolvimento de Software.[3]

Vejamos quais são:

Trabalho Inacabado

O problema do trabalho parcialmente feito é um dos grandes problemas dentro do desenvolvimento de software. Frases como “já está pronto, só falta testar” exemplificam muito isso. Alguns exemplos de trabalho inacabado podem ser: documentações não codificadas, código não ‘mergeado’ no repositório master, código não testado, sistema não instalado;

Funcionalidades Extras

É o famoso gold plating, ou seja, é desenvolver funcionalidades não requeridas pelo cliente como forma de agradá-lo, colocando uma “cerejinha no bolo”. Este é o pior dos desperdícios, onde Taiichi Ohno chama de superprodução, ou seja, é criar estoque que não será “imediatamente” necessário.

Reaprendizagem

Há dois níveis de desperdício dentro deste tópico que são: 1) esquecer o que foi aprendido no passado e ter que reaprender; 2) ignorar conhecimento de outras pessoas não envolvidas no processo de desenvolvimento. Resumidamente, é perder o controle do conhecimento gerado/absorvido.

Transferências de Controle (handoffs)

Esse é um problema que raramente será eliminado, mas pode ser mitigado. Isso porque a comunicação do conhecimento tácito, aquele adquirido pela experiência, sempre resulta em perda de conhecimento. Estima-se que 50% do conhecimento tácito fica para trás na primeira transferência de controle.

Troca de tarefas

É o famoso dividir o foco em mais de uma atividade. É cientificamente comprovado, segundo Vítor Massari em Gerenciamento Ágil de Projetos, que 40% do esforço é desperdiçado quando um desenvolvedor alterna de uma tarefa para outra. Existe um consumo de energia no cérebro para que o desenvolvedor se desligue de uma tarefa e inicie uma outra.

Atrasos

O software implementado e testado precisa ser homologado pelo cliente ou designados por ele, mas eles não tem tempo disponível para homologar: desperdício. Aguardar pela disponibilidade de pessoas de outras áreas é uma das grandes causas de desperdício gerando o famoso “atraso”.

Defeitos

Este desperdício gera um sentimento negativo diante do cliente: falta de credibilidade. Construir um software cheio de bugs é terrível, porque além de gerar uma sensação de desconfiança, gera custo de qualidade e gasta tempo de desenvolvedores.

Como resolver a questão dos desperdícios?

Os métodos ágeis possuem muitos profissionais experientes, mas que muitas vezes tropeçam em uma armadilha que é corriqueira demais: focar em ferramentas e técnicas e não na resolução de problemas e eliminação de desperdícios. O desenvolvimento de software, deveria abarcar tanto o foco no método ágil, otimizando o processo de construção, quanto na melhora do fluxo inteiro de valor.

Estima-se que apenas 20% dos recursos e funcionalidades em software são utilizados com regularidade e que 50% dos recursos de um software (utilizados ou não) nao agregam valor ao negócio.[4]

Os desenvolvedores, segundo pesquisa feita pela Carnegie Mellon com 13.000 programas, cometem entre 100 e 150 erros em cada mil linhas de código, comprometendo assim a qualidade do produto, demandando 80% do orçamento para correção destes erros.

Em suma, uma boa metodologia de desenvolvimento de software inicia-se com uma premissa simplória: identificar 20% do código que proporcionam 80% de valor e executá-los dentro do tempo de forma puxada ao invés de empurrada e sempre envolver o cliente na definição dos requisitos e testes.[4]

De forma sintética, usando o contraponto mencionado no início deste post, quando falamos que crescemos em Eficiência, deixo uma frase do famoso Peter Drucker e logo em seguida abordaremos os métodos resolutivos para cada tipo de desperdício demonstrado até aqui:

Sem dúvida, não há nada tão inútil quanto fazer com grande eficiência o que não devia ser feito de modo algum[2]

Drucker está confrontando aqui Eficiência versus Eficácia. Isso é assunto para um outro post.

Métodos resolutivos

Espero ter contribuído. Até mais!

Referências:

  1. https://www.embrapa.br/busca-de-noticias/-/noticia/28827919/os-desperdicios-por-tras-do-alimento-que-vai-para-o-lixo (27/12/2017);
  2. Startup Enxuta. Ries, Eric

3. Implementando o Desenvolvimento Lean de Software. Poppendieck, Mary; Poppendieck, Tom

4. TI Lean, capacitanto e sustentado sua transformação Lean. Bell, Steven.

Categories: desenvolvimento ágil, desenvolvimento de software, lean, princípios lean


Originally published at www.agilean.eti.br on February 20, 2018.

Like what you read? Give Daniel Moreira a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.