De geek à directeur technique

(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 ?

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

Alors, j'ai commencé par discuter de l'accès au service et de son prix. Maintenant il serait bon de s'attacher au cœur du problème : à quoi va-t-il servir exactement, quelles vont être ses fonctionnalités ?

Je voudrais définir un outil qui puisse servir aussi bien pour gérer des projets professionnels que personnels. Je dois avouer que la plupart de mes projets personnels ressemblent furieusement à des projets informatiques, mais ce n'est pas une règle absolue.
Comme je l'ai dit en commentaire du précédent billet, la vision que j'ai de Skriv est celle d'un outil de travail collaboratif plus que d'un outil de gestion de projet. Je ne souhaite pas faire un logiciel qui servira uniquement aux “décideurs” pour suivre le travail de leurs employés ; je veux faire le méga-tableau-de-bord qui servira tous les jours (et plusieurs fois par jour !) à l'ensemble de mes collaborateurs pour organiser leur travail, pour communiquer sur tous les aspects de leur travail.

Fonctions de base

On peut reprendre les 4 grands types de fonctionnalités habituelles :

• Un affichage “tableau de bord” qui affiche l'activité récente sur un projet ou sur tous les projets auxquels l'utilisateur a accès.
• Les listes. Il faut pouvoir créer autant de listes que nécessaires, avec la possibilité de les adapter aux besoins (buglist, todolist, checklist).
• Les pages de documentation textuelle. Appelons ça un "wiki", même si j'hésite entre l'utilisation d'une syntaxe de type wiki et l'utilisation d'un éditeur HTML WYSIWYG. Il faut pouvoir lier une page de wiki à une tâche.
• Le partage de fichiers. Chaque projet a bien souvent besoin de fichiers binaires, qu'il s'agisse de feuilles de calcul, d'images ou autres. Il faut pouvoir lier un fichier à une tâche.

Fonctions supplémentaires

Ce qu'on peut y ajouter :

• Des “vues” calendaires, mais je place ça plutôt dans la partie ergonomie/affichage. Cela reste important, surtout si on se sert de ces vues pour éditer les tâches (ce qui revient plus ou moins à avoir un diagramme de Gantt).
• Des rappels par email ou SMS, que ce soit pour nous rappeler des tâches (todolist/buglist de projet) ou définis personnellement.
• La connexion à un compte IMAP. Il y a toujours des informations importantes qui sont échangées par email (même si ce n'est pas une bonne pratique). On pourrait dédier un dossier IMAP à chaque projet, et y accéder via l'interface. On pourrait trouver un moyen pour créer des tâches à partir d'emails, et extraire les pièce-jointes des emails pour les ajouter au partage de fichiers.
• Un système de micro-blogging. Même si j'ai déjà fait part de mon scepticisme vis-à-vis de ce genre d'outil, il y a sûrement moyen de créer un canal de communication supplémentaire. Les micro-messages seraient affichés sur le “tableau de bord” au milieu des indications d'évolution du projet.

Concernant la «communication» :

• On pourrait imaginer que le logiciel pourrait envoyer des emails avec un résumé quotidien ou hebdomadaire des évolutions d'un ou plusieurs projets qu'on aurait décidé de "suivre".
• Il faudrait proposer des flux RSS permettant aux utilisateurs de suivre leurs projets dans un outil externe. Un flux qui reprenne l'activité de tous les projets, un flux pour l'activité des projets “suivis”, et un flux par projet.
• Il faudrait aussi proposer un export au format ICS (iCalendar), pour permettre de suivre les tâches et les projets dans un outil externe comme iCal, Sunbird ou Google Calendar.