O Que É Pagamento por Marcos no Desenvolvimento de Software? (E Por Que Protege Mais Que Pagar Tudo Adiantado ou no Final)

Pagamento por marcos (milestone-based payment) é um modelo de pagamento em que o dinheiro de um projeto de software não é transferido todo adiantado nem fica retido até a entrega final: ele é dividido em partes ligadas a marcos concretos, e cada parte só é liberada quando esse marco é cumprido e verificado. Existe para que nenhum dos dois lados carregue sozinho o risco — a empresa não paga por um trabalho que ainda não existe, e o time não entrega semanas de trabalho sem nenhuma garantia de receber.

É o modelo usado na maioria dos projetos remotos entre partes que estão começando a trabalhar juntas, e é a razão de fundo pela qual o escrow de software existe: alguém retém o dinheiro até o marco ser cumprido, em vez de deixar a critério de um só lado decidir quando pagar ou quando dar o trabalho por concluído.

Como funciona o pagamento por marcos na prática?

O mecanismo tem três partes combinadas antes de o projeto começar, não definidas ao longo do caminho. Primeiro, os marcos são definidos: pontos de entrega concretos e verificáveis —uma funcionalidade funcionando, um módulo integrado, uma versão publicada—, não datas de calendário nem uma porcentagem de tempo decorrido. Segundo, fixa-se o critério de aceitação de cada um: o que precisa ser visto exatamente para considerá-lo cumprido. Terceiro, o dinheiro de cada marco é bloqueado antes de o time começar a trabalhar nele, e só é liberado quando a entrega é verificada contra esse critério.

Qual a diferença para pagar tudo adiantado ou tudo no final?

Os outros dois modelos comuns concentram todo o risco em um único lado.

• Tudo adiantado: a empresa assume todo o risco. Se o time não entregar, entregar atrasado ou desaparecer no meio do caminho, o dinheiro já saiu.
• Tudo no final (contra entrega ou em 30 dias): o risco se inverte por completo. O time trabalha semanas ou meses sem nenhuma garantia de receber, e se o cliente questiona o escopo só no final, não há nada retido que obrigue a resolver isso rápido.
• Pagamento por marcos: o risco é dividido em partes do tamanho do que já pode ser verificado. Ninguém paga nem trabalha além do que já foi entregue até aquele ponto.

Por que dividir o risco assim importa?

Porque o risco de algo dar errado em um projeto de software não é hipotético. Segundo o CHAOS Report 2020 do Standish Group —a maior base de dados sobre resultados de projetos de TI—, apenas 31% dos projetos terminam dentro do escopo, prazo e orçamento: 50% terminam "desafiados" (com estouro de custo ou corte de escopo) e 19% são cancelados diretamente. Pagar tudo adiantado expõe o orçamento inteiro a essa estatística. Pagar por marcos limita a exposição ao que já foi entregue e verificado, marco a marco — se o projeto sair dos trilhos, o que está em jogo é uma parte, não o total.

É uma prática formal ou só um truque de marketplace?

Não é uma prática inventada por marketplaces de talento. O Project Management Institute formaliza isso dentro do seu Practice Standard for Earned Value Management, no método "milestone weights": cada marco combinado tem um valor de orçamento atribuído com antecedência, e esse valor só é considerado "ganho" quando o marco é cumprido —não antes, nem proporcionalmente ao tempo decorrido. E já é infraestrutura padrão na contratação remota: a Deel, uma das maiores plataformas de folha de pagamento e contratos para times globais, inclui o pagamento por marcos como um dos seus três tipos de contrato padrão para 2026, junto com tarifa fixa e pagamento por uso.

O que acontece se um marco não é cumprido?

É aí que o escrow faz o trabalho real: o dinheiro retido para aquele marco só é liberado quando a entrega é verificada, então nenhum dos dois lados consegue forçar o pagamento —nem o trabalho— sem cumprir a sua parte. Se o time não consegue terminar, o que fica exposto é a parte daquele marco específico, não o projeto inteiro, e o resto do orçamento continua protegido para o que falta.

Como a Zenit implementa isso?

Na Zenit, esse mecanismo é o SafePay: os fundos são bloqueados antes do primeiro commit e liberados milestone a milestone, não todos juntos no final do projeto. O critério de aceitação de cada milestone é assinado antes de o squad começar a trabalhar nele —não é negociado depois de o trabalho já estar pronto— e a reputação de ZenitRank de cada squad é construída sobre esse mesmo histórico de milestones cumpridos, não sobre reviews autodeclaradas.

Definir bem os marcos, porém, depende de ter entendido o projeto real antes de começar — que é exatamente o trabalho que o Kaizen faz antes de montar qualquer match.