Permettre aux utilisateurs de rassembler eux-mêmes les exigences ou de les guider?

Je suis sûr que tout le monde a vécu quelque chose comme ça. Vous entrez en réunion avec un client qui a un projet. Ils n'ont pas / peu d'exigences à l'esprit et la compréhension la plus vague de ce qu'ils veulent / ont besoin. À ce stade, il semble y avoir deux options:

1) Dites aux utilisateurs: "D'accord, donc je ne peux pas construire quelque chose pour vous si vous ne pouvez même pas encore le décrire. Pourquoi ne nous réunirons-nous pas dans quelques semaines quand vous saurez ce que vous voulez".

2) Rencontrez les utilisateurs à quelques reprises et aidez-les à comprendre ce qu'ils veulent en les guidant avec la bonne vieille méthode socratique. "Avez-vous besoin de suivre X?", "Et Y?", "Avez-vous besoin de la fonctionnalité Z?"

Avec la première option, vous ne restez pas coincé à faire le travail de quelqu'un d'autre ou à gagner des pouvoirs psychiques, cependant, les utilisateurs pourraient ne jamais vous présenter une spécification cohérente, ou ils pourraient prendre une éternité alors que la date limite continue de s'approcher. Avec la deuxième option, vous perdez beaucoup de temps à devenir analyste d'entreprise et vous devez vous emparer d'un tas de connaissances commerciales que vous n'utiliserez probablement plus jamais, mais vous aurez beaucoup plus de chances de sortir une spécification qui est logique.

Pour moi, c'est l'un des aspects les plus difficiles du développement, et j'ai le sentiment que je ne suis pas seul dans ce sentiment. D'après votre expérience, laquelle de ces options a tendance à mieux fonctionner?

Je dois admettre que parfois je choisis l'option 3)

3) Écoutez les idées vagues des clients, blanchissez à l'idée de passer des semaines à les aider à comprendre exactement ce qu'ils veulent ... alors déterminez ce dont ils ont besoin, construisez-les et refactorisez-les au besoin.

Cela fonctionne, en particulier pour les petits travaux, car cela permet d'éviter les situations où les clients ont cette idée brillante en tête, ce qui n'est pas pratique dans le monde réel.

Cela m'arrive tout le temps; "nous pourrions sûrement faire ..." est une phrase très effrayante. D'autant plus que les choses mentionnées sont presque toujours les cloches, les sifflets et la catégorie de fonctionnalités "sympa d'avoir". Ils n'obtiennent pas tout à fait cela dans la déclaration "bien un traqueur de bogues évidemment, et puis ..." la majeure partie du travail potentiel repose dans les quatre premiers mots.

Ainsi, il est parfois agréable d'adopter une vision client , d'appliquer une bonne dose de programmeurs de bon sens et de créer quelque chose qui corresponde à leurs besoins.

En termes de la question d'origine; Je trouve que cela dépend beaucoup du contexte. Si je suis coincé avec le client (c'est-à-dire que c'est par le biais d'un contrat de travail auquel je suis lié ou qu'il n'y a pas d'autre travail), alors # 2 est l'approche la plus saine. Sinon, il est fort probable que dans une semaine, vous serez présenté avec une spécification merveilleuse et détaillée ... qui est complètement inutile pour vous en tant que programmeur.

À peu près le même problème que mentionné ci-dessus (# 3) et celui qui vous laisse de toute façon faire # 2.

si vous voulez être juste un programmeur, alors vous attendez que quelqu'un d'autre ait compris ce dont le client a besoin, puis le codez

si vous voulez être un développeur , et c'est votre client, alors vous prenez la main de votre client et vous le promenez doucement à travers la forêt effrayante de possibilités jusqu'à ce que vous trouviez ensemble la prairie remplie de lapins heureux à l'intersection de Wants and Needs.

ADDENDA: ce processus est appelé "analyse et conception de systèmes" aka Consulting, et il ne devrait jamais être fait gratuitement

La programmation consiste au préalable à résoudre les problèmes des utilisateurs. Donc, pour moi, entrer dans des efforts et des souffrances «supplémentaires» afin d'obtenir une solution satisfaisante et fonctionnelle pour nos utilisateurs l'emporte presque toujours en évitant les tracas «supplémentaires» et en ne fournissant rien d'utile à la fin.

(Bien sûr, il y a de vrais utilisateurs qui n'ont vraiment aucune idée de ce qu'ils veulent, et aucun effort ne peut les amener dans un état où ils peuvent prendre une décision significative. Mais je crois que dans la plupart des cas, ils ont un vrai problème, ils sont prêts à dépenser des efforts et de l'argent pour le résoudre, et ils seront heureux si nous pouvons les aider à se rapprocher d'une solution de travail.)

Donc, l'essentiel est que notre objectif soit de résoudre les problèmes des utilisateurs. Cela peut parfois nécessiter de poser des questions ciblées et de leur donner plus de temps pour trouver les réponses. Parfois, cela nécessite de cartographier le domaine ensemble, en étroite coopération. Parfois, cela nécessite de passer du temps à faire de simples croquis / prototypes / maquettes, puis à leur montrer le résultat et à demander "cela ressemble-t-il à ce que vous aviez en tête?" (puis jeter le prototype quand ils disent "en fait, je pensais à quelque chose de complètement différent ..." et recommencer ... :-)

La vraie compétence est de choisir la bonne approche au bon moment.

Enfin, selon mon expérience, les bonnes solutions nécessitent presque toujours au moins une certaine connaissance du domaine de la part du développeur. Sans cela, vous n'avez pas de véritable langage commun avec l'utilisateur, il n'y a donc aucune garantie que ce que vous livrez leur sera vraiment utile. Les utilisateurs n'ont généralement pas beaucoup d'indices sur la technologie, donc n'ont aucune idée de ce qui est et n'est pas possible, et du coût des différentes approches / fonctionnalités. Comme nous ne pouvons raisonnablement nous attendre à ce qu'ils apprennent la technologie avec suffisamment de détails, nous devons prendre cette mesure supplémentaire de notre côté du pont.

Cela peut être considéré comme un effort "supplémentaire" qui ne rapporte pas - cependant, je préfère le voir comme un investissement, pour deux raisons:

• cela m'aide à fournir de bonnes solutions, ce qui à long terme augmente ma valeur marchande en tant que développeur, et
• différents domaines ne sont pas complètement distincts, donc au moins une partie de cette connaissance de domaine sera probablement réutilisable dans de futurs concerts.

En tant que développeur de logiciels, une partie de votre tâche consiste à acquérir une compréhension suffisante du domaine dans lequel le logiciel va être utilisé. Ainsi, faire partie de la phase naissante d'un projet est extrêmement précieux (en termes de temps et d'expérience client) . Oui, cela signifie faire une analyse approfondie du domaine et des exigences. C'est le moment idéal pour incorporer les utilisateurs cibles, les interroger ou se promener à l'endroit où votre logiciel sera utilisé.

Mais, acquérir cette compétence est presque une forme d'art, surtout lorsque le domaine n'est pas connecté à une discipline d'ingénierie. Vos questions évidentes peuvent sembler intimidantes pour le client, votre présence in situ peut ne pas être souhaitée, votre manque de compréhension de la structure sociale de votre public cible peut ruiner les connexions encore fragiles.

Ne pas comprendre les subtilités de cette phase conduit souvent à la déception, tant chez les développeurs de logiciels que chez le client. Nous aimerions traverser cette phase toujours plus rapidement ou nous en débarrasser complètement. Les résultats sont souvent désastreux: après un démarrage accéléré, les enjeux de réussite sont de plus en plus importants au cours du développement et il devient de plus en plus difficile de revenir à la planche à dessin. Lorsque le système est enfin terminé et que des millions ont été dépensés, ni le client, ni la firme d'ingénierie ne sont prêts à admettre sa défaillance, ce qui a conduit à l'introduction forcée d'un système défaillant.

Une alternative consiste à laisser un analyste d'entreprise faire le travail pour vous. Cela peut être judicieux pour certains produits, et l'analyste peut souvent être un intermédiaire, mais cela ne fera que créer plus de canaux de communication (et donc un risque d'erreur plus élevé).

Dans tous les cas: la réécriture d'un morceau de code ne l'emporte jamais sur la réécriture d'un morceau d'exigences.

ps vous pensez peut-être que je préconise la méthode de la cascade. Je ne suis pas partisan de la «grande conception d'avance», mais je crois que l'effort d'analyse de domaine devrait être proportionnel à l'effort de mise en œuvre. On peut faire plusieurs cycles (prototype, libérer des candidats, etc.).

Certainement l'option 2, sauf si vos utilisateurs sont des développeurs (même alors, l'option 2 peut être nécessaire).

La plupart des cycles de vie de développement logiciel se concentrent sur la collecte des exigences. Non seulement la plupart des utilisateurs ne savent pas ce qu'ils veulent, mais ils ne savent pas non plus ce qui est possible, donc travailler avec l'utilisateur pour comprendre ses besoins est une tâche critique de développement logiciel.

Je pense que vous devez choisir les deux options. Laissez-les partir et décidez ce qu'ils veulent. Ensuite, quand il y a une idée concrète à utiliser comme point de départ, guidez-les pour aider à affiner les exigences en quelque chose d'utile.

Vous ne voulez pas sauter dans l'option # 2 quand ils peuvent à peine exprimer ce qu'ils veulent car cela rendra le processus plus lent et plus frustrant (à moins qu'ils aient déjà une idée très claire de ce qu'ils veulent quand ils viennent à vous, mais d'après mon expérience, c'est très rare). Faites-leur rassembler leurs idées. Demandez-leur d'écrire quelque chose sur papier, de décrire si possible ce qu'ils veulent en termes de systèmes existants (ex. "Nous voulons un site Web comme blahblah.com mais avec ces différences ... nous voulons un outil qui exécute la tâche A comme le produit X , mais l'interface utilisateur doit également effectuer la tâche B ... "). Ensuite, c'est le bon moment pour commencer à affiner ce qu'ils veulent en exigences très spécifiques que vous pouvez utiliser pour construire le système.

En général, les clients viennent vous voir en sachant exactement de quoi ils pensent avoir besoin. Malheureusement, c'est ce qu'ils vous diront, au lieu de décrire les problèmes qui conduisent à la solution qu'ils pensent que vous apporterez.

Pour concevoir quelque chose qui répondra à leurs besoins, vous devez identifier ces besoins, et pour ce faire, quelqu'un devra retenir le client et extraire ces besoins. Si personne d'autre ne peut le faire, vous devez le faire. (Si quelqu'un d'autre le pense, vous devrez peut-être vous asseoir avec lui et extraire les vrais besoins plus tard ...)

Avec l'option 2, sur un certain nombre de réunions, vous pouvez, espérons-le, former le client à partager des problèmes avec vous plutôt que des solutions. (Même si le client a des capacités techniques - par exemple, il n'a pas de disponibilité pour faire ce travail et a besoin que vous le fassiez à la place - il peut toujours se concentrer sur une implémentation qui n'est pas idéale pour le client final.) Peu importe le processus de développement que vous utilisez, vous devrez toujours faire plusieurs allers-retours jusqu'à ce qu'ils puissent répondre aux questions de manière à définir les spécifications pour vous.

N'oubliez pas que vous souhaitez détecter les défauts le plus tôt possible dans le cycle de développement. Si vous pouvez les attraper pendant les exigences plutôt que pendant le codage ou les tests, vous vous économiserez beaucoup de temps.

L'option 1 est un excellent moyen d'éviter de faire du travail. Je l'ai utilisé quand je pensais que le travail n'était pas nécessaire ou que j'avais des choses plus importantes à faire.

Premièrement, les utilisateurs ne savent pas ce que les ordinateurs peuvent faire. La plupart d'entre nous ont passé des années à apprendre à comprendre les ordinateurs et le calcul, et ce qui est évident pour nous pourrait ne pas être facilement compréhensible pour quelqu'un qui a passé ces années à apprendre d'autres choses.

Deuxièmement, les utilisateurs ne savent pas nécessairement ce dont ils ont besoin et ne savent généralement pas ce qu'ils veulent, dans un sens concret.

Pour donner une analogie, lorsque j'ai acheté ma maison actuelle, un architecte d'intérieur a sélectionné les couleurs des murs pour les pièces du rez-de-chaussée principal (États-Unis d'abord, Royaume-Uni). Je n'aurais jamais choisi ces couleurs moi-même. Je voulais une maison qui avait l'air bien, et je l'ai eue. Si le designer m'avait écouté et m'avait donné tout ce que je pouvais articuler, cela n'aurait pas été aussi bien sorti.

La seule façon de donner aux utilisateurs quelque chose qui fait ce dont ils ont besoin d'une manière qu'ils aiment est de travailler avec eux-mêmes.