Quantificando o preço do código fonte e do produto de software

Estou prestes a realizar um projeto. Isso requer que eu escreva um código e muito. O requisito do cliente é entregar todo o código-fonte no final do projeto.

Minha pergunta é: Como quantifico o preço do código fonte e do produto de software? Existe alguma métrica a seguir para determinar o preço? Como quantificaria o produto de software?

Informações adicionais: o aplicativo deve ser executado em qualquer lugar, em qualquer sistema operacional, incluindo tablets (iPad, guias Galaxy, etc.), smartphones (iPhone, telefones Android, etc.) e também na web. (Agora, imagine quanto código será esse) .

Você nunca pode saber um preço exato ou quase exato, pois depende de muitos fatores. Exemplo:

Estudo de caso

Você recebeu uma solicitação para um pequeno site baseado no WordPress. A única coisa que você precisa fazer: trabalhar com seu designer para criar gráficos atraentes, depois criar o próprio site (nada altamente técnico, apenas um conjunto de plugins para adicionar ao WordPress) e depois implantá-lo. O trabalho é realmente fácil, você citou US $ 600.

Seu designer criou o primeiro rascunho. O cliente explicou que não acha nada atraente. O mesmo ocorreu com o segundo, terceiro e quarto rascunho. Finalmente, após duas semanas de trabalho duro, o designer finalmente conseguiu o rascunho que foi aceito pelo cliente.

Mas, infelizmente, o designer foi atropelado por um ônibus e a única coisa que você conseguiu foram os JPEGs que ele enviou, mas não os PSDs originais, então você teve que começar de novo com um novo designer. Finalmente, você conseguiu os gráficos e começou seu trabalho.

Surpresa: você descobriu que o plug-in A é incompatível com o plug-in B, que o plug-in C não está funcionando conforme o esperado e que o plug-in D não pode ser instalado na versão mais recente do WordPress, enquanto o plug-in A pode ser instalado apenas nesta versão mais recente. Agora você precisa fazer muita codificação PHP manualmente, e como você é desenvolvedor de Python e nunca escreveu uma única linha de código em PHP, essa não é a tarefa mais fácil.

Enquanto isso, o cliente começa a enviar e-mails assustadores, perguntando por que o trabalho ainda não foi concluído, enquanto o prazo era uma semana atrás. Você finalmente termina a codificação PHP e tudo funciona perfeitamente bem em sua máquina. O cliente está feliz.

Em seguida, você começa a implantar o site no servidor de hospedagem para descobrir que não apenas o site falha com algum erro enigmático, mas também a empresa de hospedagem não suporta um recurso do PHP que você usou muito em seu código.

Por fim, depois de gastar mais de US $ 3.000 nesse projeto, você terá o site em funcionamento. O cliente está com raiva por causa dos prazos e porque "nada funciona como esperado com você". Você pediria $ 600? US $ 3.000?

Por que isso acontece?

O que ilustrei neste exemplo acontece com muito mais frequência do que você imagina. Por quê? Porque existem muitas variáveis ​​que você não pode prever e que aumentam o risco. Aqui, o risco foi aumentado por:

• As especificações pouco claras relacionadas ao design visual,
• A morte do designer,
• A incompatibilidade dos plug-ins que você selecionou,
• O mau suporte dos plug-ins que você selecionou,
• O fato de você não ter usado o PHP antes,
• A diferença entre o ambiente de desenvolvimento e o ambiente de produção e a ausência de preparação.

Pode-se resolver esses problemas com abordagens específicas:

• Requisitos funcionais e não funcionais claros e precisos,
• Gerenciamento de cenário de ônibus por ônibus (ou seja, o designer teve que compartilhar todos os documentos com você para que ele pudesse morrer a qualquer momento sem comprometer o projeto),
• Conhecimento prévio de ferramentas e idiomas que você precisa usar (o que exige muito trabalho),
• Estadiamento, testes intensivos, etc.

O único problema é que, com essa abordagem, você precisa informar ao cliente que ele pagaria pelo menos US $ 5.000 em primeiro lugar, já que na verdade é o preço dos requisitos, especificação, projeto, teste etc. Chances para esse cliente aceitar sua cotação é extremamente baixa.

Então não há nada a fazer?

Se você não pode fornecer um preço muito preciso, ainda pode fornecer uma aproximação, que leva em consideração todas as partes do trabalho a serem feitas separadamente, com um índice de risco sendo afetado em todas as partes. Quanto maior o risco previsível, maior o preço.

Você tem duas maneiras de fazer isso:

1. maneira Watefally

Se você trabalha em projetos que se encaixam no modelo Waterfall / V, isso pode funcionar:

1. Liste os requisitos funcionais e não funcionais de um projeto. Obtenha o documento assinado pelo cliente, da mesma forma que ele assina o contrato.

2. Depois de obter este documento, você já tem:

   • O preço que você já gastou reunindo os requisitos e criando este documento. Isso pode representar uma quantia importante, pois esses documentos podem variar de vinte a cem páginas para um projeto comum e podem ser centenas ou milhares de páginas para projetos grandes.

   • O entendimento claro, preciso e completo do produto que você é solicitado a fazer.

3. Acompanhe sua equipe passo a passo, analisando cada requisito e avaliando:

   • Um preço médio dessa parte do projeto,

   • Um preço máximo sem levar em conta o risco,

   • Um índice de risco.

   Todos os três serão levados em consideração para determinar o preço que você dará ao cliente.

4. Ative o risco que não depende de um requisito específico, mas sim da compatibilidade entre os requisitos ou o sistema em geral.

Prós da abordagem waterfally: o cliente obtém um preço bastante preciso, considerando que você tem uma visão muito clara do trabalho a realizar e dos riscos que podem surgir.

Contras da abordagem waterfally: você deve escrever um documento de 200 páginas antes de dar o preço. E se o cliente cancelar o projeto enquanto isso, ou for ao seu concorrente? Todo o processo também é extremamente pesado e os requisitos não podem ser alterados posteriormente.

2. maneira ágil

Se você trabalha em projetos que se encaixam no Scrum ou em outros modelos ágeis:

• ou não fornecem o preço geral do projeto, mas os preços de cada componente,
• ou você pode indicar um preço geral muito aproximado no início e, em seguida, fornecer um preço cada vez mais preciso.

Nos dois casos, você deve ter uma forte confiança entre você e o cliente ou ter excelentes pessoas no departamento de vendas. De outra forma,

• no primeiro caso, a pessoa acreditaria que você está roubando o dinheiro dela pedindo pequenas quantias repetidas vezes, e isso nunca terminará,

• no segundo caso, a pessoa não entenderia por que você está alterando seu preço o tempo todo, especialmente se o preço estiver subindo a maior parte do tempo.

Prós da abordagem ágil: o cliente pode cancelar a qualquer momento. Além disso, se ela cancelar nos estágios iniciais, ela ainda terá algum código fonte que funcione.

Contras da abordagem ágil: o preço é muito impreciso ou nem sequer é fornecido. A maioria dos clientes não gostaria de negociar com você se você não lhes disser quanto eles terão que pagar.

Não aceite um projeto quando não estiver claro o resultado e o dinheiro que o cliente precisa pagar. Eu apenas faço o seguinte:

• Crie etapas e pagamentos que o cliente precisa fazer.
• Quando a etapa anterior estiver concluída e totalmente paga e o cliente estiver feliz, vá para a próxima.

Para a forma de pagamento, escolha o pagamento com base nos recursos. Portanto, se o cliente tiver a oportunidade de descartar os recursos, se não puder pagar o projeto inteiro.

Ser pago com base em linhas de código (LOC) é uma coisa estúpida. Porque LOC não significa nada! Seja esperto, escreva um bom código e carregue com base no recurso !.

Boa sorte,

Não aceite um preço fixo para um compromisso aberto. Você será ferrado toda vez que fizer isso.