Lacune en matière de communication: utilisateur et analyste-concepteur

Question

La pratique habituelle est d’utiliser des études de cas, de construire des flux de travail et de données, etc. Mais cela ne crée pas nécessairement un vocabulaire partagé entre l’utilisateur / sponsor et l’analyste-concepteur: l’un ou l’autre, normalement les deux, acquérir les conditions et les points de vue des "internals". des autres domaines d’expertise, ce qui conduit généralement à des incompréhensions et à des réunions de clarification (entrez dans les techniques RAD telles que le prototypage évolutif), etc.

L’utilisateur / sponsor se concentre sur ses besoins / son environnement et ne souhaite ni ne devrait être obligé d’acquérir, de son point de vue, une "terminologie de programmation" non liée. La responsabilité d'apprendre un nouvel environnement incombe à l'analyste / concepteur (/ programmeur).

Comment surmontez-vous la courbe d'apprentissage? Qu'est-ce qui fonctionne pour vous lorsque vous êtes confronté à un utilisateur qui souhaite une solution logicielle?

Answer 1

Essayez d'éliminer autant que possible les étapes intermédiaires entre l'utilisateur et le responsable de la mise en œuvre final. Chacune de ces étapes masque et perd des informations. Les membres les plus utiles de votre équipe peuvent être des personnes pouvant porter les deux combinaisons - "interface". avec les utilisateurs, et effectivement mettre en œuvre la chose.

Si ce n'est pas le cas, assurez-vous de disposer de itérations rapides et mettez-les en œuvre de manière itérative. Il est facile de le confondre progressivement. La différence est que, avec l'approche itérative, vous disposez d'une large gamme de fonctionnalités mises en œuvre dans une faible mesure, mais de manière uniforme. Dans l’approche incrémentielle, vous implémentez d’importants blocs de fonctionnalités les uns après les autres.

Dans l'approche itérative, vous bénéficiez de la agilité. L'utilisateur a changé d'avis, ou il y a eu un malentendu? Pas de problème, il reste encore de la place pour changer. Peu d’efforts ont été déployés, même, espérons-le.

Answer 2

J'utilise les commentaires

"Si vous ne pouvez pas expliquer votre physique à une serveuse, ce n'est pas une très bonne physique" et "Vous ne comprenez pas vraiment quelque chose à moins que vous puissiez l'expliquer à votre grand-mère". (Attribué à Rutherford et Einstein)

comme mantras quand je parle des besoins avec les clients.

Adoptez une approche à deux volets, une présentation de haut niveau, Powerpoint ou un tableau blanc, et laissez les utilisateurs perdants sur un POC ou une maquette.

Ensuite, définissez les exigences détaillées, ligne par ligne. Le diable est dans les détails. Demandez-leur de signer ces détails. Étiquetez-les et numérotez-les pour qu'ils puissent effectuer une analyse ligne par ligne.

Si vous définissez les exigences détaillées avant le jeu de haut niveau, les utilisateurs ne comprendront jamais aucun concept de la conception et ne s’enliseront pas dans les plus infimes spécifications. Sans aucun cadre, ni concept, les utilisateurs détermineront le nombre d'anges sur la tête d'une épingle.

L'agilité et les itérations sont bonnes, à condition que le client et l'équipe de développement puissent parler un langage similaire. Assurez-vous que les attentes sont définies et satisfaites.

Answer 3

Un bon concepteur d’interaction devrait être capable de décrire le fonctionnement du logiciel en termes simples. Sinon, il ne devrait pas faire d'interface, à mon humble avis.

Answer 4

Il faut toute une gamme de techniques et les deux parties doivent apprendre à comprendre un peu les affaires de l’autre: les analystes doivent comprendre le domaine de l’utilisateur et l'utilisateur doit se familiariser avec certaines des techniques de analystes.

Je trouve que Process Flows est un bon moyen de commencer, de s’entendre à un haut niveau sur le fonctionnement de l’entreprise. Certains utilisateurs maîtrisent bien les modèles de données (les DRE, par exemple), mais généralement, je dirais que non: ils répondent souvent mieux lorsque les règles sont énoncées dans du texte, par exemple.

• Une commande peut comporter une ou plusieurs lignes de commande
• Chaque commande a un numéro de référence unique à 10 chiffres

Ils peuvent lire et cocher ou croiser ceux-ci beaucoup plus facilement qu'ils ne peuvent contrôler la qualité d'un DRE.

Ensuite, rien ne vaut les esquisses d’écrans de saisie et de rapports permettant aux utilisateurs de se concentrer sur les détails de ce qu’ils veulent.