J’en parlais récemment dans le post concernant l’avenir de ce blog : Je réfléchis à l’idée de développer un outil de gestion de projet ouvert à tous.

Quasiment depuis que je travaille, j’ai développé des outils pour suivre les projets ou traiter les bugs. Comme j’ai souvent bossé dans des entreprises de petite taille, pour ne pas dire des start-ups, ces outils comblaient des manques évidents et étaient adoptés rapidement.

• Il y a maintenant un paquet d’années, j’avais fait un gestionnaire de buglist. Doté d’une interface web, il était écrit en C et stockait ses données dans un fichier XML. Technologiquement, ce n’était pas une très bonne idée, mais c’était l’occasion de tester des librairies XML et CGI que j’avais écrites en C. Au niveau des fonctionnalités, je ne me souviens plus trop. Je crois que c’était assez simple, avec pour chaque bug le niveau de criticité, une description, et le projet affecté.
• J’avais par la suite repris le même genre d’outil, mais écrit en PHP/MySQL. Pus facile à faire évoluer, je n’ai pas souvenir qu’on l’ait utilisé à son plein potentiel.
• Dans mon entreprise actuelle, j’ai dès le début mis en place des outils open-source, les plus important étant Flyspray pour la buglist et MediaWiki pour le wiki. Depuis, j’ai développé des extensions MediaWiki qui nous servent à gérer les projets. Ainsi, chaque projet a une page dédiée sur laquelle apparaissent : la liste des bugs du projet, une liste de tâches, des pages wiki liées au projet, et des fichiers en « pièce-jointe ».

Cette extension est clairement inspirée par Backpack. J’aime vraiment ce logiciel. Par rapport à d’autres outils plus orientés « projet », comme Basecamp par exemple (pour reprendre un autre logiciel développé par 37signals), j’apprécie le fait que toutes les informations soient regroupées sur une seule page.
Habituellement, les logiciels de gestion de projets offrent plusieurs vues différentes, chacune pour un type d’information. Il y a un onglet pour les tâches, un onglet pour le calendrier, un onglet pour les bugs (si l’outil les gère), un onglet pour les pages de wiki (si c’est disponible), un onglet pour les fichiers, et ainsi de suite.
Pour ma part, je préfère avoir la vue la plus « intégrée » possible. Cela implique de penser l’interface en conséquence, ce qui peut s’avérer plus délicat qu’il n’y paraît.

Je cherche donc maintenant à définir un outil que je pourrais utiliser aussi bien pour mes besoins en entreprise, que pour gérer mes projets personnels. Je vais donc m’intéresser à chaque aspect d’un tel logiciel dans une série de billets sur le blog. Je ferais appel aux avis des lecteurs du blog, en espérant réussir à dégager des principes clairs de fonctionnement. J’espère aussi trouver le temps de développer ce logiciel, pour que tout cela ne reste pas théorique (d’un autre côté, si un autre outil est développé à partir de spécifications dérivées de mes idées, je n’y verrais aucun problème, bien au contraire).

Ah, au fait, pourquoi appeler ce projet «Skriv» ? C’est un nom que j’affectionne, que j’ai donné par le passé à plusieurs logiciels que j’ai développé. Le plus important était une interface web qui intégrait un webmail, un gestionnaire de bookmarks, un bloc-notes, un carnet d’adresses, une gestion de compte bancaire. Je l’utilisais tous les jours pour centraliser ma vie numérique. De nos jours, c’est assez commun ; mais à l’époque où je l’ai développé (en 2002), c’était assez novateur.
Pour le nom lui-même, il signifie « écrire » dans plusieurs langues comme le breton et le suédois. Ça va bien dans l’idée d’un outil qui sert principalement à communiquer.