Como precificar um projeto corretamente?
Fala turma,
A forma mais precisa que eu conheço para precificar um projeto de desenvolvimento de software é atraves de Ponto de Funcao (PF) e método COCOMO.
Mas ai surge um grande problema: pra fazer uma analise de requisitos bem feita e na sequencia aplicar o primeiro ou o segundo método, é preciso investir muitas horas. E na vida real um cliente as vezes quer saber o preço de um app por um audio de briefing no WhatsApp.
A grande maioria dos clientes casuais não está disposta a pagar pelo preço da sua análise de requisitos para receber a proposta. Tenho cerca de 20 anos de experiencia com software e no ano passado errei feio uma estimativa de projeto (atrasei 5 meses a entrega e tive que custear 100% do prejuízo do atraso) - justamente porque era um projeto pequeno que se transformou em um monstro.
Como vocês fazem quando o cliente não está disposto a renegociar? E alguém conhece alguma forma mais equilibrada de contrato pro modelo de dev sob demanda?
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:
- Faço a pergunta: Esse é um problema que já resolvi antes?
- 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);
- 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.