Re: estimation de cout d'une application ruby on rail

Une appli rails ne vaut pas plus ou moins cher parcequ’elle en Rails. En
general, le client paye un resultat, pas le moyen d’arriver a ce
resultat.
Enfin en realité c’est un peu plus compliqué, car il faut
eventullement
s’integrer a de l’existant, et les choix techniques ne sont pas
totalement
anodins.
Par contre, Rails peut eventuellement te permettere d’arriver a ce
resultat plus rapidement, et donc soit de faire payer moins cher ton
client,
soit d’avoir une meilleur marge…
Donc pour en revenir a ton app, deux moyens:

  • le cout de developpement. Tu dis 2 semaines apres les cours, donc on
    va
    dire 2 heurs/jours sur 10 jours, donc 15 heures, ou 2 jours de dev. En
    debutant, tu va pas facturer bcp plus que 400€/jours a un client (et
    400€
    inclu les charges et je suis tres tres large…), donc au mieux tu
    arrive a
    800€ pour 2 jours de dev moins les charges a enlever. Ca c’est le coup
    de
    ton dev, donc ton prix te vente doit au moins etre cela.

    L’autre manière de voir, c’est combien ton client est pret a payer,
    quelle
    est la valeur percue… La, c’est un peu different, et tu a plus de
    marge…

ok, merci beaucoup pour ton estimation.
Juste une petite question, tu dis:

donc au mieux tu arrive a 800€ pour 2 jours de dev moins les charges a enlever.

et après tu dis:

donc ton prix te vente doit au moins etre cela.

donc les 800€, c’est au mieux ou au moins?

merci d’avance

Pat

Thomas L. wrote the following on 25.12.2006 14:14 :

  • le cout de developpement. Tu dis 2 semaines apres les cours, donc on
    va dire 2 heurs/jours sur 10 jours, donc 15 heures, ou 2 jours de dev.
    En debutant, tu va pas facturer bcp plus que 400€/jours a un client
    (et 400€ inclu les charges et je suis tres tres large…), donc au
    mieux tu arrive a 800€ pour 2 jours de dev moins les charges a
    enlever. Ca c’est le coup de ton dev, donc ton prix te vente doit au
    moins etre cela.

Après il faut compter la maintenance. La plupart des clients s’attendent
à un engagement là -dessus. L’état de l’art dans les applications à façon
est de proposer une période de garantie où le client peut demande la
résolution des problèmes présents dans le code vendu (normalement on se
borde là -dessus en indiquant les conditions d’utilisation du code pour
qu’il ne vienne pas t’embêter parce que ça ne marche pas sur son ZX
Spectrum avec une version de l’OS patchée par ses soins…) sans verser
un centime. Tu dois prendre en compte cela dans ton prix de vente (au
risque de devoir le faire gratos pour conserver de bonnes relations avec
ton client ensuite). Après la période de garantie on entre en
maintenance : tu vends un service de maintenance au forfait garantissant
que tu résouds les problèmes cachés qui se manifestent au cours de
l’utilisation normale de l’application. Tu peux également faire du
one-shot à chaque problème rencontré : tu factures le temps passé Ã
corriger mais ce n’est pas très rassurant pour le client.
Tout cela est optionnel, mais le proposer à ton client fait pro : en
général ça le rassure que tu prévoies pour lui les problèmes qu’il aura
à résoudre. Il ne faut pas avoir peur d’admettre que ton code peut avoir
des bugs, bien au contraire : il faut faire comprendre au client que
ceux qui se vantent de ne jamais avoir de bugs sont généralement des
amateurs n’ayant jamais développé d’applications professionnelles voir
de simples escrocs. S’il a déjà utilisé un ordinateur il doit être
habitué aux bugs de toute façon…
Utiliser les tests est également une bonne habitude qui te permet de
minimiser tes coûts de maintenance. En codant les tests tu augmentes tes
coûts initiaux mais à chaque fois que tu sortiras un patch, tu éviteras
d’avoir à tout retester à la main ou pire le pousser en prod sans
vérifier qu’il n’a pas d’effet de bord : tu économiseras donc a
posteriori (en pratique, bien plus que ce que tu auras économisé au
départ). Si le client est en plus susceptible de te demander des
évolutions, tu y gagneras encore bien plus.

Tu as les problèmes d’intégration également : si le client veut ton
appli sur un système particulier différent de ton environnement de
développement, tu vas passer du temps à installer les dépendences, ton
code et éventuellement demander aux opérateurs en charge du firewall, de
la base de données et Cie à réaliser différentes manips. Tu dois voir si
ces problèmes existent dès le départ et chiffrer le temps que tu vas
passer dessus… Sinon tu risques de bosser 3x plus que prévu.

Lionel.

Salut

Comment calculez-vous votre tarif?

  • taux horaire?
  • jour?
  • semaine?

Que pense-vous de ce taux horaire
http://www.payscale.com/research/US/Industry=Consultant/Hourly_Rate

Salut,

Si c est du forfait ( obligation de resultat ), alors tu peut taper a
500 euros min par jours.

Si c est de la regie ( obligation de moyen ), 450 euros min.

Si la mission est courte, cela augmente le prix.

Un dev dotnet se vend sans problem a 500 euros de nos jours. ( j ai un
pote a 600 )

Donc te brade pas trop surtout. des seruriers sont plus cher que toi…

       py