Qui devrait payer pour les correctifs / bugs? [fermé]

Donc, je viens juste de commencer à travailler en freelance dans le développement web / sur le bureau et chez ce client qui a déjà accepté mon travail et qui me paye sans cesse, chaque fois qu’il trouve un bogue, etc. libre. Est-ce correct ou dois-je commencer à facturer des frais d'assistance?

Quelle est la meilleure façon de traiter des corrections sur un travail supposé accepté et achevé?

Une partie de votre contrat doit décrire les tests de réception, c’est-à-dire les tests que le client effectuera et que votre application doit réussir pour que le contrat soit rempli. Tout ce qui n'est pas couvert par ces tests est la responsabilité du client. Tout ce qui est couvert par eux est à vous.

Comme il n’est pas possible (en particulier pour un client non technique) de prévoir tous les problèmes possibles, vous devez ajouter à votre contact une clause spécifiant une période au cours de laquelle vous résoudrez les nouveaux problèmes dans le cadre d’un contrat. Après cela, vous ne devez offrir que du support technique.

Ça dépend.

En premier lieu, vous devriez payer, car on peut affirmer que le travail n'est pas terminé.

Plus tard, le client devrait payer pour une assistance continue.

Cependant, le problème réside dans le choix de la limite, de ce qui constitue un bogue et de la nouveauté. Avoir des exigences et / ou des tests d'acceptation contribue grandement à définir cela.

Vous avez vraiment besoin d'obtenir ces choses en place avant de vous livrer le travail, mais si vous n'avez pas alors peut - être le moment est venu dire alors - « Je vais soutenir cela gratuitement pour les jours suivant N / semaines, mais après que nous besoin de discuter d’un contrat de support "(notez mon accent sur" nous ").

Cela dit, il est parfois nécessaire de corriger un bogue gratuitement et de prendre le risque. Si rien d'autre ne crée de la bonne volonté.

Toutes les réponses données ci-dessus sont bonnes. Cependant, je voudrais ajouter quelques points à prendre en compte:

• Le client est-il précieux pour vous? Parfois, il vaut la peine de dépenser quelques mètres supplémentaires pour satisfaire un client si vous estimez qu’il est précieux pour vous et vous apportera plus de travail à l’avenir. Vous devez trouver un équilibre entre rigidité et souplesse, ce qui peut varier d’un client à l’autre. Inutile de perdre des travaux futurs simplement parce que vous êtes persuadé qu'un bogue facile à résoudre tombe hors de son champ d'application. D'autre part, vous ne voulez pas laisser le client vous parcourir. C'est un équilibre délicat!

• Le bogue est-il quelque chose qui aurait facilement pu être manqué lors des tests utilisateurs? Par exemple, prenons un bogue lié à la date qui n’intervient que lorsqu’une certaine année est entrée (pensez au bogue du Millénaire, etc.). On ne pouvait pas raisonnablement s'attendre à ce qu'un client voie cela pendant les tests, il vous incombe donc de le réparer.

Lorsque j'étais en freelance, mon contrat client de base définissait une condition appelée "acceptation", qui était requise avant que je mette le projet à exécution pour le public. Au moment de l'acceptation, une période de 30 jours a débuté, j'ai appelé "un soutien opérationnel". Après cette période de 30 jours, les travaux en cours sur le projet étaient facturables à l’heure.

Si vous entretenez de bonnes relations avec ce client, assurez-vous que la situation actuelle est impraticable pour vous et proposez un taux horaire équitable pour la maintenance et l'assistance. Les gens pensent parfois qu'acheter un logiciel personnalisé, c'est comme acheter un sandwich ou autre chose, comme une fois construit, c'est fait. C'est juste pas comme ça.

En règle générale, vous pouvez bénéficier d'une assistance gratuite pendant un nombre de jours déterminé après la livraison de l'application. Assurément, un support gratuit à vie n'est pas possible / inacceptable.

Assurez-vous que le bogue soulevé est un bogue et non une modification d'une fonctionnalité existante. Pour tout changement de fonctionnalité, vous devriez facturer.

S'il le testait et le signait, vous pourriez prétendre qu'il devrait payer.

Si vous êtes fier et valorisez votre travail, vous pourriez soutenir que vous corrigeriez le code. Tirez les leçons de ces expériences et construisez un meilleur code la prochaine fois, de manière plus efficace. Ou encore, prenez en compte plus de bénéfices pour couvrir la résolution des bugs.

Si le programme fait quelque chose d’indésirable ou d’inattendu compte tenu des entrées, il s’agit d’un bogue qui doit être corrigé.

Vous auriez pu citer les frais d’assistance dès le départ, en plus des travaux de développement initiaux.

Dans votre contrat, spécifiez un taux horaire et gardez une trace de votre temps. Lorsque vous donnez le prix à votre client, précisez qu'il s'agit d'une estimation et que le résultat réel peut être inférieur ou supérieur.

Tenez le client au courant des progrès et, lorsqu'il fait inévitablement des suggestions, vous pouvez simplement lui dire le temps qu'il vous faudra (si le changement dépasse les spécifications d'origine) et il peut décider si le changement en vaut la peine. Par conséquent, seuls les changements importants pour lui seront ajoutés.

Je voudrais personnellement couvrir les bogues acceptables par rapport aux support inacceptables (support payant par rapport au support gratuit) dans le contrat, et ainsi vous aurez au moins un élément écrit dès le départ. Il se demandera sans aucun doute pourquoi vous devriez avoir besoin de cette clause, alors soyez franc et expliquez que si une nouvelle mise à jour du système d'exploitation, qui casse quelque chose, n'est pas une assistance gratuite. Toutefois, les bogues dans votre code conformément à la spécification d'origine sur les plates-formes spécifiées seraient couverts.

Cependant, je devrais mentionner que je n'ai fait que du travail informatique indépendant plutôt que de la programmation. Cela pourrait éventuellement effrayer les clients, mais assurez-vous simplement que votre travail se vend, soyez plus professionnel, plus sociable et plus serviable que le reste, et expliquez clairement les raisons pour lesquelles vous avez un contrat plus strict.

En outre, un client qui n'acceptera pas cette clause est très probablement un mauvais client.