Skriv : Les listes

(ce billet fait partie d’un ensemble consacré au projet Skriv)

Comme vu précédemment, l’une des fonctionnalités de base de Skriv sera la possibilité d’y ajouter des listes.

J’imagine globalement 3 types de listes (les éléments en italique sont optionnels) :

  • minimales : La liste a juste un titre. Chaque entrée de liste ne contient qu’un titre et une description. Utile pour prendre des notes, ou pour faire une checklist.
  • simples : La liste a un titre, une date de début et une date d’échéance. Chaque entrée de liste contient un titre, un état (à faire / fait) et une description. Utile pour lister rapidement les tâches d’un sous-projet.
  • complètes : La liste a un titre, une date de début et une date d’échéance. Chaque entrée de liste contient un titre, un état (à faire / fait), une description, une importance (basse, moyenne, haute, critique), un responsable, une date d’échéance, un état d’avancement (en pourcentage). Utiles pour faire une vraie todo-list ou une buglist.

Quelques fonctionnalités sont générales à tous les types de listes :

  • Les entrées de liste peuvent être déplacés les unes par rapport aux autres par drag and drop. Idéalement (en fonction de la complexité technique) une entrée de liste pourra être déplacée d’une liste à une autre par drag and drop ; elle s’adaptera alors aux caractéristiques de la liste qui la réceptionnera.
  • On enregistre la date de création et le nom de l’utilisateur qui a créé l’entrée de liste. Ces informations seront disponibles (par exemple dans une infobulle).
  • Les descriptions associées aux entrées de liste utilisent une syntaxe Wiki.
  • Il est possible d’ajouter des commentaires aux entrées de liste. Le commentaires utilisent une syntaxe Wiki.
  • Il est possible d’ajouter des pièces-jointes aux entrée de liste et aux commentaires. Les pièces-jointes peuvent être des fichiers déjà présents sur le partage, des fichiers que l’on uploade à ce moment-là, des emails, des URLs.
  • Les entrées de liste avec un état (à faire/fait) ont une case à cocher devant leur titre. Quand on clique sur la case à cocher, le titre est barré, et l’entrée est déplacée en fin de liste. En décochant la case, le titre n’est plus barré, et l’entrée est déplacée à la fin des tâches « à faire » (au-dessus des tâches « faites »).
  • Les entrées de liste ayant un responsable possèdent une fonctionnalité de «harcèlement», qui sert à envoyer un message au responsable.

Ma vision

La plupart des outils de gestion de projet proposent une liste de tâches ; certains y ajoutent une buglist en plus. Les logiciels orientés « diagramme de Gantt » découpent les projets en sous-projets, qui sont eux-mêmes constitués de tâches.

Dans l’outil que j’utilise actuellement dans mon entreprise, nous avons aussi une todo-list et une buglist séparées. La todo-list est linéaire, elle contient une suite de tâches dont on peu définir un certain nombre de paramètres (responsable, avancement, criticité, urgence, deadline, …). Malheureusement, le concept de “sous-projet” manque, ce qui oblige souvent à créer des tâches dont la description contient une liste de sous-tâches.

Pour Skriv, j’imagine que l’on créera plusieurs listes pour créer autant de sous-projets. Pourquoi alors ne pas directement appeler ça des «sous-projets» ? Parce que ça me semble peu flexible. Dans certains cas, on voudra gérer plusieurs listes, sans les associer à une notion de sous-projet.
Je veux que ce soit l’outil qui s’adapte à notre vision, et non l’inverse. Si on veut signifier des choses différentes, il suffira d’utiliser l’outil de manière différente. C’est quand même mieux que d’être obligé à faire tenir nos propres concepts à l’intérieur de ceux de l’outil.

Qu’en pensez-vous ?

Ne pas faire confiance à sa mémoire

Je vais le marteler une nouvelle fois : les listes sont la base de toute organisation, qu’elle soit personnelle ou d’équipe.

L’une des erreurs qu’on voit le plus souvent, que ce soit que les juniors que chez les gens désorganisés, est de faire confiance à sa mémoire.

Par exemple, un jeune développeur qui ne prend pas de notes. On lui donne 3 choses à faire pour la journée, et il revient le soir tout fier de lui. Malheureusement, il en a oublié une en cours de route.
Ou encore, un graphiste qui doit corriger une création, sans utiliser une buglist. Évidemment, il faut alors plusieurs itérations pour lui rappeler les petits détails qui lui ont déjà été remontés.
J’ai même vu une DRH qui n’avait établi aucune procédure, pensant avoir tout bien en tête. Régulièrement, il fallait lui rappeler qu’on était en attente d’un justificatif qu’elle n’avait pas préparé.

Le fondement de cette erreur, c’est qu’au moment où on reçoit une information, notre attention se focalise dessus. Elle remplit toutes nos « cases mémoire ». On a naturellement l’impression qu’à tout moment cette donnée sera disponible dans un coin de notre tête.
Malheureusement, il faut composer avec 2 choses :

  • Chaque nouvelle information pousse les précédentes vers la sortie.
  • Les informations se périment en mémoire avec le temps, et toujours plus vite qu’on ne le croit.

La conjonction de ces deux facteurs fait qu’il est difficile de se souvenir de plusieurs choses bénignes (qui ne sont pas d’une importance marquante) plus de quelques heures d’affilée.

Dans certaines disciplines, comme en ergonomie ou en présentation, on considère habituellement qu’il ne faut pas présenter plus de 7 éléments à la fois. C’est la limite au-delà de laquelle le cerveau humain ne peut pas tout retenir instantanément. Une liste comportant plus de 7 choix demandera plusieurs lectures successives avant qu’une personne puisse s’en faire une représentation mentale.
Sachant cela, combien de ces 7 éléments vont s’envoler de votre mémoire avant la fin de la journée ?

La solution pour remédier à ce problème, c’est de noter toutes les informations qu’on ne peut pas traiter dans la seconde, et qui nécessitent une action. Ce ne sont pas les moyens qui manquent : dans un cahier, un outil de gestion de projet, une buglist, une feuille de papier volante, un wiki, etc.
C’est simple, c’est facile. Pas d’excuse.

Basecamp

Je vais vous présenter aujourd’hui le logiciel Basecamp, qui est développé par 37Signals. C’est un peu le grand frère de Backpack dont je vous parlais la semaine dernière.

Là où Backpack visait à faciliter le stockage et l’échange d’information autour de projets, Bascamp va plus loin et propose des outils pour gérer plus finement le travail de groupe. On peut distinguer 5 fonctionnalités principales :

  • Les todo-lists.
  • La messagerie partagée.
  • Le partage de fichiers.
  • Les objectifs calendaires.
  • « Reporting » du temps passé sur chaque projet.

Auxquelles s’ajoutent des panneaux de vues globales sur un projet ou sur tous les projets.

Les todo-lists

(image © 37signals.com)

Je vous ai déjà expliqué pourquoi les listes sont à la base de toute organisation. Basecamp permet de créer facilement des listes et de les organiser comme on le souhaite. Très similaires à celles de Backpack, on peut éditer leurs titres en utilisant la syntaxe Textile (syntaxe wiki-like simplifiée), et leur affecter un état fait/à faire simplement en cochant ou décochant une case. Par contre, elles offrent la possibilité d’affecter une tâche à un utilisateur, ce qui était un des manques que je pointais du doigt sur Backpack.

Il est aussi possible de créer des listes privées, qu’on est le seul à pouvoir voir. C’est une bonne idée, qui permet d’avoir au même endroit les todo-lists générales et celles qui nous concernent ; cela évite d’avoir à gérer plusieurs systèmes de listes en parallèle.

La messagerie partagée

(image © 37signals.com)

On a beau classer nos emails dans des dossiers, il est toujours pénible d’y rechercher une information intéressante. On est souvent obligé d’ouvrir une demi-douzaine de messages – de quelques lignes chacun – avant de retrouver ce qu’on veut.

Continuer la lecture de « Basecamp »

Les listes

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.

Continuer la lecture de « Les listes »