Avantages du taux horaire pour le client [fermé]

Il est bon pour un développeur de travailler à l'heure, mais il est difficile d'expliquer au client les avantages du taux horaire.

Quels sont vos arguments sur le taux horaire pour le client? Comment lui expliquez-vous ses avantages et comment argumentez-vous sur "Je veux connaître le coût exact du projet"?

Old Joke: La chaîne de montage tombe en panne et un réparateur est amené. Après avoir regardé la machine, il tire un marteau, frappe la machine et elle commence à fonctionner. Le chef d'atelier est étonné jusqu'à ce que le réparateur dise: «Ce sera 500 $». Pris au dépourvu, le forman réplique: "Vous voulez facturer 500 $ pour avoir frappé la machine avec un marteau? Mon directeur financier va avoir besoin d'une facture détaillée."

La facture est envoyée par la poste:

• Machine à frapper avec marteau: 5,00 $
• Savoir où frapper la machine: 495,00 $

D'une certaine manière, un taux horaire est le moyen de contrôler les coûts. Quelle est la valeur d'une application qui évite à une entreprise d'avoir à embaucher un employé au salaire minimum à temps plein? Les coûts annuels totaux pour cette personne, y compris le salaire, les avantages sociaux, les vacances, les congés de maladie, pourraient atteindre 20 000 $. Il doit en valoir 15 000. Si la solution s'avère être une importation dans une base de données qui peut être créée en 30 heures ou moins, je doute que le taux en cours soit de 500 $ / heure.

Le client peut contrôler le coût tout au long de la vie du projet.

De nombreux projets qui ont des frais fixes demandent généralement la moitié d'avance. Le client peut payer au fur et à mesure avec un taux horaire.

Le chargement à l'heure me semble juste mal. Je veux être apprécié pour savoir où balancer le marteau.

Un taux horaire ne profite pas au client. Cela profite au développeur, car peu importe le nombre de modifications demandées par le client.

Tout comme un contrat à prix fixe ne profite pas au développeur. Du moins, non sans ordre de changement. :-)

Dans la construction, il y a une nette séparation entre l'analyse et la conception (architecture) et la mise en œuvre (construction). Même avec cette séparation et un siècle ou plus d'informations sur les coûts de mise en œuvre, les projets de construction peuvent dépasser le budget.

Dans le développement informatique, il n'y a pas de séparation aussi claire entre l'analyse, la conception et la mise en œuvre. Le client ne réalise pas ce qu'il en coûte pour changer un écran une fois le codage terminé, par rapport à abattre un mur.

Le développeur a la responsabilité d'éduquer son client et de s'assurer que le client comprend la valeur, par opposition au prix.

La principale différence entre le forfait et l'heure est de savoir qui assume le risque. En particulier dans ce domaine, les estimations de projet ne sont qu'approximatives et peuvent comporter une grande part d'incertitude.

Par conséquent, sur un prix fixe, le développeur doit s'assurer d'estimer élevé pour couvrir les difficultés imprévues. C'est raisonnable, car dans la plupart des activités commerciales, le fait de couvrir le risque vaut de l'argent (c'est ainsi que fonctionne l'assurance).

Si le client fait suffisamment confiance au développeur, un taux horaire permettra au client d'économiser de l'argent si le projet se termine plus tôt que ladite estimation élevée, bien que si cela se passe, le client perd de l'argent. Dans ce cas, le client couvre le risque et économise en moyenne de l'argent.

En particulier, si le client est une grande entreprise et que le développeur est un particulier, le client est probablement mieux placé pour assumer les risques. Devoir débourser 160 heures supplémentaires est susceptible de nuire moins à une grande entreprise que de devoir travailler un mois supplémentaire gratuitement nuira à un développeur isolé.

Cela facilite également la négociation des changements de spécifications lorsque le développeur n'a pas à effectuer une réestimation approfondie pour chaque changement.

Un taux horaire profite au client dans les cas où il y a de fortes chances qu'il veuille ajouter des fonctionnalités supplémentaires au-dessus de celles initialement identifiées. Cela bénéficiera également au client lorsque le processus de développement comprend la collaboration avec des tiers et que le rôle du développeur peut devoir inclure d'autres tâches qui ne sont que tangentiellement liées à la tâche de programmation.

Un taux horaire permet au développeur de dire «je vais m'en occuper». Plutôt que «Ce n'est pas couvert par le prix convenu. Ce sera un montant supplémentaire de X dollars. »

Dans ces cas, un taux horaire élimine la nécessité de négociations continues et peut aider à éviter les malentendus résultant de divergences de vues sur ce qui avait été initialement convenu.

Au tarif horaire, le client doit s'assurer que vous travaillez efficacement. Dans un contrat à prix fixe, le client doit décrire exactement ce qu'il veut. Si le client veut connaître le coût exact du projet, vous devez savoir exactement ce qui doit être construit. Habituellement, le client ne sait pas, ou pense qu'il sait mais change d'avis plus tard.

Dans les deux cas, un drone de vente trouvera un moyen de surcharger le client: enchérissez sur la partie fixe d'un projet et rattrapez-le plus tard avec d'énormes factures pour chaque modification ou ajout mineur, ou laissez les personnes les plus compétentes remporter l'enchère et les remplacer par des programmeurs de merde (au même taux horaire) plus tard.

Si j'étais client, je préférerais:

• payer un taux horaire
• demander aux développeurs de fournir du code de travail validé par des tests automatisés par incréments courts
• être en mesure de remplacer les développeurs qui ne fonctionnent pas (couvrant les droits d'auteur, etc.)

De cette façon, je suis libre de me décider au fur et à mesure et de savoir ce que je paie.

Pensez à poser à votre client la question comme celle-ci:

Dans quelle mesure sont-ils confiants quant à leurs spécifications? Ont-ils vraiment pensé à tout? Qu'est-ce qui pourrait changer entre maintenant et la mise en service du produit? Expliquez qu'avec un prix fixe, vient une spécification fixe. tout changement, et le prix changera.

Je proposerais alors une alternative. Citez un prix et une allocation de changement de spécification, peut-être de 20%. De cette façon, le client a déjà budgété dans une certaine pièce pour les changements, et s'il a réussi à obtenir les spécifications correctes en premier lieu, il mettra le projet sous le budget!

Si le client souhaite diriger et contrôler le processus de développement et / ou apporter des modifications fréquentes au produit, il peut le faire, mais il doit accepter un taux horaire / quotidien.