Preço fechado ou pagamento por horas no desenvolvimento de uma aplicação

O que muda entre os modelos

A diferença real entre os modelos aparece no primeiro imprevisto. Uma integração devolve dados incompletos, os utilizadores não compreendem um fluxo já aprovado ou uma regra comercial muda antes do lançamento. Numa proposta, a descoberta gera um novo orçamento; na outra, obriga o cliente a escolher o que pode descer na lista de prioridades.

Até esse momento, a soma fechada parece mais segura e a estimativa de esforço menos previsível. Mas o número inicial não explica como cliente e fornecedor vão colaborar quando o plano deixar de servir. Na nossa opinião, é essa reação que está realmente a ser escolhida.

O modelo de pagamento decide como as partes tratam a incerteza; não a elimina. Por isso deve acompanhar o que o projeto sabe hoje, em vez de criar uma certeza artificial em torno do que ainda falta descobrir.

Este guia destina-se à preparação comercial de um projeto. Não substitui aconselhamento jurídico sobre o contrato e o direito aplicável.

Num projeto de preço fechado, o fornecedor aceita entregar um âmbito definido por um valor acordado. Uma necessidade adicional gera uma alteração, uma troca de âmbito ou uma fase posterior. Em Time and Materials (T&M), o cliente paga o trabalho real das funções e taxas combinadas. Um modelo híbrido reconhece que algumas partes já podem ser fechadas e outras ainda precisam de descoberta.

Quando o preço fechado faz sentido

O preço pode ser fechado de forma responsável quando duas equipas independentes conseguiriam ler a descrição e imaginar praticamente a mesma primeira versão. Uma lista com «registo, perfil, pagamentos e notificações» ainda não chega. O registo pode incluir recuperação, verificação, eliminação e vários papéis. Os pagamentos podem exigir reembolsos, recibos, renovação ou divisão de valores.

Um pequeno instrumento interno com regras conhecidas é um bom candidato. O mesmo vale para a implementação de ecrãs aprovados sobre uma API já testada ou para uma migração cujos dados foram examinados. Nestes casos, é possível escrever os testes de aceitação antes de começar.

Uma proposta de preço fechado deve mostrar o que está incluído, o que fica de fora e quais as suposições sobre design, conteúdos, dados e sistemas externos. Precisa também de marcos, critérios de aceitação e um processo para defeitos e alterações. A lista de verificação para o contrato de desenvolvimento acrescenta propriedade do código, acessos, componentes externos e entrega do projeto.

Por que razão um preço fechado pode aumentar

O valor permanece fixo apenas dentro do âmbito descrito. Quando existe uma incógnita, o fornecedor inclui uma margem de segurança, exclui essa zona ou deixa-a para uma alteração posterior. O problema não está necessariamente numa destas opções, mas na falta de transparência.

Depois de o projeto começar, a mudança de fornecedor torna-se cara. Por isso, uma regra esquecida pode custar mais do que custaria na fase de definição. Combine antecipadamente quem descreve a alteração, como se calcula o impacto, se o trabalho deve parar e se uma nova prioridade pode substituir outra para manter o orçamento.

A análise atual da Match.dev sobre preço fixo e T&M explica que o fornecedor pode incorporar no preço o risco que aceita antes de conhecer todos os detalhes. Uma investigação técnica curta pode ser uma forma mais barata de reduzir essa margem do que tentar transferir uma incógnita inteira para o fornecedor.

Como controlar um projeto pago por horas

O pagamento por horas é adequado quando o próprio trabalho produz aprendizagem. Um MVP pode mudar depois dos testes. Um sistema antigo pode ter dados diferentes da documentação. Uma funcionalidade de inteligência artificial precisa de ser avaliada com exemplos reais antes de se decidir a versão final.

T&M não deve significar que a equipa trabalha sem uma fronteira e apresenta a conta no fim. O cliente precisa de saber quais as funções que podem faturar, as respetivas taxas e a capacidade semanal esperada. O trabalho pendente deve estar visível, ordenado e ligado a um objetivo.

Peça também uma previsão curta. A cada semana ou quinzena, o relatório deve mostrar valor utilizado, orçamento disponível, resultado esperado no próximo marco e principais incertezas. Uma folha de horas prova atividade; uma demonstração funcional prova progresso.

O teto de orçamento completa o controlo. A equipa não o ultrapassa sem autorização. Este limite não garante que toda a lista inicial será entregue. Obriga a decidir antes de gastar mais: simplificar, retirar, adiar, financiar a continuação ou lançar a melhor versão que já está completa.

O cliente deve ainda poder pausar o projeto e conservar código, design, contas e documentação utilizável. Caso contrário, a flexibilidade do pagamento cria dependência do fornecedor.

Comparar apenas taxas horárias também pode induzir em erro. Uma equipa mais experiente pode ter uma taxa superior e um custo total inferior se identificar cedo funcionalidades desnecessárias. Compare o custo para chegar a um marco aceite, e não apenas o preço de uma hora.

Um modelo híbrido pode ser mais fiel ao projeto

As aplicações não têm o mesmo grau de certeza em todas as áreas. O fluxo de marcação pode estar definido, enquanto a sincronização com o software existente nunca foi testada. O design pode estar aprovado, mas a operação de reembolsos ainda não.

Uma estrutura útil começa com uma fase de definição limitada e de preço fechado. O resultado inclui percursos, protótipo, riscos técnicos, fronteira da primeira versão, trabalho pendente e suposições da estimativa. As partes incertas seguem em T&M com teto, demonstrações e previsões curtas. A publicação e a entrega final podem ter marcos fixos quando as condições já estão preparadas.

Outra opção fecha apenas o primeiro percurso completo, por exemplo registo e transação principal, e mantém as integrações flexíveis. A proposta deve indicar a separação. A palavra «híbrido» não protege o cliente se tudo o que é difícil ficar aberto.

O guia da Launch Day Advisors olha para estes modelos como distribuição de risco. É uma pergunta mais útil do que procurar um vencedor universal: cada incerteza deve ser acompanhada por quem consegue observá-la e tomar decisões.

Quatro situações reconhecíveis

Ferramenta interna simples. A equipa lê um código, escolhe um de cinco estados e exporta um relatório. Dispositivos e dados são conhecidos. O preço fechado pode apoiar-se em critérios objetivos.

Primeiro MVP para consumidores. O problema está identificado, mas ainda é necessário testar entrada, regresso e monetização. Um T&M com teto ou híbrido permite alterar prioridades a partir de dados reais.

Ligação a um ERP antigo. Os ecrãs podem parecer claros, mas a API, os acessos e a qualidade dos dados continuam desconhecidos. Contrate primeiro uma prova técnica limitada. Fechar o preço de toda a aplicação antes disso tende a produzir exclusões ou uma margem elevada.

Produto existente com melhorias mensais. Não existe um âmbito final. Uma capacidade mensal pode funcionar se a equipa mostrar resultados, consumo do orçamento e prioridades. O processo de desenvolvimento de uma aplicação ajuda a manter marcos úteis em vez de uma fila interminável de tarefas.

Seis perguntas para tomar a decisão

1. Conseguimos descrever uma primeira versão útil com uma fronteira clara?
2. Os ecrãs, conteúdos, dados e sistemas externos estão disponíveis para análise?
3. Um responsável do negócio consegue aceitar os resultados com base em exemplos escritos?
4. Esperamos que testes com utilizadores alterem a ordem das funcionalidades?
5. Alguém do lado do cliente pode ver uma demonstração e decidir a cada uma ou duas semanas?
6. O que custa menos: a margem de risco do fornecedor ou a nossa capacidade controlada de mudar de direção?

Respostas maioritariamente estáveis favorecem preço fechado. Várias respostas abertas favorecem T&M com teto. Um núcleo estável com integrações ou decisões de produto abertas favorece um híbrido.

Se as três primeiras respostas ainda não existem, talvez o próximo contrato deva ser um protótipo, uma prova técnica ou um piloto, e não o desenvolvimento completo. A comparação entre protótipo, prova de conceito, piloto e MVP explica o que cada etapa precisa de demonstrar.

Sinais de alerta numa proposta

Num preço fechado, desconfie da ausência de critérios de aceitação, dependências e processo de alterações. Uma proposta baixa com a frase «backend fornecido pelo cliente» é enganadora se esse backend não existir ou não tiver sido testado.

Em T&M, uma tabela de taxas sem equipa esperada, primeiro marco, ritmo de acompanhamento e limite inicial também é insuficiente. O acesso ao repositório e às contas não deve ser adiado até ao fim.

Nos dois modelos, verifique se produto, experiência, testes, analytics, preparação das lojas, gestão e entrega foram considerados. O guia de preparação de uma estimativa ajuda a fornecer a mesma informação a vários fornecedores e a comparar respostas equivalentes.

Como a Appfyl prepara a estimativa

A Appfyl separa o âmbito conhecido das suposições que ainda precisam de evidência. Analisamos papéis de utilizador, percursos principais, dados, integrações, administração, analytics, publicação e propriedade das contas. Uma questão aberta torna-se uma investigação limitada, um item flexível ou uma exclusão clara, em vez de aparecer como surpresa no fim.

O questionário da Appfyl para estimar uma aplicação permite descrever o produto em linguagem prática. Consulte também o serviço de desenvolvimento de aplicações móveis da Appfyl e os nossos projetos publicados.

Veja como a Appfyl transforma escopo em produtos lançados. Ver cases da Appfyl.

Perguntas frequentes