Le développeur du logiciel a-t-il la responsabilité de comprendre ce que le client voulait dire avec sa demande?

Une sorte de question oui / non et pourquoi?

Est-ce la responsabilité du développeur du logiciel de comprendre ce que le client voulait dire avec sa demande ou est-ce la responsabilité du client d'expliquer correctement sa demande au développeur?

La situation au travail est actuellement "le client nous a déjà expliqué ce qu'il veut. Il est de votre responsabilité de comprendre la demande, pas de poser plus de questions".

Bien que l'anglais ne soit pas ma suite, toutes les demandes sont écrites dans un anglais obscur avec des mots mal placés et des phrases difficiles à comprendre, certaines demandes supposent une compréhension préalable du système de ma part.

Je suis le 3e ou 4e développeur du système (les derniers développeurs ont quitté le travail) et cela pourrait être la raison pour laquelle le client attend une certaine compréhension du côté des développeurs.

Le système lui-même est assez désordonné à la fois dans l'interface utilisateur et au niveau du code source. Cela ressemble à du codage de singe pour moi - code et j'espère que vous obtiendrez la bonne demande, tout en ne comprenant pas réellement la demande.

En fait, je pense à quitter le travail, mais je ne l'ai pas encore fait, étant donné que je ne sais pas qui a raison et qui a tort.

Si c'est votre travail de comprendre, c'est votre travail de poser des questions jusqu'à ce que vous le fassiez

La personne que vous demandez peut être une personne qui n'est pas le client (j'ai souvent parlé à un intermédiaire, qui était en contact avec le client), donc ceux qui vous interdisent de parler au client devraient plutôt répondre eux-mêmes aux questions ou vous référer à quelqu'un qui peut.

Mais, en fin de compte, il doit y avoir QUELQUE type de communication. S'ils le nient (et fournir des documents que vous ne comprenez pas revient à nier la communication), vous devriez faire comme vos prédécesseurs: fuyez, rapidement.

Lorsque vos clients et vos supérieurs vous quittent avec une trace papier désordonnée, la seule chose que vous pouvez faire est de rassembler autant de sens que possible à partir de ce que vous avez et de commencer à rédiger des scénarios en anglais simple dans le but de structurer vos connaissances sur la façon dont le le système est censé se comporter.

Les scénarios donnés / quand / alors vous permettent d'entrer dans les détails de ce qui doit arriver et parce qu'ils sont écrits en anglais simple et structurés, vous pouvez les utiliser pour communiquer avec votre supérieur et votre client: "Écoutez, J'en suis arrivé là et je n'ai aucune idée de ce que le système est censé faire ici ".

Si vous avez simplement fui lorsque vous demandez des éclaircissements supplémentaires, même si vous avez investi des efforts pour documenter tout ce que vous faites et ne comprenez pas, les développeurs précédents ont échoué non pas parce qu'ils ne savaient pas comment communiquer les spécifications, mais parce que c'est impossible de le faire.

À mon avis, les deux (client et développeur) doivent avoir la même compréhension du problème et de sa solution.

Si vous ne comprenez pas la demande, vous ne pouvez pas créer la solution.

Vous devez donc lire les spécifications. Si la spécification n'est pas assez claire (ou s'il n'y a pas de spécification écrite), il devrait y avoir quelqu'un qui peut donner les réponses.

Je travaille dans des équipes qui ont une seule personne qui peut répondre aux questions commerciales. Ce propriétaire d'entreprise est soit un membre de la société de développement pour laquelle je travaille, qui connaît l'activité des clients, soit un membre de l'équipe des clients.

Il semble que dans votre situation spécifique, le chef de projet craint que le client ne soit ennuyé si on lui pose plusieurs fois les mêmes questions (nécessaire en raison du roulement du développeur), et que cela se répercutera mal sur lui et son entreprise.

Bien sûr, si vous ne posez pas ces questions, il vous faudra beaucoup plus de temps pour terminer / modifier le système et le résultat peut ne pas être ce que le client voulait, ce qui entraînera plus de retards et reflétera AUSSI mal sur le chef de projet et son entreprise, du moins aux yeux du client.

Il y a quelques raisons pour lesquelles le chef de projet peut choisir de ne pas vous laisser poser de questions:

1. Il ne comprend pas vraiment les conséquences négatives ou les nie.
2. Il est conscient des alternatives mais sait que le client est plus susceptible d'accepter des retards et une mauvaise qualité que des questions ennuyeuses.
3. Il joue à des jeux politiques: il sait peut-être qu'il quitte bientôt le projet et veut garder les problèmes cachés jusque-là, ou il prévoit de vous blâmer pour les problèmes causés par ce manque de communication.

La raison 2 de l'OMI est peu probable. Afin d'éliminer la raison 1, essayez de lui expliquer les alternatives et demandez-lui de faire un choix explicite entre elles - suggérez d'expliquer le problème au client pour réduire la gêne. Afin d'éliminer la raison 3, faites-le par écrit afin de pouvoir prouver que vous étiez au courant des problèmes potentiels et que vous avez essayé de les résoudre. Mais pour être honnête, si vous pensez que cela est nécessaire, vous devriez probablement vous rendre sur place le plus rapidement possible.

Je pense qu'il est toujours de la responsabilité du prestataire de services de s'assurer qu'ils ont compris les intentions des clients.

En tant qu'experts dans notre domaine, ce n'est pas seulement notre travail de rédiger des mémoires, mais aussi d'aider à guider nos clients dans le processus d'utilisation de notre service, ce qui impliquait de les éduquer sur les possibilités que nous offrons et ce que nous faisons maintenant.

Je crois qu'une approche centrée sur le client est absolument la façon de faire les choses, c'est un modèle commercial éprouvé.

Le client et les développeurs doivent travailler ensemble pour affiner leur compréhension du système.

L'entreprise de logiciels doit parvenir à un accord avec le client sur ce qui est exigé de chaque partie, c'est l'aspect fondamental d'un contrat. S'il n'y a pas de «rencontre des esprits», alors, dans un sens très réel, il n'y a pas de contrat.

En supposant que vous êtes un programmeur compétent, si la spécification n'est pas claire, il vous est tout simplement stupide de se faire dire "C'est votre responsabilité de comprendre la demande, de ne pas poser plus de questions".

Ceci est basé sur de nouvelles informations dans les commentaires sur la question d'origine.

La déclaration selon laquelle

le client nous a déjà expliqué ce qu'il voulait. Il est de votre responsabilité de comprendre la demande, de ne pas poser plus de questions

vient du chef de projet; la justification indiquée est

comme je ne suis pas le premier développeur du système, nous ne devrions pas déranger le représentant du client avec plus de questions, mais essayez et si nécessaire, passez plus de temps à interpréter la question

Donc, ce qu'on vous dit spécifiquement d'éviter, c'est de déranger le client avec des questions .

Vous demander de «passer plus de temps à interpréter la question» n'est pas nécessairement déraisonnable. Vous devez faire un effort raisonnable, ou peut-être même un peu déraisonnable, pour déterminer quelles sont les exigences basées sur ce que le client a réellement dit. Si rien d'autre, c'est une compétence précieuse.

Si cela échoue (et il semble que ce soit déjà le cas, pour diverses raisons), demandez de l'aide à votre chef de projet. Essayez d'être aussi précis que possible dans vos questions, en montrant que vous avez fait vos devoirs. Par exemple, plutôt que

qu'est-ce que ces gens veulent ??? »

demander quelque chose comme,

Au paragraphe 17 du document sur les exigences, il est dit que le foobar doit frotter le surgelé; à laquelle de ces trois glaces cela fait-il référence? "

Ou, si les exigences sont vraiment si mal écrites que vous ne pouvez pas les déchiffrer, dites-le lui.

Je dirais que c'est en fin de compte la responsabilité du chef de projet de s'assurer que les exigences sont bien comprises (il est certainement dans son intérêt que le projet réussisse). Mais en tant que membre de l'équipe, vous partagez une partie de cette responsabilité. Si vous montrez que vous avez fait des efforts vous-même et que le chef de projet refuse de vous aider, alors il en a fait entièrement votre responsabilité. Si cela arrive à ce point, assurez-vous qu'il le sait.

Dans un monde parfait, il devrait y avoir une liste de fonctionnalités et de spécifications quelque part, quelque chose d'écrit sur un contrat liant votre entreprise et votre client.

Pour répondre à votre question, le développeur doit en effet comprendre ce que veut le client, et disposer d'un document écrit pour que les deux parties s'accordent sur la même vision.

Bien sûr, ce n'est pas un monde parfait et souvent il n'y a pas de spécifications, et si vous n'avez aucune spécification écrite, eh bien, ça va être difficile. Y a-t-il quelqu'un dans votre entreprise qui travaille comme délégué aux relations avec le client, qui pourrait vous aider à comprendre ce que le client veut?

Sinon, à votre place, j'essaierais d'obtenir des informations des développeurs précédents, en supposant qu'ils ont bien sûr compris la tâche.

Je pense que le rôle réel qui spécifie qui prend soin de comprendre les exigences varie en fonction de certaines de ces variables

• Taille de l'équipe
• Normes de l'entreprise
• La façon dont le patron est habitué à travailler
• Expertise différente parmi les membres de l'équipe

Donc, si vous n'êtes qu'une équipe d'un seul homme, vous devez faire tous les efforts pour aller au fond des demandes. si vous êtes nouveau dans un projet en cours, vous devez faire un effort pour revoir les demandes avec le client.

EDIT: Plus important encore, le client peut ne pas savoir qu'il a fait des exigences aussi médiocres, et le processus de collecte des exigences est souvent long et fastidieux, mais c'est un processus important, et si cela vous incombe parce que personne d'autre ne le fait, alors vous devriez faites-le avec eux.