Elcio Ferreira Atraso e estouro do orçamento são só a ponta do iceberg: o principal desperdício de dinheiro em desenvolvimento de software.
Todo mundo nesse mercado sabe que projetos de software costumam atrasar e custar mais que o necessário. Isso já “está no preço”.
Mas o verdadeiro desperdício está no projeto de software:
- Excesso de escopo: features demais que não vão ser usadas.
- Software complexo demais: muita informação, muito processo, muito controle. Isso custa tempo e dinheiro, e tira o foco: é comum, apesar do excesso, não ter a informação, os processos e o controle realmente necessários.
- Essa complexidade gera consequências: conduz a UX ruim, induz os usuários ao erro, gera custos de treinamento e suporte.
- A complexidade também se reflete na infraestrutura: quanto mais complexo o software, mais chances de precisar de componentes extra de infraestrutura. Maior o custo e esforço para hospedar e manter.
Além disso, softwares precisam evoluir. Software com excesso de escopo torna a evolução cara e complexa. Some-se ao prejuízo os custos extras com evolução e os custos com oportunidades perdidas porque o software deixou de evoluir.
A principal causa para o desperdício de dinheiro em desenvolvimento de software está em como projetos de software são encarados, especialmente em comparação com outros projetos.
Ao construir uma nova planta fabril, você precisa decidir e projetar tudo antes. Se você descobrir que o galpão da linha de produção é baixo demais para o maquinário depois que ele foi construído, o prejuízo é gigantesco.
Por isso, gasta-se muito tempo, esforço e dinheiro em projeto: para se ter certeza de tudo antes de começar a obra.
Ao trazer essas mesmas restrições para o desenvolvimento de software, estamos resolvendo um problema inexistente. Numa arquitetura de software projetada para ser ágil, o custo de mudar não é desprezível, mas é muito menor do que em projetos de outras áreas. Tão menor, que todo o esforço que fazemos para preservar nosso investimento, em geral, acaba gerando custo extra.
Como seria o projeto ideal, então?
Faz-se o mínimo necessário. Muito bem feito, afinal, é só o mínimo. Coloca-se em produção e os resultados são observados. Afinal, software é sobre pessoas.
Mas como você faz isso se a burocracia corporativa não permite?
Para iniciar um projeto, você precisa de um business case detalhado, incluindo custos e esforço a ser despendido, fornecedores envolvidos, problemas a serem resolvidos, um overview da solução e uma projeção dos resultados esperados? Depois, você precisa apresentar o business case para um comitê que se reúne duas ou três vezes por quarter, onde você vai ser sabatinado para que eles tenham certeza de que você pensou em tudo. (Pensar em tudo é exatamente o que você não deveria fazer.)
Além disso, exige-se de você que submeta a solução técnica a um comitê de arquitetura, que vai também conduzir uma sabatina sobre tecnologia, arquitetura de software, escopo da solução, necessidades de infraestrutura e processos.
Ou seja, a burocracia corporativa foi feita justamente para exigir de você que faça muito projeto, muito planejamento, pense em tudo antes. Pode soar bem, mas é o oposto de como se inova em software.
Precisa construir software realmente inovador? A Visie pode ajudar.
20 de junho de 2023
