Qual o valor de seu trabalho

Este artigo trata da precificação da tarefa de desenvolvimento (programação). Não busca descrever ou analisar metodologias de precificação, mas sim, indicar parâmetros e conceitos que devem ser seguidos, segundo a ótica contábil/financeira/econômica.

[ Hits: 24.523 ]

Por: EVERTON DA ROSA em 13/02/2008 | Blog: http://everton3x.github.io


Precificação do trabalho de desenvolvimento



Reza a lenda que certa vez, uma grande empresa, dona de uma grande e moderna máquina, da qual dependia toda a sua produção, subitamente enfrentou um grave problema: essa máquina parou e não haviam técnicos na empresa para concertá-la. Foi então que contrataram um famoso engenheiro mecânico para pôr essa preciosa máquina para funcionar.

Como não sabia exatamente qual a origem do problema, nem como poderia concertá-lo, o engenheiro não disse de imediato o valor do seu trabalho. Faria isso após o concerto ser realizado.

Já chegando, deparou-se com um imenso painel repleto de milhares de parafusos que faziam a regulagem da máquina. Após ouvir atentamente o relato dos operários e de analisar por alguns minutos o painel, o engenheiro pediu uma chave-de-fenda e apertou 3/4 de volta um dos para fusos. Nesse instante, a máquina voltou a funcionar.

Após calorosos aplausos, o diretor-presidente da empresa perguntou quanto deveria pagar ao engenheiro, no que este respondeu: R$ 10.000,00.

Com os olhos arregalados, o diretor-presidente pergunto por que um valor tão alto se o engenheiro havia apenas apertado um parafuso.

A resposta do engenheiro foi categórica: "R$ 1,00 pelo aperto no parafuso e R$ 9.999,00 por saber qual parafuso apertar e quanto apertar".

Então. Você, desenvolvedor/programador, sabe o quanto cobrar pelo aperto no parafuso e por saber quanto e qual parafuso apertar?

Como vimos na estória acima, tão importante quanto realizar o trabalho, é saber como realizar o trabalho de forma que os melhores resultados sejam alcançados.

Quando o tema é precificação do trabalho de desenvolvimento/programação, é comum constarem como variáveis a serem consideradas apenas os materiais gastos, viagens para a sede do cliente, horas de trabalho dos programadores. Entretanto estas não são as únicas variáveis a serem consideradas.

Também devem ser consideradas questões como o suporte desejado pelo cliente quando a aplicação estiver em funcionamento, o treinamento necessário para utilização do sistema e a vida útil esperada e a necessidade de atualizações do sistema.

Um software, por mais simples que ele seja, é como um filho: vai exigir cuidados constantes, atualizações, correções e vinculará o seu desenvolvedor eternamente aos seus usuários. Portanto, o suporte ao cliente é uma variável fundamental para estabelecer o preço do trabalho realizado.

Questões como a maneira de se oferecer suporte (internet, telefone, viagens até o local, e-mail, etc) influenciam diretamente no valor do serviço.

O treinamento necessário também é outra questão que deve ser considerada na precificação do serviço de desenvolvimento. Quantas horas de treinamento serão necessárias? Onde ele será realizado? Para quantas pessoas? Todas estas questões devem ser corretamente dimensionadas para evitar que um projeto que espera-se que resulte em lucro, não se torne numa fonte de estresse e de prejuízo para o programador.

A vida útil do sistema é uma variável que poucos se preocupam, porém de grande utilidade, principalmente no momento da negociação com o cliente.

Entende-se por vida útil o tempo em que o sistema poderá ser utilizado pelo cliente sem se tornar obsoleto quanto as tecnologias utilizadas.

Quanto maior esse tempo, maior é a valorização que o programador obtém pelo seu trabalho, uma vez que o cliente não precisará gastar tão cedo com um novo sistema.

Também deve-se considerar a necessidade de atualizações constantes, já que isso significa mais custos no pós-implantação do sistema. Um software destinado a executar rotinas fiscais requer muito mais atualizações do que um software de workflow, por exemplo, em virtude das constantes mudanças na legislação fiscal, e isso deve ser considerado no momento da negociação de preço com o cliente.

Por fim, e não menos importante, a complexidade do sistema deve ser considerada também para a sua precificação, em virtude de que, quanto mais complexo for o software, mais complexa é a sua atualização, rastreamento e correção de erros e maior é o risco de que estes erros aconteçam.

Assim, ao negociar o valor a ser cobrado por determinado projeto, o programador deve considerar os seguintes fatores, além da sua margem de lucro:
  • Custos diretos, tais como horas trabalhadas (com base nos salários pagos àqueles diretamente envolvidos no projeto), material a ser utilizado, viagens, telefone e todos os demais gastos que podem ser quantificados e ter quantidades atribuídas aos projetos de acordo com a utilização de cada recurso por cada projeto.
  • Custos indiretos: eletricidade, aluguel, internet e todos os custos que não podem ter quantidades diretamente atribuídas a cada projeto, ou seja, sabemos que cada projeto ocupou um pouco de eletricidade, mas não sabemos quanto de eletricidade foi gasto com cada projeto, sendo necessário utilizar critérios de rateio para atribuição dos custos.
  • Custos pós-execução: são custos estimados de suporte, treinamento, periodicidade de atualizações e bônus pela vida útil do software.

Para maiores detalhes sobre a atribuição dos custos indiretos e de pós-execução, aconselho a leitura de trabalhos sobre formas de custeio, principalmente o Custeio ABC.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Precificação do trabalho de desenvolvimento
   3. Avaliação da técnica de precificação
   4. Conclusões
Outros artigos deste autor

SLiM: Simple Login Manager - Mini review

Utilizando PHP para validar dados passados pelo usuário

Funções da categoria Miscelânea do PHP

PHP5 Orientado a Objetos: Visibilidade, herança e extensões de classes

Relatórios com PHP e XSLT - Conceitos iniciais e utilização básica

Leitura recomendada

Dual-boot: instalando o Windows depois do Linux

Ubuntu Linux 20.04.1 LTS

obshutdown, Shutdown Menu para OpenBox

Linux, a pirataria de software e a desvalorização do desenvolvedor (parte 1)

Instalar o TeamViewer no Ubuntu/Debian

  
Comentários
[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 nicolo 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 EdDeAlmeida 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.


Contribuir com comentário