A maior parte das propostas de desenvolvimento de software que dão problema não erra no preço. Erra em não deixar claro o que exatamente o cliente está comprando: um time por um período, ou um resultado pronto. São duas coisas diferentes, com riscos diferentes, e a proposta precisa escolher uma antes de chegar no valor.
Os dois modelos, na prática
Quase toda squad vende de uma das duas formas, mesmo quando não chama assim:
- Por sprint (ou por alocação): o cliente compra capacidade do time por um período. Dois devs e um designer, por dois meses. O escopo pode mudar dentro disso, e muda mesmo.
- Por entrega (escopo fechado): o cliente compra um resultado definido. O app com essas telas, essas integrações, esse comportamento. Quanto tempo leva é problema seu, não dele.
Não existe modelo superior. Existe modelo adequado ao que o cliente sabe sobre o próprio projeto no momento em que pede a proposta.
| Critério | Por sprint | Por entrega |
|---|---|---|
| Quem absorve mudança de escopo | O cliente (vira mais sprint) | Você (vira mais hora sua) |
| Funciona melhor quando | O produto ainda está sendo descoberto, a prioridade muda a cada duas semanas | O escopo já foi definido, validado, e não deve mudar no meio |
| O que a proposta precisa detalhar | Composição do time, duração do sprint, cerimônias, o que conta como capacidade | Lista de entregas, critério de aceite, o que está fora |
| Risco maior | Cliente sentir que paga sem ver resultado | Escopo crescer em silêncio até o projeto virar prejuízo |
| Como o preço aparece | Valor por sprint ou mensal, com período mínimo | Valor total, parcelado por marco |
Se você vende por sprint, a proposta precisa vender capacidade
O cliente que compra sprint está comprando uma coisa abstrata: gente disponível. Se a proposta só disser "squad de 3 pessoas, R$ X por mês", ela deixa o cliente sozinho pra imaginar o que vai receber, e quem imagina sozinho imagina errado.
Três coisas resolvem isso:
- Composição explícita do time. Quantas pessoas, com que papel, em que dedicação. Meio período de um tech lead é diferente de período integral, e essa diferença precisa estar escrita, não subentendida.
- O que acontece a cada ciclo. Duração do sprint, o que o cliente recebe no fim dele (ambiente atualizado, demo, relatório), e em que momento ele decide a prioridade do ciclo seguinte. Isso transforma "pagar por tempo" em "receber alguma coisa a cada duas semanas".
- O que não conta como capacidade. Reunião fora do combinado, suporte a sistema legado que não faz parte do contrato, correção de bug em código de terceiro. Não é para criar barreira, é pra que a primeira vez que isso apareça não vire uma negociação desconfortável.
Se você vende por entrega, a proposta precisa vender fronteira
Aqui o risco inverte. O cliente já tem o resultado garantido no papel, e qualquer coisa que ele considerar "parte do combinado" vai sair do seu tempo. A proposta por entrega vive ou morre na clareza do que está dentro e do que está fora.
Duas seções fazem quase todo o trabalho:
- Critério de aceite por entrega. Não "tela de login", e sim o que precisa acontecer pra tela de login ser considerada entregue: autenticação funcionando, recuperação de senha, validação de erro. Sem isso, "pronto" vira opinião.
- Uma lista curta do que está fora. Migração de dados do sistema antigo, criação de conteúdo, publicação nas lojas, manutenção depois do go-live. Cada item dessa lista é uma conversa difícil que você não vai precisar ter no mês que vem.
E vale dizer, com todas as letras, o que acontece quando o escopo muda: uma frase simples sobre pedidos novos entrarem como adendo com prazo e valor próprios já evita a maior parte dos atritos.
O que precisa estar nos dois modelos
Independente de como você cobra, quatro pontos aparecem em toda proposta de desenvolvimento que funciona bem:
- Premissas técnicas. Em que stack, em que infraestrutura, com que acessos, dependendo de que APIs de terceiro. Se o projeto assume que o cliente vai fornecer credenciais de um sistema dele, isso é uma premissa, e premissa não atendida trava cronograma.
- Responsabilidades do cliente. Quem aprova, em quanto tempo, e o que acontece se a aprovação atrasar. Praticamente todo atraso em projeto de software tem um pedaço que não é técnico.
- Propriedade do código e acessos. De quem é o repositório, quando o cliente recebe acesso, o que acontece com o código se o contrato acabar antes do fim.
- O que vem depois da entrega. Garantia de correção por algum período, suporte, manutenção. Mesmo que a resposta seja "não incluso, cotado à parte", ela precisa estar escrita.
O erro mais comum: misturar os dois
A proposta que promete escopo fechado e cobra por sprint junta o pior dos dois lados: o cliente acha que tem garantia de resultado, e você acha que tem liberdade de ajustar. Quando os dois descobrem que entenderam coisas diferentes, já tem código escrito.
Se o projeto realmente tem uma parte definida e outra em aberto, o caminho é separar em duas fases na mesma proposta, cada uma com seu modelo e seu valor, e não fundir os dois num parágrafo ambíguo.
Escolher entre sprint e entrega não é detalhe de formatação. É a decisão que define quem carrega o risco do projeto. Uma proposta que deixa isso claro na primeira página fecha mais rápido, porque o cliente para de tentar adivinhar o que está comprando.
Se quiser aprofundar a parte de estrutura do documento em si, vale a leitura de o que incluir em uma proposta comercial.
