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.
Como o leitor pôde perceber nas colocações anteriores, existem diversos fatores que influenciam na decisão de preço de serviços de programação/desenvolvimento e, muitas vezes, o tempo despendido nas tarefas diretamente ligadas ao desenvolvimento não é o fator mais relevante numa negociação de preço com o cliente.
Existem casos onde o tempo e os demais custos ligados diretamente com a atividade de programar são irrelevantes quando comparados com a necessidade de suporte futuro, treinamento, atualizações e a própria vida útil do projeto.
Quanto maior a necessidade de suporte pelo cliente, maior a necessidade de treinamento e mais constantes forem as atualizações demandadas, maior tende a ser o custo contínuo do software e menores serão os lucros obtidos com ele.
Da mesma foram, quanto mais tempo o cliente poderá utilizar o software sem que este se torne obsoleto, mais valorizado é o trabalho de desenvolvimento.
Também, quanto maior a complexidade do sistema, maior é a valorização do profissional (tal como ocorreu na estória que contamos anteriormente).
A técnica de realizar um levantamento dos custos totais do projeto, acrescentar a margem de lucro desejada e apresentar um preço final hermético ao cliente não funciona mais à tempos no mercado competitivo atual.
Há muitos anos que é o mercado quem dita os preços dos bens e serviços e esse panorama não deve se alterar tão cedo. É aí que entra a questão de saber qual parafuso apertar e quanto ele deve ser apertado. O programador deve saber negociar com o cliente mostrando a ele que além de investir em um software, ele estará investindo também em uma rede de suporte que não o deixará à mercê das mudanças e dos problemas. O programador deve vender a imagem de um parceiro e não de um reles prestador de serviço.
Não é a quantidade de trabalho que deve ser valorizada, mas sim a qualidade e a complexidade dele e também toda a bagagem de conhecimento e experiência que o desenvolvedor irá colocar à disposição do seu cliente.
No momento da negociação de preço, o programador deve enfatizar os aspectos qualitativos e não os quantitativos do seu trabalho.
[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?
[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.