95% das software houses não sabem medir retrabalho.

Segunda-feira costuma ser o dia em que os números da semana passada começam a aparecer porque normalmente as promessas de entregas foram feitas para as sexta e infelizmente nem todos os times conseguem entregar.

E existe um número que quase ninguém acompanha nas software houses: o custo do retrabalho.

Tem muitos anos que trabalho com times de desenvolvimento e por mais que exista uma métrica para medir a performance do time quase ninguém olha o tanto de retrabalho que existiu. Toda segunda-feira vejo líderes preocupados com prazo, produtividade, o que esta no sprint, horas apontadas e faturamento. Mas existe uma pergunta que quase ninguém faz:

Quanto da capacidade do time está sendo consumida refazendo o que já deveria estar pronto?

Não estou falando de Bugs, estou falando de retrabalho sabe? aquele escopo que foi mal definido, os requisitos que mudaram (ou mudam) no meio do caminho (e normalmente quando tudo ja estava quase pronto), aquelas correções que poderiam ser evitadas, os deploys que voltam, as milhares de reuniões para alinhar algo que ja havia sido alinhado, os desenvolvedores que não conseguem focar nas atividades do sprint porque vivem apagando incêndio e quer saber o mais curioso disso?

Poucas empresas medem isso e quando falamos em software houses estamos falando do coração da empresa.

A maioria das empresas medem quantidade de horas alocadas, quantidade de entregas, quantidade de pessoas no projeto e não medem desperdiço.

Peter Drucker dizia que "o que não pode ser medido, não pode ser gerenciado".

E na prática, muitas empresas estão comemorando velocidade enquanto aceleram na direção errada.

Já vi times aparentemente "ocupados" descobrirem que entre 20% e 40% da capacidade mensal estava sendo consumida por retrabalho.

Isso significa que, em um time de 10 pessoas, talvez 2 ou 3 estejam trabalhando em algo que já foi feito antes ( ja ouviram falar de Pareto? então rs)

Sem contratar ninguém, sem crescer e sem perceber.

O problema é que retrabalho raramente aparece no DRE.

Ele aparece disfarçado de:

• atraso de projeto;
• cliente insatisfeito;
• margem apertada;
• equipe sobrecarregada;
• sensação permanente de urgência.

Minha impressão é que a maioria das software houses não tem um problema de produtividade. Tem um problema de visibilidade e quem ja trabalhou comigo ja deve ter me ouvido falar que o time apanhou "de graça".

Porque produtividade não é fazer mais. É desperdiçar menos.

Algumas perguntas que todo líder deveria conseguir responder:

1 - Quantas horas do último mês foram gastas em correções?

2 - Qual o percentual de capacidade do time dedicado a demandas não planejadas?

3 - Quanto o retrabalho custou em dinheiro?

4 - Quais são as três principais causas desse desperdício?

Se essas respostas não existem, provavelmente o problema também não está sendo gerenciado. E aquilo que não é gerenciado costuma virar custo. Só que custo silencioso.

E custo silencioso é o mais perigoso de todos.

Na sua experiência, quanto do tempo do time é consumido por retrabalho?

Se você ainda não tem uma estimativa te convido a acessar nossa calculadora de eficiência disponível gratuitamente em fluidagroup.com e realizar seu diagnostico.

Em menos de 5 minutos, você sai da escuridão e começa a enxergar para onde sua capacidade realmente está indo.

Abraço,

Ana