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

29

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.)

bug users

— Maxpm
source

19

Peut-être que certains des programmeurs de Lotus Notes aimeraient commenter, car la réponse standard est "ce n'est pas un bug, c'est une fonctionnalité que vous ne comprenez pas".

— James Anderson

5

Cela me suggère que les exigences des utilisateurs telles que données aux développeurs ne correspondent pas à ce que les utilisateurs pensent avoir demandé.

— temptar

7

@temptar "C'est ce que j'ai demandé, mais ce n'est pas ce que je voulais."

— StuperUser

5

Un élément de travail «bogue» m'a récemment été attribué pour un comportement qui était exactement, spécifiquement, ce qui était explicitement énoncé dans la spécification (et qui avait été discuté pendant la phase de spécification). Alors que le comportement peut très bien avoir été inattendu du point de vue d'un utilisateur (un paramètre particulier, qui a fait attention ailleurs, a été ignoré), si la spécification littéralement tout mais dit "ignorons cela pour l'instant pour gagner du temps", alors pour moi ce n'est pas un bug, mais plutôt une demande de changement. Certes, un bon argument pourrait être fait pour que cela change, mais ne l'appelez pas un bug .

— un CVn du

7

@Dunk: J'ai implémenté un système qui supposait 24 heures par jour, car nous n'avons pas réussi à convaincre le client de l'existence de l'heure d'été. Ils ne pourraient tout simplement pas croire qu'il y a des jours avec 25 heures. Est-ce un bug dans le programme?

— MSalters

54

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.

— Scott Whitlock
source

3

Une mauvaise communication comprend également un mauvais souvenir (ou un simple oubli) des attentes qui ont été communiquées et acceptées.

— Peter Taylor

1

De grandes distinctions, mais je pense toujours que la demande devrait tenter d'expliquer la mauvaise communication si elle le peut. Avec vos multiples personnes portant le même nom, l'application pourrait dire: «Nous avons déjà 3 John Smith, êtes-vous sûr que ce n'est pas l'un d'entre eux» avec une option «Non, je suis sûr que c'est un nouveau John Smith».

— Alex Andronov

@Alex Andronov - une mauvaise communication ne signifie pas qu'il n'y a pas d'action à entreprendre: modifiez la documentation, les info-bulles, etc., mettez à jour le matériel de formation, ou peut-être juste une brève explication et continuez.

— Scott Whitlock

7

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.

— maple_shaft
source

2

+1 mais veuillez rechercher la différence entre complexe et compliqué ... Le logiciel n'a pas besoin d'être compliqué du tout, mais il est souvent très complexe.

— Marjan Venema

C'est très vrai. Le cas le plus courant que je rencontre est que les utilisateurs ne réalisent pas la différence entre les relations plusieurs-à-un et plusieurs-à-plusieurs. Une demande courante que je reçois est: "pouvez-vous faire en sorte que le rapport affiche le numéro de commande dans l'en-tête?" et je dois expliquer que, alors que dans environ 95% des cas, il n'y a qu'un seul numéro de commande sur les éléments sur lesquels ils travaillent, il existe de nombreux cas où la requête peut inclure des données sur plusieurs commandes. Ensuite, je dois demander, voulez-vous que je liste tous les numéros de commande dans l'en-tête séparés par des virgules ou voulez-vous le numéro de commande sur chaque ligne de détail du rapport?

— Scott Whitlock

@ScottWhitlock Oui, c'est la même chose. Un bon développeur ou analyste d'entreprise ne devrait pas simplement faire ce que le client demande, mais essayer de découvrir le problème principal qu'il rencontre pour expliquer pourquoi il a fait une telle demande en premier lieu. Une fois que vous avez identifié leur problème, vous pouvez identifier une solution appropriée et rédiger des exigences appropriées ou des histoires d'utilisateurs.

— maple_shaft

5

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.

— JeffO
source

1

Il n'y a donc pas de réponse unique, je suppose. Il doit être évalué au cas par cas. Je ai pensé autant.

— Maxpm

5

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?

— Tim Williscroft
source

5

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.

— Joris Timmermans
source

3

Ou, qu'il existe un groupe d'utilisateurs divisé. Par exemple, supposons que votre application Web mimmicks un bureau. Vous attendez-vous à ce que la fermeture d'une fenêtre ferme le programme? Oui pour les utilisateurs Windows, Non pour les utilisateurs Mac.

— keppla

1

@Keppla - vous faites valoir un bon argument. Vous ne pouvez pas plaire à tout le monde, donc dans le cas de "bugs" comme ceux mentionnés ici, une enquête est nécessaire pour vous assurer que vous n'obtiendrez pas plus de rapports de bugs après la "correction" qu'auparavant.

— Joris Timmermans

1

peut-être, mais il est beaucoup plus puissant de citer les données de "des centaines de personnes ont déposé des bugs à ce sujet!" que d'avoir quelques utilisateurs enragés vous disant que vous avez violé leur interprétation personnelle du principe magique du moindre étonnement et qu'ils sont étonnés. Je suis un peu las de ce dernier, car "l'étonnement" d'un homme est "simple" pour un autre.

— Jeff Atwood,

@Jeff Atwood - comme le dit le proverbe "une hirondelle ne fait pas un été", "un rapport de bogue n'implique pas une erreur de conception". Un seul rapport de bogue sur quelque chose qui est une fonctionnalité n'est pas une raison pour une refonte, et même plusieurs rapports sur une fonctionnalité commune ne signifient pas nécessairement que la majorité de vos utilisateurs ne seraient pas plus heureux sans un "correctif". Surtout si votre version originale est déjà populaire et que les gens ont l'habitude de l'utiliser "de cette façon".

— Joris Timmermans

2

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.

— Karl Bielefeldt
source

2

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.

— James McLeod
source

Je ne vois pas vraiment que cela soit marqué comme un rapport de bogue. Plus comme une suggestion ou une demande de fonctionnalité. (Bien que, avec certains systèmes de suivi des bogues, cela puisse compter comme un de toute façon.)

— Maxpm

1

Je suis d'accord, la plupart du temps, mais cela peut signifier une erreur (bug) dans la conception, ou une zone grise dans les spécifications, ou un ensemble différent d'hypothèses formulées par le développeur et l'utilisateur.

— James McLeod

1

James, si vous ajoutez ce commentaire à votre réponse, la réponse entière devient meilleure.

— Marjan Venema

1

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.

— 18 octets
source

1

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!

— AndSoYouCode
source

0

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).

— HLGEM
source