Estimando preço de um projeto
29/07/2013 12:42
1
Bom dia pessoal, tudo bem?

Pois bem, sou desenvolvedor Grails há alguns anos, parti do Rails para o Grails por uma oportunidade de trabalho, e não sai dele até hoje. =]

Minha experiência é ampla como desenvolvedor, atualmente junto com outros amigos estamos começando uma startup focada no desenvolvimento de soluções web, pesquisa e desenvolvimento de produtos. Gostaria de uma ajuda de vocês mais experiêntes no quesito serviço. Qual a melhor prática para estipular custos de um projeto Grails, como vocês o fazem, por LOC, total de CRUD's, nível de integração, complexidade de views?

Como estamos no início, nossos projetos ainda são pequenos, nada de grande porte... além do desenvolvimento de nossos produtos (que ainda não finalizaram, e nesse caso nós somos os clientes).

Conto com a ajuda de vocês, para que se possível compartilhem suas experiências, desafios, e superações!

Muito obrigado!
Tags: Projetos, Custos, Estimar Custos


1
Esta é uma arte negra, e difícilmente vi uma solução para o problema, mas posso ao menos dizer quais os piores caminhos. :)

* Linhas de código: FURADA. Você vai incentivar a sua equipe a ser incompetente gerando mais linhas de código para faturar mais. E outra: muitas vezes código pequeno da mais trabalho que complexo.

* Ponto de função: FURADA. A não ser que o sistema seja APENAS CRUDs, talvez você consiga estimar o tamanho e a partir daí cobrar por unidade de ponto de função. O problema é que difícilmente você vê ponto de função aplicado a complexidade do que vai ser implementado. E aí, já viu: da merda.

* Por hora trabalhada: é talvez o menos cagado, mas é sempre uma aposta. Se você conseguir entregar no prazo, perfeito. Caso contrário, o prejuízo é seu.

O que costumo fazer: eu uso uma unidade "hora" pra medir a complexidade do trabalho. Não é uma hora cronológica, deixo isto claro pro cliente de cara, mas sim uma unidade de complexidade. Ela também é indiferente do tamanho do código gerado. Então, por exemplo, se é apenas CRUD, e eu posso usar o scaffolding do Grails pra quebrar o galho, eu consigo fazer, sei lá, uns 10 CRUDs basicos (basico do basico) em 12, 20 horas. Por ponto de função seria isto por crud, e por linha de código, seria mais gelada ainda.

Há também os projetos que pego por empreitada. Tipo: "Olha: tenho X pra gastar nesta funcionalidade do sistema. Você quer implementar pra mim?". Se achar que o valor vale à pena, mando ver, caso contrário, deixo passar e indico outra pessoa.

No final, você só vai ganhar precisão com experiência. Hoje, batendo o olho, eu consigo dizer de cara a complexidade por "horas Kico" de uma tarefa. Mas isto leva tempo.

Dica de livro: http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351


1
Opa! Muito obrigado pela rápida resposta Kico.

Então, eu estimo o custo por "hora" também, e queria saber e sentir uma segurança sobre isso... rs
Devido a experiência como desenvolvedor, é possível "chutar" um tempo e complexidade, mas ainda assim é complicado, tenho muito a aprender.

E você faz o cálculo do custo ponderando o prazo e o tamanho da equipe? Considera o valor que o produto representa ao cliente? Ou é um cálculo "frio", ou seja, você apura a complexidade e taxa o valor.

Mais uma vez agradeço a ajuda.

29/07/2013 12:57


1
Oi Luciano,

minha equipe em 90% das vezes é composta por um apessoa: eu. :)
Então fica muito mais tranquilo eu obter uma previsão precisa.

Recentemente, conforme eu tenho terceirizado parte do trabalho tenho começado a sofrer com estas estimativas: acaba que pra estimar levando em consideração a equipe, varia demais de acordo com o membro da equipe, saca? Aí é aquela conversinha chata de perguntar pro cara o prazo e tal que, numa boa? Nunca vi funcionar direito. To apanhando bastante neste ponto.

O que observo é que quanto menor a equipe, e mais comprometida esta é, melhor. Já peguei desenvolvedor com experiência em Grails que fez merda e outro que não tinha nenhuma e brilhou. Quando vejo aquele papo furado de que da pra tirar média e tal, fico sempre muito desconfiado.


1
Infelizmente (ou felizmente) a intuição acaba falando mais alto. :)


0
Nossa equipe é pequena, 3 desenvolvedores. Então acho que complica menos que um terceiro.

Existem algumas pessoas como nesse post que dizem que o custo final adequado de um projeto seja:

Tempo Estimado * h/h(relação custo hora homem) * 4 ou 5 (margem mágica de lucro). O que você pensa a respeito?

Mas de qualquer forma, o que pesa mesmo é a experiência em realizar a estimativa.
29/07/2013 14:45


0
Oi Luciano,

eu penso que fórmulinhas como estas ignoram o principal fator que é o humano.
Não que devamos pensar que as pessoas vão fazer merda, mas sim o contrário: acho que a maior parte dos prejuízos que vejo é justamente porque as pessoas não sabem tirar proveito do fato dos membros da equipe serem... humanos. :)

Então sempre desconfio.


0
Legal Kico, muito obrigado pelas contribuições. É sempre bom trocar idéias com pessoas mais experientes, ver diferentes perspectivas... e isso funciona de forma muito ativa nesta comunidade.

[]'s
29/07/2013 17:21


1
Vi alguns contratos indo na moda do agile em que o pessoal "alugava" o time por mês por um preço fixo e as entregas eram semanais / quinzenais
alguma coisa do tipo: oferecemos 2 desenvolvedores por mes por X, 4 por 2X, etc

O problema disso é que tem muito receio do lado do contratante, que acha que com isso gera enrolação pra ganhar mais (o que acontece se ele não acompanhar as entregas)
29/07/2013 18:36


0
Interessante isto Mussatto, mas na prática acaba transformando agile em mero outsourcing, não?


0
acho que a diferença é que já entra com um escopo mais definido para o projeto (vou fazer o CRM, vou fazer o ADMIN, etc), devem entrar algumas metricas de custo maximo, prazo maximo e negociacao mais abrangente....

mas na pratica imagino que acaba acontecendo isso sim

alias esses termos se confundem tanto na pratica que nem sei quando estou usando eles corretamente hehehehehe
29/07/2013 21:08



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto