Como o investimento é estruturado
Sprints, gates de validação e percentual por etapa validada.
ARTIGO · INVESTIMENTO
Não existe tabela, e quem apresenta uma está orçando outro projeto. Este texto explica o que de fato move o preço, por que orçamento fechado antes do diagnóstico é o formato mais caro para o cliente, e como ler uma proposta técnica.
Software sob medida não é produto, é escopo. Duas empresas que pedem “um sistema de gestão de pedidos” podem estar descrevendo projetos com uma ordem de grandeza de diferença entre si — e a diferença raramente está na tela, está em quantas regras existem por trás dela e em com quantos sistemas ela precisa conversar.
Por isso qualquer número dado antes de entender o escopo é chute. Se acertar, foi sorte; se errar para menos, alguém vai absorver o prejuízo — e normalmente é o cliente, em qualidade ou em aditivo.
O que dá para explicar com honestidade é o que move o preço. Isso não muda de projeto para projeto.
| Fator | Por que pesa |
|---|---|
| Quantidade de regra de negócio | Não é o número de telas: é o número de decisões que o sistema precisa tomar sozinho, e as exceções de cada uma |
| Integração com o que já existe | Cada sistema com que o novo precisa conversar acrescenta trabalho de mapeamento, tratamento de erro e sincronização |
| Qualidade do dado atual | Se o dado que vai alimentar o sistema está inconsistente, a etapa de conferência e correção costuma ser maior que a de programação |
| Nível de disponibilidade exigido | Um sistema que pode ficar fora do ar por uma hora custa uma fração do que custa um que não pode ficar fora nem um minuto |
| Quem vai manter depois | Entregar para uma equipe interna assumir exige documentação, transferência de conhecimento e escolhas técnicas mais conservadoras |
| Prazo | Encurtar prazo não reduz trabalho: aumenta o número de pessoas em paralelo, e coordenação também custa |
Repare no que não está na lista: a quantidade de telas, a linguagem de programação e o tamanho do fornecedor. Os três aparecem em conversa comercial e nenhum deles é bom previsor de esforço.
Dois números ajudam a entender por que o custo de um sistema não termina na entrega — e vale registrar de onde vêm.
Um levantamento com mais de mil desenvolvedores e mais de mil executivos em cinco países estimou que o desenvolvedor médio gasta cerca de 17 horas por semana lidando com débito técnico. É estimativa de percepção de executivos sobre o tempo de terceiros, não medição instrumentada, e vem de uma empresa que vende infraestrutura para desenvolvedores — mas dá a ordem de grandeza.
Uma pesquisa com 50 CIOs de grandes empresas de serviços financeiros e tecnologia apontou que de 10% a 20% do orçamento de tecnologia destinado a novos produtos é desviado para resolver problemas de débito técnico. A amostra é pequena e a consultoria que a produziu vende modernização.
A leitura útil, apesar das ressalvas: uma parte relevante do custo total de um software é decidida depois da entrega, pela facilidade ou dificuldade de alterá-lo. Um projeto mais barato que produz um sistema difícil de mudar não é mais barato — é mais caro em parcelas.
É contraintuitivo, e vale explicar o mecanismo.
Quando um fornecedor precisa dar um número fechado sem conhecer o escopo, ele faz uma de duas coisas. Ou coloca margem de risco para cobrir o que não sabe — e o cliente paga por incerteza que talvez não se materialize. Ou aperta o número para ganhar — e aí o ajuste vem depois, em aditivo ou em corte de qualidade onde o cliente não vê: teste, documentação, tratamento de exceção.
Nos dois casos, quem absorve é o cliente. A diferença é só quando ele descobre.
Por isso estruturamos investimento em sprints com gates de validação, com percentual de pagamento vinculado a etapa entregue e aprovada. O cliente vê resultado antes de comprometer o todo, e pode parar entre etapas. É um formato que expõe o fornecedor — se a etapa não entregar, o gate não passa — e é justamente por isso que funciona.
Os custos de infraestrutura que ficam com o cliente — servidor, licença de terceiro, serviço de nuvem — são listados à parte, e não embutidos. Embutir esconde o que é recorrente dentro do que parecia ser único.
Sete perguntas que separam uma proposta técnica de um orçamento. Se a proposta não responde a elas, o número que está nela não significa muito.
Nenhum desses itens é desconto. Todos reduzem esforço real.
Escopo menor na primeira entrega. Um sistema que entra em uso resolvendo bem uma parte ensina mais sobre o que é preciso do que seis meses de reunião de levantamento.
Dado organizado antes. Se a empresa consegue chegar com o dado consistente, uma etapa inteira sai do projeto.
Uma pessoa com autoridade para decidir. A maior parte do atraso em projeto de software é espera por decisão, não tempo de programação.
Aceitar o que já existe. Onde um componente de mercado resolve, usar componente de mercado. Sob medida deve ser aplicado ao que é diferencial da empresa, não a tudo.
Sprints, gates de validação e percentual por etapa validada.
O que construímos, como funciona e o que fica com a empresa.
Por que uma parte do custo é decidida depois da entrega.
Trinta minutos para entender o problema. O número vem depois, na proposta técnica, e vem por etapa.
Respondemos em até 1 hora útil. Confirmação no mesmo dia útil.