Como precificar um projeto corretamente?

Hey, @depaula. Essa é a pergunta coringa. Já quebrei muito a cara, e depois de viver a experiência de muitos projetos (trabalhei em Fábrica de Software), de tocar projetos por conta própria e de ler muito Taleb, percebi que tentar prever o futuro de projetos não é muito diferente do que uma "Mãe Diná" faz. Com a diferença que ela ganha por fofoca e a gente por resultado haha
Atualmente tenho um método que é o seguinte:

1. Faço a pergunta: Esse é um problema que já resolvi antes?
   1. Se sim: Vejo quanto isso me custou de tempo no passado e precifico por valor agregado (geralmente isso funciona bem com demandas genéricas e coisas pequenas, tipo corrigir um bug, ou configurar uma infra específica);
   2. Se não: Abro o jogo com o cliente e vendo meu trabalho por horas. Junto com o cliente crio um board e monto um backlog (que vai continuar se alterando, tudo depende da necessidade do cliente. Backlog é vivo), e toda entrega priorizo com ele as demandas mais interessantes de serem feitas e as faço em ciclos pequenos (geralmente de 1 a 2 semanas). Somo o tempo gasto e ele me paga. Com isso, paro de tentar prever o futuro e trabalho com demandas curtas e palpáveis, sem tentar prever nada. O cliente acaba entendendo que o software nunca está pronto e que a ideia inicial dele não é o software e que naturalmente ele vai moldar e aprimorar o entendimento do que ele quer ao longo do tempo (por isso que prever é perigoso).

O legal dessa abordagem que tenho adotado, é que o meu acordo com o cliente é que farei aquilo que fecharmos para aquele ciclo pontual. Isso é muito mais fácil de entregar. E o mais legal é que ele começa a enxergar o valor real de cada funcionalidade.
Vale lembrar que ali tu comentou que os clientes não gostam de pagar pelo trabalho de análise e estimativa, e isso é verdade. Por isso que o preço da minha hora contempla esse tempo que gastarei junto com ele gerenciando o backlog (enriquecendo, etc) e priorizando tarefas.
Geralmente uso para tracking de tempo de trabalho o Clockify.
Espero ter ajudado.

Minha mãe sempre falava: "O que é combinado não sai caro". Tomei uma ou duas pauladas por não ter sido extremamente específico nos contratos, principalmente no que tangia o escopo do projeto. Hoje, mesmo que longe de fazer uma super análise de requisitos, me esforço muito para definir o escopo do projeto, detalhando cada entrega e parando de entregar quando atingir o objetivo.
Tive projetos que foram "renovados" mais de 3 vezes pois preferi ganhar menos no inicio mas acordar uma pequena parte do sistema do que assumir um gremilin que, quando menos eu esperava, viravam 100 pequenos monstrinhos.
Acho que parte da lógica advêm da experiência que adquirimos com o tempo, afinal, cobrar, precificar e valorizar o nosso esforço são skills que não são ensinadas em faculdade.

como um "projeto pequeno que se transformou em um monstro"? o cliente aumentou o escopo original?

Meus queridos amigos. Não troquem seu tempo por dinheiro. Tempo é o recurso mais escasso e insubstituível que existe.

Criem software que escala, que pode ser vendido por 10, 100, 1000...

Não percam tempo contando pontos por função. Percam tempo engenhando soluções que muitos estariam dispostos a pagar pra tê-las. Não precisa ser algo complexo. Só revolva.

Não é fácil porque dinheiro não nasce em árvore. Mas é muito recompensador.

Contrato eu faria em projetos relativamente grandes que levariam mais de 6 meses para ser concluido (sem considerar respaldos) firmados em cartórios. Mas geralmente eu só pego projeto pequeno, dou o prazo + 3 semanas utéis de homologação, e para acalmar o coração do cliente eu falo que dependendo das condições a homologação pode levar só 1 dia, os projetos q eu pego realmente são bem pequenos.