(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.
Fonctions à intégrer ?
J’hésite encore sur certaines fonctionnalités :
- Gestion des compte-rendus d’activité. Je sais que c’est vraiment nécessaire pour certaines entreprises, celles qui factures leurs clients en fonction du temps passé sur les projets. Et, de manière générale, il est toujours bon de savoir combien aura coûté un projet. Mais j’ai un peur peur de complexifier l’ensemble du logiciel pour une fonctionnalité qui n’est pas utile à tout le monde.
- Un forum de discussion propre à un projet peut parfois être très utile, surtout pour les équipes qui sont éclatées géographiquement. Mais je me dis que si le système de micro-blogging est bien fait, et qu’il autorise les vrais fils de discussion, il n’y aura pas besoin de faire un forum séparé du reste.
- Une édition collaborative simultanée en temps réel des pages de wiki. Un outil comme EtherPad permet de travailler à plusieurs sur le même document, en même temps. Mais c’est quand même un niveau de complexité bien supérieur, pour un usage qui reste encore à démontrer, je pense.
- Permettre de créer des dessins directement dans l’interface, par exemple en utilisant un outil comme FlockDraw. Un dessins vaut souvent mieux qu’un long discours. Alors c’est souvent intéressant d’ajouter des diagrammes explicatifs dans les fichiers d’un projet. Habituellement, il faut utiliser un logiciel de dessin, enregistrer l’image puis l’uploader sur le projet. Si on pouvait directement dessiner ”online”, ce serait plus pratique, non ?
Fonctions à ne pas intégrer
Ce que Skriv ne sera jamais :
- Un carnet d’adresse.
- Un calendrier complet pour gérer ses rendez-vous.
- Un CRM.
- Un outil de gestion de code source, d’édition de code, de profiling, de déploiement à distance, …
- Un serveur d’intégration continue.
- Un outil de facturation ou un ERP.
Avez-vous des idées de fonctionnalités qui vous semblent nécessaires, en plus de celles-ci ?