Devriez-vous facturer aux clients les heures passées sur la mauvaise voie? [fermé]

J'ai relevé un petit défi CSS à résoudre pour un client et je vais être payé au taux horaire. Je l'ai finalement résolu, cela a pris 5 heures mais j'ai passé environ 25% du temps sur la mauvaise piste, essayant une solution CSS3 qui ne fonctionnait que dans les navigateurs récents et découvrant finalement qu'aucune solution de repli n'est possible via JS (comme je le pensais à l'origine). Dois-je facturer au client ces 25%?

Plus de détails: je n'ai pas fourni d'estimation, j'ai aimé le défi en soi, alors j'ai commencé à travailler dessus avant de donner une estimation (mais j'ai déjà travaillé avec lui, donc je sais qu'il n'est pas une de ces personnes qui ont des attentes irréalistes ). Au pire, j'aurai passé 5 heures non rémunérées sur un défi CSS intrigant. Et je donnerai l'estimation la plus juste possible pour nous deux, puisque j'aurai déjà fait le travail. :)

Edit: Merci à tous, j'aimerais pouvoir accepter plus d'une réponse! J'ai fini par ne pas le facturer pour les heures supplémentaires (je l'ai facturé 3 ans et demi), mais je les ai mentionnés, afin qu'il sache que j'y ai travaillé plus que je ne l'ai facturé. C'est peut-être pour cela qu'il a immédiatement accepté le "devis" (qui dans ce cas n'était pas un devis, d'où les devis).

J'ai souvent de telles situations lorsque je passe quelques heures à faire quelque chose, puis à remarquer qu'il existe une solution plus simple en ligne, ou que ma première idée était trop mauvaise, etc.

En général, dans ces cas, je fais la différence entre trois situations:

• La solution nouvellement découverte n'était pas évidente et / ou un développeur moyen serait probablement sur la mauvaise voie aussi et / ou la mauvaise piste était une condition préalable pour trouver la solution finale. Dans ce cas, je facture au client le temps passé sur la mauvaise piste.

• La solution récemment découverte n'était pas si évidente, mais probablement beaucoup de développeurs moyens iraient directement dans ce sens. En d'autres termes, si je réfléchissais mieux avant de commencer à écrire du code, je pourrais probablement trouver la solution finale directement, ou peut-être pas. Dans ce cas, je facture le client, mais je réduis le prix de moitié ou d'un pourcentage qui me semble le plus adéquat.

• Évidemment, j'étais trop stupide, trop somnolent, ou pas du tout pensé avant de commencer à écrire du code, car la solution finale était extrêmement facile à trouver. Dans ce cas, même si j'ai passé deux jours sur la mauvaise voie, c'est ma propre responsabilité et le client n'a pas à payer pour cela.

Je ne pense pas que vous étiez sur la mauvaise voie. Vous avez codé une solution, testé la solution (bravo) et constaté qu'elle ne fonctionnait pas comme prévu. Vous avez débogué la solution, puis apporté votre correctif en allant dans une direction différente.

À mon humble avis, ce n'est pas la mauvaise piste. C'est un développement logiciel régulier.

Si j'étais vous, je facturerais les 4 heures complètes.

La plupart des programmes que nous écrivons, nous écrivons parce qu'une solution n'est pas immédiatement, facilement disponible. Presque tout ce que nous faisons implique d'apprendre quelque chose de nouveau. Le client ne vous payait pas pour le produit. Il vous payait pour apprendre à construire le produit et vous donner les résultats (et s'il appelait cela un "défi" lui-même, il s'attendait à ce que vous appreniez quelque chose). Voir "Valse avec des ours" de Tom de Marco et Timothy Lister - "Si un projet ne comporte aucun risque, ne le faites pas".

Si vous souhaitez rembourser le client correctement, envoyez-lui votre solution avec les détails des solutions qui n'ont pas fonctionné, afin qu'il puisse les transmettre à tout autre personnel qu'il embauche et les aider à prendre moins de temps également.

C'est à vous de négocier s'il pense qu'il paie trop. Certes, je m'attendrais à ce qu'il paie pour tout apprentissage qui n'est pas facilement utilisable ailleurs.

Parfois, la résolution d'un problème implique d'éliminer les solutions sous-optimales d'un ensemble d'options raisonnables. Le processus d'élimination est l'un de vos outils de résolution de problèmes; le client vous paie pour une solution et doit s'attendre à ce que vous utilisiez les outils à votre disposition.

Ce serait un client déraisonnable qui s'attend à ce que vous envisagiez instantanément la meilleure solution - en passant directement du briefing de projet à votre clavier, où vous émettez un flux de code rapide et optimal sans retour arrière. Ce qui ne veut pas dire qu'il n'y a pas de tels clients. J'ai eu le client qui a appelé au milieu du projet pour vérifier qu'il ne payait en fait que pour "la programmation, pas le débogage". Et bien sûr, il y a les clients (ou patrons) pour qui la programmation est l'acte physique de taper.

Votre allée aveugle pourrait représenter le meilleur argent dépensé par le client: un autre développeur n'a peut-être pas été aussi minutieux que vous et a fourni une solution moins chère mais moins compatible qui mordrait à l'avenir.

ces questions me rendent fou ...

si un mécanicien ou un avocat a passé du temps à travailler sur votre cas / problème, vous pariez votre @ $$ que vous seriez facturé, même s'il a passé du temps sur la mauvaise voie

les programmeurs doivent commencer à valoriser leur temps plus

Ce que vous avez fait était parfaitement normal. Fred Brooks discute de ce phénomène dans le chapitre "Plan de jeter un loin" de son livre séminal sur l'ingénierie logicielle "The Mythical Man-Month".

Vous travailliez sur un contrat de temps et de matériaux; par conséquent, vous devez facturer à son client tout le temps que vous avez passé à travailler sur le projet. Il appartient au client de déterminer s'il a reçu suffisamment de valeur pour son investissement.

Je le vois de cette façon: à la fin de la journée, c'est votre appel ce que vous facturez. Il existe de nombreuses variables telles que la satisfaction que vous souhaitez pour le client, la relation existante, vos compétences en vente, etc ... nous les connaissons tous. Ce que vous fournissez au client, et ce qu'il veut vraiment, c'est de la valeur. Quelle valeur avez-vous apportée au client et quelle est la solution / livrable que vous lui offrez?

Cela peut vous prendre 10 minutes pour résoudre un problème, mais il vous a fallu 10 ans pour apprendre à résoudre ce problème. Cela mérite d'être pris en considération. Dans le même temps, certains d’entre nous envisagent la possibilité d’apprendre une rémunération «sur le tas». J'apprends souvent des choses qui sont vraiment à la charge du client, je considère que c'est une forme de compensation non monétaire.

Vous pouvez également l'ajouter à la facture, puis la marquer comme "remise client privilégié" sur la facture, ne pas facturer et créer de la bonne volonté. Je le fais de temps en temps, ce qui fait que le client se sent bien.

Aussi, votre question de savoir s'il y a des développeurs qui font des milliers de dollars par jour, la réponse est oui. Vous devriez aussi être l'un d'eux avec vos compétences. Je suis pratiquement là, et je suis loin d'être dans la même ligue avec vous en CSS.

Cela dépend de l'accord initial.

Avez-vous dit que vous alliez le livrer prêt et prêt à partir? Ensuite, vous feriez mieux de charger tout le temps que vous avez passé à le développer. Tout!

Si vous engagez un avocat pour plaider une cause pour vous, et qu'ils la bâclent et perdent pour vous, vous payez toujours leur facture.

C'est ainsi que font toutes les autres professions. Il n'y a aucune raison pour que les programmeurs fassent autrement.

Si le client pense qu'il a trop payé, il ne reviendra pas vers vous. Les garder en tant que client régulier est la seule raison valable de ne pas facturer toutes les heures travaillées.

Si c'est un projet que j'ai pris spécifiquement pour que quelqu'un me paie, alors que je me suis enseigné une nouvelle technologie, j'ai tendance à le faire pour moins que ce que je facturerais normalement. D'un autre côté, vous ne pouvez pas enchérir trop bas, ou cela fera des histoires étranges avec ce client pour toujours ("Hé, quand vous avez fait cette chose vraiment cool, vous avez facturé bien moins que ça!") Sinon, je ne ' t facture pour le temps où j'ai foiré et ça a fini par prendre trop de temps.

Mon exception à cette règle: si la raison pour laquelle le problème a pris des heures à résoudre est que le client m'a fait connaitre quelque chose qu'il avait cassé, je facturerai le tout.

Normalement, je ne facturerais pas si c'était manifestement de ma faute et je ne faisais que me branler, mais je ne suis pas du tout intelligent pour les affaires. J'ai constaté que la plupart des gens intelligents en affaires appliquent cette philosophie que les clients paient pour leur temps , et pas seulement un résultat final. Il y a de nombreuses fois dans ma carrière où, rétrospectivement, j'ai regretté de ne pas avoir pensé de cette façon. Tout ce à quoi je pensais était que le résultat final valait la peine, mon temps étant vide de sens à moins qu'il n'améliore le résultat final. Pourtant, on pourrait être traîné et perdre beaucoup de temps à cause du changement d'avis des clients, des collègues qui causent des bogues qui vous sont attribués et retardent votre travail, par exemple, et pas seulement parce que vous aviez besoin d'un peu plus de recherche dès le départ pour vraiment savoir ce que vous faisiez.

Lorsque vous commencez à contourner les règles et à faire des exceptions au type de temps de travail qui devrait être payé et à ce qui devrait être gratuit, il peut être facile de finalement en profiter. Le temps est la mesure la plus simple à utiliser pour le paiement. Cela vous libère de beaucoup de responsabilités complexes, ce qui peut sembler irresponsable, mais cela vous protège d'être bloqué et que l'irresponsabilité du client entraîne une baisse de salaire.

Dans mon cas, ce serait désespéré si je ne pouvais pas facturer le mauvais chemin, car je travaille souvent sur des choses comme celle-ci:

... en essayant de battre un algorithme de subdivision Catmull-Clark vieux de près de 40 ans qui a été ancré dans l'industrie et amélioré à plusieurs reprises par des sociétés comme Microsoft et Pixar en essayant de fournir des résultats plus intuitifs tout en restant aussi compétitif que ces grandes sociétés en termes de vitesse.

95% du temps dans de tels cas, je vais dans la mauvaise direction, revenant constamment au tableau blanc après échec après échec après échec. Si je ne pouvais pas facturer mes échecs, je serais déjà sans abri. Je considère plus de la moitié de mon travail comme de la recherche, alors que personne n'a jamais essayé ces choses auparavant, et il n'y a aucun moyen que je puisse simplement trouver l'approche parfaite pour trouver une solution dès le premier essai (peut-être le 20e). Pour moi, l'objectif n'a jamais été de réussir du premier coup, mais d'échouer le plus tôt possible, chaque échec après échec fournissant des indices sur ce que pourrait être cette bonne solution, qui pourrait en fait être capable de changer le monde.

Tout le monde ne travaille peut-être pas dans un domaine à forte intensité de R & D où les clients veulent et s'attendent à ce que vous battiez les techniques les mieux établies simplement parce que vous démarrez un nouveau projet, mais pour moi, la programmation n'est jamais tout à fait routinière, peu importe comment une solution simple et établie est. La façon dont vous concevez et intégrez les pièces sera toujours unique, toujours une certaine forme d'art en soi produisant des avantages et des inconvénients uniques, pas mécaniques, pas parfaitement scientifiques, sinon les robots pourraient le faire. Je pense donc inévitablement que nous devrons toujours payer pour emprunter de mauvaises routes ici et là, sinon nous ne pourrions profiter que du travail le plus routinier que nous ayons déjà fait cent fois pour lequel nous appliquons exactement la même chose. solution à chaque fois, auquel cas nous facturerions pour avoir appuyé sur le bouton copier-coller.

Imprévisibilité

Une autre chose est que la programmation est toujours difficile, imprévisible, jamais tout à fait routinière. Ce n'est pas comme la livraison de pizza qui est routinière, où tout sauf un accident de voiture peut être comptabilisé (j'ai malheureusement travaillé une fois avec un patron qui a assimilé les estimations du programmeur aux estimations de livraison de pizza et pensé que le seul travail que nous faisions était de taper) . C'est l'apprentissage sur le site, toujours - je ne peux pas imaginer que cela devienne jamais une routine à moins que quelqu'un ne me paie à plusieurs reprises pour l'implémenter comme un tri rapide encore et encore. Il y aura toujours de l'expérimentation et de l'apprentissage là-bas, et tant que ce n'est pas excessif, pas besoin de se sentir coupable.

J'ai souvent rêvé de devenir agriculteur ou quelque chose juste pour pouvoir trouver beaucoup plus de mouvements de routine dans mon travail, sans repousser toujours les limites de mes connaissances existantes. Au lieu de cela, j'essaie de compenser en faisant de ma vie en dehors du travail une routine et aussi banale que possible, pour ajouter quelque prévisibilité et mouvements de routine quelque part par souci de raison, ce qui me rend ennuyeux parmi les personnes qui veulent trouver de l'excitation dans leur vie à l'extérieur de travail - j'en trouve assez au travail.

Il parle d'apprendre de nouvelles choses, de ne pas travailler sur la mauvaise solution.

Travailler sur la mauvaise solution, c'est apprendre de nouvelles choses, n'est-ce pas? Saviez-vous que c'était une mauvaise solution lorsque vous avez commencé, ou avez-vous continué à y travailler de manière persistante même après avoir su qu'elle était désespérément mauvaise? Si tout va bien pas le dernier. Souvent, le processus d'apprentissage passe par des erreurs. C'est le meilleur professeur. La stratégie la plus efficace que j'ai trouvée est de simplement faire des erreurs le plus tôt possible, de découvrir qu'elles sont, en effet, des erreurs de conception le plus tôt possible avant de tout leur engager et de marier de telles solutions, car la seule constante que je peux compter et prédire avec une certitude proche de 100% est que des erreurs seront commises. Ils ne sont chers que s'ils sont découverts très tard.

Cela dépend vraiment de la façon dont vous avez proposé le projet et de la façon dont le projet est facturable.

Par exemple, s'il s'agit d'un contrat basé sur les livrables, toutes les heures doivent être suivies indépendamment du projet, même si c'était pour apprendre quelque chose de nouveau.

S'il s'agit d'un contrat basé sur le temps et les matériaux, vous devez être beaucoup plus sensible à cela. Par exemple, si vous vous trouvez dans le contexte du problème et que vous rencontrez des problèmes, il devrait être facturable. Un exemple de ceci est si vous apprenez une API ou un morceau de code hérité et essayez de le faire fonctionner avec votre code.

Cependant, si vous vous faites dépister en essayant de faire quelque chose ou si vous voulez simplement apprendre à le faire d'une nouvelle façon, alors je ne facturerais que le temps qu'il a fallu pour mettre en œuvre la solution réelle, pas le temps que j'ai pris pour l'apprendre.

Je ne suis pas d'accord avec Lunivore, qu'ils nous paient pour apprendre des choses. Ils nous paient en raison de notre expertise et que la plupart du temps, nous sommes censés savoir comment le faire déjà. Ils nous paient pour la mise en œuvre.

En bref, si votre estimation initiale n'incluait pas le temps nécessaire pour apprendre le problème, vous ne devriez probablement pas le facturer. Faites-en une expérience d'apprentissage et sachez que la prochaine fois, vous n'aurez pas ce délai.

Edit: Puisque vous avez précisé plus tard qu'il n'y avait pas d'estimation, je n'inclurais certainement pas ce temps si vous pensez que ce sera un client récurrent. Je fournirais également toujours une estimation initiale à l'avenir.

Pour contourner ce problème, je pense à ce que serait, selon moi, un mauvais cas et un devis basé sur une heure sur ce que je pense qu'il devrait prendre avec un maximum de devis fixé par le "mauvais" cas. De cette façon, nous sommes tous les deux gagnants.