Comment dissuader un client qui vient d'apprendre une technologie et veut l'utiliser partout? [fermé]

Mon client a récemment découvert ce qu'est la réécriture d'URL, sans bien comprendre ce que c'est, comment cela fonctionne et ses avantages et inconvénients. Maintenant, il demande beaucoup de changements étranges dans les exigences réelles des projets actuels et des changements dans les anciens projets afin de mettre en œuvre ce qu'il pense être la réécriture d'URL.

D'une part, je suis ennuyé qu'on me demande de faire des choses qui n'ont aucun sens au lieu de faire un vrai travail. En revanche, je ne peux pas dire à mon client qu'il ne comprend rien au sujet malgré son intérêt.

Je pense que beaucoup de gens ont eu des situations où leur manager ou leur client venait d'apprendre un nouveau mot à la mode ou une nouvelle technologie, et il l'a tellement aimé qu'il voulait l'utiliser dans tous les projets, partout, réécrire toute la base de code juste pour utiliser cette nouvelle chose, etc.

De plus, j'ai récemment lu quelque chose de similaire sur Programmers.SE où les gens ont raconté leurs expériences quand il y avait un énorme buzz autour de XML, et certains gestionnaires demandaient d'introduire XML dans chaque projet juste pour montrer à tout le monde qu'ils l'ont utilisé.

Alors, ceux qui ont été dans une situation similaire, comment l'avez-vous géré?

IMO, vous devriez avoir la discussion "Vous ne comprenez pas la réécriture d'URL" avec votre client.

De toute évidence, vous ne devez pas dire sans détour à votre client: «Vous ne comprenez pas». Au lieu de cela, je commencerais par: "Avant d'investir quoi que ce soit, je pense que nous devrions discuter de X pour nous assurer que nous sommes sur la même longueur d'onde concernant les avantages et les inconvénients de X et ses alternatives."

S'il s'avère qu'il sait réellement ce que vous faites, mais qu'il veut quand même implémenter X, alors vous lui demandez de quelle couleur il le veut.

Vous devez vous assurer de bien choisir votre libellé. Après tout, il y a une chance (mais non significative) qu'il en sait plus sur X que vous faites (et il est le point évident - vous parlez à managment ), alors assurez-vous vous débarrasser de tous les tons condescendant.

C'est exactement là où une liste prioritaire de tâches se produisant dans l'équipe aide. Si j'étais vous, j'évaluerais les avantages économiques de la réécriture d'URL et montrerais au client comment cela s'ajouterait / se retirerait de l'expérience globale.

Considérez-vous comme un médecin. Les gens consultent tout le temps les médecins avec une liste de médicaments qu'ils ont vus sur une annonce / symptômes qu'ils imaginent. C'est le travail du médecin de s'assurer que la personne obtient réellement ce qu'elle devrait obtenir.

En outre, utilisez rigoureusement le contrôle de code source et les branchements pour chaque modification. De cette façon, vous pouvez revenir en arrière dans le temps et montrer au client ce qu'il a manqué, juste au cas où il oublie qu'il l'a apporté lui-même.

Enfin, transcrivez toutes vos réunions. Ils sont utiles un jour.

Décomposez-le en dollars et en cents. Donnez-lui des estimations réalistes du temps qu'il faudra pour mettre en œuvre ses caprices et incluez l'impact sur d'autres fonctionnalités. Transformez cela en discussion des priorités et demandez où cela se situe. De là, vous pouvez passer à une discussion pour vous assurer qu'il comprend vraiment ce qu'il demande. Cela garantira que:

1. Il sait ce qu'il demande
2. Il sait combien ça coûte
3. Il sait comment cela affectera le calendrier des autres fonctionnalités
4. Il sait combien de temps cela prendra

Dans de nombreux cas, après avoir eu cette discussion, il sera facile pour lui d'accepter de l'abandonner ou d'en faire une priorité très faible (lire: ne jamais s'attendre à ce que cela soit fait).

D'une part, je suis ennuyé qu'on me demande de faire des choses qui n'ont aucun sens au lieu de faire un vrai travail.

Comment savez-vous que ce qu'on vous demande a si peu de valeur? Peut-être y a-t-il des arrière-pensées qui peuvent ne pas être claires à première vue pour expliquer pourquoi quelque chose est fait. " Cire on, main droite. Cire off, main gauche. Cire on, cire off. Inspirez par le nez, par la bouche. Cire on, cire off. N'oubliez pas de respirer, très important. " Serait la ligne de "The Karate Kid" mérite d'être noté ici dans une certaine mesure.

Lorsque j'ai eu des expériences avec des entreprises faisant des choses que je me demande, "Pourquoi faites-vous de cette façon?" il y a des moments où je vais demander quel est l'avantage souhaité et y a-t-il d'autres façons d'y arriver. La clé ici est d'être ouvert et curieux plutôt que de juger et de se contenter de soi que le "vrai travail" semble impliquer assez fortement dans mon esprit.