Valor de um sistema

No baixaki em sua grande maioria, os softwares share lá… não cobram o preço total, e sim somente um valor simbólico ao registro do programa…

Dica: pesquise a HORA trabalhada, e cobre pela tal que gastou para fazer o programa…

Abraços

Rapaz, na empresa onde trabalho, nós alugamos o sistema, assim todo mês o cliente paga para continuar tendo ele, e a cada três ou quatro meses o sistema expira e pede um serial novo, assim o cliente entra em contato via MSN ou telefone pedindo um novo codigo de liberação; Mas ai, porque disso? Para ter um controle melhor das pessoas que estão pagando direito. Bom, agora quanto a valor, eu sinceramente não posso afirmar ao certo, sei que em alguns casos é R$100,00, outros R$150,00, varia muito.

Forte Abraço!

Oi,
isso é um assunto um tanto quanto complicado…
o valor a ser cobrado por um sistema é muito relevante…

depende de varios fatores:

• Quantidade de pessoas (desenvolvedores).
• Quantidade de horas.
• Prazos, dias…
• Se foi trabalhado final de semana, feriados etc…
• Sistema adequado para o mercado
  entre outras…

Não leve em consideração o preço cobrados por outros,
realmente acho que um sistema assim não se cobra 150,00 nem 100,00 reais…

O que pode ser feito é estudado a forma de pagamente, em quantas vezes, ou se você vai
cobrar uma bolada a vista…ou até então como nosso amigo falou, cobrar uma taxa de “manutenção” por mês do seu sistema.

Hoje em dia é comum esse tipo de situação, vale cobrar um preço menor e lucrar com manutenção.
Faça um contrato com o pessoal que ira comprar seu produto, de tanto tempo e tantas manutenções, assim você pode ir melhorando a versão a cada mês.

Espero ter ajudado.
Tchauzin!

Kra eu faço o seguinte. Bom vou dar um exemplo

Valor para um projeto

Supondo q sua hora fosse R$30,00 a hora X a hora q
vc gasta por dia (02 horas) X os dias q gastou 20…

02 x 20

40 horas trabalhadas

40 x 30,00(Valor por hora)

= total do projeto R$ 1.200,00

Isso é so um exemplo para vc ter uma ideia…

Espero ter ajudado…

Veja que um software específico pra um cliente, é muito diferente de um software para consumo em massa, pois este tem seu valor diluído exatamente na tiragem que ele pode ter.
Um software específico pode custar por exemplo 5 mil, mas o mesmo se for pra ser de consumo em massa, talves seria vendido à 50 reais.

Existem várias métricas para mensuração do valor de um software, precisa ver qual se aplica melhor ao seu caso, leve em conta oq vc disse, que é seu primeiro sistema, ou seja, não tem experiência ainda, então não enfie a faca no seu cliente… rsrs

blza galera após analizar a ideia de vcs acho q o mais justo ficou pela hora trabalhada vou cobrar então 700 conto. vlw galerinha

Vcs acham que o valor de um sistema pode variar
se ele for desktop ou web?

Supondo que as horas de programação sejam as mesmas.

Pense em um contrato de escopo aberto.

IMHO vc deveria ler sobre Scrum. Um sistema é uma coleção de histórias de diferentes níveis de complexidade. A cada Sprint coisas novas podem surgir e vc por ir cobrando Por Sprint, sei la.

peczenyj:

Pense em um contrato de escopo aberto.

IMHO vc deveria ler sobre Scrum. Um sistema é uma coleção de histórias de diferentes níveis de complexidade. A cada Sprint coisas novas podem surgir e vc por ir cobrando Por Sprint, sei la.

Fora que um valor fixo e um contrato não tão bem elaborado pode tornar o desenvolvedor escravo do cliente.

Defina com seu cliente as funcionalidades desejadas, a complexidade de cada funcionalidade, quais são prioridade para o cliente. Desta maneira você pode negociar caso o cliente queira uma nova funcionalidade(troca de funcionalidades, valor apenas para a funcionalidade nova, etc).

Mas lembre de ir entregando o sistema a medida que ficar pronto, com o feedback sobre seu trabalho fica mais facil seguir em frente.
[

aleck:

peczenyj:

Pense em um contrato de escopo aberto.

IMHO vc deveria ler sobre Scrum. Um sistema é uma coleção de histórias de diferentes níveis de complexidade. A cada Sprint coisas novas podem surgir e vc por ir cobrando Por Sprint, sei la.

Fora que um valor fixo e um contrato não tão bem elaborado pode tornar o desenvolvedor escravo do cliente.

Para um contratos no “pessoal” (diferentemente de um “profissional”, onde leva-se em consideração até as marcas envolvidas), a melhor forma de trabalhar é por marcos mesmo (ou Sprints, como o peczenyj falou).
Feche os valores por entrega e esqueça o tamanho final do projeto…

Mas se vc não tem um cliente em vista para a ferramenta final, a maneira de calculo muda totalmente… neste caso, acho que vc deve contar:

• Quantidade de horas
• Seu valor hora
• O valor do intelectual utilizado (caso seja uma ferramenta unica no mercado, seja em tecnologia ou em utilidade)
• O valor da marca do seu software (inicialmente zero mas, a partir de mais vendfas este valor cresce)
• O quanto vc vai agregar ao cliente
• E o principal: Quando o cliente pode economizar com esta ferramenta

Lembre-se, o cliente ouve melhor o vc vai economizar X por mês do que a ferramenta vai custar Y!

Esse negócio de contrato pessoal não existe, cliente pagou e não recebeu vira rapidamente profissional, então é bom tomar cuidado.

Ps: Não estou discordando de você Rodrigo, apenas complementando

Melhorando a minha colocação, quando eu disse “contrato pessoal” eu estava tentando dizer um contrato sem chancela de um departamento juridico, com regras e mais regras… ou até mesmo um contrato com passagem juridica mas entre empresas sem expressão, ou em empresas onde ter uma ação juridica em seu nome não influencia em muita coisa, tanto faz pra ela arcar com o contrato ou não (acredite, existem empresas assim)

Um software não e um produto fechado que vc vende no mercado… em um software tem:

diversos algoritimos, diversas funcionalidades (use cases), a arquitetura, modelagem, componentes reutilizaveis… e porai vai… inicialmente vc tera que bolar a arquitetura ideal, a base de dados, a modelagem do sistema… e isto tem muitas horas utilizadas… e depois vc tera que bolar os use cases as funcionalidades… minha dica e para cada etapa veja mais ou menos a quantidade de horas que vc ira gastar (com sua experencia no desenvolvimento de projetos passados vc pode saber uma base), veja a complexibilidade… se for algo com media a alta complexibilidade vc tera que pesquisar a melhor maneira de fazer e isto lhe da mais tempo… ao final veja o tempo medio mais ou menos que vc demoraria a cada funcionalidade e some mais 20% a 25% de tempo em cima (afinal nem sempre as coisas ocorrem como planejadas)… dai sim feche pacotes com x, y e z use cases… mas sempre cobre por use case… pois projetos não são produtos fechados seus ciclo de vida e diferente que um produto fecado qualquer… projetos são como construções que serão construidas, serão mantidas e serão expandidas… e bem diferente que um produto que vc compra em uma loja… vc tenque pensar neste ponto… softwares vendidos no baixeaqui e etc… são softwares que são de uso compartilhado… milhares de pessoas vão comprar por isto tem um preço baixo que no final vai cobrir os custos das horas e do gasto utilizados (multiplique milhares por um valor de uns 50 pau…) então… um software especifico é algo bem mais caro do que um compartilhado…

Existem algumas divergências no seu tópico, Thiago…

As coisas não são bem assim… Vc pode desenvolver um produto para atacar uma determinada demanda de uma empresa OU montar um software para atender a uma demanda latente do mercado, ou seja UM PRODUTO FECHADO.
Vc quer um exemplo de SOFTWARE/PRODUTO?!? JForum, SAP, Cognus. Alguns deles dependem de customização, mas ai já é outra história, vamos focar no PRODUTO.

Aqui vc está correto! Mas lembre-se que se vc estiver fazendo um PRODUTO, vc deve ratiar esses custos na sua carteira de clientes. Como fazer isso?!? Dificil! Até hoje eu não consegui fazer uma formula para isso. O que eu faço, normalmente, é calcular o preço pelo valor agregado da ferramenta ao cliente, e não pelo tempo gasto (leia-se qualquer tipo de gasto que não somente o tempo) para o desenvolvimento. É um outro modelo de vendas, um outro cenário de vendas.

Esqueceu do principal aqui… O SEU LUCRO!!!

Mais uma vez, PRODUTOS são diferentes de ENCOMENDAS!!! Projeto é uma outra coisa… em ambos vc precisará de projetos. E projetos NECESSARIAMENTE tem INICIO E FIM, seja este inicio e fim chamados de iterações ou não. Então, quando vc faz uma iteração do RUP/XP/SCRUM por exemplo, vc tem um subprojeto dentro de um projeto maior, que tambem tem fim! E o exemplo utilizado tb foi muito ruim: construção de prédios x construção de sistemas é justamente o exemplo dado pela galera de metodologias ageis… onde vc realmente vê as diferenças…

Ao owner do tópico, precificar um produto é extremamente dificil e extremamente importante para a vida da sua empresa. Vc tem que achar um meio termo entre lucro e satisfação do cliente! E vc ainda depende de dados que não são dificeis de se conseguir de inicio, por exemplo para quantos clientes vc vai vender esse software e não para quantos clientes vc pretende vender esse software…