Travailler avec des clients qui ne savent pas ce qu'ils veulent

J'ai récemment commencé un travail qui me fait travailler sur un système existant. Il nécessite des ajustements et des mises à jour ainsi qu'un nouveau code. J'ai fait plusieurs projets de maintenance / ajout de fonctionnalités maintenant, et plusieurs d'entre eux ont fini par être très différents de ce qui était réellement demandé. J'ai donc dû programmer l'article plusieurs fois pour l'amener là où le demandeur le voulait.

Maintenant, cela ne me dérange pas de reprogrammer la fonctionnalité si c'est ce qui doit être fait. Cependant, je voudrais réduire le délai d'exécution de mes projets. Le goulot d'étranglement semble résider dans la perception du demandeur de ce qui doit être fait. Avez-vous des idées sur ce que je pourrais faire pour comprendre ce dont le demandeur a besoin plus rapidement?

Quelques conseils:

• Écoutez les problèmes, pas les solutions . Beaucoup de clients aiment vous dire comment résoudre leurs problèmes. Ne les écoute pas. Vous êtes le programmeur et c'est votre travail de trouver des solutions aux problèmes. Écoutez plutôt les problèmes rencontrés par les clients et trouvez la meilleure façon de les résoudre. comme d'autres l'ont dit, les clients ne savent pas vraiment ce qu'ils veulent, parfois vous devez d'abord le leur montrer.

• Posez des questions . Lorsque vous avez terminé de poser des questions, posez-en plus. Les clients communiquent rarement des détails, car ils n'y pensent pas vraiment. La seule façon d'obtenir les informations dont vous avez besoin est de les extraire.

• Obtenez les choses par écrit Selon la situation avec le client, cela peut être très important plus tard quand il commence à se plaindre du fait que ce que vous avez livré "n'est pas ce qu'il a demandé". et à tout le moins, la rédaction de spécifications détaillées peut vous aider à vous assurer que vous disposez de toutes les informations dont vous avez besoin et à lever les ambiguïtés entre vous et le client.

• La communication est la clé . ne vous contentez pas de parler au client, d'obtenir des informations, de supprimer du code et de ne pas lui parler tant que ce n'est pas fait. Restez toujours en contact avec le client. Posez des questions tout au long du processus. montrez-leur les progrès que vous avez réalisés et obtenez des commentaires. Cela facilitera la vie de chacun à long terme.

À peu près n'importe quel livre d'entraide que vous prenez sur la communication va vous donner quelques variantes de ceci:

• Cherchez d'abord à comprendre, puis à être compris

Cela vient du livre des 7 habitudes, mais ce sont toutes des variantes de la méthode de "l' écoute active ". Le but n'est pas seulement de comprendre, mais de leur communiquer ce que vous avez compris.

Une fois que je pense avoir une bonne idée de ce dont ils ont besoin (éloignez-vous de ce qu'ils veulent en particulier s'ils commencent à décrire les détails de la mise en œuvre - c'est votre travail pas le leur), je leur donne des exemples d'histoires de différentes personnes utilisant le système, et voir si qui jive avec eux.

Ensuite, j'implémente cela, en espérant pleinement qu'une fois qu'ils verront la fonctionnalité, ils se rendront compte que ce n'est pas exactement ce qu'ils veulent. Gardez tout flexible. La seule constante est le changement. J'obtiens généralement la plupart des bords rugueux après la deuxième mise à jour rapide après la première, mais je trouve toujours que j'approche asymptotiquement d'un idéal que je ne pourrai jamais atteindre. Finalement, vous devez laisser aller les choses sans importance et passer à des cibles de plus grande valeur.

Je ressens ta douleur....

La mauvaise nouvelle est la suivante: selon le type de clients avec lesquels vous traitez, cela peut être normal.

Un problème général commun est essentiellement que les clients ne savent pas ce qu'ils veulent . Ils savent généralement ce qu'ils veulent réaliser, en termes d'objectif commercial, mais ils n'ont souvent aucune idée de ce à quoi cela devrait ressembler en termes de solution logicielle. Donc, dans de nombreux cas, vous vous retrouverez dans ce cycle itératif où un projet rebondit cinq fois plus longtemps que l'estimation initiale, car le client ne cesse de changer d'avis et souhaite que la solution soit modifiée et retravaillée. Et oui, il n'est pas inhabituel que le résultat final soit transformé en quelque chose de complètement différent de ce à quoi ressemblait l'objectif initial.

J'ai eu un exemple épique de cela il y a quelques années - un projet qui a initialement pris 10 semaines pour coder s'est transformé en un processus de réitération de 15 mois. Dans ce cas, c'était principalement parce que différents gestionnaires et départements de l'entreprise cliente voulaient des choses différentes, ils ont donc continué à renvoyer le travail, à le peaufiner et à le peaufiner (notre logiciel est basé sur un abonnement et c'était un client majeur, donc ce il n'y avait pas de peau financière dans notre dos - juste un gros ennui technique vraiment).

Donc, fondamentalement, mon conseil est le suivant:

Si tel est le cas de votre industrie et de ces clients (c'est un gros SI), alors habituez-vous. Considérez-le comme un travail agile et orienté vers la maintenance (c'est ainsi que se déroule mon concert actuel, plus ou moins). :)

Si ce n'est pas ainsi que les choses sont censées être faites, et que vous reprenez la responsabilité des longs délais, alors parlez à vos patrons. Expliquez-leur qu'il y a des problèmes de communication et que les spécifications qui vous parviennent des clients ne sont pas assez claires pour que vous puissiez mettre en œuvre la solution souhaitée. Vous ne voulez pas vous retrouver dans la situation où vous reprochez de ne pas donner aux clients ce qu'ils veulent, si vous n'obtenez pas toutes les informations nécessaires pour leur donner ce qu'ils veulent.

Tout d'abord, vous devez accepter le fait que les clients ne savent pas vraiment ce qu'ils recherchent jusqu'à ce qu'ils le voient. Ils pourraient vous dire en ce moment qu'ils ont besoin de la fonctionnalité X. Montrez-leur la fonctionnalité X, puis ils se rendront compte que ce dont ils ont vraiment besoin est la fonctionnalité Y ou une autre variante de la fonctionnalité X.

Un bon moyen de comprendre plus rapidement ce que le client veut vraiment est d'adopter et de suivre le Manifeste Agile , qui se concentre sur la communication et la collaboration client. Divisez le cycle de développement en itérations et montrez au client un prototype de la fonctionnalité à chaque fin de l'itération. De cette façon, vous obtiendrez une rétroaction immédiate et la modifiez, selon les commentaires du client, sans avoir à investir trop de ressources sur la fonctionnalité. De cette façon, vous et le client serez satisfaits du résultat du produit.

Je suis sûr que la transition sera difficile pour votre équipe ou votre entreprise, mais c'est l'un des meilleurs moyens de faire face à des exigences en évolution rapide.

Beaucoup, et beaucoup d'histoires similaires peuvent être trouvées ici . Je n'ai jamais, même en travaillant comme sous-traitant pour une autre société de développement, trouvé un client qui savait exactement ce qu'il voulait.

Je suis assez heureux de travailler avec quelqu'un qui a une très bonne idée de ce qu'il NE VEUT PAS ou ne veut pas éviter. Je peux généralement travailler à partir de là vers quelque chose qui les satisfait.

Mon expérience concerne principalement le développement d'applications / de plateformes. Heureusement, je dois rarement faire face à des problèmes d'esthétique comme le font les concepteurs de sites Web.

Après de nombreuses réécritures ennuyeuses, j'opère maintenant ce que j'appelle une divulgation complète.

Ainsi, après avoir discuté des exigences et des désirs des clients, je rédigerai toujours ce que je perçois comme ils veulent et comment je procéderai pour répondre à cette exigence. Je vais ensuite leur envoyer ce que j'ai écrit et attendre qu'ils répondent par l'affirmative avant de commencer le travail.

Si c'est un grand projet (plus que disons 5 jours de travail), je prototyperai aussi. Cela leur donne une chance de changer d'avis sans changements massifs de code de ma part.

Cela ne fonctionne pas toujours, mais au moins je suis dans une position où le client sait que ce sont eux qui changent d'avis et pas moi qui les mettent en œuvre de manière incorrecte.