Como dimensionar o custo de software sob medida antes do orçamento

A maioria dos artigos sobre isso abre com uma faixa: "espere de R$ 200 mil a R$ 2 milhões". Essa faixa é tecnicamente verdadeira e completamente inútil, porque abarca desde uma ferramenta interna pequena até uma plataforma que faz a empresa funcionar.

O custo é movido por seis fatores, e só dois são sobre funcionalidades

O instinto é estimar pela lista de funcionalidades. A quantidade importa, mas raramente é o termo dominante. Estes seis fatores, aproximadamente em ordem de quanto movem um total:

1. Superfície de integração. Com quantos sistemas isso precisa conversar, e quantos têm API de verdade? Cada integração carrega investigação, tratamento de erro, gestão de credencial e uma obrigação contínua de manutenção. Uma integração com sistema legado não documentado pode custar mais do que a funcionalidade que ela viabiliza. É a razão mais comum de estimativas erradas.

2. Migração de dados. Mover histórico é quase sempre subestimado, porque o custo não está na transferência. Está em reconciliar vinte anos de dado inconsistente que o sistema antigo tolerava e o novo não vai tolerar. Se ninguém sabe dizer que percentual dos registros existentes está limpo, isso é tarefa de discovery antes de ser estimativa.

3. Exigências regulatórias e de auditoria. HIPAA, SOC 2 e regimes semelhantes não são um item no fim da lista. Mudam a arquitetura, o registro, o modelo de acesso e o pipeline de publicação. Acrescentar no meio do projeto custa múltiplos de já desenhar assim. Se você lida com informação de saúde protegida, leia o que um BAA realmente obriga antes de escopar.

4. Quantidade de perfis de usuário distintos. Cada perfil com permissões e fluxos genuinamente diferentes é quase uma superfície de aplicação à parte. Cinco perfis não é cinco vezes um, mas é bem mais do que um.

5. Exigência de disponibilidade e de exatidão. Um sistema que pode ficar fora por uma hora num domingo é um problema de engenharia diferente de um que não pode. E um sistema em que um número errado é constrangedor é diferente de um em que é republicação de demonstrativo.

6. Quantidade de funcionalidades e complexidade de interface. É por aqui que a maioria das conversas começa, e onde mora a menor variância.

Um teste que você mesmo pode rodar

Avalie o seu projeto em cada fator. O objetivo não é a nota, é descobrir onde você não consegue responder.

Fator	Pergunta a responder	Sinal de que vai custar mais
Integrações	Quantos sistemas, e quantos têm API documentada?	Qualquer sistema em que a resposta é "teríamos que perguntar ao fornecedor"
Migração de dados	Quantos registros, e que fração está limpa?	Ninguém analisou o dado existente
Conformidade	Qual regime se aplica, e há contrato assinado?	Conformidade descrita como "a gente vê isso depois"
Perfis	Quantos perfis têm permissões genuinamente diferentes?	Mais de três, ou perfis que agem em nome uns dos outros
Disponibilidade	Quanto custa uma hora fora do ar?	A resposta é "não pode cair" sem orçamento associado
Escopo	Qual a menor versão que ainda é útil?	Ninguém sabe descrever uma

A última linha é a pergunta de maior alavancagem do exercício inteiro, e está diretamente ligada a se você deveria estar construindo. Um time que não consegue descrever uma versão menor útil vai construir a grande, e a grande é onde orçamentos morrem.

O que torna uma proposta confiável

Você não vai conseguir verificar o número. Vai conseguir verificar o raciocínio por trás dele.

• Declara premissas explicitamente. "Assume que o ERP expõe uma API REST de pedidos" é uma proposta que você pode corrigir. Um total sem premissas é um total que você não tem como discutir.
• Separa discovery de construção. Quem dá preço fechado para um sistema que não examinou está inflando bastante ou planejando renegociar. Os dois custam a você.
• Nomeia o que está fora. Limpeza de dados, treinamento, licenças de terceiros e suporte pós-lançamento são as quatro surpresas mais comuns.
• As fases têm pontos de decisão, não só entregas. Você deveria conseguir parar depois do discovery com algo útil na mão. O que é esse algo está em o que uma discovery de duas semanas precisa entregar.

O custo depois do lançamento

A construção é a metade menor do custo total de propriedade. Um sistema em funcionamento precisa de atualização de dependência, correção de segurança, conserto de integração quando um fornecedor muda a API, e mudanças conforme o negócio muda.

Não reservar nada para isso no primeiro ano é a forma mais confiável de terminar com um sistema sem manutenção no segundo, e aí você está pagando por uma modernização. Se uma proposta não trata do que acontece depois do lançamento, pergunte.

Onde o trabalho é feito também muda a aritmética de formas que a hora esconde. É o tema de nearshore, offshore ou EUA, e saber se o fornecedor consegue construir é avaliar profundidade de engenharia.

Publicamos como trabalhamos e o que protegemos nas práticas de segurança, e a forma como escopamos está em desenvolvimento sob medida.