A algum tempo percebi uma dinâmica um tanto perigosa que acontece nas empresas que demandam software via fornecedores internos ou externos. Isso engloba praticamente todo o mercado corporativo, mas deixa de fora empresas que desenvolvem software de prateleira. O que vou escrever a seguir trata deste primeiro tipo de empresa.

Sempre que um departamento precisa de um sistema, ele precisa demandar este sistema para alguém. Seja a demanda repassada para um departamento de TI interno, ou para um terceiro, o foco com razoável frequência costuma ser custo. Quando o departamento é interno estamos falando de rateio baseado em horas internas de outro departamento da empresa, então a discussão é em torno de horas. Quando a demanda vai para fora da empresa a discussão é financeira. Grandes empresas mantém departamentos de compras responsáveis por comprar desde toner para impressora e papel higiênico quanto software, e o tom, principalmente em tempo de crise, é comprar focado em preço. Para se proteger as empresas geralmente apostam em especificações e estimativas bem feitas (algo que não existe), e SLAs. Assumindo que a especificação determina o que vai ser entregue, faz sentido que o critério seja preço. Quer dizer, faria sentido se software não fosse software. Comprar software assim é como comprar serviços de advocacia por preço. Você faria isso se estivesse em uma enrascada? Arriscaria seu pescoço? E porque então arriscamos o dinheiro das empresas?

Invariavelmente os fornecedores, sejam eles internos ou externos, vão ter que baixar o custo para atender o cliente, que quer uma Mercedez pelo preço de um Fusca. Frequentemente o cliente simplifica o escopo ao máximo, a fim também de baixar o preço, e remove itens fundamentais a qualquer software. De cara morrem coisas “inúteis” como log de erros, por exemplo. Design gráfico também costuma nem entrar no projeto. Outros itens, de tanta falta de demanda, às vezes nem são oferecidos pelos fornecedores. Coisas “inúteis” como análise estática de código, integração contínua, e claro, uma análise arquitetural e/ou um arquiteto acompanhando o projeto. Afinal, essas coisas “inúteis” só acrescentam custo e não valor (atenção para a ironia). Então o cliente fala que não vai pagar por isso.

Porque isso acontece? Pois é, foi isso que eu descobri. Talvez vocês já saibam, mas para mim foi algo que de certa forma estava na minha cara, mas eu nunca tinha parado para ver.

A questão é simples: quem paga pelo software e quem paga pela manutenção? É muito frequente que o cliente final pague pelo desenvolvimento do projeto, mas não pelas pequenas manutenções subsequentes. O dinheiro sai do seu centro de custo somente no nascimento do projeto. Quem paga as manutenções geralmente é TI, que mantém uma equipe de suporte, alocada no seu centro de custo, debaixo do seu budget.

Esse fato leva o cliente a pedir o software mais barato possível. Os problemas e necessidades que vierem depois são resolvidos “de graça”, ao custo do departamento de TI. E como o software foi feito de qualquer jeito, a manutenção é muito cara, o que leva a equipe de suporte a inchar cada vez mais, ou entregar cada vez menos valor. Quem disse que não existe almoço grátis?

Não é a toa que os CIOs são tão criticados por não entregar valor. Cerca de 80% do custo de TI vão para manutenção, e devido a essa dinâmica, uma manutenção cara que se originou nos próprios incentivos dados por TI.

Como eu disse no começo, essa é uma dinâmica perigosa, já que os custos do projeto são muito maiores do que o planejado, e o software não é feito para durar, mas para sair de qualquer jeito. E o trabalho do arquiteto é justamente fazer software para durar.

Gostaria de saber se isso é uma visão particular das minhas experiências ou se vocês confirmam esta visão. Comentários são muito bem vindos.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.