Preço fixo x tempo e material: como cobrar um projeto de software?

Preço fixo é um contrato de desenvolvimento de software em que escopo, prazo e custo total são combinados antes de começar, e o risco de algo custar mais do que o previsto fica com o squad ou a consultoria que executa. Tempo e material (T&M) é um contrato em que se paga pelas horas realmente trabalhadas, e esse mesmo risco de estouro de custo fica com a empresa contratante. Nenhum dos dois é superior em abstrato: preço fixo funciona quando o escopo já está bem fechado, e T&M quando se espera que ele mude ao longo do caminho. O problema real é que a maioria dos projetos de software não se encaixa totalmente em nenhum dos dois extremos.

O que é um contrato de preço fixo em desenvolvimento de software?

Em um contrato de preço fixo, o squad ou a consultoria cotiza um valor fechado para um escopo definido de antemão: tantas funcionalidades, tantas telas, tantos meses. A empresa sabe exatamente quanto vai pagar antes de a primeira linha de código ser escrita, e esse é o principal atrativo do modelo —orçamento previsível, sem surpresas—. O outro lado da moeda é que esse mesmo fechamento absorve o risco de estimativa: se algo leva mais tempo do que o calculado, quem executa o trabalho perde margem, não a empresa.

Esse modelo funciona bem quando o escopo está genuinamente fechado antes de começar —um redesign pontual, uma migração com especificação clara, um MVP com funcionalidades já definidas—. Ele quebra assim que aparece um pedido de mudança no meio do caminho, porque qualquer ajuste no escopo original significa renegociar o contrato inteiro, não só somar uma tarefa avulsa.

O que é um contrato de tempo e material (T&M) em desenvolvimento de software?

Em um contrato de tempo e material, a empresa paga pelas horas reais que o time dedica ao projeto, mais os recursos usados pelo caminho. Não há um valor total fixado de antemão: o custo final depende de quanto trabalho o projeto acabar exigindo. Em troca dessa incerteza, a empresa ganha a flexibilidade de ajustar prioridades, somar funcionalidades ou mudar de direção sem precisar renegociar um contrato fechado cada vez que algo muda.

O risco se inverte em relação ao preço fixo: aqui quem assume é a empresa, não o squad. Se o escopo cresce sem que ninguém o controle, o custo cresce junto —e, ao contrário do preço fixo, não existe um teto que force uma conversa explícita antes disso acontecer—. T&M funciona bem quando o projeto é evolutivo por natureza (um produto que itera a partir de feedback real) e mal quando a empresa não tem a disciplina de acompanhar o avanço semana a semana.

Por que a maioria dos projetos de software não se encaixa em nenhum dos dois modelos puros?

Os dois modelos partem da mesma premissa: que o escopo pode ser fixado com precisão no início (preço fixo) ou que a empresa consegue acompanhar cada mudança em tempo real (T&M). Os dados da indústria dizem que nenhuma das duas premissas se confirma com a frequência necessária. Segundo o Pulse of the Profession 2018 do Project Management Institute (PMI) —uma pesquisa com 5.402 organizações—, 52% dos projetos concluídos nos 12 meses anteriores tinham tido scope creep, escopo que cresce sem passar por um processo formal de aprovação, ante os 43% que a mesma pesquisa media cinco anos antes. As três causas mais citadas de um projeto não atingir seu objetivo foram uma mudança nas prioridades do negócio (39%), uma mudança nos objetivos do projeto (37%) e um levantamento incorreto de requisitos no início (35%).

O custo de não resolver isso bem não é pequeno: os grandes projetos de TI estouram o orçamento em uma média de 45%, segundo o estudo conjunto da McKinsey & Company com a Universidade de Oxford sobre 5.400 projetos. Com um escopo que se move em mais da metade dos projetos reais, um contrato de preço fixo termina em uma negociação de mudança de contrato atrás da outra, e um de tempo e material termina em uma fatura que cresce sem que ninguém tenha decidido explicitamente que deveria crescer.

O modelo de cobrança importa se o projeto de qualquer forma não atinge os objetivos?

Menos do que parece. O Standish Group, que mantém a maior base de dados sobre resultados de projetos de TI, encontrou em seu CHAOS Report 2020 que apenas 31% dos projetos são concluídos dentro do escopo, prazo e orçamento; 50% ficam "desafiados" —com estouro de custo ou corte de escopo—, e 19% são cancelados diretamente. Essa distribuição não depende de o contrato original ser preço fixo ou T&M: depende de o escopo ter ficado bem definido desde o início, e de as mudanças, quando aparecem, serem tratadas como uma decisão explícita ou se infiltrarem sem que ninguém as meça.

Existe um modelo intermediário entre preço fixo e tempo e material?

Na prática, cada vez mais squads e agências de desenvolvimento cobram por milestone: em vez de fixar o custo do projeto inteiro de uma vez, ou deixá-lo aberto por hora, define-se um escopo e um custo limitado para o próximo trecho de trabalho —duas, quatro semanas—, executa-se, entrega-se, e só então se combina o próximo. Cada milestone funciona como um mini contrato de preço fixo com um escopo pequeno e verificável, em vez de comprometer o projeto inteiro desde o início.

A diferença em relação a um preço fixo tradicional é que o compromisso fechado dura só o tempo daquele trecho: se o escopo precisa de ajuste, ele é ajustado no próximo milestone, com seu próprio custo, em vez de forçar uma renegociação do contrato inteiro ou deixar a mudança entrar sem controle.

Como a Zenit resolve isso: pagamento por milestone, nem preço fixo puro nem T&M aberto

Na Zenit, cada milestone começa com um critério de aceitação assinado pela empresa e pelo squad antes de a primeira linha de código ser escrita: o que aquele marco inclui, o que fica de fora, e qual evidência comprova que está concluído. Esse acordo cumpre a função que o preço fixo tradicional não consegue cumprir sem quebrar na primeira mudança, e a que o T&M aberto nunca teve: se algo novo aparece no meio de um milestone, não é somado aos poucos —vira uma decisão explícita sobre se entra no milestone atual, com custo e prazo ajustados, ou no seguinte—.

Essa definição antecipada do escopo —a mesma que, segundo os dados do PMI citados acima, é o que mais reduz o risco de um projeto sair de controle— também é o trabalho que o Kaizen faz antes de montar o match: em vez de partir de um formulário, ele escuta as reuniões do time e monta um brief com escopo, milestones e decisões já documentadas antes de o squad começar a trabalhar.

A pergunta que realmente importa não é "preço fixo ou tempo e material". É o que acontece no dia em que o escopo precisa mudar —porque, na maioria dos projetos reais, segundo os dados citados acima, esse dia chega—: se essa conversa fica documentada e limitada milestone a milestone, ou se vira uma renegociação de contrato inteiro ou uma fatura que cresce sem que ninguém a veja chegar.