ROI, você está calculando isso errado!

Desculpa ai, mas talvez você esteja calculando ROI errado. Evite usar uma visão restrita a resultados de curtíssimo prazo, não entre no lugar comum de avaliar o ROI apenas contra custos imediatos do projeto, o ônus posterior decorrente da ausência de domínio, qualidade, boa arquitetura, automação, não é acaso do destino, ele foi gerado conscientemente ou fruto do descaso. Softwares são ativos ou passivos, temos dezenas ou centenas deles em uma empresa, que gerarão um grande desperdício para mantê-los ou não.

Na década de 70 do século XX a relevância com os custos recorrentes e o valor agregado por um software já estava embutido nas Leis de Lehman, após 40 anos esta relação ficou ainda mais clara e racional. Se você demorou 6 meses para construir um produto que vai ser usado por 10 anos, é enganação calcular ROI apenas se atendo ao resultado dos 6 meses. Cada linha desnecessária ou de baixa qualidade gera sobre-custos e antecipa sua obsolescência, rasgando dinheiro na forma de mais e mais investimento, equipe, alocação, incidentes, insegurança.

projeto-x-manutencao

O racional de muitas empresas é produzir, quanto mais melhor, se depois gastar o dobro para manter e o triplo para refazer antes do previsto é outra história, o que importa é “seu projeto concluir com aparente sucesso”, “merecer parabéns e uma promoção por ter entregue” … quase ninguém considera ou reflete sobre débito técnico e qualidade-desperdício, no contraste entre o valor real e aparente.

A tempo, importante diferenciar CAPEX (CAPital EXpenditure) relativo a investimento e OPEX (OPerational EXpenditure) relativo a despesas operacionais, muitas empresas acabam dando especial atenção ao investimento para aquisição ou construção (temporário) em detrimento ao custo continuado (recorrente), que poderia ter sido amplamente mitigado, evitado ou melhor planejado.

Princípios e métodos ágeis, iterativo-incrementais-articulados, design thinking, devops, kanban, melhoria contínua, tantos fundamentos e argumentos são utilizados e o maior deles que é o desperdício em uma análise de ROI é muitas vezes esquecido. Como evitar? Lean Business Analysis, Métodos ágeis em projetos Scrum, Kanban para gestão de fluxo, XP para engenharia de software, qualidade e automação, sem esquecer DevOps, etc.

roi

1. Falta de boas práticas ágeis – Elicitação, modelagem, planejamento e execução colaborativas. O quanto não antecipamos riscos e oportunidades, validando e adaptando desde antes de construir, mitigando desperdícios?

2. Transição eterna – você inclui no cálculo de ROI daquele projeto que foi um “sucesso”, a necessidade de uma equipe de atendimento rápido para corrigir ou ajustar problemas em produção … que poderia ter sido evitado ou reduzido?

3. Retrabalho – Você calcula o tempo de vida do produto construído versus o custo de ter que refazer partes ou todo a cada tanto porque inviabiliza mantê-lo devido a tantos remendos pela falta de boas práticas de engenharia de software?

4. Não automação – Pesa no cálculo de ROI a falta de testes automatizados, inexistência de testes de regressão, de boas práticas de aceitação que pesarão contra a sua usabilidade, integridade e imagem futura junto ao mercado e clientes?

5. Insustentável – Você inclui no ROI o ônus de ter dito que a equipe virou semanas sem dormir gerando código feito sob pressão, stressados, cansados e com foco apenas na data, em entregar a qualquer custo (com baixa qualidade)?

6. Inutilidades funcionais – Você inclui no ROI o custo de ter feito requisitos e dados inúteis, que só tornaram o produto mais complexo e inchado, onerando sua evolução, escalabilidade e manutenção?

7. Insatisfação – Você inclui no ROI o turnover e seus desperdícios em eternamente estar treinando novos integrantes, porque acha que isso faz parte e não precisa de um programa de atração e retenção de talentos?

8. Hardware proprietário – Você inclui no ROI o custo de ter silos e feudos, um pedaço na cabeça de cada integrante e área, sem sinergia, investindo só em capital individual, pontos únicos de falha, na síndrome do super-herói?

Não tem mágica, precisamos atrair, valorizar e reter talentos, usar métodos ágeis, boas práticas em engenharia de software, investir no coletivo e senso de pertença, testes automatizados, code review, … Qualidade não é não ter bugs, é construir certo na medida certa, com uma empresa e equipe engajadas e conscientes, porque neste contexto a palavra sustentabilidade ganha outra dimensão e profundidade.

De toda forma, tem cada vez menos Baby Boomers enviando currículos e cada vez mais Millenials, talvez em breve possa faltar talentos querendo trabalhar para empresas que continuem dependentes de workaholics, peças fundamentais para manter códigos “eternamente legados”, onde ninguém assume a responsabilidade pelo futuro, mas ganha méritos por ter apagado mais um incêndio.

 

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s