Dez erros das fábricas de software

A comparação entre desenvolvimento de software e a indústria tradicional começa com um erro terrível: encarar a produção em série, como um produto em uma fábrica. Software é feito de forma individual e criativa para resolver um determinado problema. O nível de padronização é baixíssimo, e a precisão e a repetição são feitas pelos compiladores e linkers, não por desenvolvedores. Na comparação com a construção civil, o arquiteto é o desenvolvedor, enquanto o trabalho repetitivo feito pelos pedreiros é, em software, feito de forma automatizada pelos geradores de programas.

O segundo problema, não menos grave, é colocar o desenvolvedor como parte de uma linha de montagem. Tratar esse profissional como um recurso é não só infantilizá-lo como desumanizar uma mão de obra extremamente sofisticada e escassa. Os “coders” são trabalhadores do conhecimento e precisam ser motivados para que produzam o melhor, alinhando seus interesses com os do cliente.

Outro erro é a reutilização de componentes já desenvolvidos. Cada projeto ou iniciativa tende a cobrir um pedaço do problema, que não será o mesmo no futuro. As iniciativas de SOA tentam prescrever quais seriam os serviços reusáveis de uma organização, o que gera um ciclo waterfall dentro de outro ciclo waterfall e aumenta muito a complexidade.

Quarto equívoco: o consumidor final não testa o produto até que ele esteja pronto, com todas as funcionalidades previstas no plano. O produto tardiamente testado tem pouca chance de sucesso, e a falta de feedback prejudica a alocação de despesas, que é feita com estimativas sem nenhum embasamento.

Outro problema é encarar a massificação como uma forma de reduzir custos. Se não analisarmos o sistema como um todo, podemos criar falsas economias de escala e gerar desperdício produzindo a quantidade errada da coisa errada.

As fábricas de software também costumam tratar o processo de trabalho de forma rígida, ou seja, você acredita que sabe qual é o problema e como vai resolvê-lo, prescrevendo todo o trabalho que normalmente dá errado no fim. O desenvolvimento deve ser uma jornada de aprendizado focada no cliente, buscando melhoria continuada de forma iterativa. É preciso manter times disciplinares trabalhando juntos, em um mesmo domínio e próximos ao cliente para gerar eficiência e aprendizado na prática.

Estimar um comportamento futuro com base em um acontecimento passado é mais um erro desta abordagem. Em software, não existe uma série histórica válida a não ser que tenhamos o mesmo time, no mesmo ambiente de negócios e tecnologias fazendo a mesma coisa.

A criação de uma taxonomia que sirva para criar uma série (e um modelo de previsão) para descrever um fenômeno tão amplo como desenvolvimento de software, ignorando a necessidade de condições de contorno estritas, é completamente desprovida de rigor, seja pela visão da academia ou pela visão da comunidade.

Isso leva ao oitavo erro das fábricas de software: elas acreditam que é possível prever o futuro durante o desenvolvimento. É como se um gestor de fundo de investimento mandasse uma lista detalhada de todos os “trades” que ele vai fazer nos próximos seis meses, ignorando o mercado e garantindo o nível de retorno desta estratégia, e você acreditasse nele.

O excesso de modelos e documentações também atrapalha o desenvolvimento em fábricas de software. Neste sentido, o código é o melhor modelo e o único que vai representar uma solução real para um determinado problema, uma vez que o ambiente é dinâmico e complexo. O software, e consequentemente o próprio produto, devem ser usados nas iterações de aprendizado.

Por fim, destaco novamente a importância da não rigidez. Em software, só conseguimos controlar duas dentre as variáveis tempo, custo e escopo. Para não abrir mão da qualidade, temos que controlar custo e tempo de entrega. O que nos sobra é o escopo, e é aí que podemos variar.

 

(*) Fernando de la Riva é diretor-executivo da Concrete Solutions