ANALYSE DE TÂCHES Eric Fimbel Modifié par Jean-Marc Desharnais Ensuite modifié par Michael McGuffin Département de génie logiciel et des TI

Qu’en pensez-vous? Conséquences? Un ingénieur/programmeur qui passe 7+ heures/jour à concevoir et à coder, et 1 heure/jour à utiliser un logiciel de dessin, connais bien les besoins des artistes qui auront à se servir du même logiciel 8+ heures/jour Les raccourcis avec le clavier c’est bon pour les experts, pas pour un utilisateur moyen. Les ajouter à la programmation fait perdre du temps L’utilisation des abréviations et des acronymes sauve du temps d’écriture et de lecture On peut sauver beaucoup de temps et d’argent en réduisant les rencontres avec les utilisateurs

Question Comment peut-on satisfaire les utilisateurs si on ne sait pas ce qu'ils font et comment ils le font ? Une approche centrée utilisateur commence par l'analyse des tâches et des façons de faire actuelles

Méthode suggérée S'immerger dans le contexte de l'entreprise. Apprendre sur le domaine et les personnes. Observer les futurs utilisateurs et dialoguer avec eux. Déterminer les tâches qu'ils réalisent et les façons de faire actuelles.

Contexte d'utilisation de l'analyse de tâches Avant de commencer la conception, et même si possible avant d'établir des spécifications. Dans le cas d'une application d'entreprise. Partant de procédures partiellement ou pas automatisées. Partant de procédures réalisées par une application existante. Remarque: l’analyse de tâches en profondeur est peu utile si tous les besoins et fonctionnalités sont pré-établis

Objectif: construire un "inventaire" contenant plusieurs éléments … Déterminer le domaine et le contexte dans lesquelles on utilisera la future application Déterminer les intervenants (types d’utilisateurs) qui réalisent ces tâches, et les caractériser sous forme de profils. Ex: est-ce que les intervenants connaissent les ordinateurs, etc. Déterminer les tâches prescrites (quoi) et réelles (comment), c'est à dire les façons de faire actuelles. Collecter les paramètres de réalisation de chaque tâche par différents intervenants. Fréquence, temps d'exécution, erreurs, degré de difficulté... 5. Autres …

1. Domaine de l'application Le domaine décrit l'activité générale pour laquelle l'application sera utilisée. Exemples de domaines : comptabilité, gestion de portefeuille, conception de circuits imprimés... Il faut se familiariser avec la terminologie et les concepts du domaine Indispensable pour une compréhension minimum des tâches. Permet un meilleur dialogue avec les intervenants

2. Intervenants Personnes jouant un rôle dans la réalisation des tâches. Aussi appelés agents, acteurs, stakeholders. Dans un sens plus large, tous ceux qui sont concernés ou touchés par la tâche Exemples: Responsable Intervenants qui participent toujours à la tâche Internes ou externes à l'entreprise Clients

Intervenants Donner un profil des intervenants qui utiliseront l'application. Idéalement le plus précis possible, sans être spéculatif. Caractéristiques professionnelles. Caractéristiques socio-démographiques. Profession, années d’études (en moyenne), langue maternelle... Degré de familiarité avec les interfaces graphiques. Utilisation de logiciels similaires ou d’usage général. Degré de familiarité avec le domaine et les tâches. Exemple: système de support technique (centre d’appels). Intervenant type = technicien(ne), réceptionniste, gérant ?

Utilité des profils des intervenants Permettent de choisir un style d'interface adapté Exemple. Technicien(ne) en informatique. Personnel de bureau.

3. Description de tâches Les tâches prescrites sont des descriptions théoriques (le « quoi ») Exemples: maintenir les comptes à payer, faire le suivi du portefeuille des clients … Les tâches réelles caractérisent les détails des façons de faire actuelles (le « comment ») Exemples: choisir telle option dans tel menu; téléphoner telle personne pour vérifier; comment fait-on l’enregistrement des données--qui ou quoi consulte-t-on? Les tâches prévues sont celles qu'on pourra (dans le futur) réaliser totalement ou partiellement avec l'application. Je place le dossier client dans la filière 3 sous le titre client. Sauvegarder un client.

4. Paramètres de réalisation des tâches Ces paramètres caractérisent la façon dont une même tâche est réalisée par différents intervenants. Il est fréquent que différentes personnes réalisent une même tâche, même si théoriquement elle est assignée à un seul intervenant. Une tâche donnée sera réalisée plus ou moins bien par différents intervenants. Paramètres importants: Fréquence à laquelle différents intervenants réalisent une tâche. Performances de chacun, i.e., temps d'exécution, taux d'erreur... Degré de difficulté de la tâche pour différents intervenants.

5. Autres choses à noter… -Vocabulaire du domaine, termes employées, concepts, etc. -Outils, équipements, accessoires utilisés ou produits lors des tâches: Exemples : photocopieuse, déchiqueteuse, stylo, bloc-notes, facture, etc. ... -Les opérations de base formant les tâches: Aussi appelées : actions élémentaires. Exemple: transmettre, payer, rechercher, ...

Décomposition des tâches Décomposer selon le niveau d'agrégation (ou granularité). Exemple. s'identifier (granularité grossière, forte agrégation) Exemple. cliquer le champ "login", taper "login"... (granularité fine). Problème: déterminer le niveau de détail. On pourrait descendre jusqu'aux gestes élémentaire.

Décomposition des tâches Examiner les tâches et leur décomposition en sous-tâches (étapes) pour vérifier si on a la situation suivante: La tâche a des sous-tâches (étapes) en commun avec d'autres tâches. Exemple : s'identifier Exemple : signer un document. On considère les sous-tâches communes comme de possibles opérations de base.

Détermination des opérations de base Considérer qu'une tâche est une opération de base dans l'une ou l'autre des situations suivantes: 1. Tout utilisateur peut réaliser la tâche sans formation. 2. Il est peu important que la tâche réussisse ou non. C'est à dire qu'on a des alternatives pour obtenir le même résultat. Quand c'est le cas, la tâche en question est considérée comme une opération de base (et ajoutée comme telle au glossaire).

Comment recueillir les données

Observation directe des activités Observer l’agent pendant son travail. Identifier: outils utilisés, comportement de l’utilisateur, comportement des technologies, les communications liées au travail, les procédures de prise de décisions, les intrants et extrants des tâches, les problèmes rencontrés par l’utilisateur, etc. Tip: demander à l'agent de verbaliser (« talk aloud ») Noter le verbal et non-verbal. Tip: essayer de se faire oublier. Définir clairement l'objectif (PAS espionner, mais comprendre). Minimiser les questions et interférences. Les appareils d'enregistrement : plus objectifs, mais peuvent être mal perçus, et génèrent beaucoup de données

Observation directe des activités Avantages. Collecte de données sur le travail réel. Recueillir des données non accessibles autrement. Désavantages. L’observation change la façon dont la tâche est faite. L’observation permet rarement de recueillir des données sur les exceptions. Demande certaines connaissances pour comprendre ce qui se fait.

Autres techniques d’observation … Un journal (« diary ») qui est entretenu par un intervenant Permet une étude longitudinal peu couteux Demande beaucoup de discipline de la part de l’utilisateur Caméra vidéo cachée Techniques ethnographiques Devenir un utilisateur

Entrevues et questionnaires Personnes à interroger Employé, superviseur, etc. Préparer l’entrevue/le questionnaire Définir des objectifs clairs. Préparer sa stratégie et ses questions. Types: Dirigiste: questions fermées (quand, comment, combien de fois). Non-dirigiste: questions ouvertes (permettre des développements). Libre: laisser l'interviewé aborder les sujets qui l'intéresse

Entrevues et questionnaires Avantages Permet de recueillir beaucoup de données sur les perceptions des tâches Désavantages Données non rigoureuses Biais des interviewés N’accède pas aux parties inconscientes du travail (automatismes)