Cobrança por hora / projeto [fechado]


9

Isso está relacionado a uma pergunta que fiz anteriormente - /software/34023/how-to-end-a-relationship-with-a-client-without-pissing-them-off

Quais são as suas obrigações ao cobrar por hora versus cobrar por projeto? Se você concorda em participar de um projeto, faça uma estimativa aproximada de que pode levar 10 dias para você trabalhar e cobrar £ X por hora - você é obrigado a trabalhar de graça depois que esses 10 dias terminarem e você ainda não conseguiu concluir seu projeto devido a problemas imprevistos? E se você entregou o projeto, mas foram encontrados erros - você deve corrigi-los gratuitamente se os 10 dias terminarem ou cobrar do cliente?

Além disso, para o projeto acima, qual deve ser o resultado quando você iniciar o projeto, mas após os 10 dias, por qualquer motivo, terá que desistir e informar ao cliente que não pode mais fazê-lo? Sei que isso não ajuda a construir sua reputação e relacionamento com o cliente, mas você é obrigado a devolver o dinheiro pago ou apenas entrega o código-fonte meio / quase concluído e ajuda-os a encontrar outra pessoa para concluí-lo?

A razão pela qual estou fazendo as perguntas acima é porque sou muito novo no freelancer e gostaria de saber como lidar com as situações acima, se elas surgirem. Obrigado!

Respostas:


9

Se você concorda em participar de um projeto ... trabalha e cobra £ X por hora - você é obrigado a trabalhar de graça após esses 10 dias e ainda não conseguiu concluir seu projeto devido a problemas imprevistos?

Não. £ X por hora é £ X por hora. Claramente, você nunca fez trabalhos complexos em sua casa ou barco.

Incapacidade de estimar não significa nada. Nada.

£ X por hora é £ X por hora. Até que o trabalho esteja concluído ou o cliente diga "você está demitido". (ou "você está demitido". Eu sou um ianque, então não sei o que eles dizem no Reino Unido.)

E se você entregou o projeto, mas foram encontrados erros - você deve corrigi-los gratuitamente se os 10 dias terminarem ou cobrar do cliente?

Depende do bug. Você deve fazer a análise da causa raiz. Especificação ruim (ou incompleta) é principalmente o problema deles. Rugas técnicas imprevistas são o par para o curso - elas pagam. Erros de codificação idiotas são o seu problema.

você tem que desistir e dizer ao seu cliente que você não pode mais fazer isso?

Opa. Isso não é profissional. Se você tiver que desistir, realmente cometeu um erro terrível.

Sei que isso não ajuda a construir sua reputação e relacionamento com o cliente, mas você é obrigado a devolver o dinheiro pago ou apenas entrega o código-fonte meio / quase concluído e ajuda-os a encontrar outra pessoa para concluí-lo?

Suspiro. Neste ponto, você se comportou tão mal que nada importa. Você realmente deve encontrar outra carreira se não conseguir cumprir seus contratos. A sério. Repense sua vida.

O software pela metade não vale nada. Ninguém "completará". Eles explicam que você é um idiota (porque é) jogue seu código fora e comece novamente do zero.

Você precisa fazer o seguinte.

  1. Reduza os requisitos para algo final, entregável e utilizável.

  2. Crie essa coisa final, entregável e utilizável. Mesmo que não seja o grande esquema original.

  3. Cobrar por essa coisa entregável e utilizável.

  4. Transição da lista de pendências de coisas não entregues para outra pessoa.

Código que não pode ser usado é inútil. Na verdade, é um custo.

Você e seu cliente perderão tempo tentando "fazer a transição" do código incompleto para outra pessoa. Ênfase no desperdício . É mais fácil para a maioria das pessoas começar do zero do que começar pela metade.


Por que o cliente deve pagar por "rugas técnicas imprevistas"? Eles não estão apenas pagando pelo código, estão pagando pelo conhecimento técnico - a menos que a especificação deles tenha mudado, você deveria saber o que estava por vir.
Nicole

LOL BOAT = Traga mais mil.
Job

No que diz respeito às "rugas técnicas". É verdade que essas coisas são paritárias para o curso - e é apenas o trabalho que precisa ser feito - elas certamente pagam. No entanto, não deve ser transparente para eles. Considere a complexidade do projeto com antecedência e tente explicar o risco potencial de erros grandes. Se você é o desenvolvedor único, é mais fácil fazer isso, basta preencher suas estimativas em áreas onde você não tem certeza da solução. As estimativas devem incluir o tempo de depuração. A capacidade de acolchoar adequadamente vem com a experiência.
eddiemoya

6

Quais são as suas obrigações ao cobrar por hora versus cobrar por projeto?

Essencialmente o mesmo. Seja profissional.

Se você concorda em participar de um projeto, faça uma estimativa aproximada de que pode levar 10 dias para você trabalhar e cobrar £ X por hora - você é obrigado a trabalhar de graça depois que esses 10 dias terminarem e você ainda não conseguiu concluir seu projeto devido a problemas imprevistos?

Não - desde que durem aproximadamente 10 dias, você estará bem. Eu definiria aproximadamente 10 dias como algo entre 50 - 120 horas nas extremidades. Qualquer coisa acima de 120 horas (uma superação de 50%) está muito além do óbvio.

Embora "questões imprevistas" deixem muita imprecisão. Profissionais experientes antecipam muito mais problemas do que novos desenvolvedores. No entanto, se o cliente sabe que você é um novo desenvolvedor (e sabe que está obtendo um desconto significativo por causa disso), então há uma margem de manobra aqui.

E se você entregou o projeto, mas foram encontrados erros - você deve corrigi-los gratuitamente se os 10 dias terminarem ou cobrar do cliente?

Insetos? Sim - você deve corrigi-los gratuitamente. Você não está sendo pago por 10 dias para produzir código quebrado.

Agora, novamente, "bug" é um pouco vago. Existem erros de interrupção de exibição (como, o programa não é executado - obviamente, sua culpa) e erros de maiúsculas e minúsculas (o programa trunca o texto no Windows localizado na Turquia com o IME chinês ativado - não é realmente razoável). A maioria cai em algum lugar no meio, mas o ônus da prova está em você.

Há também erros de especificação - estes são os mais difíceis. Você terá que usar seu julgamento para saber se deveria ter razoavelmente antecipado, questionado ou implícito a alteração nas especificações. Mais uma vez, eu colocaria o ônus da prova em você.

Para um projeto de 10 dias (80 horas) com um desenvolvedor ecológico, outras 10 a 15 horas de correções de bugs não seriam demais. Qualquer coisa além disso, tentaria calcular o pagamento - embora provavelmente fizesse mais 5 a 10 horas de graça antes de demitir o cliente.

Além disso, para o projeto acima, qual deve ser o resultado quando você iniciar o projeto, mas após os 10 dias, por qualquer motivo, terá que desistir e informar ao cliente que não pode mais fazê-lo? Sei que isso não ajuda a construir sua reputação e relacionamento com o cliente, mas você é obrigado a devolver o dinheiro pago ou apenas entrega o código-fonte meio / quase concluído e ajuda-os a encontrar outra pessoa para concluí-lo?

Você devolve o dinheiro. Se você não pode terminar o projeto, é provável que não possa julgar pela metade. Se o cliente o contratou, é ainda mais provável que ele não consiga julgar pela metade. Se você puder encontrar alguém para finalizá-lo, poderá subcontratar com eles - a diferença entre o que eles cobram e o que você já fez é o seu lucro (ou perda).

No final, geralmente é melhor curvar-se ao cliente e classificá-lo como uma lição aprendida. Depois de um tempo, você poderá identificar os "clientes problemáticos" e evitá-los (ou aumentar a taxa) no início. Você também aprenderá a estimar um pouco melhor, a acrescentar custos de correção de bugs nos preços, etc.

Como desenvolvedor de estudantes, você tem alguma margem de manobra. É provável que ninguém processe você pela multa que você cobrou por um projeto de 10 dias. Você nunca mais receberá negócios desse cliente (ou de seus amigos) - mas, como eles contrataram um desenvolvedor de estudantes, é provável que eles apenas desejem mão de obra barata e não entendam o que realmente custa contratar um bom desenvolvedor de qualquer maneira. Você não está perdendo muito no futuro, exceto dores de cabeça - embora à custa de uma consciência limpa.

Meu conselho? Basta terminar - você se sentirá melhor, o cliente se sentirá melhor e você será um desenvolvedor e empresário melhor. Não é como se valesse um ano de trabalho - e você tem todos os seus amigos no Stackoverflow e no Stackexchange para ajudar. ;)


3

O que você está descrevendo é apenas "valor fixo ou menos". Isso beneficia apenas o cliente; portanto, se você estiver fazendo o lance, não tenho idéia do porquê de trabalhar dessa maneira.

  • Taxa horária - Uma taxa horária pode ser usada quando o cliente sabe que ainda não se decidiu sobre algumas coisas e concorda que o projeto é um pouco aberto - mas isso deve ser acordado com antecedência .

  • Taxa fixa - use se o cliente souber exatamente o que deseja. Se o fizerem, mas você não poderá fazer lances para um valor fixo, ainda não tem nenhum negócio fazendo lances. Não faça o cliente pagar por sua inexperiência.

Se você seguir isso, não acabará em uma situação em que não sabe o que fazer. Se você tiver que desistir, discuta com o cliente e trate como uma demissão ou dissolução da parceria. Reembolse todo o dinheiro e não entregue nada ou ofereça o projeto parcial em troca de pagamento parcial.

É tentador aplicar a taxa horária sempre que houver alguma incerteza, mas ela deve ser usada quando o cliente é insosso . Se você tiver experiência, mas ainda tiver perguntas técnicas não respondidas significativas, seja aberto com isso com o cliente.

E, contrate um contrato, ou é apenas uma questão de tempo antes de encontrar problemas.


0

Não sou advogado, mas a resposta para ambas as situações depende do que você concordou contratualmente com o cliente. Vi na sua pergunta anterior que você estava trabalhando sem um contrato que parece bastante perigoso pelas razões exatas que levantou aqui. Nenhum contrato escrito certamente não significa nenhuma obrigação vinculativa. É bom ter esse tipo de coisa resolvido antes de você iniciar seu relacionamento de trabalho, para que, se surgirem problemas, eles possam ser resolvidos de maneira profissional e amigável.


Esse é um bom ponto e suponho uma lição aprendida aqui. Mas e se eu não tiver assinado nenhum contrato, como na minha situação atual?
thesam18888

Você ainda tem acordos verbais que possa ter feito. O problema é que é um pouco "ele disse, ela disse" e isso pode levar a litígios, a menos que você e seu cliente possam resolver as coisas e alcançar um compromisso razoável.
Drew

0

Afinal, por razões legais, este é um negócio de serviços e você vive e morre por referências. Só é preciso um ruim para dar a você um péssimo representante. Só posso levar um cliente realmente satisfeito para lhe dar muitos outros trabalhos. Portanto, aplique a regra de ouro, trate seu cliente como gostaria de ser tratado, dentro do razoável. As pessoas lembram e valorizam as pessoas que vão um pouco além do seu "dever".

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.