Skriv : Organisation de l’information

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

Cela fait longtemps que je n’ai pas écrit d’article au sujet du projet Skriv.
En ce moment, je cherche un moyen permettant de gérer les projets en autorisant 2 visions différentes :

• Une vision macro, pour suivre l’avancement global des projets et des sous-projets. Sans avoir le détail de toutes les tâches qui composent chaque sous -projet, il faut savoir quelles sont les deadlines des sous-projets, et éventuellement à quel pourcentage de complétion ils se situent.
• Une vision micro, pour accéder à toutes les informations liées aux différents sous-projets, les tâches, la documentation, etc.

La vision macro est absolument nécessaire pour prendre des décisions à moyen terme, ou simplement pour avoir une vision synthétique du travail. La vision micro est nécessaire pour tout le travail au quotidien : définir les priorités des tâches, accéder à la documentation, etc.

Découpage des projets

Je me creuse la tête depuis un moment au sujet de la meilleure manière de découper les projets. Avoir un seul niveau d’organisation n’est pas satisfaisant ; on se retrouve à avoir une liste de tâches interminable, sans pouvoir faire de regroupements logiques.

J’aime bien l’idée d’offrir un deuxième niveau d’organisation. Cela semble assez naturel de pouvoir découper un projet en plusieurs sous-projets. Dans ma tête, chaque sous-projet est un ensemble logique pouvant comporter :

• une ou plusieurs listes (par exemple une liste de tâches et une buglist)
• une collection de « pages » de wiki (spécifications du sous-projet, documentation technique, checklist, …)
• un espace de stockage pour des pièces-jointes, elles-mêmes éventuellement réparties dans des sous-dossiers
• une liste de messages portant sur le sous-projet

Si on suit cette vision, il faut proposer une vision complète au niveau du projet, qui rassemble toutes ces informations de manière agrégée (une liste avec les tâches de tous les sous-projets, toutes les pages de wiki, toutes les pièce-jointe, et ainsi de suite).

Faut-il proposer une organisation plus complexe ? Certain logiciels permettent de créer autant de niveaux de sous-sous-projets que l’on veut. Mais personnellement je trouve ça inutilement complexe ; on s’y perd et la productivité n’y gagne rien.

Informations liées aux sous-projets

Avec ce découpage en sous-projets, il m’est venu naturellement une idée : on pourrait donner une date de début et une date de fin à chaque sous-projet. De cette manière, il serait très facile de représenter graphiquement les sous-projets sur une ligne de temps, de manière à faire une sorte de diagramme de Gantt simplifié. C’est parfait pour la vision macro dont je parlais plus haut.
On aurait donc deux informations très synthétiques associées à chaque sous projet : ses dates de début et de fin, et son pourcentage de complétion (qui serait calculé à partir du statut des tâches faisant partie du sous-projet).

Imaginons que pour le projet « Mini-satellite en orbite », on aurait les sous-projets :

• Construction de l’espace de lancement – 28 fév. au 4 mars – 10%
• Étude de la fusée – 21 fév. au 11 mars – 25%
• Montage de la fusée – 14 mars au 1 avril – 0%
• Construction du satellite – 7 mars au 31 mars – 5%

Sauf que… tout dépend de la manière dont vous gérez vos projets. Dans mon entreprise, les sous-projets décrivent souvent une nouvelle fonctionnalité ; pour l’implémenter, on a besoin d’une spécification fonctionnelle, une spécification technique, de maquettes graphiques, de documentation technique ; pour en faire le suivi, on a besoin d’une liste de tâches qui va nous servir à découper précisément les différentes étapes de l’implémentation, et d’une buglist qui va servir durant les tests et la recette.

Mais bien souvent, un sous-projet va être segmenté en plusieurs unités fonctionnelles. Parce qu’on veut développer rapidement les aspects essentiels de cette nouvelle fonctionnalité, mais que certains détails peuvent être repoussés à plus tard. On ne peut alors pas considérer le sous-projet comme étant un bloc unique sur lequel on va travailler d’une seule traite et sur lequel on ne reviendra jamais.
Faut-il prévoir qu’un sous-projet puisse être découpé en plusieurs sous-unités ? Arg, non, on en reviendrait à une gestion de sous-sous-projets, que j’ai éliminé précédemment.

À cela s’ajoute une notion essentielle, celle de livraison. La plupart des projets, qu’ils soient informatiques ou non, prévoient que plusieurs sous-projet − appartenant à des projets différents − soient mis en production (ou l’équivalent) en même temps. Comme faire pour gérer ça correctement si la seule vision disponible est projet par projet (ou sous-projet par sous-projet) ?

Labels et assimilés

À partir de là, j’ai commencé à réfléchir à encore une autre notion : On peut tout à fait avoir un élément (tâche, wiki, pièce-jointe) qui soit commun à plusieurs sous-projets, voire même à plusieurs projets. Tout n’est pas aussi segmenté qu’on le voudrait parfois. Une maquette graphique peut contenir des informations pertinentes pour plusieurs réalisation finales différentes.

Est-ce que la solution ne serait pas d’appliquer des labels (ou tags, si vous préférez) ? Imaginons une tâche «Mettre à jour MySQL» ; elle peut être dans le projet « IT », sous-projet « Maintenance », mais aussi dans le projet « Site Web », sous-projet « Performances ». En fait, si on y réfléchit bien, la tâche doit être effectuée, et en ce sens elle a une existence propre. Qu’on veuille la voir dans les projets « IT/Maintenance » ou « Site Web/Performances » n’est qu’une question d’organisation de l’information. Suivant les personnes impactées, il faudra qu’elle soit visible dans l’un ou dans l’autre.
Habituellement, on contourne ce genre de considérations en dupliquant les informations, mais je ne suis pas certain que le gain en simplicité (relative) à la création vaille la peine au regard de la plus grande complexité dans le suivi.

J’en arrive donc à penser que les projets et les sous-projets deviendraient des tags. Quand on navigue dans les projets et les sous-projets, on se retrouve simplement à filtrer les contenus qui sont affichés, pour ne voir que ceux qui portent le tag correspondant.
Première chose importante : On peut appliquer autant de tag que l’on veut à n’importe quel élément.

Mais si on revient sur la notion de «livraison» dont je parlais tout à l’heure, le problème reste entier. Mais… est-ce qu’une livraison (ou un jalon, ou une deadline, ou une release, appelez ça comme vous voulez) ne serait pas là encore une sorte de filtre, qui sert à ne voir qu’un sous-ensemble des informations d’un projet ? Bien sûr que si ! Pour définir un jalon, il suffit de créer un label (avec une date de fin), et de l’appliquer à tous les éléments nécessaires. Ainsi, pas de modification sur le découpage projets/sous-projets, et on peut facilement retrouver tous les éléments qui portent ce label.La même logique pourrait s’appliquer pour affecter des tâches à une ou plusieurs personnes. Il suffirait de placer des tags idoines.

Tiens, je pense à autre chose : Je ne sais pas pour vous, mais il m’arrive souvent de vouloir regrouper des informations ensemble, parce que j’en ai besoin temporairement. Et je ne le fais pas, parce que cela voudrait dire que tous les autres utilisateurs verraient ces changement dans l’organisation des projets. On pourrait imaginer des tags privés, qui permettrait d’organiser les choses sans pour autant modifier ce que les autres peuvent voir.

Dernière chose qui me semble intéressante, la possibilité de créer des tags dynamiques. Cela voudrait dire qu’on pourrait créer un tag qui soit lié à un autre, mais en ajoutant des informations de filtrage supplémentaire. Par exemple, je pourrais créer un tag lié à un sous-projet donné, mais qui n’en afficherait que les entrées de buglist (filtre 1) qui me sont affectées (filtre 2).

Au final, quels seraient les caractéristiques d’un label ?

• Sa visibilité (privé ou public). Un label privé n’est visible que par son créateur. Un label public est attaché au projet et tout le monde le voit.
• Son projet. Ou plus exactement, l’information de projet qu’il va transmettre aux éléments auquel il sera appliqué.
• Son sous-projet. Ou plus exactement, l’information de sous-projet qu’il va transmettre aux éléments auquel il sera appliqué.
• Ses dates de début et de fin.
• Son filtrage, c’est-à-dire les types d’informations visibles lorsqu’on utilise le label comme filtre d’affichage.
• Le label auquel il est lié.
• L’utilisateur concerné.
• Un texte libre, pour créer des tags au sens habituel du terme.

Labels, filtres, droits utilisateurs

Ce dont je viens de parler au sujets des labels et des filtres est valable d’un point de vue technique uniquement. D’un point de vue ergonomique, il faut proposer des fonctionnalités claires, pas simplement laisser les utilisateurs jongler avec leurs tags, car cela peut facilement porter à confusion.

Il faut quand même éclaircir la différence entre un label et un filtre. Si techniquement cela représente une seule chose, la différence se fait suivant qu’on soit en lecture ou en écriture.

Prenons l’exemple du projet « Anniversaire ». Il contient un sous-projet « Cuisine ». J’ajoute une tâche à ce sous-projet, lui donnant le titre « Préparer gâteau ».
La tâche possède donc automatiquement le tag « Anniversaire/Cuisine ». C’est à la création de la tâche que le label a été ajouté.
Maintenant imaginons que je crée un sous-projet « Moi/À faire », que je paramètre pour (1) n’afficher que les tâches et (2) celles qui me sont affectées. Lorsque je vais voir ce sous-projet, il va m’afficher toutes mes tâches, c’est alors un filtre.

Bon, mais si on gère tous les aspects techniques à travers un tel système de tags, il faut se poser quelques questions concernant la gestion des droits utilisateurs.
Dans tous les logiciels de gestion de projet, les buglists, et même les blogs multi-utilisateurs, il y a la possibilité de gérer «qui peut voir quoi» et «qui peut faire quoi». Il faudrait donc spécifier la relation que chaque utilisateur entretient avec les labels. Il peut être :

• Administrateur. Il peut modifier à loisir la définition du label, ainsi que tous les contenus qui portent ce label.
• Accès en lecture. Il peut accéder au label et voir tous les contenus qui le portent.
• Accès en écriture. Il peut accéder au label et voir tous les contenus qui le portent, mais il ne peut pas modifier la définition du label.

Ainsi, l’administrateur peut décider que le sous-projet « Musique/Concert » contient une liste de tâche et un partage de fichier, mais rien d’autre (pas de wiki, pas de buglist). Une personne ayant les droits en écriture peut ajouter, modifier et effacer des tâches et des pièces-jointes ; il ne peut pas ajouter une buglist dans ce sous-projet. Une personne ayant les droits en lecture peut lire les tâches et les pièces-jointes.
Ce sont les administrateurs  qui déterminent les droits des utilisateurs. Bref, quelqu’un qui a les droits Administrateur sur un label décide des droits des autres utilisateurs pour ce label. Pour que cela ne devienne pas trop répétitif, il faudra proposer une option à la création d’un sous-projet, pour donner les mêmes droits que sur le projet.

Cette gestion des droits me paraît être celle qui offre le meilleur rapport entre simplicité et souplesse. En contrepartie, il sera impossible de donner des droits du genre : autoriser la lecture des pages wiki mais pas leur modification, tout en autorisant la création d’entrées dans la buglist mais pas leur effacement. Est-ce vraiment un soucis ?

Tags à l’ancienne

Avec tout ça, je n’ai quasiment pas parlé de l’utilisation de tags comme on a l’habitude de le faire… Pour tagguer les contenus, quoi. Ajouter une information sur certains contenus afin d’en faciliter la recherche.

J’avais en tête un système légèrement différent de ce qu’on trouve en temps normal. Je m’explique.
La plupart du temps, les systèmes de tag sont assez simples : on peut assigner des labels textuels à des contenus. Et c’est tout. Il n’y a pas de contexte (le tag « pouet » a la même signification quel que soit l’endroit où il a été placé). Il n’y a pas de suggestion réelle (éventuellement une liste des tags les plus utilisés, mais toujours hors contexte). Bref, je trouve personnellement que ces systèmes ne font pas gagner beaucoup de temps. Si on veut filtrer les données en utilisant les tags, c’est un peu galère. Si on veut faire une recherche, autant utiliser une recherche full text.

J’imaginais donc de pouvoir associer des listes de tags « préférentiels » aux différents éléments. Prenons un exemple :

• Le projet « Vacances » possède le tag « prix ».
  • Le sous-projet « Activités » possède les tags « enfants » et « adultes ».
    • Un groupe de pages de wiki possède les tags « proposition », « accepté » et « refusé ».
    • Une liste neutre (une liste simple, ni une liste de tâche, ni une buglist) possède les tags « réservé » et « à fuir ».

Ainsi, il serait possible de créer une page de wiki et de lui assigner les tags « enfant » et « proposition ». Ou un élément de liste avec les tags « prix », « enfants » et « réservé ». Ensuite, il serait possible de filtrer l’affichage pour ne faire apparaître que les éléments qui possèdent un ou plusieurs tags parmi ceux disponibles.

Mais… Si on peut appliquer des tags à un projet (pour que ceux-ci soient applicables aux éléments du projet, vous suivez ?), cela veut dire qu’on doit pouvoir tagguer un tag…

On va peut-être se calmer

Sauf que là je commence à imaginer une espèce d’usine à gaz où tout est fait à base de tags. Les projets sont des tags, les sous-projets sont des tags, l’assignation d’une tâche à quelqu’un se fait en ajoutant à la tâche un tag représentant la personne, les deadlines sont aussi des tags, ainsi que le « filtrage ».
On risque d’avoir même des tags sur plusieurs niveaux (des tags de tags). Et encore, je n’ai pas parlé de la gestion des groupes d’utilisateurs…

Tout ça semble bien beau d’un point de vue théorique, mais peut-être moins évident à implémenter qu’avec une base de données un peu plus relationnelle.

Pour conclure

Wow, cet article est quand même vachement long. J’ai mis plusieurs jours à l’écrire. Il m’a servi à éclaircir mes idées sur certaines choses, mais à force de pousser ma réflexion cela m’a amené à un point où tout s’écroule un peu. Voilà pourquoi j’ai du mal à faire avancer le projet Skriv, je cogite peut-être trop.