Quanto vale um Software

Nos últimos anos, tenho trabalhado com um assunto desafiador: Fábrica de Software. 

E isso tem adquirido uma importância especial pra mim, até pelo fato de estarmos envolvidos com o tema sob diferentes dimensões.

Já fui desenvolvedor, já fui demandante dos serviços de fábrica, já cuidei dos contratos – sendo, portanto, intermediário entre a contratante e a contratada – e agora, pra completar o ciclo, estou do lado de lá, como fornecedor.

O tema, por si só, já é muito interessante. E percebê-lo sob diversas óticas torna tudo mais complicado – afinal, a ignorância é o segredo da felicidade – mas também muito mais gratificante.

Esses dias, conversando com duas colegas de trabalhado, fui consultado sobre o que, em princípio, parecia ser feijão-com-arroz pra mim, mas que percebi ser uma abordagem totalmente diferente: quanto vale um software. 

Minha preocupação sempre foi o preço justo de um sistema sob a ótica do custo, afinal o desafio era, até então, a prestação do serviço, visto que o seu produto – no caso, o aplicativo – era propriedade do contratante.  

Nesse contexto, podemos definir a métrica como a questão central. Quem é do meio sabe que apenas isso já é uma questão bastante complexa, envolvendo conceitos como SLoC (linhas de código), UCP (Casos de Uso), Pontos por Objeto,  APF (Pontos de Função) e outros. 

Para termos uma ideia de grandeza, há alguns anos (ou seriam décadas?) trabalhávamos no BB com uma ferramenta Case (Computer-Aided Software Engineering, ou Engenharia de Software apoiada por computador) da Texas Instruments. Reza a lenda que esse produto, chamado de IEF, tinha 20 mil pontos de função. Para efeito de comparação, o compilador VB e os populares Word, Excel e Project, todos produtos Microsoft, assim como o CICS, monitor de TP da IBM, têm entre 2 e 3 mil Pontos de Função de tamanho. 

Há alguns meses fiz uma palestra no IFPUG sobre as métricas contratuais adotadas nas Fábricas de Software do BB (basicamente APF e a nossa USTIBB) e, pela reação da plateia, percebi que estamos no caminho certo.

Até aqui, falamos basicamente de medir o produto. Para o adquirente, no entanto, há outras questões, podendo envolver inclusive métricas de processamento, como os MIPS (milhões de instruções por segundo) consumidos pela aplicação.

Bom, mas como falei, a questão aqui não é métrica. Ou não é só métrica.

Trata-se do valor de um software de prateleira, que vai muito além da questão do custo.

Para entendermos o problema – primeiro passo para chegarmos à solução – vamos trabalhar com um exemplo hipotético, de um aplicativo que custou R$ 100 mil para a softwarehouse em despesas de pessoal. Em tese, a aplicação poderia ser vendida por uns R$ 150 mil, propiciando uma margem bruta de 50% e uma margem líquida bem menor, se considerarmos outras despesas administrativas, de infraestrutura, impostos, taxa de risco, etc.

Mas vamos a algumas das diversas variáveis envolvidas.

A primeira (e principal): qual a percepção de valor que um potencial cliente enxerga no nosso produto? O que ele vai propiciar de retorno para o comprador? Ele se dispõe a pagar os R$ 150 mil? Meu produto é exclusivo ou há similares no mercado? Quanto custam? E se existir um Software Livre que atende os mesmos requisitos?

Mas tem muito mais: posso vender para apenas um cliente ou lucrar com várias cópias? Vou vender a licença? Ou o serviço (SaaS)? Haverá um contrato de manutenção? O treinamento está embutido no preço? Para quantos usuários?

Vamos adiante: o produto será customizado às necessidades do cliente? Qual o nível de integração envolvido? Requer a aquisição de outros produtos? Vai rodar na nuvem? O cliente tem um processo de diferimento definido? Isso torna o produto “mais barato” na prática. Qual o SLA do contrato?  

Bom, respostas pra tudo isso (se eu as tivesse) iria estender demais esse artigo. Além disso, no mundo real, envolvemos vários intervenientes, como a área técnica, o marketing e o jurídico, dentre outros.

Escrevo aqui mais como uma provocação para refletirmos sobre o tema. Afinal,  essa é uma preocupação que envolve desde gigantes da TI como uma IBM ou uma Oracle, até o estudante de ciência da computação que está desenvolvendo um site para a microempresa de um amigo.