Quando se pensa em qual valor cobrar do cliente pelo desenvolvimento de uma aplicação (programação), imediatamente surgem duas formas de medir o trabalho executado distintas:

• Cobrar pelas horas trabalhadas ou;
• Pela quantidade de código escrito.

Sendo a primeira mais comum que a última.

Assim, as horas empregadas na execução do projeto ou a quantia de linhas de código que o projeto contém não passam de unidades de medida e não são, por si só, capazes de definir o valor desse projeto.

É necessário que se utilize alguma metodologia de precificação, ou seja, é necessário que o desenvolvedor/programador se utilize de uma técnica para determinar qual será o preço da hora trabalhada ou da linha de código escrita.

Neste momento, o conhecimento sobre economia e contabilidade são essenciais para a determinação do preço pelo trabalho executado.

O objetivo deste artigo não é fornecer ao leitor nenhuma técnica específica sobre precificação, mas sim, oferecer-lhe alguns conceitos fundamentais e orientações gerais para que o profissional desenvolva sua própria técnica, de acordo com o contexto em que atua.

Este artigo se divide em três partes. A primeira delas trata da precificação propriamente dita, quais as principais variáveis que atuam sobre o valor do trabalho e algumas breves noções de economia e contabilidade.

Na segunda parte é abordada a questão da avaliação dos custos do projeto, durante e após sua execução a fim de que questionar se a técnica de precificação utilizada foi eficiente e se os resultados foram alcançados, e caso não o sejam, onde ocorreu o baixo desempenho.

A terceira parte apresenta as conclusões e algumas dicas voltadas a questões mercadológicas.

[1] Comentário enviado por marcio68almeida em 13/02/2008 - 16:41h:

Interessante a sua explanação sobre o assunto.

[2] Comentário enviado por Teixeira em 13/02/2008 - 20:43h:

O assunto foi muito bem abordado. Parabéns.

Existem ainda outros fatores esporádicos que poderão modificar o preço final, porém o essencial foi bem exposto.

[3] Comentário enviado por shadow3 em 13/02/2008 - 22:54h:

Realmente aqui está um assunto que deveria ser abordado mais amplamente

[4] Comentário enviado por bakunin em 14/02/2008 - 08:23h:

?comentario=Prezado autor. O Sr passeia pela teoria chega ao ponto certo e se afasta dele novamente. Há dois conceitos: Vender custo com uma margem de lucro sobre ele. Isso é coisa antiga. Soma-se os HH´s os custos de eletricidade, o overhead, o lucro e manda-se a conta.
Na estorieta do engenheiro (tal como esse que vos escreve) ele cobrou 9.999 precisamente pela solução.
No conceito moderno não se vende custo mais lucro mais over head, Vende-se solução. A pergunta não é quanto custou para fazer?
A pergunta é quanto vale a solução?

O software é solução porque faz o que o cliente precisa.
Treinamento é solução, porque aumenta e produtividade da equipe do cliente.
Software e treinamento são pacotes distintos. Um informático com talento em didática pode vender muito treinamento para um cliente sem ter feito uma linha de programação (por exemplo no pacote microsoft).
O Sr passa pelo conceito certo e retorna pelo desvio.
Claro que os custos são importante, mas são apenas um dos ítens da solução.
Os outros são: O que o cliente ganha com a solução?
Novamente o Sr passa em cima do alvo.
Os experts em marketing tem isso mais claro na cabeça que os administradores.
O lucro mesmo vem de um princípio do marketing: Um cliente mal atendido (insatisfeito) destrói 5 oportunidades. Um cliente satisfeito lhe tráz mais 3. Isso é realmente o lucro do negócio.
O Sr está no caminho certo, o que é raro neste país: Parabéns pela lucidez.

[5] Comentário enviado por edlonewolf em 14/02/2008 - 10:33h:

Excelente artigo!

Dar preço para a tarefa de programar é sempre complicado.

Devido à complexidade da atividade, quase todas as avaliaçõe siniciais acabam se perdendo no decorrer do desenvolvimento. Coisas que pareciam simples acabam dando um trabalho terrível e aí os orçamentos vão para o espaço. Ou sofre o cliente com a elevação do custo esperado, ou sofremos nós desenvolvedores com nosso lucro indo pelo ralo.

Valeu o tema e oartigo merece um aprofundamento. Quem sabe discutindo técnicas específicas para avaliação de custos?

[6] Comentário enviado por Cooler_ em 17/02/2008 - 01:24h:

Pelo artigo
parabens

[7] Comentário enviado por fiabani em 18/02/2008 - 19:44h:

Olá Everton da Rosa,

parabéns pelo artigo.

[8] Comentário enviado por Teixeira em 21/02/2008 - 23:26h:

Mas precificar não é tarefa fácil ou mesmo simples.
Não existe uma "receita de bolo" para isso, pois cada caso é um caso. Suponhamos dois sistemas de RH, um para atender a uma construtora multinacional, outro para atender a uma pequena empreiteira.
Muito embora o sistema se refira a uma só coisa (RH) e ambos os clientes hipotéticos sejam "construtoras", não somente o preço final é diferente, mas também as formas de se chegar a esses preços diferem de uma forma gritante.
O que muda não é somente o número de empregados e as rubricas com que teremos de lidar, nem mesmo o tamanho ou abrangência dessas empresas, ou a quantidade de horas trabalhadas ou a quantidade de código necessário.
Antigamente os programadores levavam em consideração apenas esses quesitos, mas a coisa é muito mais complexa.
Até mesmo o preço de um programador autônomo (free lancer) será diferente do preço cobrado por uma pequena equipe de programadores, ou daquele cobrado por uma empresa.
(Quero dizer que, mesmo na eventualidade do preço ser igual, a fórmula utilizada para seu cálculo será inevitavelmente diferente).
Poderíamos criar uma base teórica (ou uma fórmula) para a formação desses preços em particular, contudo teríamos sempre que fazer alguma adaptação.
Acho que o autor foi até onde era possível ir, e "levantou a lebre".
Bom artigo.