Comment éduquez-vous vos clients?

Les clients ont besoin d'une éducation parce qu'ils pensent différemment. Les clients pensent:

• les changements ne sont pas un problème à tout moment du projet

• les détails ne sont pas importants (les exceptions encore moins)

• le temps ne coûte pas d'argent (ils ont un prix fixe convenu)

• une phrase de la spécification peut être étendue / lue librement pour répondre aux besoins réels - et cela n'affecte pas le contrat. (ici, nous voyons souvent la discussion sur le "bon sens" - exemple: "Bien sûr, nous avons besoin d'un écran de gestion des factures lorsque nous parlons de gestion comptable - c'est du bon sens!")

• la liste continue...

Le principal problème est que le client (qu'il soit externe ou interne / département) ne veut pas ou ne peut pas comprendre. Il m'a fallu de nombreuses années pour comprendre le processus de création de logiciels et j'apprends encore, alors comment peuvent-ils le faire en quelques mois seulement.

Quelle est votre expérience, quelle est la meilleure approche pour éduquer les clients?

L'été dernier, j'ai eu une conversation très similaire avec un client.

Le client voulait que je fournisse un prix compétitif pour le travail défini, puis lorsque leurs besoins changent ou que leur compréhension de leurs besoins change, ils voulaient changer les spécifications sans me permettre de changer le coût pour refléter le changement dans le travail.

J'ai demandé à mon client s'il avait des suggestions sur la façon dont je pourrais coûter des modifications inconnues dans le cadre du devis. La solution que nous avons élaborée consistait pour moi à citer une allocation pour éventualités détaillée de 15%, que nous travaillerions ensuite avec le client pour hiérarchiser ses modifications afin d'utiliser cette allocation. Finalement, l'éventualité n'a pas été complètement utilisée, je n'ai facturé que le travail effectué.

Le résultat final a été que j'étais heureux d'avoir été payé pour le travail effectué, le client livré en interne sous le budget, et parce que j'avais soulevé la question de manière professionnelle avec eux à l'avance, ils m'ont choisi plutôt qu'un concurrent pour le faire l'oeuvre.

Je souhaite simplement à tous les clients potentiels ce travail professionnel et de qualité.

Éduquez le client . Je souhaite que je ne sois pas un de vos clients;)

Sérieusement, je comprends que vous avez des ennuis et que vous pensez que le problème vient du client. Peut-être que oui, mais cela n'a pas d'importance. Changer vos clients est vraiment difficile, alors que changer la façon dont vous travaillez avec eux est beaucoup plus facile.

Le problème est que la plupart des clients ne sont pas conscients de toutes les implications du développement de logiciels et vous n'êtes pas au courant de leurs activités en détail.

Juste une petite chose:

les changements ne sont pas un problème à tout moment du projet

"Peu importe jusqu'où tu es allé sur une mauvaise route, reviens en arrière." Proverbe turc

J'adore ce proverbe, donc quand je peux l'utiliser, je suis content. Merci pour cette opportunité ;)

Voici quelques solutions:

Vous devez donner au client la possibilité de changer d'avis, car cela l'aidera à obtenir le bon logiciel qui correspond vraiment à ses besoins. Il finira par avoir plus d'idées pendant que vous le développez.

Vous êtes dans un contrat à prix fixe, donc je suppose que vous avez dû rassembler les besoins, les estimer et fixer un prix pour chacun?

Si vous devez construire une nouvelle chose, utilisez le même processus: vous modifiez le contrat à prix fixe avec les exigences supplémentaires. Acceptez de supprimer les exigences qui seront inutiles (vous ne les avez pas déjà construites bien sûr).

Une autre approche serait de terminer ce qui a été négocié (exigences moins inutiles et non développées) en version 1, et de négocier une version 2 avec ses nouvelles idées.

La deuxième solution serait de créer une itération dans le développement comme dans Scrum . Je n'ai pas encore d'expérience avec cela dans un projet à prix fixe (parce que je ne fais plus de projets fixes), donc je ne sais pas si cela fonctionne ou non. J'ai sérieusement beaucoup de doutes que Scrum (ou Agile ) est la solution à tous les projets de développement logiciel, mais peut-être que certaines des pratiques décrites vous aideront.

Si vous avez un contrat à prix fixe, vous devez indiquer clairement que chaque changement de portée coûtera de l'argent, et vous évaluerez le changement et présenterez un devis chiffré pour la mise en œuvre du changement.

C'est une pratique largement acceptée dans la plupart des industries, mais certains clients en seront très contrariés.

Si vous avez l'impression que vous avez un plus gros problème, mais si vous avez du "bon sens".

Un peu comme un client il y a de nombreuses années où je travaillais qui lisait les spécifications et disait des choses comme "Il y a une EXIGENCE IMPLICITE que vous fassiez XXX"). À laquelle la réponse a été: Il n'y a aucune exigence implicite. Les seules exigences sont celles de la spécification écrite. Si vous souhaitez ajouter ou modifier des exigences, veuillez soumettre une demande de changement de spécification et nous citerons le changement de portée.

Le message a fini par passer, mais cela a pris beaucoup de temps.

Une solution consiste à consacrer plus de travail à la définition de ce que vous acceptez de faire avant de commencer à travailler. Comme vous l'avez dit, une phrase du contrat peut facilement être lue différemment par vous et les clients. Plus le plan de projet est détaillé, plus il vous est facile de dire que le supplément qu'il souhaite que vous fassiez ne fait pas partie de l'accord initial.

Il est également important d'être cohérent. Le client ne sait pas combien de travail est impliqué pour une nouvelle fonctionnalité donnée. Si vous acceptez d'ajouter gratuitement des fonctionnalités rapidement implémentables, il est très difficile d'expliquer plus tard au client pourquoi vous ne pouvez pas également utiliser cette autre fonctionnalité gratuitement lorsque le bon sens du client dit qu'il ne devrait plus y avoir de travail.

Une astuce avec les contrats à prix fixe est que même si vous faites le travail avec un prix fixe, indiquez une estimation du nombre d'heures de travail. Même si vous ne facturez pas à l'heure, cela enlève l'illusion que le prix fixe équivaut à des heures de travail infinies.