Gérer les attentes des utilisateurs qui ne veulent pas faire de tests utilisateur
J'ai un utilisateur, d'un service interne, qui demande de nombreuses modifications ou signale des bogues sur le site Web de notre entreprise. Nous avons des liens très étroits et forts, mais récemment, ils se sont énervés de devoir tester ces changements. Ils les considèrent comme une perte de temps. Un courriel récent que j'ai reçu contenait même cette petite ligne:
Lorsque vous emmenez une voiture dans un garage pour être réparée, vous n'êtes pas invité à effectuer un test pour vous assurer que la voiture fonctionne.
Le problème est que nous suivons un modèle selon lequel, à moins qu'un changement / correction de bogue ne soit une urgence ou en utilisant des procédures écrites standard (par exemple, un changement de paramètre normalisé), nous avons besoin de tests / confirmation de l'utilisateur avant de pouvoir publier le changement ou la correction de bogue.
Quelle est la meilleure façon de gérer les attentes de cet utilisateur et de toujours faire compléter ou confirmer les tests par lui?
Réponses
Il n'y a pas de réponse universelle. Supposons que l'utilisateur signale une faute d'orthographe sur une page Web. « Il dit Teh où il devrait dire le ». Vous ne retarderiez pas le déploiement de ce correctif unique en attendant que l'utilisateur accepte que vous ayez corrigé la faute de frappe.
Maintenant, disons que l'utilisateur a demandé (comme l'un des miens l'a fait une fois) pour qu'un bouton soit "deux nuances de bleu plus claires". Il est logique de leur demander de confirmer que vous avez bien deviné ce que cela signifie. La formulation est la clé ici, cependant: «Veuillez tester le correctif et l'approuver» implique que vous n'êtes pas sûr de l'avoir fait correctement, et peut sembler un peu «c'est à vous si quelque chose ne va pas plus tard». Un "pouvez-vous me faire savoir si vous aimez la nouvelle couleur" ou "assurez-vous que c'est ce que vous vouliez" ou même "assurez-vous que mon développeur vous a bien compris" n'est pas seulement plus précis, il explique pourquoi les développeurs demandent pour le travail d'un client.
Vous devez également vous assurer que le client comprend que vous testez votre travail et que vous avez codé ce que vous vouliez coder. Ce que le client teste, c'est que vous avez compris la demande. Alors ils vous demandent d'ajouter une colonne à un rapport et vous oubliez de demander où ils le voulaient: lorsque vous livrez vous dites "Je l'ai ajouté à la fin" ou "Je l'ai ajouté à côté de la date de commande" et demandez-leur ensuite de confirmer c'est ok.
Bien sûr, tout cela est "test". Regardez-le et assurez-vous que vous l'aimez. Pour utiliser leur analogie, si vous preniez votre voiture pour être peinte en bleu, vous ne partiriez pas dans une voiture rouge vif sans rien dire. Donc, pour tout sauf les urgences absolues, vous faites le correctif ou ajoutez le nouveau truc, vous le mettez en scène pour qu'ils le regardent et confirment que c'est bon, puis vous le mettez en ligne. L'utilisation de l'expression « confirmez que c'est bien » fait en grande partie ce que vous recherchez:
- il contient l'hypothèse que vous avez fait la bonne chose. "Rechercher les erreurs" suppose qu'il y a des erreurs
- il n'utilise pas un verbe que le client vous paie pour faire comme "test"
- il n'utilise pas un verbe qui rend le client nerveux à l'idée d'assumer la responsabilité, comme «acceptation»
Nous ajoutons souvent des détails spécifiques à nos demandes de test. Confirmez que la mise en forme de la nouvelle colonne correspond à ce que vous vouliez. Confirmez que le développeur a fait le bon choix concernant la taille de la police. En gros, toute décision que vous avez dû prendre vous-même parce qu'elle n'a pas été spécifiée, et pour une raison quelconque, vous ne l'avez pas demandé avant de le faire, dites-leur cela et demandez-leur de confirmer. Tout ce qui était ambigu et que vous n'avez pas clarifié avant le codage, signalez-le maintenant.
Quelle est la meilleure façon de gérer les attentes de cet utilisateur
Comprenez bien le problème avant de le résoudre, puis effectuez un test professionnel.
Vous ne devez pas faire confiance à un utilisateur final pour le test, cela doit être fait par un professionnel qui a tout intérêt à s'assurer qu'il est exempt d'erreurs avant la publication.
Vous devez présenter l'étape d'acceptation de l'utilisateur comme quelque chose qui profite au client, pas à vous.
Vous avez parlé des avantages pour votre entreprise ("nous avons besoin de tests utilisateur pour confirmer que le changement / bogue fonctionne comme prévu par l'utilisateur", "nous ne sommes pas autorisés à publier en direct sans validation de l'utilisateur"). Il n'est pas surprenant que le client ait l'impression de travailler pour vous. Ceci, après (dans leur esprit) que vous n'avez pas réussi à répondre à leurs besoins en premier lieu, en publiant quelque chose qui n'était pas ce qu'ils voulaient!
Vous pouvez commencer par expliquer qu'il s'agit d'un élément clé du processus qui leur profite . Imaginez à quel point ce serait pire si vous publiiez un "correctif" et qu'il n'était toujours pas corrigé, ou fonctionnant comme ils le souhaitaient! Imaginez si vous avez accidentellement aggravé les choses !
Il y avait clairement une panne de communication qui a causé les bugs en premier lieu. Si vous aviez parfaitement compris ce qu'ils voulaient, vous auriez parfaitement testé vous-même ces attentes et sorti quelque chose de ... parfait. Ils ont trouvé un bug. Cela signifie que quel que soit le processus dont vous disposez pour qu'ils demandent une fonctionnalité et que vous la fournissiez, il a manqué quelque chose. Il n'est pas raisonnable de supposer que le processus pour signaler le bogue et le corriger ne peut pas manquer quelque chose aussi. La chose sensée à faire est de vérifier: "nous pensons que nous l'avons fait comme vous le vouliez, est-ce vrai?".
Cela est particulièrement vrai s'ils paient pour l'un de ces changements ou correctifs. C'est l'occasion pour eux de s'assurer qu'ils en ont pour leur argent. Si vous libérez quelque chose et que ce n'est toujours pas ce qu'ils veulent, vous devrez recommencer tout le processus et les recharger à nouveau. Ne serait-il pas préférable pour eux de confirmer le correctif avant de le publier, afin qu'ils ne paient qu'une seule fois?
Dans tous les cas, cela doit leur être expliqué comme une opportunité positive pour eux d'avoir leur mot à dire, et non comme une perte de temps et une demande de temps sans avantage.
FWIW, je pense que c'est une mauvaise idée d'argumenter par analogie, comme le font d'autres réponses, parce que vous finissez par parler de quelque chose qui n'est pas réellement le problème dont vous devriez parler. Même ainsi, si je prenais ma voiture pour réparer un pneu crevé, je jetterais un œil au pneu avant de partir, pour m'assurer qu'il semble vraiment avoir été réparé. Sinon, si je commençais juste à conduire et que je remarquais que c'était plat sur la route, le garage pourrait dire qu'il a bien fait son travail et que le nouveau pneu a dû être crevé après mon départ.
Lorsque vous emmenez une voiture dans un garage pour être réparée, vous n'êtes pas invité à effectuer un test pour vous assurer que la voiture fonctionne.
Ah, drôle. Lorsque j'apporte une voiture à une RÉPARATION (et que les modifications apportées au site Web ne sont pas de la réparation), cela peut inclure des éléments trouvés lors de l'entretien, tels que les roulements à billes d'un pneu ne sont pas totalement ronds ...
... chaque fois que cela s'est produit lorsque j'ai récupéré la voiture, on m'a demandé de faire un essai routier avec un représentant du mécanicien (représentant en tant que: travailleur de première ligne, car ce ne sont pas de très petits plans qui séparent les mécaniciens du client).
Votre client semble penser que les modifications apportées au site Web sont utiles. Ce n'est pas le cas. La maintenance consisterait à patcher les bibliothèques. Les changements s'apparentent à des réparations ou des mises à niveau sur une voiture. Et l'assortiment qu'aucun essai routier n'est effectué dans ces cas est tout à fait faux ou indique l'utilisation d'un atelier de mécanique bas de gamme, selon mon expérience.
Vous devriez en parler au client. Également sur le fait que les mises à niveau vers un flux d'interface utilisateur de site Web peuvent ne pas fonctionner comme le client les attendait. Non pas que vous fassiez une erreur - mais je ne peux pas vous raconter le nombre de fois qu'une demande de modification a été suivie de "ah, cela ne fonctionne pas comme je m'y attendais" bien que le changement ait été exactement ce qui a été commandé. Attraper cela tôt fait partie d'un flux de travail.
Je vous suggère de leur parler et de leur expliquer que leur comparaison est une erreur qui pointe davantage vers l'utilisation d'un atelier de mécanique bas de gamme;)
Je suis d'avis que vous ne devriez pas dire à l'utilisateur de tester les bogues qu'il vous a signalés, ou les fonctionnalités qu'il a demandées que vous / votre entreprise avez choisi de mettre en œuvre, à moins que vous ne puissiez pas recréer le bogue sur votre fin pour une raison quelconque.
Lorsqu'ils vous signalent un bogue, vous devez d'abord recréer le bogue avant de mettre en œuvre un correctif, afin que vous sachiez que vous avez réellement corrigé le bogue ... Ensuite, lorsque ce correctif est déployé, vous pouvez communiquer à l'utilisateur que un correctif a été déployé.
S'ils demandent une nouvelle fonctionnalité, vous / votre entreprise devez obtenir toutes les exigences / attentes avant tout travail visant à mettre en œuvre la fonctionnalité. Ne pas deviner aveuglément ce qu'ils veulent, le mettre en œuvre, puis leur demander de le tester pour vous.
Tu as dit:
Le problème est que nous suivons un modèle selon lequel, à moins qu'un changement / correction de bogue ne soit une urgence ou en utilisant des procédures écrites standard (par exemple, un changement de paramètre normalisé), nous avons besoin de tests / confirmation de l'utilisateur avant de pouvoir publier le changement ou la correction de bogue.
Pourquoi suivez-vous ce modèle? Quelles exigences / quels objectifs ce modèle est-il censé atteindre? Qui l'a institué?
Si l'idée est de donner aux parties prenantes l'occasion de vérifier la solution, mettez un minuteur sur l'étape de vérification des parties prenantes et si la partie prenante n'a pas vérifié une solution (que vous avez testée) dans 2 semaines, fermez le problème / élément de travail comme "Achevée".
Si l'idée est de déléguer les tests aux parties prenantes, eh bien, j'imagine que vous auriez besoin de faire remonter cela dans l'organigramme, car cette partie prenante particulière ne semble pas croire que ses tâches incluent l'exécution des tests que vous voulez qu'elle fasse.
Si vous pensez généralement que vous êtes sur la même longueur d'onde avec les rapporteurs de problèmes quant aux problèmes qu'ils signalent, la stratégie de délai d'attente semble être la voie à suivre.