Les «bogues» de conception sont-ils un mauvais signe?

Est-ce un mauvais signe si les utilisateurs soumettent des rapports de bogues pour des choses qui sont par conception?

Cela signifie-t-il généralement que l'application est source de confusion ou n'est pas claire, ou devrais-je simplement la signaler à une erreur utilisateur ponctuelle, sauf indication contraire?

(Je n'ai pas réellement de tels rapports. Il s'agit d'une question purement hypothétique sur la question de savoir si l'existence de "bogues" de conception est une mauvaise chose.)

Est-ce un mauvais signe? Je pense que c'est un avertissement qui mérite d'être examiné, mais je pense également que cela arrivera.

Lorsque les gens me soumettent des commentaires, j'essaye de les filtrer en trois compartiments:

• Bogues
• Requêtes de nouvelles fonctionnalités
• Miscommunication

Bogues

Les bogues surviennent lorsque quelque chose ne fonctionne manifestement pas comme vous vous attendez, ni comme l' utilisateur le devrait. Comme, il m'a demandé mon nom, j'ai entré "Scott", appuyez sur Entrée, et il a dit: "Salut Joe!"

Requêtes de nouvelles fonctionnalités

C'est comme "Je sais que nous n'en avons jamais parlé, mais le programme peut-il déduire de mes gestes de souris que je suis gaucher et déplacer le bouton OK sur le côté gauche de l'écran?" C'est à ce moment que le comportement actuel correspond à la fois à vos attentes et à celles de l'utilisateur , mais qu'il souhaite modifier l'attente.

Miscommunication

C'est à ce moment que vous attendez un résultat d'un scénario, mais que l' utilisateur attend un résultat différent. Parfois, cela devient une demande de fonctionnalité, s'ils n'ont tout simplement pas communiqué leurs attentes, mais qu'ils pensaient l'avoir fait. Parfois, cela devient un bogue s'il s'avère que votre attente est fausse.

Cependant, vous savez souvent que l'utilisateur n'en a pas. Et s'ils disaient: "Sur cet écran, je peux ajouter un enregistrement pour moi deux fois avec le même prénom et le même nom! C'est évidemment un bug!" Votre réponse pourrait être: «Il y a beaucoup de personnes dans le monde avec le même prénom et le même nom, nous n'avons donc pas besoin que cette combinaison soit unique. Nous avons une tâche de nettoyage qui s'exécute la nuit et envoie un rapport de doublons possibles par e-mail à service client lorsqu'il pense qu'il détecte un doublon avec un nom et une adresse similaires, et leur demande de le vérifier manuellement. "

Vous devriez donc lire chaque rapport de bogue, mais la plupart des systèmes complexes auront des rapports de bogue qui ne sont en réalité que des demandes de fonctionnalités, ou peut-être une mauvaise communication des exigences. Ne pas comprendre la complexité sous-jacente du monde réel est probablement la plus grande source de ces problèmes.

Cela n'a pas été abordé dans les réponses précédentes jusqu'à présent, donc j'ajouterai que cela pourrait également être le signe d'une base d'utilisateurs ignorants. Je n'utilise pas le mot «ignorant» de manière désobligeante ou condescendante, simplement comme un moyen d'exprimer qu'ils sont sans connaissances ou éducation appropriées dans leur domaine ou de la complexité du logiciel lui-même.

La plupart des utilisateurs ne savent pas à quel point un logiciel doit être compliqué pour répondre à certaines exigences. Quelque chose à l'effet de 80% de l'effort n'entre que dans 20% des fonctionnalités (cas marginaux et exceptionnels).

Parfois, ils ne comprennent pas pourquoi le logiciel doit intrinsèquement se comporter d'une certaine manière, souvent pour éviter une multitude de défauts ou de corruption de données, etc.

Ce n'est pas inquiétant car cela s'améliore avec une documentation et une communication claires et concises.

Si vous avez un utilisateur expert dans son domaine, vous pourriez avoir un problème majeur. Imaginez un comptable qui trouve votre logiciel, par conception, ne suit pas les procédures comptables générales ou un ingénieur qui découvre que vous avez une formule incorrecte. Cela ne devrait pas être trop difficile à rechercher pour voir s'ils sont corrects. Reconcevoir et réparer si besoin-rapide.

Une opinion sur une fonctionnalité d'interface utilisateur particulière ou un champ qui, selon eux, devrait avoir un symbole monétaire ou un autre formatage, doit être prise en compte, au moins jusqu'à ce que vous obteniez plus de commentaires. La recherche pourrait être un peu plus difficile.

D'après mon expérience, les bogues de conception signifie que vos cas d'utilisation ne correspondent pas à vos utilisateurs réels. Essayez de lire comment utiliser de vrais utilisateurs pour vos cas d'utilisation (leur donner simplement des noms et une description miniature fait des merveilles pour la qualité des cas d'utilisation.)

Lorsque d'importants fournisseurs de systèmes d'exploitation déclarent que «ce comportement est inhérent à la conception», ils avaient généralement à l'esprit la facilité de mise en œuvre ou l'avantage commercial. Si ce n'est pas vous, essayez de découvrir les compétences et les relations réelles de vos utilisateurs avec votre logiciel. L'utilisent-ils toute la journée? Pour s'amuser ? Une fois par semaine car il remplaçait les formulaires TPS?

L'interface utilisateur doit suivre le principe du moindre étonnement - des rapports de bogue répétés sur une fonctionnalité qui fonctionne comme prévu sont une indication que ce principe n'a pas été respecté correctement.

Il existe deux types de bogues: la fonctionnalité ne correspond pas aux intentions du programmeur, ou la fonctionnalité ne correspond pas aux exigences. Les programmeurs ont tendance à se concentrer sur les premiers au détriment des seconds. Pour le dire simplement, si vos utilisateurs signalent beaucoup de "bogues de conception", vos exigences ne sont pas ce que vous pensez qu'elles sont.

Pas nécessairement. Il se pourrait que le bogue signalé soit dans une utilisation du logiciel qui est juste en dehors de sa portée initialement définie. Considérez un logiciel conçu pour faire A, B et C (pour un exemple trivial, dessinez des lignes, des triangles et des rectangles). Si D est une prochaine étape logique (par exemple les pentagones), l'utilisateur peut supposer qu'il devrait le faire également, et que ne pas le faire est un bug. Mais si cela sort du cadre d'origine, ce n'est pas un bug. Il pourrait plutôt s'agir d'une erreur (bogue) dans la conception, ou d'une zone grise dans les spécifications, ou d'un ensemble différent d'hypothèses formulées par le développeur et l'utilisateur.

(Modifier - a ajouté mon commentaire à la réponse selon la suggestion de @Marjan Venema.

Je pense que c'est un mauvais signe principalement dû au fait que la conception n'est pas générique et que les exigences des utilisateurs ne sont pas entièrement comprises / analysées.

Je vois deux catogories du design, - Design par accident. - Conception par intention.

La conception par accident entraîne fréquemment de tels problèmes et ne peut pas durer.

Je voudrais ajouter à la réponse de maple_shaft sur "l'ignorance" des utilisateurs. Vous devez également garder à l'esprit que 90% des utilisateurs ne se soucient que de leur propre expérience et de leur façon d'utiliser le système. Ils ne se soucient pas des autres utilisateurs, pourquoi devraient-ils? C'est notre travail en tant que concepteurs / développeurs de recueillir les commentaires de tous les différents types d'utilisateurs et de créer quelque chose qui convient à tout le monde aussi bien que possible. La plupart du temps, vous ne pouvez pas trouver une solution optimale pour tout le monde.

Mais bien sûr, vous devez lire et évaluer les commentaires de vos utilisateurs! Ce sont, après tout, ceux qui utilisent votre création!

Les utilisateurs soumettant les demandes de bogues n'ont généralement pas été consultés sur la conception, il n'est donc pas surprenant qu'ils voient les choses comme des bogues qui étaient des décisions de conception délibérées. Pour un utilisateur, tout ce qui ne fonctionne pas comme prévu est un bogue.

J'ai trouvé que le problème est souvent un signe que le BA ou le PM n'a obtenu des exigences que des gestionnaires et non des utilisateurs réels. Ce que les gestionnaires attendent du système est souvent très différent de ce dont les personnes qui saisissent les données ont réellement besoin. On m'a appris à collecter des données directement auprès des utilisateurs réels, mais la plupart des BA que j'ai rencontrés récemment ne parlent qu'aux gestionnaires (et généralement aux cadres relativement supérieurs).