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.
Uma vez que foi estabelecido o preço a ser cobrado pelos serviços, faz-se necessária a avaliação dos resultados obtidos, durante e após a conclusão do projeto.
No processo de avaliação é importante que sejam confrontados todas as projeções com os valores efetivamente realizados.
Por exemplo, se foram estimadas em 200 horas de trabalho, é importante que sejam acompanhadas as horas trabalhadas. Se foram estimadas 5 viagens até o cliente, é importante que elas não ultrapassem esse limite.
Após concluída a fase de desenvolvimento e implantação é importante confrontar o suporte efetuado com o estimado nos custos, bem como as demais variáveis já mencionadas (treinamento, atualizações). Esse acompanhamento deve ser feito tanto em quantidades, quanto em valores gastos.
A avaliação é tão importante quanto a precificação pois é através dela que o programador poderá identificar falhas no seu processo de precificação.
Além disso, os dados colhidos durante a avaliação de determinado projeto poderão servir como referência para a precificação de novos projetos para o mesmo cliente.
[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.