“Uma aplicação com login, reservas e pagamentos.” A frase cabe numa linha. O trabalho pode incluir uma confirmação manual por email ou uma agenda sincronizada, reembolsos, permissões de equipa e recuperação de pagamentos interrompidos. Antes de perguntar porque diferem dois orçamentos, convém descobrir se estão a orçamentar a mesma coisa.
Isto também vale para quem desenvolve um produto próprio: a estimativa interna pode esquecer exatamente as mesmas tarefas. A comparação útil começa pelo resultado esperado, pelo que está incluído e pelas incógnitas. Um total mais alto não prova qualidade; um total mais baixo não prova imprudência.
O título da funcionalidade esconde as 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. Ambas 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 a definição do âmbito, uma base técnica, pressupostos, análise de risco e atualização com custos reais. É uma referência de método, sobretudo no contexto de programas públicos; não fornece uma tabela de preços para uma app portuguesa. A aplicação prática aqui é nossa: documente o que o número está a estimar. Guia de estimativas do GAO.
Cinco parcelas que merecem uma linha própria
Produto e interface: investigação necessária, percursos, conteúdo, estados vazios e mensagens de erro. Integrações: sistemas externos, permissões, limites e comportamento quando uma ligação falha. Dados: importação, limpeza, validação e exportação. Qualidade: testes, acessibilidade e dispositivos efetivamente abrangidos. Operação: instalação, monitorização, cópias de segurança e procedimento de recuperação.
Esta divisão é uma proposta de trabalho, não uma norma universal. O objetivo é impedir que “incluído” signifique coisas diferentes. Por exemplo, importar um ficheiro de teste limpo é diferente de reconciliar anos de registos com duplicados. Peça uma amostra representativa dos dados e confirme quem resolve os erros antes de transformar a migração numa 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 que atividades concretas estão previstas e quem acompanha problemas depois da entrega. Secure Software Development Framework.
O desconhecido precisa de uma experiência, 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. Registe-a: “O fornecedor permite consultar disponibilidade e criar reservas com estas permissões.” Defina uma experiência pequena 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, compreender o problema, os utilizadores e as restrições antecede a decisão de construir. A investigação 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 grande compromisso. Não importamos automaticamente a duração ou a estrutura de equipa desse 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 produz o limite inferior, o que eleva o esforço e quando será revista? Uma margem sem pressupostos é apenas outro número com ar importante. Não há uma percentagem de contingência que sirva para todos os projetos.
Um briefing curto que permite comparar
Preencha estes 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 pretendida 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 utilizadores 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 registos acordados num formato documentado.” Estes exemplos descrevem resultados que se podem demonstrar; “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 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 alojamento, 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 volume de utilização 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 procura atual justifica. Nenhum destes cenários é resolvido pelo preço inicial isolado.
Antes de decidir, peça uma explicação para a maior diferença entre propostas. Pode resultar de âmbito, reutilização de componentes, disponibilidade, risco ou estratégia comercial. Sem essa conversa, escolher o mais caro por segurança é tão frágil como escolher o mais barato por reflexo.
Uma boa estimativa torna as decisões visíveis: o que se vai resolver agora, o que fica de fora, que hipótese falta testar e como se reconhece uma entrega concluída. Não precisa de adivinhar o futuro. Precisa de permitir que a próxima descoberta atualize o plano sem transformar uma surpresa técnica numa discussão sobre o significado de “óbvio”.