Partie 1: Analyse de tâches. 

Plus tôt ce mois-ci au Symposium PMI 2017, nous avons présenté une étude de cas sur la façon dont une entreprise en TI avec qui nous collaborons, Stelvio, a intégré les meilleures pratiques en expérience utilisateur dans ses cycles Agile. Cette intégration UX a permis à Stelvio de livrer au-delà des attentes en terme de qualité de produit, de délais de livraison et de budget, et ce dès la première de trois années de développement d’un logiciel d’exploitation pour une petite compagnie d’aviation. Sérieusement, ç’a été super à date.

La combinaison de leur maîtrise de l’Agile et du Scrum à la nôtre, en design d’expériences, nous a fait réaliser jusqu’à quel point l’UX n’est pas seulement compatible avec l’Agile, mais le rend plus performant, tout en réduisant de beaucoup le risque et en livrant des produits de grande qualité.

Et c’était un projet à haut risque. Stelvio développe à partir de rien un logiciel d’exploitation qui remplacera celui actuellement utilisé par son sponsor, une compagnie d’aviation basée à Montréal et ayant ses opérations en Afrique—dire que ce type de logiciel est complexe est un euphémisme. De plus, c’était la première fois que Stelvio développait un produit pour l’industrie aéronautique. D’emblée, tous avaient convenu que l’équipe projet devait s’assurer de bien comprendre les processus de l’entreprise aérienne avant de se mettre à coder. À cette fin, une phase de découverte et d’analyse préliminaire avait été accordée avant les trois années de développement anticipées.

Devant la complexité du projet, Gaétan, le chef de produit, sentait qu’il y avait un écart entre les objectifs visés et les tâches des employés une fois les changements anticipés. Il n’y avait aucune approche ni de méthodes en expérience utilisateur de déployées et le risque lui a semblé bien grand de ne pas livrer un produit compatible aux vrais besoins des usagers. Gaétan avait suivi quelques semaines auparavant une formation en UX destinée aux chefs de produits et gestionnaires de projets, et c’est grâce à cette introduction au UX que Yu Centrik est entré dans le projet. Nous sommes fiers de pouvoir dire que l’approche et nos méthodes UX ont comblé l’écart entre la vision d’affaires du sponsor pour ce logiciel et la façon dont cette vision devait prendre forme afin d’être complètement pertinente, efficace et utilisable par les employés.

Plus spécifiquement, Gaétan attribue son succès à trois apports de l’UX, à savoir:

1. faire une analyse de tâches
2. bâtir sur un concept de design UX cohérent, et
3. de mettre les utilisateurs au cœur de chaque aspect du projet; oui, utiliser l’approche du « User-Centered Design ».

Aujourd’hui, Gaétan demeure étonné de voir comment son équipe a complètement adopté, et s’est appropriée, le point de vue des utilisateurs comme le leur… au-delà de l’application ponctuelle d’une méthode. L’histoire de l’impact de ces trois facteurs sur ce projet vaut la peine d’être lue, mais est peut-être un peu longue pour un seul billet de blogue, donc nous l’avons divisée en deux: l’analyse de tâches ici, les deux autres dans le prochain billet.

Êtes-vous sérieux: Vous voulez qu’on fasse quoi …?

L’analyse de tâches examine en détail comment une tâche est accomplie, ses activités manuelles et cognitives, ses déclencheurs, la technologie et l’information impliqués, les interactions nécessaires avec d’autres personnes, les raccourcis qu’on aura bricolés, et tous les autres facteurs particuliers impliqués dans une tâche donnée (Kirwan, B. and Ainsworth, L. (Eds.) (1992). A guide to task analysis. Taylor and Francis).

Dans le cas présent, l’analyse de tâches regardait 17 informations différentes contextualisant chaque segment de chaque tâche. Ces segments ont été identifiés par les employés que nous avons interviewés; chaque segment était perçu comme une étape en soi à l’intérieur d’une tâche (par exemple : vérifier la priorité d’une commande, vérifier le numéro d’une pièce). Chacun requérant des informations propres à lui-même. L’équipe projet a identifié des centaines de ces segments ou étapes et en ont conservé 208 pour le futur logiciel. Gaétan appelle ces étapes des « business steps ». Pour illustrer un peu plus, l’analyse de tâches est à l’analyse fonctionnelle ce que l’explication de la préparation est à la liste des ingrédients d’une recette. L’analyse de tâches présente les étapes dans leur séquence d’accomplissement et du point de vue de l’usager.

208 business step x 17 colonnes d’une feuille Excel = un processus de collecte de données qui semble laborieux, le craignait Gaétan.

Mais l’analyse de tâches est devenue son outil UX le plus fiable, le plus apprécié et le plus concret. L’analyse de tâches a ancré chaque « business steps » dans le détail de son contexte.

Cette méthode offre deux avantages majeurs:

1. Premièrement, elle a permis de délicatement disséquer chaque tâche dans ses étapes respectives, prêtes à être priorisées et planifiées dans l’enchaînement des sprints. Cette précision garantit que ce qui est développé soit pertinent et puisse être utilisé d’emblée parce que c’est une étape complète et autonome; il ne manque aucune dimension (feature) cruciale (il n’y avait pas non plus de feature superflus en attente de développement futur).
2. Deuxièmement, l’analyse de tâches sert également de portrait instantané de l’écosystème actuel (fonctionnel, mais surchargé) dans lequel le nouveau logiciel devra s’inscrire. Par le passé, lorsqu’un nouveau logiciel remplaçait graduellement l’ancien, Gaétan et ses équipes perdaient facilement leurs repères, ne se souvenant pas toujours des détails de l’écosystème d’origine. Cela entraînait un fort risque d’inadéquation entre le nouveau système et les manières de faire nécessaire pour bien accomplir les tâches. Dans ce cas-ci, Stelvio arrive à remplacer avec une précision chirurgicale l’ancien logiciel et ses processus connexes par le nouveau sans perturber les opérations quotidiennes du sponsor (en fait, en améliorant considérablement ses opérations).

Les business steps permettent de structurés les sprints, ceux-ci se décomposant en un nombre variable de “stories” et du coup, de “story points” selon le cas. Cette articulation fine permet d’évaluer la pertinence (et l’urgence) de chaque dimension de chaque business step, s’assurant de la cohérence et de la nécessité de ce qui est développé. Pour vous donner une idée, Gaétan, avec son équipe de 8 développeurs, planifie et livre une cinquantaine de business steps par année. Il utilise les business steps pour faire sa planification macro.

À la fin de leur première année de développement, l’équipe de Stelvio a pu livrer un Produit Minimum Viable entièrement utilisable, 6 semaines avant l’échéance, pour la plus grande satisfaction du sponsor et de ses employés. Mais l’analyse de tâches n’aurait pas pu faire une percée dans leur processus de développement seule; un bon concept de design UX et une solide approche axée sur l’utilisateur ont été des éléments clés de ce succès, comme cela sera expliqué dans notre prochain blogue.