Você deve cobrar horas gastas pelos clientes no caminho errado? [fechadas]

Aceitei um pequeno desafio de CSS para solucionar um cliente e serei pago a cada hora. Eu finalmente resolvi, demorou 5 horas, mas passei cerca de 25% do tempo na trilha errada, tentando uma solução CSS3 que só funcionava em navegadores recentes e finalmente descobrindo que não é possível fazer fallback via JS (como eu pensava originalmente). Devo cobrar ao cliente que 25%?

Mais detalhes: eu não forneci uma estimativa, gostei do desafio em si, então comecei a trabalhar antes de fazer uma estimativa (mas já trabalhei com ele antes, sei que ele não é uma daquelas pessoas que têm expectativas irreais ) Na pior das hipóteses, passarei 5 horas não remuneradas em um intrigante desafio de CSS. E darei a estimativa mais justa possível para nós dois, uma vez que já terei feito o trabalho. :)

Edit: Obrigado a todos, gostaria de poder aceitar mais de uma resposta! Acabei não cobrando por horas extras (cobri-o por três horas e meia), mas mencionei-os, para que ele saiba que eu trabalhei mais nisso do que cobri. Talvez seja por isso que ele aceitou imediatamente a "estimativa" (que nesse caso não era uma estimativa, daí as aspas).

Frequentemente, tenho situações desse tipo quando passo algumas horas fazendo alguma coisa e depois percebo que há uma solução de linha única mais fácil ou que minha primeira ideia foi muito ruim etc.

Em geral, nesses casos, faço a diferença entre três situações:

• A solução recém-descoberta não era óbvia e / ou um desenvolvedor médio provavelmente também estaria no caminho errado e / ou o caminho errado era um pré-requisito para encontrar a solução final. Nesse caso, cobro o cliente pelo tempo gasto na trilha errada.

• A solução recém-descoberta não era tão óbvia, mas provavelmente muitos desenvolvedores comuns seguiriam esse caminho diretamente. Em outras palavras, se eu pensasse melhor antes de começar a escrever código, provavelmente poderia encontrar a solução final diretamente, ou talvez não. Nesse caso, cobro o cliente, mas reduzo o preço pela metade ou uma porcentagem que parecer mais adequada.

• Obviamente, eu era muito estúpido, com muito sono, ou nem pensei antes de começar a escrever código, pois a solução final era extremamente fácil de encontrar. Nesse caso, mesmo que eu tenha passado dois dias no caminho errado, é minha responsabilidade e o cliente não precisa pagar por isso.

Eu não acho que você estava no caminho errado. Você codificou uma solução, testou a solução (kudos) e descobriu que ela não funcionava conforme o esperado. Você depurou a solução e, em seguida, fez sua correção, indo em uma direção diferente.

IMHO, esse não é o caminho errado. Isso é desenvolvimento regular de software.

Se eu fosse você, cobraria pelas 4 horas completas.

Na maioria dos programas que escrevemos, estamos escrevendo porque uma solução não está disponível de maneira imediata e fácil. Praticamente tudo o que fazemos envolve aprender algo novo. O cliente não estava pagando pelo produto. Ele estava pagando por você aprender a construir o produto e fornecer os resultados (e se ele próprio o considerasse um "desafio", estava esperando que você aprendesse alguma coisa). Veja "Waltzing with Bears", de Tom de Marco e Timothy Lister - "Se um projeto não tiver riscos, não faça".

Se você quiser devolver o cliente adequadamente, envie a ele sua solução, juntamente com detalhes de soluções que não funcionaram, para que ele possa repassá-las a qualquer outra equipe contratada e ajudá-los a levar menos tempo também.

Cabe a você negociar se ele pensa que está pagando demais. Certamente, eu esperaria que ele pagasse por qualquer aprendizado que não seja facilmente utilizável em outros lugares.

Às vezes, resolver um problema envolve eliminar as soluções abaixo do ideal de um conjunto de opções razoáveis. O processo de eliminação é uma das suas ferramentas de solução de problemas; o cliente está pagando por uma solução e deve esperar que você use quaisquer ferramentas à sua disposição.

Seria um cliente irracional que espera que você visualize instantaneamente a melhor solução - caminhando diretamente do briefing do projeto para o teclado, onde você emite um fluxo de código rápido e ideal, sem espaço de backspace. O que não quer dizer que não haja esses clientes. O cliente que telefonou no meio do projeto para verificar se estava pagando apenas pela "programação, não pela depuração". E é claro que existem clientes (ou chefes) para quem a programação é o ato físico de digitar.

Seu beco sem saída pode representar o dinheiro mais bem gasto do cliente: outro desenvolvedor pode não ter sido tão cuidadoso quanto você e entregou uma solução mais barata, mas menos compatível, que voltará no futuro.

essas perguntas me deixam louco ...

se um mecânico ou advogado passou algum tempo trabalhando no seu caso / problema, você apostou que seu @ $$ seria cobrado, mesmo que eles passassem algum tempo no caminho errado

programadores precisam começar a valorizar seu tempo mais

O que você fez foi perfeitamente normal. Fred Brooks discute esse fenômeno no capítulo "Planeje jogar fora", de seu livro seminal sobre engenharia de software "O mês do homem mítico".

Você estava trabalhando em um contrato de tempo e materiais; portanto, você deve cobrar do cliente dela o tempo todo que passou trabalhando no projeto. Cabe ao cliente determinar se ele recebeu valor suficiente para seu investimento.

Eu vejo da seguinte maneira: no final do dia, é sua decisão o que você cobra. Existem muitas variáveis, como quão feliz você quer o cliente, o relacionamento existente, suas habilidades de vendas, etc ... estamos todos familiarizados com eles. Em última análise, o que você está fornecendo ao cliente e o que ele realmente deseja é valor. Qual foi o valor que você deu ao cliente e qual a solução / entrega que você está fornecendo para ele?

Você pode levar 10 minutos para resolver um problema, mas você levou 10 anos para aprender a resolver esse problema. Isso merece ser considerado. Ao mesmo tempo, alguns de nós consideram a capacidade de aprender a compensação "no trabalho". Muitas vezes aprendo coisas que realmente estão na moeda do cliente. Considero uma forma de compensação não monetária.

Você também pode adicioná-lo à fatura e marcá-lo como um "desconto preferencial para o cliente" na fatura, não cobrar e criar boa vontade. Faço isso de vez em quando, o que faz o cliente se sentir bem.

Além disso, sua pergunta sobre se existem desenvolvedores que estão ganhando milhares de dólares por dia, a resposta é sim. Você também deve ser um deles com suas habilidades. Estou praticamente lá e não estou nem perto de estar na mesma liga que você em CSS.

Isso depende do contrato original.

Você disse que iria entregá-lo pronto e pronto para ir? Então é melhor você cobrar por todo o tempo gasto no desenvolvimento. Tudo isso!

Se você contratar um advogado para discutir um caso a seu favor, e ele o perder e perder, você ainda pagará a conta.

É assim que todas as outras profissões. Não há razão para que os programadores façam o contrário.

Se o cliente achar que pagou demais, não voltará para você. Mantê-los como clientes recorrentes é a única razão sadia para não cobrar todas as horas trabalhadas.

Se é um projeto que eu especificamente aceitei para que alguém me pagasse, enquanto eu me ensinava algumas novas tecnologias, eu costumo fazê-lo por menos do que normalmente faturaria o tempo. Por outro lado, você não pode fazer lances muito baixos, ou isso vai incomodar as coisas com esse cliente para sempre ("Ei, quando você fez aquela coisa muito legal, cobrou muito menos do que isso!") Caso contrário, eu não Não cobro o tempo em que eu estraguei tudo e acabou demorando muito.

Minha exceção a esta regra: se o motivo pelo qual o problema levou horas para ser resolvido é porque o cliente me enganou sobre algo que havia quebrado, cobrarei pela coisa toda.

Normalmente, eu não cobraria se fosse culpa minha e estava apenas brincando, mas não sou inteligente em negócios. Descobri que a maioria das pessoas inteligentes em negócios aplica essa filosofia de que os clientes estão pagando pelo seu tempo , e não apenas como resultado final. Há muitas vezes na minha carreira em que, em retrospecto, me arrependi de não ter pensado dessa maneira. Tudo o que pensei foi o resultado final como tendo valor, meu tempo não tendo sentido a menos que melhorasse o resultado final. No entanto, pode-se arrastar e desperdiçar muito tempo como resultado de os clientes mudarem de idéia, de colegas de trabalho causando bugs atribuídos a você e atrasando seu trabalho, por exemplo, e não apenas porque você precisava de um pouco mais de pesquisa antecipadamente para realmente saber o que você estava fazendo.

Quando você começa a dobrar as regras e a abrir exceções a que tipo de horário de trabalho deve ser pago e qual deve ser gratuito, pode ser fácil, eventualmente, ser aproveitado. O tempo é a métrica mais fácil de usar para pagamento. Isso o libera de muitas responsabilidades complexas, que podem parecer irresponsáveis, mas o protege de ser puxado e ter a irresponsabilidade do cliente levando a algum corte de pagamento.

No meu caso, seria inútil se eu não pudesse cobrar por seguir o caminho errado, pois geralmente trabalho em coisas como esta:

... tentando vencer um algoritmo de subdivisão Catmull-Clark de quase 40 anos que foi entrincheirado no setor e aprimorado repetidamente por empresas como Microsoft e Pixar, tentando fornecer resultados mais intuitivos e ao mesmo tempo ser tão competitivo quanto essas grandes empresas velocidade.

Em 95% do tempo, nesses casos, estou seguindo o caminho errado, voltando constantemente ao quadro branco após falha após falha após falha. Se eu não pudesse cobrar pelas minhas falhas, já estaria sem casa. Eu vejo mais da metade do meu trabalho como pesquisa, quando ninguém tentou essas coisas antes e não havia como encontrar a abordagem perfeita para resolver uma solução na primeira tentativa (talvez 20ª). Para mim, o objetivo nunca foi ter sucesso na primeira tentativa, mas falhar o mais rápido possível, com cada falha após falha fornecendo algumas pistas sobre qual seria a solução correta, que poderia realmente mudar o mundo.

Nem todo mundo pode estar trabalhando em uma área tão intensiva em P&D, onde os clientes querem e esperam que você domine as técnicas mais bem estabelecidas lá fora, simplesmente porque você está iniciando um novo projeto, mas para mim a programação nunca é muito rotineira, não importa quão é simples e estabelecida uma solução. Como você projeta e integra peças ainda será único, sempre alguma forma de arte em si produzindo prós e contras exclusivos, não mecânicos, nem perfeitamente científicos; caso contrário, os robôs poderiam fazê-lo. Acho que, inevitavelmente, sempre teremos que cobrar por percorrer algumas rotas erradas aqui e ali, caso contrário, apenas poderíamos lucrar com o trabalho mais rotineiro que já fizemos centenas de vezes, para o qual aplicamos exatamente o mesmo solução cada vez; nesse caso, estaríamos cobrando por pressionar o botão copiar e colar.

Imprevisibilidade

Outra coisa é que a programação é sempre difícil, imprevisível, nunca muito rotineira. Não é como a entrega de pizza, que é rotineira, onde tudo, exceto algo como um acidente de carro, pode ser contabilizado (infelizmente uma vez trabalhei com um chefe que equipara estimativas de programador a estimativas de entrega de pizza e achava que o único trabalho que estávamos realmente fazendo era digitar) . É um aprendizado no site, sempre - não consigo imaginar que ele se torne totalmente rotineiro, a menos que alguém realmente me pague repetidamente para implementar como uma busca rápida repetidamente. Sempre haverá alguma experimentação e aprendizado acontecendo lá, e desde que não seja excessivo, não há necessidade de se sentir culpado por isso.

Sempre sonhei em me tornar agricultor ou algo assim, para poder encontrar muito mais movimentos rotineiros em meu trabalho, nem sempre forçando os limites do meu conhecimento existente. Em vez disso, tento compensar, tornando minha vida fora do trabalho a mais rotineira e mundana possível, acrescentando alguma previsibilidade e movimentos rotineiros em algum lugar por uma questão de sanidade, o que me torna um tédio entre as pessoas que desejam encontrar emoção em suas vidas fora de trabalho - acho bastante o suficiente no trabalho.

Ele está falando sobre aprender coisas novas, não trabalhando na solução errada.

Trabalhar na solução errada é aprender coisas novas, não é? Você sabia que era uma solução errada quando começou, ou continuou trabalhando nela mesmo depois de saber que era irremediavelmente errado? Esperemos que não o último. Muitas vezes, o processo de aprendizado ocorre através de erros. É o melhor professor. A estratégia mais eficaz que encontrei é apenas cometer erros o mais rápido possível, descobrir que eles são, de fato, erros de design o mais rápido possível antes de comprometermos tudo com eles e nos casarmos com essas soluções, pois a única constante que posso contar e prever com quase 100% de certeza é que serão cometidos erros. Eles só são caros se forem descobertos muito tarde.

Realmente depende de como você propôs o projeto e de como o projeto é faturável.

Por exemplo, se for um contrato baseado em entregas, todas as horas, independentemente, devem ser rastreadas em direção ao projeto, mesmo que seja para aprender algo novo.

Se for contrato baseado em tempo e materiais, você precisará ser muito mais sensível a isso. Por exemplo, se você estiver dentro do contexto do problema e tiver problemas, ele deverá ser cobrado. Um exemplo disso é se você estiver aprendendo uma API herdada ou um pouco de código e tentando fazê-lo funcionar com seu código.

No entanto, se você for desviado tentando fazer algo ou apenas quiser aprender como fazê-lo de uma nova maneira, cobrarei apenas o tempo que levou para implementar a solução real e não o tempo que levei para aprendê-lo.

Eu discordo de Lunivore, que eles nos pagam para aprender coisas. Eles nos pagam por causa de nossa experiência e que na maioria das vezes devemos saber como fazê-lo. Eles nos pagam pela implementação.

Em suma, se sua estimativa inicial não incluía o tempo necessário para aprender o problema, provavelmente você não deveria cobrá-lo. Giz como uma experiência de aprendizado e saiba da próxima vez que você não terá esse atraso.

Edit: Como você especificou mais tarde que não havia estimativa, eu certamente não incluiria esse tempo se você acha que esse será um cliente recorrente. Eu também sempre forneceria uma estimativa antecipada no futuro.

Para contornar isso, imagino o que acho que seria um caso ruim e cito com base em uma hora no que acho que deve levar com uma citação máxima definida pelo caso "ruim". Dessa forma, nós dois somos vencedores.