Estimando o custo de modificar o código de outra pessoa [fechado]


8

Eu sou relativamente novo no desenvolvimento da Web e ainda não precisei fornecer estimativas para muitos projetos grandes (meu último grande projeto foi pago por hora sem um prazo ou orçamento estrito).

Um cliente está me pedindo para fornecer uma estimativa de custo e tempo para fornecer uma infinidade de alterações em outro código de desenvolvedor de um site (back-end php / mysql).

Alguém pode fornecer alguns conselhos ou links sobre como proceder para analisar e estimar isso? O código é horrível (o site foi originalmente terceirizado para a Índia anos e anos atrás) e é difícil saber se vou de repente enfrentar obstáculos e explodir minhas estimativas na água.

Respostas:


4

Eu acho que você não deve citar um preço desde o início. Se alguém falar com você sobre um projeto, você deve trabalhar de graça o suficiente para descobrir o que o cliente deseja e quanto pode custar. Não mais ou menos que isso.

Dê a eles uma proposta, que pode ser extremamente breve, mas dê algo que descreva o que eles querem e o que você entregará. Você pode definir um intervalo, se quiser, e pode até dizer que essa é uma “estimativa de boa fé”, mas que o valor final será baseado no tempo gasto.

Da minha experiência como freelancer, há três etapas principais para fazer isso:

  1. peça 50% de entrada para começar a trabalhar

  2. solicite o pagamento final antes de entregar os arquivos

  3. peça um bloco de horas para o trabalho em andamento ou trabalho que provavelmente aparecerá com o tempo

Boa sorte!


3
4. Atenha-se às suas armas quando o cliente tentar recuar. 5. Esteja preparado para ir embora.
Tzerb

ask for 50% downpayment to begin work... hm, isso não é um pouco alto? Eu prefiro dizer 20%
šljaker 5/05

Penso que 50% do pagamento final seria o melhor valor para pedir ao cliente. Dessa forma, ele não ficará tentado a pedir a outro programador que faça seu trabalho (metade do dinheiro é muito para desperdiçar, não é? Enquanto uma pequena porcentagem é mais fácil de ser abandonada) e ele ficará preso com você até o fim.
Appoll

1

Peça uma taxa horária. Não espere muitas horas antes de faturar.


Sim. "Não deixe muitas horas se acumularem ..."
Dynamic

1

Vá ágil! Não avalie um monte, especialmente se você não tem muita experiência.

  • Converse com seu cliente e veja o que precisa ser implementado / entregue.
  • Para cada funcionalidade / unidade de trabalho, crie uma história do usuário (parte não técnica, escreva uma descrição adequada) e divida-a em uma ou mais subtarefas (parte técnica)
  • Estimar cada história de usuário

Lembre-se, estimar por sua definição está sempre errado, caso contrário, seria chamado de número! É muito importante que seu cliente entenda isso também!

Você deve fazer a entrega incremental. Diga ao cliente para priorizar as histórias do usuário e selecione aquelas a serem entregues na primeira iteração. Cada iteração deve durar 2 semanas ou menos, mas não mais que 3 semanas! Quando você terminar uma história do usuário (todas as suas subtarefas estão fechadas), notifique o cliente e peça que ele a verifique enquanto estiver trabalhando na próxima história do usuário.

Você não precisa cobrar antecipadamente, pode fazê-lo após cada iteração.

Feliz codificação!


1

Como você é novato na tecnologia relevante e não está familiarizado com a base de códigos de baixa qualidade existente com a qual precisará trabalhar, é provável que a estimativa possa variar até certo ponto nas duas direções. Mas informe o cliente sobre o último motivo :-P

Primeiro, liste a infinidade de alterações / recursos que seu cliente solicitou. Para cada requisito, faça uma pequena revisão de código e pesquise sobre como implementá-lo e testá-lo. Você deve investir esse tempo sem retorno antes de fazer uma estimativa.

Segundo, faça 3 colunas para estimativa - melhor caso (probabilidade de 25%), caso médio (50%), pior caso (75%). Pelas 2 razões mencionadas no primeiro parágrafo, você pode escolher a estimativa do pior caso. Você pode adicionar até 20% de tempo do buffer. Por exemplo, para um requisito específico, sua estimativa de melhor caso é 2 dias, o caso médio é 4 dias e o pior caso é 5 dias. Adicionando 20% de tempo de buffer, sua estimativa é de 6 dias.

Terceiro, não dê um ponto fixo de estimativa, mas um intervalo. Para o exemplo acima, você pode informar ao cliente que a estimativa é de 4 a 6 dias. Seu cliente pode insistir na estimativa de toda a lista de alterações. Nesse caso, você pode adicionar os mínimos e máximos de intervalos para todos os requisitos. Em seguida, forneça uma estimativa final no intervalo, digamos 5 a 6,5 ​​meses. Isso tem a seguinte vantagem: você pode exceder a estimativa para um requisito, mas pode concluir outro requisito anteriormente. No total, eles se cancelam e a estimativa final se mantém.

Quarto, ao concluir cada requisito do usuário e entregar de forma incremental, revise suas estimativas anteriores para cada requisito. Este é um processo contínuo e você deve ajustar / refinar a estimativa à medida que avança no projeto e sua experiência aumenta. Se você perceber que a diferença entre sua estimativa refinada e sua estimativa inicial está fora de controle, sente-se imediatamente com seu cliente e discuta o assunto.

Aprendi essas coisas com o livro "Estimativa de software: desmistificando a arte negra", de Steve McConnell. Sou grato a ele.


0

Você pode citar um total com base nas horas estimadas de trabalho, esclarecendo suas suposições e o fato de que qualquer tempo adicional necessário será adicionado. Dessa forma, se você for abaixo (improvável), sairá à frente.

Verifique se a qualidade do código existente é clara para o cliente. Se forem razoáveis, devem ser flexíveis, caso contrário, estejam preparados para ir embora.

Eu estava nessa situação quando comecei e, infelizmente, o Stack Exchange não existia naquele momento. Eu citei um preço fixo e tive que pagar a transação dois meses depois. Perdi o dinheiro e queimei uma ponte porque não consegui entregar.


0

Veja como indústrias similares fazem isso. Um arquiteto não faria uma estimativa precisa de uma extensão de garagem sem ter visto a propriedade primeiro.

Cobrar uma taxa de investigação pela primeira vez. Explique que o código está em um estado em que você não pode fornecer uma estimativa precisa sem examinar mais detalhadamente a situação atual. Certifique-se de que eles recebam algo no final, como uma marca de fé, alguma documentação que eles poderiam fornecer a outro desenvolvedor, se assim o desejassem, para evitar que eles tenham que fazer o mesmo trabalho.

E então, se for importante para você obter o trabalho de desenvolvimento real, diga-lhes que, se eles o procurarem para o trabalho de desenvolvimento real, você eliminará 50% ou mesmo 100% dessa cobrança da fatura final. Você não pode perder e as pessoas gostam de receber algo de graça.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.