Comment éviter le fluage de la portée dans les projets agiles lors des tests d'utilisabilité?
J'ai un client qui m'a récemment posé des questions sur ce problème. Je me demandais comment tu gérerais ça?
Ils sont nouveaux dans les méthodes UX et Agile, ils se débattent donc de manière intéressante.
Dans le cadre d'un projet récent, ils ont ajouté des tests d'utilisabilité à leurs sprints. Ils n'avaient jamais fait de test d'utilisabilité auparavant et, par conséquent, ont découvert de nombreux problèmes d'utilisation avec la conception.
Cependant, bon nombre des problèmes rencontrés sortaient du cadre initial du projet. Les membres de l'équipe UX voulaient désespérément ajouter de nombreux problèmes au carnet de commandes du projet, mais ont immédiatement trouvé la résistance des propriétaires de produits qui ne voulaient pas retarder la livraison. Le résultat était un sentiment chez les utilisateurs UX que les propriétaires de produits ne se souciaient pas d'une bonne expérience utilisateur.
Ma question est de savoir comment avez-vous pu éviter ce problème? J'avais initialement suggéré que l'équipe avait besoin d'une définition plus précise de ce qui est ou non dans la portée du projet et d'un moyen d'enregistrer les problèmes d'utilisation hors de la portée pour les projets futurs.
Qu'est-ce que tu penses?
J'ai rencontré ce problème exact sur un projet. Tout le monde dans l'équipe est déjà mis à rude épreuve pour faire expédier un produit - et il est important de le sortir avant un événement international particulier (par exemple). Ainsi, un examen UX qui se produit trop tard dans le cycle de vie du développement soulève des problèmes graves que personne n'avait prévus. Que faire - et comment cela aurait-il pu être évité afin d'apprendre sur le prochain projet.
Afin d'éviter le fluage de la portée, il doit y avoir un processus de réévaluation continue de la portée et de hiérarchisation. L'évaluation des changements, du temps et des risques doit être effectuée ainsi que l'impact et la valeur de la fonctionnalité pour la plupart des utilisateurs . Et tout le monde doit en faire partie précisément pour que personne ne se sente ignoré.
De plus, il ne s'agit pas seulement de savoir quoi gérer dans la version, mais comment gérer la prochaine étape après cela . Il est préférable de pouvoir dire que nous allons reporter une fonctionnalité pour la prochaine version plutôt que drop une fonctionnalité. Une fois que vous avez surmonté le problème qui: `` ok oui peut-être que vous n'obtenez pas ce que vous aviez initialement sur votre liste de fonctionnalités, mais qu'en fait vous obtenez un meilleur produit à la fin de la journée '', puis l'état d'esprit des parties prenantes et par conséquent, tout le monde dans l'équipe peut s'améliorer considérablement.
Donc, pour cette raison, il est utile d'obtenir l'adhésion des parties prenantes dès le premier jour que c'est ce qu'est le développement agile. Adapter, itérer, améliorer. Le but est d'obtenir le meilleur produit possible - de ne pas cocher un tas de cases à cocher sur une liste de fonctionnalités - vous n'êtes pas payé par fonctionnalité!
Quand des problèmes surviennent si tard dans la journée, c'est vraiment pas le temps de paniquer. Le contraire en fait. Il est temps de 'Tweak not redesign'. Le plus grand impact pour les changements les moins risqués et les plus rapides.
Le rapport UX s'avère justement être un bon coup de pied pour faire une autre série de réévaluations de la portée. Le problème dans votre scénario est qu'il s'agit d'un choc - comme des lapins pris dans le phare. Ça ne devrait pas être un choc. Tout ce qui est assemblé pour fabriquer un produit fait partie de l'expérience utilisateur. Pourquoi alors laisser les tests à la fin, alors qu'il y avait probablement toutes sortes d'autres tests en cours ailleurs.
Les chances sont qu'il y a un tas de changements qui sont en fait assez faciles et ceux-ci sont vraiment une évidence. Il y a également des chances qu'il existe des domaines de fonctionnalité déjà partiellement inachevés ou risqués et qu'en réalité ceux-ci ajoutent moins de valeur à l'expérience de l'utilisateur que de corriger cela en premier impression "ou le formulaire" d'inscription "ou tout ce qui a été lancé. Il ne fait aucun doute que des compromis devront être faits, mais c'est tout à fait normal pour le cours - montrez-moi un projet qui n'a pas eu à faire de compromis.
L'un des plus gros problèmes que je vois aujourd'hui est que les entreprises doivent encore être informées des avantages de l'expérience utilisateur et de la façon dont elle les affecte, ainsi que leurs produits, et que la prise en compte de l'expérience utilisateur devrait commencer au jour. Ça ne change pas assez vite. Des lunettes UX gratuites pour tout le monde, c'est ce que je pense. Désolé pour la longue réponse :-)
+1 sur "UX à partir du jour 0".
[Avertissement mineur que je suis un développeur et non une personne UX, donc je pourrais avoir une compréhension naïve de ce qui est fait/doit être fait du point de vue UX].
J'ai travaillé sur des équipes Agiles où les gens UX faisaient partie intégrante de l'équipe et quelques choses qui semblaient bien fonctionner:
Implication précoce en UX
Souvent, notre concepteur d'interaction "consultait" le backlog d'un ou plusieurs sprints (en fonction de la vitesse actuelle) et commençait à réfléchir à ce que devait être l'UX.
Premières conversations UX/Dev/Product Owner sur les "histoires" à venir
Cela a été fait (nous avons utilisé Scrum) lors des sessions de préparation du backlog. Toute l'équipe examinerait l'arriéré au moins un sprint à venir; PO et/ou UX aideraient à décrire l'histoire; UX aurait peut-être des wireframes de l'interface utilisateur et guiderait l'équipe à travers les interactions
Test de convivialité précoce
Si possible, commencez le test le plus tôt possible avant du sprint actuel. Oui, cela signifie que vous ne testerez pas une application qui fonctionne. Essayez de créer des maquettes ou maquettes filaires cliquables. J'ai travaillé avec des concepteurs d'interaction qui ont utilisé du html pour câbler une interface utilisateur dépouillée qui a suffisamment d'interactions clés pour qu'ils puissent au moins avoir un premier sentiment d'utilisation. Essayez peut-être un outil comme Balsamiq. J'ai même vu des gens faire des tests sur papier ("où vous attendriez-vous à x?").
Estimer les alternatives
Dans le cadre de ce processus de "toilettage", l'équipe de développement est responsable d'estimer ou de dimensionner ce qui est décrit. Souvent, UX propose plusieurs alternatives et les développeurs estiment chaque option. Il n'y a rien qui rendra une OP moins susceptible de négocier que le sentiment qu'elle n'a pas d'options.
Estimer le coût du report
Cela peut être une approche utile lorsque vous essayez de convaincre un bon de commande de déplacer une histoire liée à l'expérience utilisateur différée vers le haut de la priorité. Engagez l'équipe de développement pour estimer le coût du report. Les choses sont souvent plus coûteuses à refaire plus tard sur la route que pour les affronter d'avance. Essayez d'estimer le coût de faire quelque chose maintenant vs de le faire plus tard. C'est la carte que vous jouez si le PO dit: "nous le ferons plus tard. Nous devons nous concentrer sur les fonctionnalités maintenant". Dites au PO combien cela coûtera plus tard, puis la balle sera dans son camp.
C'est généralement ma stratégie lorsque je travaille avec des bons de commande, fais tes devoirs, présente les options, puis espère qu'ils feront le bon choix.
Je dois ajouter que faciliter la collaboration dans l'équipe, si vous êtes une équipe Scrum, est le travail du Scrum master - ils devraient rechercher activement des moyens pour aider l'équipe à mieux travailler en tant qu'unité (y compris le PO).
Donc, la version courte: early, early, early, estimation, estimation : p
Dans l'entreprise où je travaille, l'équipe UX est responsable de la création des PRD, qui est le plan détaillé des exigences pour l'équipe d'ingénierie. Cela nous aide à éviter le problème en nous assurant que l'équipe UX a eu la chance (au début) de bien concevoir les choses.
Une fois qu'un problème est trouvé, j'ai eu beaucoup de difficulté à le mettre sur la feuille de route (comme vous l'avez remarqué dans votre question). J'attends littéralement 4 ans pour résoudre un problème particulier qui me rend (et les utilisateurs) fous dans l'UX. Le problème n'a pas glissé la version, le problème a été obtenu du tout. Les correctifs attendent généralement que nous refassions le composant.
C'est un cas de "une once de prévention vaut une livre de guérison".
Une dernière pensée: à un moment donné, j'ai dit que les tests d'utilisabilité étaient comme l'assurance de la qualité. Créons des rapports de bogues. Les ingénieurs avaient une vache. "Notre code n'était pas faux, votre design était faux!" Pouah.
En fait, il semble que l'équipe UX n'ait pas fait partie de l'équipe de développement depuis le "jour 0", comme le déclare Roger. Vous devez être une seule équipe et créer des fonctionnalités ensemble (toutes les disciplines requises). Cela réduirait mais n'éliminerait probablement pas les problèmes d'utilisation rencontrés lors des tests. L'UX aurait également dû être intégrée à la conception stratégique.
Si c'était moi, j'aurais inséré une ou plusieurs tâches de test d'utilisabilité dans le Sprint et également inséré une tâche de correction de l'utilisabilité pour les choses qui tombent hors de l'utilisabilité. Cela réduirait votre vitesse globale mais c'est la réalité.
Une autre façon consiste simplement à prendre les histoires d'utilisation Fallout et à les mettre dans le carnet de commandes, qui est la responsabilité des propriétaires de produits. N'empêchez pas quelqu'un de mettre ces choses dans le Backlog. De nombreuses équipes Agile autorisent tout le monde à ajouter au Backlog et c'est le travail du PO de prioriser les éléments du Backlog afin que les plus importants viennent en premier. Mais c'est la décision du PO car il est responsable du ROI du produit.
Jared a également posé cette question sur la liste de diffusion agile et les gens peuvent trouver les réponses là-bas d'intérêt. Austin a surtout inclus quelques trucs très sympas .
Ma réponse à Jared y inclus ci-dessous pour ceux qui pourraient être intéressés:
Pas un problème unique à l'agile. Je suis étonné du nombre de personnes qui budgétisent à temps pour les tests d'utilisabilité, mais attendez-vous à ce que les résultats puissent être intégrés comme par magie sans travail supplémentaire :-)
Je pense que votre suggestion initiale est bonne. Avant de commencer à tester les utilisateurs avec une équipe, nous essayons de déterminer ce qui est/n'est pas possible en termes d'implémentation. C'est bon pour deux raisons:
1) Il aide à définir les attentes des deux côtés de ce qui va être fait avec les résultats. Donc, je ne suis pas ennuyé que mes conseils avisés soient ignorés, et l'équipe ne reçoit pas un ensemble de problèmes de haut niveau qui ne peuvent pas être résolus dans le cadre du plan de version actuel.
2) Il permet un meilleur ciblage des ressources UX. Si nous savons que nous n'avons pas vraiment le temps de réimplémenter complètement la fonctionnalité Foo, alors nous pouvons passer plus de temps à regarder la barre de fonctionnalités à la place - ou plus de temps à enseigner/faciliter un bon travail UX ailleurs.
En amenant les équipes à évaluer l'UX, je trouve beaucoup plus efficace de fournir des conseils qui peuvent être appliqués immédiatement afin que la valeur de ces conseils puisse être rapidement vue. Une fois que vous commencez à montrer de la valeur, il est beaucoup plus facile de vous mettre d'accord sur la résolution de problèmes plus importants.
Avoir cette conversation sur la façon dont les tests d'utilisabilité peuvent affecter le produit final peut conduire à des endroits intéressants.
Par exemple, il peut mettre en évidence des situations dans lesquelles l'équipe de développement de produits doit devenir plus agile.
Le plan de sortie est-il fixe? Est-ce réparé pour une bonne raison? La nouvelle fonctionnalité Foo est-elle vraiment plus importante que la correction de la barre de fonctionnalités? Est-ce qu'un accord sur un plan de version N mois à l'avance aide ou empêche de créer un meilleur produit?
La conversation sur la façon dont les résultats des tests d'utilisabilité s'intègrent peut rapidement devenir une discussion beaucoup plus large sur le processus dans son ensemble, la définition de fait et la priorité des fonctionnalités.
Cette conversation plus large est utile et bonne - mais peut parfois gêner la résolution des problèmes à court terme qui peuvent être résolus dans le cadre des deux prochaines itérations. Surtout, comme votre client, où vous êtes confronté à une énorme dette de convivialité.
S'attaquer d'abord aux petits problèmes. Montrez qu'ils aident. Utilisez ces preuves comme carburant pour résoudre des problèmes à plus grande échelle.
À votre santé,
Adrian
Je ne comprends pas non plus pourquoi l'ajout à l'arriéré des problèmes qui ont surgi devrait retarder la livraison. Il n'y a certainement rien qui dit qu'absolument tout dans l'arriéré doit être ajouté à une version.
Je prendrais cependant une évaluation honnête de la valeur utilisateur qui serait ajoutée en abordant les problèmes découverts. Passer plus de temps sur un produit [devrait] toujours ajouter de la valeur, mais cette valeur ajoutée doit également être mise en balance avec le coût de la suppression d'autres fonctionnalités ou du report des dates de livraison. Les propriétaires de produits devraient recevoir suffisamment d'informations pour peser la valeur relative de ces nouvelles histoires par rapport aux histoires existantes et ajuster le plan de projet en conséquence. Bien sûr, la pondération de ces valeurs relatives est beaucoup plus facile si tous les problèmes sont dans l'arriéré.
L'un des principaux objectifs de l'utilisation de méthodes agiles est de faire d'une situation comme celle-ci un non-problème - tout ce qui ne fait pas la première version peut être ajouté au backlog, pour être (éventuellement) développé et poussé lors d'une version ultérieure. Comme l'a également souligné Ben Rice, l'ajout à l'arriéré ne devrait pas compromettre une date de sortie.
Comme Roger Attrill et d'autres l'ont également noté, les tests UX devraient faire partie du processus dès le début et devraient aller de pair avec les tests fonctionnels. Avec toutes les nombreuses techniques et méthodes différentes qui peuvent être utilisées pour effectuer des tests UX (dont beaucoup peuvent être gérées en interne), il n'y a vraiment aucune bonne excuse pour ne pas le faire.
Si les propriétaires de produits ne veulent pas ajouter les problèmes découverts par les tests UX (par opposition aux tests fonctionnels) au backlog, alors il semblerait qu'ils ne valeur les résultats des tests; et donc il est probable que ce soit plus un problème culturel/politique à portée de main, pas un problème de procédure, et pose la question - pourquoi ont-ils pris la peine de tester UX pour commencer?