Tarification des produits logiciels/estimation des coûts

Question

J'ai toujours eu de la difficulté à estimer le coût/prix des logiciels finis (ou du travail de programmation), alors voici deux questions à ce sujet.

question 1:
Vous êtes invité à écrire un morceau de code pour de l'argent (tous les droits sur le code appartient à l'acheteur une fois que vous avez terminé). Vous connaissez le nombre approximatif d'heures qu'il faudra (+ -25%) et la complexité approximative (c'est-à-dire si vous pouvez l'écrire dans votre sommeil ou si vous souffrez d'épuisement psychologique grave une fois que vous avez terminé). Le produit est écrit en langage compilé (C, C++, etc.).

Comment choisissez-vous (vous) le prix du travail?

question 2:
Disons que vous passez quelques mois écrire quelque chose, cette chose est maintenant terminé, et veulent maintenant (essayer de) vendre. Le produit sera extrêmement "Niche", et il ne sera pas possible de le vendre pour un grand nombre de personnes (c'est SDK, moteur de jeu, bibliothèque, ou quelque chose comme ça, pas un éditeur de texte - nombre de personnes cela voudrait que ce soit petit). "opensourcing" c'est hors de question.

Vous connaissez le nombre approximatif d'heures que vous avez passées, la taille totale des fichiers, la résolution, et vous avez un référentiel avec l'historique complet du développement. Le résultat peut être vendu avec ou sans accès au code source, à des fins commerciales ou non commerciales, ou vous pouvez (essayer de) vendre des droits logiciels.

Comment déterminer le prix pour:

1. droits pour ce logiciel?
2. Utilisation commerciale avec accès au code source?
3. Utilisation commerciale sans accès au code source?
4. Utilisation non commerciale?

Answer 1

Vous pouvez trouver des informations intéressantes recueillies dans un (gratuit) livre de Neil Davidson: http://www.neildavidson.com/dontjustrollthedice.html

Answer 2

Le prix du produit n'a rien à voir avec l'estimation des coûts, sauf que le prix devrait généralement être supérieur au coût.

Le prix est plus à faire avec: combien le client paiera pour ce logiciel? Le prix est une compétence difficile à obtenir - si vous dites un prix et que le client ne clignote pas, vous êtes probablement allé trop bas ...

Donc, le conseil pour le logiciel client unique (sur mesure) est de fixer le prix au plus haut, vous pensez qu'ils vont payer. Si le coût d'écriture du logiciel (en termes d'heures de travail) est plus élevé que le prix qu'ils paieront, ne prenez pas le travail.

Pour les logiciels prêts à l'emploi, c'est tout aussi difficile, car vous devez connaître la taille de votre marché. Dites qu'il y a 1000 clients potentiels, vous devez alors savoir combien de personnes achèteront votre produit à un prix particulier. Évidemment, comme le prix augmente, vous aurez moins d'acheteurs. Encore une fois, le prix n'a rien à voir avec combien le logiciel vous coûtera pour construire, c'est à voir avec combien de gens seront prêts à dépenser.
Donc, si 500 personnes vont l'acheter à 20 $, mais seulement 200 vont l'acheter à 30 $, il devient plus évident comment le prix (*). Le seul moyen de trouver ces chiffres est de vendre votre produit, mais vous pouvez faire des études de marché (par exemple demander à vos clients potentiels) pour savoir ce qu'ils seraient prêts à payer.(Comparez cela avec des projets de clients uniques où vous ne pouvez pas demander à votre client combien il est prêt à payer ...)

Ainsi, une fois que vous avez obtenu votre prix optimal, vous pouvez calculer votre rendement attendu (attendu nombre de ventes multiplié par le prix). Si cela est inférieur à votre coût, n'écrivez pas le logiciel ...

(*) Je devrais dire comment connaître la taille de votre marché est important ici. Si vous demandez à 20 personnes de votre marché si elles vont l'acheter à 20 $, et 10 dites oui, vous pouvez supposer que 50% de votre marché l'achètera à 20 $. En sachant que votre marché compte environ 1000 personnes, vous pouvez le multiplier jusqu'à 500 personnes l'achèteront à 20 $. Sans connaître la taille de votre marché, sachant que 50% des gens l'achèteront à 20 $ n'est pas pertinent.

Answer 3

Pour la question 1, ce n'est pas difficile de trouver le taux horaire régulier dans la région où vous êtes, rappelez-vous juste à ajoutez toutes les heures que vous passez sur le projet, pas seulement les heures passées à écrire le code ... aussi, quand vous estimez combien de temps il faudra pour mettre en œuvre un projet logiciel, toujours la loi Hofstadter ;-)

" Cela prend toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter. "

Pour la question 2, même si c'est un peu daté maintenant, je trouve toujours que les "règles d'information" de Carl Shapiro et Hal R. Varian sont le meilleur livre sur le sujet. Il n'y a vraiment pas de réponse facile à cette question, mais ce livre vous donnera une bonne compréhension des facteurs dont vous devriez tenir compte lors de la fixation d'un prix.

livres Google: Information Rules

Answer 4

Vous avez vraiment besoin de lire Joël [/ diatribe/humour/mousse] sur ce http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html