“Um aplicativo com login, reservas e pagamentos.” A frase cabe em uma linha. O trabalho pode incluir uma confirmação manual por e-mail ou uma agenda sincronizada, reembolsos, permissões da equipe e recuperação de pagamentos interrompidos. Antes de perguntar por que dois orçamentos são diferentes, vale descobrir se estão orçando a mesma coisa.
Isso também vale para quem desenvolve um produto próprio: a estimativa interna pode esquecer exatamente as mesmas tarefas. Uma comparação útil começa pelo resultado esperado, pelo que está incluído e pelas dúvidas. Um total mais alto não prova qualidade; um total mais baixo não prova imprudência.
O nome da funcionalidade esconde suas regras
Imagine um sistema fictício de reservas de salas. A proposta A inclui pedidos que uma pessoa aprova manualmente. A proposta B inclui disponibilidade em tempo real, reservas recorrentes, cobrança e cancelamento automático. As duas podem apresentar uma linha chamada “reservas”. Só uma descreve um pequeno departamento de operações disfarçado de botão.
Torne a diferença verificável: quem pode reservar, o que acontece quando duas pessoas escolhem o último horário e quem resolve uma cobrança sem confirmação? Depois separe o necessário para a primeira versão do que pode esperar. O exemplo é ilustrativo; não corresponde a um projeto ou preço da Zephyrus.
O guia de estimativas do GAO, publicado em 2020, inclui definição de escopo, base técnica, premissas, análise de risco e atualização com custos reais. É uma referência de método, principalmente no contexto de programas públicos; não fornece uma tabela de preços para aplicativos. A aplicação prática aqui é nossa: documente o que aquele número está estimando. Guia de estimativas do GAO.
Cinco parcelas que merecem uma linha própria
Produto e interface: pesquisa necessária, jornadas, conteúdo, estados vazios e mensagens de erro. Integrações: sistemas externos, permissões, limites e comportamento quando uma conexão falha. Dados: importação, limpeza, validação e exportação. Qualidade: testes, acessibilidade e dispositivos efetivamente cobertos. Operação: implantação, monitoramento, backups e procedimento de recuperação.
Essa divisão é uma proposta de trabalho, não uma norma universal. O objetivo é impedir que “incluído” signifique coisas diferentes. Importar um arquivo de teste limpo é diferente de conciliar anos de registros duplicados. Peça uma amostra representativa dos dados e confirme quem resolve os erros antes de transformar a migração em uma linha de preço fechado.
A segurança também precisa de trabalho identificável. O SSDF do NIST organiza práticas de preparação, proteção do software, desenvolvimento seguro e resposta a vulnerabilidades, adaptadas ao risco e aos recursos. Citar o documento não certifica um fornecedor. Pergunte quais atividades concretas estão previstas e quem acompanha problemas depois da entrega. Secure Software Development Framework.
Uma dúvida precisa de um experimento, não de confiança teatral
Se uma integração é indispensável, mas ninguém confirmou o acesso à API, a estimativa depende de uma hipótese. Registre-a: “O fornecedor permite consultar disponibilidade e criar reservas com estas permissões.” Defina um experimento pequeno que confirme autenticação, uma operação real em ambiente de teste e o tratamento de falhas. O resultado deve reduzir uma dúvida específica.
Na orientação de discovery do GOV.UK, entender o problema, os usuários e as restrições vem antes de decidir construir. A pesquisa pode justificar não avançar. O contexto é o de serviços públicos britânicos; a lição que aplicamos a um produto pequeno é testar a necessidade e as limitações antes de assumir um compromisso grande. Não importamos automaticamente os prazos ou a estrutura de equipe daquele contexto. Como funciona a fase de discovery.
Uma faixa de estimativa pode ser mais honesta do que um único número quando há incerteza, mas precisa de explicação: o que sustenta o limite inferior, o que aumenta o esforço e quando será revista? Uma margem sem premissas é apenas outro número com cara de importante. Não existe uma porcentagem de contingência que sirva para todos os projetos.
Um briefing curto que permite comparar
Preencha sete pontos antes de pedir ou aprovar uma estimativa: pessoa e problema; tarefa principal; primeira versão e exclusões; plataformas e integrações; dados existentes; critérios de aceitação; operação e titularidade. Acrescente a data desejada e o motivo real desse prazo. Distinguir uma campanha marcada de uma preferência ajuda a decidir o que reduzir.
Para a reserva fictícia, um critério pode ser: “Quando dois usuários tentam confirmar a mesma sala no mesmo período, apenas uma reserva é confirmada; o outro recebe uma alternativa compreensível.” Outro: “Um administrador exporta os registros combinados em um formato documentado.” Esses exemplos descrevem resultados demonstráveis; “funciona bem” não faz esse trabalho.
Envie o mesmo briefing a todos. Peça que indiquem, para cada ponto, incluído, excluído ou dependente de esclarecimento. Compare também o que você recebe: código, documentação, acessos sob a titularidade adequada e instruções de manutenção. Não presuma que o preço de desenvolvimento inclui hospedagem, serviços externos ou futuras atualizações.
Compare a decisão inteira
Separe investimento inicial, despesas recorrentes e alterações futuras. No orçamento de operação, explicite o volume de uso e quem paga cada serviço. Um produto pode ser barato de construir e exigir trabalho manual todos os dias; outro pode automatizar mais do que a demanda atual justifica. O preço inicial, sozinho, não resolve nenhum desses cenários.
Antes de decidir, peça uma explicação para a maior diferença entre propostas. Ela pode resultar de escopo, reutilização de componentes, disponibilidade, risco ou estratégia comercial. Sem essa conversa, escolher o mais caro por segurança é tão frágil quanto escolher o mais barato por reflexo.
Uma boa estimativa torna as decisões visíveis: o que será resolvido agora, o que fica de fora, qual hipótese falta testar e como reconhecer uma entrega concluída. Ela não precisa adivinhar o futuro. Precisa permitir que a próxima descoberta atualize o plano sem transformar uma surpresa técnica em uma discussão sobre o significado de “óbvio”.