O que determina o custo de um software à medida

«Quanto custa este software?» é a pergunta que mais nos fazem. A resposta não é um número único, e dizê-lo parece uma forma de fugir à pergunta. Não é. Um número dado sem conhecer as rubricas que determinam o custo ou é mais alto do que devia, ou vai subir a meio do projeto.

Neste artigo explico que rubricas determinam o custo de um software à medida e em que reparar ao ler uma proposta. Não dou valores, porque cada projeto é diferente. Mas ver de onde vem o valor torna muito mais fácil comparar propostas.

O número de ecrãs é uma medida enganadora

O custo do software é muitas vezes pensado em número de ecrãs. Um ecrã de login, uma lista, um formulário, um relatório. Mas os ecrãs são a parte visível do custo.

Dois formulários com o mesmo aspeto podem ter custos muito diferentes. Um grava os dados introduzidos numa tabela. O outro valida esses dados, mostra-os a pessoas diferentes consoante as permissões, envia-os para outro sistema e regista cada alteração. O custo é determinado pelas regras por trás do ecrã.

Integrações

Um software raramente funciona sozinho. Sistema de contabilidade, autenticação, pagamentos, e-mail, os sistemas antigos da organização ou um serviço público. Cada ligação é um trabalho à parte.

Ligar a um serviço com boa documentação e uma interface sólida pode levar alguns dias. Ligar a um sistema antigo com documentação incompleta e sem ambiente de testes pode levar semanas. Perguntar, na fase de proposta, pela documentação e pelas possibilidades de teste de cada integração clarifica a parte mais incerta do custo.

Dados e migração

Se o novo software não começa com uma base de dados vazia, vai ser preciso migrar dados do sistema antigo. Na maioria das propostas isto fica numa só linha, e é um dos pontos onde os projetos mais derrapam. Explicámos porquê no artigo sobre migração de dados.

Segurança e legislação

Um software que trata dados de saúde, dados de alunos ou dados financeiros exige mais trabalho do que uma ferramenta interna com o mesmo aspeto. Acesso baseado em funções, registos de acesso, cifragem, aplicação de prazos de conservação, eliminação e anonimização. Tudo isto é difícil de acrescentar depois. Incluí-lo no âmbito desde o início é mais barato e mais seguro.

Incerteza

Todos os projetos têm incógnitas. Uma boa proposta escreve-as à parte e diz como serão tratadas. Uma má proposta ou acrescenta a incerteza ao preço em silêncio, ou não a tem em conta de todo. A segunda é mais perigosa, porque a diferença aparece a meio do projeto numa fatura adicional.

A melhor forma de reduzir a incerteza é pôr uma curta fase de descoberta no início do projeto. Nessa fase clarificam-se o âmbito, as integrações e os dados. O desenvolvimento propriamente dito é depois orçamentado com um valor mais sólido.

Testes e aceitação

Os testes são a rubrica mais exposta a cortes. Quando são cortados, são também a rubrica cujo preço se paga mais tarde. Testes automáticos, testes de aceitação e ensaios com utilizadores reais. Se o esforço reservado aos testes não aparece na proposta, ou não vai ser feito, ou vai ficar a cargo da sua equipa.

Depois da entrega

O custo do software não acaba no dia da entrega. Continuam o alojamento, as cópias de segurança, as atualizações de segurança, a atualização das bibliotecas usadas e pequenas melhorias. Ver estas rubricas à parte na fase de proposta evita surpresas no fim do primeiro ano.

Ao ler uma proposta

Ao comparar várias propostas, escreva lado a lado o que cada uma inclui. As integrações estão incluídas? E a migração de dados? Quanto esforço vai para testes, como é orçamentada a manutenção, com quem fica o código-fonte? A maior parte das diferenças de preço mostra que não se está a orçamentar o mesmo trabalho.

Em resumo

O custo de um software à medida não é determinado pelos ecrãs, mas pelas regras por trás deles, pelas integrações, pelos dados, pela segurança, pelos testes e pela manutenção. Uma proposta que escreve estas rubricas com clareza, mesmo que pareça mais cara, sai muitas vezes mais barata.