Nivelando Por Baixo

Pense em um litro de água. Você acha que o valor dessa quantidade de água é o mesmo no deserto do Sahara ao meio-dia solar que no topo do monte Everest ou junto de uma piscina em um hotel de luxo?

A água é a mesma, a quantidade é a mesma, mas o valor depende de onde está e quem a quer comprar, assim como depende de situações climatéricas do momento.

Desde do meu primeiro contato com a criação de software que o vejo ser vendido com base no número de horas necessárias para o executar, sem nunca tomar em conta o valor daquele software para aquele cliente. Será que é assim tão difícil?

Tudo bem que a criação de software é uma atividade mental que está limitada pelo tempo que demora a construi-lo. Tudo bem que esse processo consome energia e hardware, além de outros softwares e tempo do programador. Tudo isso é verdade. Mas isso forma simplesmente o custo do software não o preço.

O preço tem que refletir o custo – afinal ninguém trabalha por nada – incluindo o rateamento de custos da empresa não diretamente relacionados ao produto. Mas é só isso?

Não vou entrar no mérito de estimar o custo corretamente e sim no preço. Muitos jogam uma percentagem de lucro em cima do custo e formam um preço. Muitos jogam até uma margem de desconto futuro. Ou seja, um valor a mais que pode ser retirado se o cliente pedir desconto. E pronto. Essas são as técnicas.

Divertidamente as pessoas desconfiam de softwares baratos e não querem pagar os caros a menos que os seus parceiros ou concorrentes os comprem também. Por exemplo, hoje em dia ninguém precisa comprar o Office da Microsoft, basta usar o OpenOffice que é tão bom ou melhor. Mas como é gratuito, é visto com maus olhos pelas empresas. Afinal o que seria da TI das empresas sem licenças para gerenciar … ?

O ponto é que o cliente sempre pagará o valor justo pelo produto. E “justo” significa “equivalente ao valor”. Nunca importou ao cliente o custo real do produto. O valor é portanto o que interessa determinar. É essa a função do departamento de vendas e do vendedor, mas qualquer membro da empresa durante o desenvolvimento pode descobrir o valor do produto.

Muitos querem saber quanto devem cobrar por um software que fizeram. É claro que se deve saber quanto o software custou a construir (horas de trabalho, esforço mental do programador, tempo de pesquisa, etc…) mas em cima disso é necessário avaliar o valor – passo a redundância – do serviço que o software irá prover ao cliente. Esse serviço irá fazer o cliente economizar quanto? Irá alavancar o lucro em quando? É isso que o cliente vê como valor. Simplicidade e economia.

Alguns requisitos não funcionais como o layout a forma de uso, a paleta de cores podem valorizar o seu software. Possibilidade de configurar ou de alguma forma alterar o software (scripts, por exemplo) são também de mais-valia. Segurança é sempre uma mais-valia se for bem feito.

Aprenda a dar valor ao software durante apresentações, demonstrações e treinamentos. Aprenda a construir sistemas pró-ativos que ajudam e não sistema passivos que só burocratizam.

Aprenda a cobra o valor, e não o custo. Os outros vão cobrar o mesmo de você.

Amarrar o preço ao custo e o custo ao tempo é uma prática do século passado (literalmente). Por que temos que nivelar o  nosso produto dessa forma?

Não nivele por baixo. Dê valor ao seu trabalho.

Anúncios

10 opiniões sobre “Nivelando Por Baixo”

  1. Não acho que se possa cobrar pelo valor para o cliente, a não ser que seja um produto, e bem diferenciado. Quando você vai cobrar pelo desenvolvimento de um sistema customizado para um cliente, 1. você não sabe o valor que a aplicação tem para o negócio dele; 2. ELE provavelmente não sabe quanto valor exatamente a aplicação vai agregar ao negócio dele; 3. se você não cobrar por hora, você tem que ter uma estimativa precisa do custo que você vai ter para desenvolver o sistema (leia-se ‘waterfall’).

    Acho que para um desenvolvimento deste tipo, a cobrança por hora é a mais apropriada sim, mas ela deve ser justa. O meu valor/hora é diferente do seu, que é diferente de um estagiário de quinto semestre. Eu não vou cobrar mais barato só porque eu estou fazendo um sitezinho para o qual o cliente não dá muito valor. Da mesma forma, não acho que um cara ‘semi-competente’ deva manter o cliente de refém só porque o sistema que ele está fazendo é a base do negócio da empresa.

    Emprestando suas palavras, ‘não nivele por baixo, dê valor ao SEU trabalho’.

  2. Tetsuo, não entendi bem a sua posição. Por um lado diz que tem que dar valor ao seu trabalho, e por outro diz que vc não sabe o valor que o software terá para o cliente. Sendo que o software é o seu trabalho, dar valor ao trabalho é dar valor ao software. Se vc não sabe o valor do software para o cliente, não tem como dar valor ao seu trabalho.
    O valor do seu trabalho é quanto ele vale para o cliente.
    O custo do seu trabalho é quanto esforço você teve que fazer para o criar.

    Cobrar por hora implica que o preço é directamente proporcional ao tempo. Isso não é bom porque perco graus de liberdade importantes. O tempo aumenta com imprevistos que podem impedir de trabalhar mas isso não encaresse o trabalho. Cobrar por hora cria expectativas falsas. O que digo é que vc pode calcular por hora, mas não passar isso ao cliente. Vc estima que demora 3 meses e cobra 160h x 3 mas ao cliente apenas diz que o preço é X e entrega no dia Y. Ele não precisa saber como vc obteve esse valor. Quando ele pedir alterações vc faz a mesma coisa. Nunca revelando que o seu fator é a hora. No momento que fizer isso vc perde liberdade. Repare que se o cliente pedir desconto no preço isso não significa que você vai trabalhar menos, pois não ?. Então se vc cobra mais do que custou a fazer também não significa que vc trabalhou tudo isso.

    Tudo o que vc vende é um produto. Pode não ser um produto de “prateleira” mas é um produto. Para quem o usa não ha diferença para o de parteleira, para alguns é até melhor (mais valor).

    Você só pode dar valor ao seu trabalho se o comprador lhe reconhece valor. É isso que ele compra. Ele não compra o seu esforço ou seu conhecimento tecnico.

  3. “Se vc não sabe o valor do software para o cliente, não tem como dar valor ao seu trabalho.”

    Então, você só sabe o quanto vai cobrar depois de conhecer a empresa e descobrir o quanto o sistema vale para o negócio (sendo que, como eu já disse, provavelmente nem o cliente sabe exatamente o valor que a empresa vai ganhar ou economizar com o sistema implantado)? Ou vai perguntar ‘esse sistema é crítico?’, e se o cliente responder ‘sim’, o preço é X e se responder ‘não’ o preço é Y?

    Imagine a seguinte situação: você estimou que o trabalho demora 3 meses, cobra 160h x 3, pediu X para o cliente e prometeu entregar no dia Y. Só que como é que você fez essa estimativa? Se o sistema é simples, e você já fez dezenas de aplicações parecidas, seu chute provavelmente vai ser bem preciso, mas vai ser um chute. E se no meio do caminho, você descobrir que a aplicação é bem mais complexa do que você imaginava? Aumenta o custo, aumenta o prazo, e diz pro cliente que as coisas são assim mesmo?

    Pra fazer essa estimativa de maneira precisa (sem colocar uma margem de segurança lá pra cima, pra não correr o risco de ficar no prejuízo), só seguindo o bom e velho waterfall: levante tudo, especifique, faça o cliente assinar o contrato com sangue, e entregue o que foi pedido (não necessariamente o que o cliente realmente precisa). Bom, eu não pensava dessa forma antigamente não, mas depois de tanto tempo ouvindo essa ladainha das inúmeras vertentes de desenvolvimento ‘ágil’, eu acabei me convencendo. 🙂 hehe

    “O valor do seu trabalho é quanto ele vale para o cliente.”

    Sim, mas você vai baixar o seu preço só porque o sistema não tem muito valor pro cliente? Não importa se você é o maior desenvolvedor do universo, o cliente não vai pagar mais que 30% de X. Provavelmente você vai simplesmente recusar o trabalho, e eles que arrangem um ‘oreia’ qualquer que faça o serviço pela merreca.

    Eu penso assim: Se você possui muito mais experiência e conhecimento, e acredita que é 5 vezes mais produtivo que um desenvolvedor ‘da média’, porque cobrar o mesmo que ele cobraria?

    O que eu quero dizer é que não é questão de cobrar por hora ou por produto, ou por ‘valor agregado’, é valorizar o SEU trabalho e fazer o seu trabalho valer o custo que o cliente está pagando.

  4. “O que eu quero dizer é que não é questão de cobrar por hora ou por produto, ou por ‘valor agregado’, é valorizar o SEU trabalho e fazer o seu trabalho valer o custo que o cliente está pagando.”

    Continuo sem entender no que isso é diferente do que eu disse.

    E sim vc vai fazer um levantamento. O numero de iterações (1=waterfall, N=agil) é irrelevante já que isso acontece em todas. O risco é menor quanto menor for o “tamanho” da feature. Dai que o waterfall tenha mais risco porque incluir todas as features de uma so vez. O ponto é que : apenas o levantamento lhe vai permitir entender o que o cliente quer, porque quer, qual o proveito que ele vai tirar disso. De tudo isto decorre o valor.

    E sim, o valor é um fator subjetivo. O ponto é que:
    a) Valor é um fator para além do custo e prazo.
    b) O preço = custo + valor.
    c) preço =/= prazo.

    Qual é a diferença entre “valorizar o software” e “valorizar o SEU trabalho” ? É isto que não entendi.

  5. “O ponto é que : apenas o levantamento lhe vai permitir entender o que o cliente quer, porque quer, qual o proveito que ele vai tirar disso. De tudo isto decorre o valor.”

    “O preço = custo + valor.”

    Certo. Com isso, entendo que você vai dar o preço só depois de entender o que o cliente quer. Se for waterfall você vai levar quatro meses levantando requisitos pra só daí dar o preço do sistema pro cliente, e se for iterativo a cada duas semanas o preço vai mudar, porque o valor vai ser reavaliado?

    Mas realmente, não é possível… Eu devo estar entendendo alguma coisa errada. Deixa eu tentar dar um exemplo mais claro, pra ver se desfazemos este mal-entendido. Por favor, me diga onde eu não estou entendendo o seu ponto:

    Imagine que, um certo dia, o cliente vire pra você e diga: ‘- Para esta iteração, eu preciso que vocês façam relatórios para absolutamente tudo o que já foi feito, com número de linhas de código escritas, e quanto tempo vocês levaram para implementar cada funcionalidade.’ Você, obviamente, pergunta ‘- E para o que vai servir isso? A gente vai passar uma iteração inteira nisso!’, e ele responde ‘- Ah,é só para entregar para o Setor de Gerenciamento Corporativo, para ser arquivado. Norma da empresa.’ Isto não agrega valor algum para o cliente, é uma mera formalidade burocrática. Mas você tem que fazer, porque é uma exigência do cliente. Valor zero. Pela sua fórmula, isso vai sair mais barato para o cliente do que a função mais crítica do sistema?

  6. primeiro que tudo waterfall = agil com uma 1 única iteração. O preço vc pode fazer no principio por todo o sistema (independentemente de iterações) com ajustes. Afinal , todo o desenvolvimento passa por um planejamento. E nesse planejamento é dito quantas e quais iterações são feitas e tudo isso é baseado em um levantamento geral do sistema em que se falam das funcionalidades “grandes” e se deixam os detalhes para depois. Isso é normalmente chamado de Visão. É a visão que lhe dá informação sobre o porquê do sistema. Se a visão não lhe dá isso, ela não está completa. É para o cliente entrar em um novo mercado ? É para consolidar a sua posição no mercado ? É um software para uso interno ? etc.. cada um destes tem um valor diferente e um risco diferente.
    Então, não, não vou esperar até ao fim para saber o valor.
    A visão é levantada antes do preço ser feito. É uma espécie de “orçamento”.
    Algumas metodologias geram um documento de visão. Outras incluem cláusulas em contrato, outras fazem ambos.

    Vc entra na iteração sem saber previamente o que seria feito nela ? Se não, então vc já avaliou o prazo, custo , esforço e valor antes. Se sim, vc vai avaliar agora. A avaliação de valor é feita junto com a de esforço , custo e risco. Portanto é sempre feita antes de gerar o preço. Se vc gera o preço por iteração, então vc avalia essas coisas por iteração. No seu exemplo, supondo que avaliamos por iteração, o trabalho seria avaliado no momento.
    Nesse exemplo o valor é muito pequeno, mas o custo é muito grande. O preço é por consequencia grande (preço = custo + valor). Se o custo for pequeno (menor que o valor) porque vc usa ferramentas que automatizam tudo isso, então é o valor que ditará o preço. Basicamente tem que responder a “quanto o cliente está disposto a pagar por essa funcionalidade absurda? ”
    Por outro lado, a função mais critica do sistema pode tão simples quanto um algoritmo recursivo em um stack que demora 8 horas a construir. Vc não vai cobrar apenas 8 horas pelo coração do sistema. vai ? Esse é o meu ponto.
    Se sim, não deveria. o custo é pequeno, mas o valor é grande por isso o preço é grande tb. Pela tecnica de preço = custo, vc apenas cobra 8 horas.
    O ponto é que o cliente – desde que não conheça o esforço (aka vc não cobre por hora) – está disposto a pagar pelo que lhe interessa.
    Requisitos não funcionais são normalmente aqueles que têm mais margem. Por exemplo, vc usa o hibernate e o seu sistema é multi banco, vc cobra o mesmo, menos ou mais que um sistema que funciona com um banco só ?
    Pela formula preço= custo, vc cobra menos, porque usar o hibernate é mais facil (vamos supor que sim, para o argumento). usando preço = custo + valor vc cobra mais porque o sistema é mais genérico e isso é uma vantagem para o cliente. O ponto é que ele pode não entender que é uma vantagem e nesse caso vc não pode cobrar esse valor. Por isso que é o valor do ponto de vista do cliente e não do seu ponto de vista.

  7. Bom, queria fazer aqui uma colocação; uma coisa que vem a intervir sobre a questão de uma avaliação sobre custo e o que o cliente tem em mente sobre o que gastar em termos de desenvolvimento, é que existe uma parte enorme de requisitos sobre o departamento de publicidade perante o desenvolvimento do projeto que naturalmente desvirtua por completo o que realmente a tecnologia envolvida cabe ou não fazer.
    Acho que existe uma guerra entre departamentos que engessam a gestão do projeto, o analista de negócio e o cliente, deve procurar objetivos reais mas o projeto é e deve ser realista com o core da equipe, nem tudo pode ser OpenSource , parte que é proprietaria é requisito pratico para a garantia da infra ou da espinha que será contextualizada para dar uma margem de segurança muito dos produtos que não são ainda tão maduros exigem uma expertise cara de profissional tarimbados e nem sempre voce tem esses serviço a disposição por meio de consultorias, pois existe muita rotadividade, por parte do consultor e seus interesses.

  8. Caros,

    As discussões tomaram um rumo aparentemente acalourado, o que significa que o assunto é “quente”.

    Foram tantos posts longos que eu admito ter passado o olho por alguns deles, mas estranho ninguém ter falado em Pontos de Função para o cálculo do custo.

    Considerem:
    1. A métrica visa acabar com detalhes irrelevantes às estimativas de desenvolvimento e padronizar o mercado de estimativas
    2. O preço de seu ponto de função deveria refletir o seu VALOR, ou seja, considerar sua capacidade, acertividade, qualidade, competência, especialização, “fama”, custos de infra, custos de marketing, etc e tal.

    Assim, estou com Tetsuo no fato de que não se pode cobrar pelo valor agregado do Software. É utopia acreditar que os clientes não encontrariam um “jeitinho” de desvalorizar suas aplicações em busca de menores gastos.

    Estou com Taborda na questão de que devemos valorizar nosso trabalho, mas como? Considerando tudo que você achar relevante no preço de seu Ponto de Função. Se o cliente vai querer pagar pelo seu “valor”, são outros 500.

    Uma observação que faço é que estimativas em PFs não parecem se aplicar de forma adequada à metodologias ágeis, mas ai também são outros 500. O assunto aqui é Custo vs Valor.

    Sds,

    Ost.

  9. Do ponto de vista do cliente comprar um software é como comprar uma casa. Ele não se importa com as técnicas que foram usadas para a construir ou quanto tempo demorou para a construirem. O que ele quer é uma casa moderna, robusta que seja agradável e coerente com o fim a que se destina ( moradia, lazer, escritório, fábrica, etc… )
    Se a casa não está construída o cliente tenta dar pitaco de como seria melhor que a casa fosse. Isso é um pesadelo para o arquiteto e decorador, mas nem tanto para o engenheiro – afinal construir uma parede virada a sul ou a norte dá o mesmo trabalho.

    Se usarmos PF para dimensionar a obra (suponhamos que era possível). Isso nos diz o quanto o engenheiro e sua equipa têm que trabalhar e nada sobre o quando o arquiteto e o decorador têm que discutir com o cliente para que ele fique satisfeito com a casa. O trabalho do engenheiro e sua equipe é custo, o trabalho do arquiteto e sua equipe é valor. Mas esse valor não advém da técnica e sim de ouvir o cliente e em certos pontos, convencê-lo de que existem melhores opções à idéia que ele teve.

    Os requisitos funcionais servem para o engenheiro saber o que fazer, enquanto que os requisitos não-funcionais delimitam e influenciam em como esse trabalho tem que ser feito. Parede é parede, mas existem dezenas de propriedades da parede que a tornam melhor ou pior em certo ambiente. O mesmo acontece com o código. Código é código, mas código de aplicações standalone é bem diferente de aplicações distribuídas e destas de aplicações web. Código de jogos é diferente de código de aplicações comerciais. Mas é tudo código. Escrito por programadores.

    Agora, por muito bom que seja o trabalho do engenheiro o decorador e/ou o arquiteto podem simplesmente detonar o valor da casa. Em software, por muito robusto , eficiente e limpo que seja o código, o cliente irá rejeitá-lo se a interface gráfica não for simples, agradável e de acordo com o seu gosto.
    Isto é real. O design pode destruir o software. Também pode fazer parecê-lo muito melhor do que é. Afinal, julgar o livro pela capa é humano e natural.

    Tudo o que digo é que se você cobra os requisitos funcionais pelo tempo que domara a implementá-los com uma equipa que custa x/hora vc está perdendo a oportunidade de cobrar muito mais. Cobrar simplesmente pelo software, com todos os seus requisitos, funcionais e não, com seu design customizações , etc.. fará o cliente realmente sentir que o sistema foi feito À sua medida. Que as opiniões e interesses dele estavam primeiro e que você não é um fanfarrão que sabe codificar e sim um profissional que sabe criar software.

  10. Eu compreendi a realidade propostas pelos blogueiros e é um relato fiel ao que se conhece como situações comuns.

    Tentando demonstrar compreensão ao que o Sérgio tem dito e na verdade tem feito isso em uma série de posts, entendo que é uma transmissão de um idéia mais ampla sobre processos modernos de negociação. Esses processos modernos envolvem um fator educativo que se fosse empregado desde o início, seria um regulador social da prostituição tecnológica.

    Eu sei o quanto custa meu trabalho, mas sempre achava que trabalhava mais do que eu especificava e que o valor agregado do produto para o cliente era 100 vezes o valor do meu custo + margem de lucro. Ou seja, se eu tivesse noção de cobrar corretamente naquela época, não ficaria insatisfeito em dizer que criei 2 aplicações que juntas proporcionam o valor agregado para as empresas que as detém de 2 milhões de reais.

    Hoje eu sei que além da medição do custo eu preciso encontrar meios de valorizar o meu trabalho em função do benefício, economia, geração de receita possa proporcionar aos clientes. E para isso tem que ser feito um trabalho psicológico que desvincule o seu bom senso do valor real (do custo) do software com o valor a ser cobrado do cliente. Que ai concordo novamente com o Sérgio, é um valor de um “produto fechado” sem memória de cálculo.

    Jeff

Deixe uma Resposta

Please log in using one of these methods to post your comment:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

w

Connecting to %s