Les listes constituent le « niveau zéro » de l’organisation. Quand j’utilise cette expression, ce n’est pas pour dire que les listes ne servent à rien, mais bien qu’elles sont la base de toute organisation, qu’elle soit personnelle ou collective. Vous ne pouvez pas espérer mettre en place une méthode de travail complète si vous n’êtes pas capable de gérer une simple liste de chose à faire.

Je vais détailler 3 types de listes : les listes de choses à faire (todo-list), les listes de bugs (buglist) et les listes de choses à vérifier (checklist).

Todo-list

Il s’agit du plus évident. Tout le monde, un jour ou l’autre, a noté quelque part une liste de choses à ne pas oublier ou de courses à acheter. Le premier pas en direction d’une organisation personnelle efficace est la tenue d’une liste de tâches. À chacun de faire de la manière qui lui semble la plus confortable, et en la matière il existe une quasi-infinité de recettes : utiliser un cahier ou un bloc-notes qu’on peut emmener partout avec soi, tout noter sur des post-it qu’on collera dans une pochette ou un classeur, utiliser la todo-list intégrée à notre logiciel de messagerie électronique, éditer des fichiers bureautiques (traitement de texte ou tableur), utiliser un wiki ou un système dédié à la tenue de todo-list.

Dans le cadre professionnel, il faut dissocier 2 types de todo-list :

• Les listes de tâches que chaque employé doit tenir, et qui lui permettent de ne pas perdre le fil du travail qu’il a à réaliser. On est alors complètement dans le cas d’une liste que chacun est libre de tenir de la manière qui lui convient le mieux.
• Les listes de tâches relatives à chaque projet. Celles-ci doivent être visibles par toutes les personnes ayant un rapport avec le projet. Il est important de savoir où le projet en est de manière globale ; c’est motivant pour tous les intervenants, mais c’est aussi nécessaire aux managers pour effectuer un suivi de l’avancement du projet. Il faut que les managers puissent modifier la liste de tâches, et que les personnes à qui elles sont assignées puissent indiquer la progression du travail.

Dans les deux cas, il faut que la todo-list permette de gérer les points suivants :

• L’intitulé de la tâche à réaliser, dans un langage suffisamment explicite pour que toutes les personnes qui y ont accès puissent comprendre en quoi elle consiste. Il ne faut pas avoir besoin d’une explication de texte pour saisir rapidement la teneur d’une tâche. Cet intitulé doit être facilement modifiable.
• La priorité de la tâche. Il ne faut pas avoir besoin de systématiquement redérouler l’intégralité de la liste pour savoir quelle est la tâche la plus importante. La liste doit refléter cela, que ce soit par l’ordre d’écriture des tâches, ou par la manière dont elles sont affichées. C’est à ce niveau que les systèmes informatisés sont plus performants que les listes papier.

D’autres fonctionnalités sont très intéressantes, mais pas forcément obligatoires :

• Assigner les tâches. Ainsi chaque personne connaîtra automatiquement les tâches dont elle aura la responsabilité, éventuellement en recevant une notification par email.
• Définir une « deadline ». En fixant une date à laquelle une tâche doit être terminée, on peut anticiper plus facilement les retards sur un projet. Attention à résister à la tentation de mettre des deadlines à toutes les tâches, ou des dates irréalistes (trop de gens font ça trop souvent).
• Indiquer l’état d’avancement de la tâche. C’est très pratique de savoir si la personne en charge a déjà commencé à traiter la tâche, si elle en est à valider son travail, ou si le boulot est terminé.

Comprenez bien que sans todo-list, il est vraiment impossible de gérer un projet. Vous avez besoin d’identifier clairement les tâches qui le composent. Il est aussi très important de passer régulièrement en revue vos listes, sinon vous risquez d’oublier d’y ajouter des tâches importantes, d’y laisser trainer des tâches terminées ou devenues obsolètes, et au final d’arrêter d’utiliser ces listes.

Buglist

Le principe d’une liste de bugs est très proche de celui d’une todo-list. L’idée reste de lister des choses sur lesquelles il faut travailler, regroupées par projets et affectables à untel ou untel. Sauf que dans ce cas, l’utilisation diffère par le fait que les nouvelles entrées ne sont pas (obligatoirement) ajoutées par les responsables du projet, mais par ses utilisateurs (ou ses testeurs désignés) ; cela impose une vérification systématique des nouvelles entrées pour faire le tri entre les vrais bugs, les erreurs d’utilisation, les doublons, etc.

Pour le reste, les gestionnaires de bugs ont besoin d’offrir les mêmes fonctionnalités que les todo-list… mais toutes les fonctionnalités : assignation, deadline et état d’achèvement compris. Et même en y ajoutant des fonctions de classement supplémentaires qui permettront de faire la différence entre les signalements de bugs et les demandes de nouvelles fonctionnalités, par exemple. Car il faut savoir que les listes de bugs ont tendance à se remplir très vite. Alors il devient d’autant plus important de pouvoir tracer efficacement leurs traitements au court du temps.

Un point sur lequel il faut être très vigilant, c’est l’unicité du système de gestion des bugs. À partir du moment où un tel système est mis en place, il doit devenir le seul et unique moyen de signaler et suivre les bugs. Il faut résister à la tentation d’utiliser d’autres moyens qui peuvent sembler plus simples ou plus rapides (l’exemple le plus fréquent étant l’envoi de listes de bugs par email), mais qui sont une catastrophe à moyen terme : le jour où vous aurez à consolider 3 listes de bugs différentes, devant les parcourir intégralement pour éliminer les doublons, avant d’avoir une idée précise des bugs que vous aurez à traiter… vous saurez que votre système aura volé en éclat. Et surtout, pensez bien que le travail sera à recommencer entièrement la prochaine fois que quelqu’un vous enverra une nouvelle liste de bugs !
Je traiterai cet aspect des choses dans un prochain billet, mais pour simplifier, la méthode à appliquer tient en 2 points : éduquer les utilisateurs (si on ne leur explique pas pourquoi ni comment utiliser le système, ils ne l’utiliseront pas), et chercher avec eux une réponse aux problèmes ergonomiques qui freineraient l’adoption du système.

Checklist

Le parent pauvre des listes, ce sont les listes de vérification, qui permettent de valider une réalisation. On a tendance à y penser que dans le cas d’un travail répétitif, dont il faut vérifier à chaque fois les mêmes points ; il devient vite évident que le meilleur moyen de ne pas oublier un de ces points, c’est encore de les lister. La prochaine fois que le travail devra être vérifié, il suffit alors de parcourir la liste, et de s’assurer de la validité point par point.
Il s’agira, par exemple, de vérifier que tous les produits qui sortent d’une chaîne de production respectent bien les mêmes critères. Ou encore que chaque nouvelle version d’un logiciel ne présente pas de bugs sur plusieurs cas d’utilisation balisés.

Mais le cas où on ne pense pas forcément à utiliser des checklists, c’est lorsqu’elles peuvent être utiles pour faire des vérifications sur de nouveaux produits ou services. C’est ce qu’on appelle aussi un « cahier de recette ». Trop souvent, on a tendance à lancer les nouveautés en effectuant des tests certes consciencieux mais un peu « artisanaux ». On prend l’excuse de vouloir lancer rapidement la nouveauté, ou encore que rien ne remplace l’expertise de l’œil humain.
Mais en procédant de la sorte, on s’expose à de multiples risques. Prenons l’exemple d’un site web qui va être mis en ligne pour la première fois. Le site a beau avoir été testé sur un serveur de test, puis validé en pré-production, il n’en reste pas moins que ces tests ont été réalisés par un être humain. Au pire, il s’agira même du développeur qui l’a réalisé. Et si jamais on voit un bug ou une « petite amélioration à apporter rapidement » (je l’adore, celle-là), il y a de fortes chances que le site soit modifié, testé à la va-vite, puis mis en ligne. Et en l’absence de checklist, personne ne verra qu’un bug de régression s’est glissé dans la nouvelle version « corrigée »… Pas très professionnel.

Je parlerais dans un prochain billet des éléments nécessaires à la bonne marche d’un projet. Et ce qu’il faut bien voir, c’est que pour chaque fonction demandée dans les spécifications fonctionnelles, il faut avoir un (ou plusieurs s’il le faut) test dans la checklist du projet. Toute raison donnée pour ne pas le faire sera toujours une mauvaise excuse.