Un programmeur doit-il «penser» pour le client?

J'ai atteint le point où je déteste la collecte des exigences. Les clients sont trop vagues pour leur propre bien. Dans un environnement agile, où nous pouvons montrer au client un travail à accomplir, ce n'est pas trop mal car nous pouvons apporter de petites corrections / mises à jour régulières des fonctionnalités.

Dans un environnement de type «cascade» (exigences d'abord, produit presque complet ensuite), les choses peuvent devenir laides. Ce type d'environnement m'a conduit à remettre constamment en question les exigences. EG Le client souhaite "convertir automatiquement l'entrée en nombre 1" (en référence à une quantité dans une commande). Mais ce à quoi ils ne pensent pas, c'est que "l'entrée" pourrait être un simple type-o. Un "x" dans une zone de texte pourrait être un "woops", je ne veux pas 1 de ces produits "dentifrice". Mais, il y a tellement de choses dans l'air avec des exigences que je pourrais rester debout et corriger pendant des heures en écrasant ce qu'elles veulent. Ce n'est tout simplement pas sain.

Travaillant pour une entreprise, je pouvais essayer d'ajuster la culture pour l'adapter au modèle agile qui nous aiderait (pas un petit travail, au-dessus de mon salaire). Ou balayez les moindres détails sous le tapis et espérez le meilleur. Peut-être que mon client essaie de se rapprocher trop du code?

Comment gérer le problème de «penser pour le client» sans le faire chier avec trop de questions?

Dans la plupart des cas, le client ne sait pas quoi faire d'autre. Ils n'ont jamais eu à décrire ce dont ils ont besoin d'une manière qui le rende sans ambiguïté pour nous. Dans leur esprit, c'est clair. Même le fait qu'ils envisagent de convertir les entrées des utilisateurs au numéro 1 va vraiment au-delà de la façon dont ils sont habitués à penser.

C'est vraiment comme ça que ça devrait être. S'ils vraiment nouveau comment décrire exactement ce qu'ils voulaient, ils n'auraient pas besoin de nous pour l'écrire pour eux. Par conséquent, notre responsabilité est de les aider tout au long du processus. Le processus exige que des décisions soient prises, ils ont donc également besoin de nos recommandations pour faciliter le processus de décision.

Alors, laissez le client être vague et parler à un niveau élevé. Ils connaissent leur métier, et c'est pour ça qu'ils sont bons (j'espère, sinon ils ne pourront pas payer vos factures ...). Prenez ce dont ils ont parlé et réfléchissez- y un moment. Finalement, vous obtenez d'excellentes idées pour leur fournir ce qu'ils veulent et ce dont ils ont besoin, tout en s'assurant que ce dont vous avez besoin est testable et cohérent.

Je recommande fortement de travailler en morceaux. Lorsque vous rencontrez le client, vous avez un ensemble d'exigences liées les unes aux autres, puis expliquez comment vous avez l'intention de faire ce qu'il veut. Expliquez également pourquoi vous avez fait les choix que vous avez faits. Le client peut alors regarder ce que vous avez fourni et le peaufiner. Si vous obtenez une réponse du type «Je n'y ai jamais pensé, mais cela aiderait vraiment», vous savez que vous avez une impulsion sur la façon dont le client pense. REMARQUE: ce n'est pas une fonctionnalité, c'est la sélection des fonctionnalités appropriées pour répondre au mieux au problème commercial du client.

Si vous avez quelque chose qui pourrait contredire ce que le client vous a dit explicitement, alors il est temps d'expliquer pourquoi. Vous devrez mettre en évidence certains problèmes auxquels le client n'a jamais pensé, et comment votre alternative leur donne toujours ce qu'ils veulent / ont besoin, mais évite également ces problèmes potentiels. Vous pouvez obtenir un peu de recul, mais cela renforce également la confiance des clients lorsqu'ils se rendent compte que vous essayez de leur donner un produit qu'ils peuvent vraiment utiliser. S'ils donnent du recul, cela les oblige à expliquer pourquoi ils voulaient quelque chose d'une certaine manière. Cela vous aide à mieux comprendre votre client et à adapter les exigences au besoin.

Le moyen le plus rapide d'user votre client est de poser toutes les petites questions l'une après l'autre. Vous souhaitez planifier et planifier une série de réunions pour revoir votre approche. Tant que vous possédez les exigences techniques (ce que votre équipe utilise pour créer le produit) et que votre client possède les exigences commerciales et que vous pouvez les relier ensemble, vous avez un moyen de combler l'écart.

Si vous les «faites chier» à cause de trop de questions, trouvez un meilleur client.

Les clients ne savent pas ce qu'ils veulent. Ils ne reconnaîtront pas nécessairement leur solution lorsqu'ils la verront. C'est un problème, et c'est le travail que vous résolvez: traduire leurs besoins en quelque chose qui peut être livré sous forme de progiciel.

Pour ce faire, vous devez apprendre ce que vous faites. Vous ne devriez pas demander "ce qui devrait arriver quand ils mettent un nombre dans une zone de texte", vous devriez demander "pourquoi ce nombre est-il important? À quoi sert-il?" Demandez-leur de vous apprendre comment ils font leur travail. Et n'écoutez pas ce qu'ils disent, parce qu'ils ne savent pas ce qu'ils veulent, mais regardez ce qu'ils font et où vont leurs yeux .

Lisez ceci pour plus d'informations: http://www.joelonsoftware.com/articles/fog0000000356.html

En supposant que vous êtes un employé d'une sorte de société, il semble que vous ayez besoin d'un bon analyste commercial pour aider à la médiation de ces détails entre le client et vous-même. Je suppose que vous n'avez pas assez d'influence pour que cela se produise, donc mon prochain meilleur conseil serait d'en savoir plus sur le domaine dans lequel vos clients travaillent. En comprenant l'entreprise et les processus avec lesquels elle travaille, vous ' J'aurai une meilleure idée de ce qu'ils veulent vraiment faire, malgré la manière lâche et peut-être erronée qu'ils le décrivent. Cela vous permet d'analyser ce qu'ils ont demandé, et vous pouvez revenir plus tard dans une réunion séparée avec une interprétation de ce qu'ils veulent et une suggestion possible pour leur donner ce qu'ils veulent vraiment. Si vous travaillez régulièrement avec les mêmes clients, vous '

Si cela semble très difficile, douloureux, extrêmement désagréable ou irréaliste, mon dernier conseil serait de commencer à chercher un nouvel emploi quelque part où ils ont des analystes commerciaux, car cela ne vous sera pas plus facile sans faire des efforts.

Si vous rassemblez des exigences, c'est votre travail de poser ces questions.

Oui, le client pourrait être agacé, mais dans ce cas, vous devez expliquer pourquoi vous posez "toutes ces questions". Vous devez comprendre leur entreprise avant de pouvoir écrire le code qui automatisera cette entreprise. Le truc serait que si vous ne le faisiez pas, ils dépenseraient beaucoup d'argent pour développer un système qui ne fait pas vraiment ce qu'ils veulent.

L'effet secondaire de cela est que vous devriez finir par aider le client à affiner ses exigences.

Cela s'applique que vous utilisiez Big Design Up Front ou Agile.

Malheureusement, c'est votre travail de penser pour le client s'il ne peut pas ou ne veut pas le faire lui-même.

J'ai eu les deux résultats possibles:

• le client est heureux que vous pensiez réellement à ce qu'il vous dit, il se sent entre de bonnes mains, ou

• le client est agacé parce que vous le forcez à repenser ses exigences. Mais alors, ce type de client vous importunera de toute façon, tôt ou tard. Il sera certainement très ennuyé s'il découvre trop tard que vous n'aviez pas pensé pour lui au début. Je dirais: évitez ce type de client si possible :-)

Un développement rapide d'application (RAD) résout bien ce problème.

Commencez par «penser pour le client» en créant une interface utilisateur non fonctionnelle très approximative pour le programme en fonction de votre meilleure estimation de ce dont ils ont besoin. Ensuite, montrez-le-leur et travaillez de manière itérative jusqu'à ce que vous répondiez à leurs besoins réels.

Ce n'est pas qu'ils ne savent pas ce qu'ils veulent. C'est qu'ils ne savent pas ce qu'ils veulent jusqu'à ce qu'ils le voient, et parfois vous pouvez déterminer ce qu'ils veulent par exclusion. C'est-à-dire, leur montrer quelque chose qu'ils NE veulent PAS et prêter attention à la façon dont ils le critiquent.

Le principal problème avec BFUD (Big Up Front design) est qu'il isole le développeur du blâme en forçant le client à conclure un contrat qui décrit explicitement ce qu'il va obtenir. Et malheureusement, cela se fait au moment où personne sur le projet n'a une bonne idée de ce qui est vraiment nécessaire. En fin de compte, cela fait simplement accepter au client ce que vous avez construit parce qu'il a signé, mais à contrecœur.

Si le client n'est pas satisfait du produit livrable, ce n'est qu'une victoire à la Pyrrhus.

Le travail du client est de vous relayer ce dont il a besoin. Votre travail consiste à comprendre suffisamment ce dont ils ont besoin pour pouvoir programmer ce dont ils ont besoin. Une question évidente à la question de changer toutes les entrées en une seule serait de dire "Pourquoi voulez-vous qu'il change toutes les entrées en 1?" Ensuite, le client peut expliquer le raisonnement sous-jacent afin que vous compreniez le besoin et que vous puissiez ensuite fournir non nécessairement ce qu'il demande, mais ce dont il a besoin. Si vous êtes sûr de savoir ce dont ils ont besoin, je ne pense pas que vous ayez nécessairement besoin de "corriger" leur façon de penser. Ils utiliseront le produit et la chose "Oh! C'est parfait". Mais à moins que vous ne soyez sûr de savoir ce dont ils ont besoin, vous devrez ensuite expliquer ce que vous pensez et travailler avec le client. Malheureusement là ' s aucun moyen d'effectuer cette partie du processus sans beaucoup de communication, ce qui implique une véritable écoute sur les deux parties. Faites attention de ne pas être ennuyé par la situation et de dire des choses que vous pouvez ou ne voulez pas vraiment dire.

Honnêtement: à moins que ce ne soit une «grande fonctionnalité», demandez à la personne ayant le plus de connaissances dans le domaine de deviner ce qui devrait se passer et de l'implémenter. Il sera étoffé dans les tests d'acceptation - c'est à cela que cela sert.