Lancement de Skriv, le logiciel de gestion de projets orienté workflow

J’ai déjà parlé plusieurs fois sur ce blog de Skriv, la startup que j’ai créée pour éditer un logiciel de gestion de projets.

Pendant mes années en tant que directeur technique,  j’avais développé l’outil qui nous servait à gérer nos projets. Cet outil implémentait le workflow que nous utilisions pour gérer nos projets, ce qui avait permis d’automatiser des tâches qui sont normalement dévolues aux chefs de projets, augmentant de fait la productivité de toute l’équipe. Et comme tout le monde devait pouvoir utiliser l’outil − même les personnes qui n’étaient pas formées à la gestion de projet ou dont le travail n’avait rien à voir avec l’informatique − j’ai dû réinventer les recettes que suivent tous les outils du marché.

Fort de cette expérience, j’ai voulu créer un logiciel que tout le monde pourrait utiliser :

  • À qui on peut enseigner la manière dont on gère nos projets, pour qu’il nous décharge des tâches répétitives.
  • Qui soit vraiment simple à prendre en main, non seulement dans son ergonomie, mais aussi par sa capacité à s’adapter à notre terminologie plutôt que d’imposer la sienne.
  • Qu’on puisse utiliser sur toutes les étapes d’un projet, depuis la première ébauche jusqu’à son déploiement (au contraire des outils qui se focalisent sur le delivery, sans gérer correctement les phases de conception).

Mieux que des mots, voici une petite vidéo de présentation :

Bref, un outil fait pour devenir indispensable pour ses utilisateurs, tout en étant le plus transparent possible : le but est d’aider les gens à travailler efficacement.

Après plusieurs mois de développement et de bêta-test, Skriv est maintenant prêt à être utilisé par tous. N’hésitez pas à vous inscrire à la période d’essai gratuit pour le tester.

L’offre tarifaire se veut la plus claire possible : le prix de lancement est de 4 € HT par utilisateur et par mois en paiement annuel, 6 € HT par utilisateur et par mois en paiement mensuel. C’est un tarif très compétitif par rapport aux concurrents.
Pour ce prix, tout est inclus : Vous pouvez créer autant de projets et stocker autant de pièces-jointes que nécessaire. Vous avez des notifications envoyées par email ou sur Slack. Vous bénéficiez d’un support par email et d’un niveau de service professionnel.

Plus d’informations sur www.skriv.com

Skriv a 3 mois : la version bêta arrive

Skriv existe depuis maintenant 3 mois, et a rejoint un incubateur en septembre. C’est le moment de vous tenir un peu au courant.

Une copie d’écran pour attiser votre curiosité 😉

Le service est toujours en cours de développement. Beaucoup de travail a été réalisé ; les principaux concepts ont été implémentés et le but est de sortir une version bêta dans le mois à venir.

Maintenant je suis à la recherche de personnes et d’équipes qui souhaitent tester Skriv.
Je vous demande de l’utiliser réellement, sur les projets de votre équipe − pas juste faire un petit test de cinq minutes. Je sais que ça demande une implication forte, et cela doit être récompensé ; en échange de votre aide, vous aurez un accès gratuit et illimité jusqu’à fin 2018, pour vous et votre équipe.

Un rappel de l’intérêt de Skriv par rapport à la concurrence :

  • Skriv est orienté workflow
    La gestion de tâches, ça n’existe pas ; cela revient à jongler entre les tâches. La gestion de projets devrait être meilleure que ça.
  • Skriv rend votre équipe plus productive
    Le travail des chefs de projets n’est pas d’assigner des tâches encore et encore tout au long de la vie des projets. Les intervenants ne devraient pas être ralentis par les tâches administratives de leurs chefs de projets.
  • Skriv est simple d’utilisation
    Je sais, tous les autres logiciels prétendent être faciles à prendre en main. Mais alors pourquoi ressemblent-ils au tableau de bord d’une navette spatiale ?

Si vous voulez participer au bêta-test de Skriv, c’est assez simple :

  1. Envoyez un email à contact@skriv.com pour montrer votre intérêt. Parlez-moi de votre équipe, des types de projets sur lesquels vous travaillez et de comment vous les gérez.
  2. Nous passerons de 15 minutes à une heure ensemble, afin que je vous présente le fonctionnement de Skriv. On peut faire ça par téléphone, mais une rencontre de visu sera plus efficace.
  3. Toutes les semaines, je vous contacterai pour savoir comment les choses se passent. Pendant ce temps, vous pourrez faire des remontées de bogues sur une interface dédiée.

J’espère qu’ensemble nous pourrons créer le meilleur outil de gestion de projets.
Je vous remercie d’avance pour votre temps et votre aide.

Création de l’entreprise Skriv

Ceux qui me connaissent, avec qui j’ai travaillé ou qui suivent ce blog depuis longtemps, ont déjà entendu parler de «Skriv». Ce mot, qui veut dire “écrire” en plusieurs langues, je l’ai utilisé pour plusieurs choses au fil du temps : langage de balisage léger, projet open-source de wiki simplifié, outil de gestion de projet utilisé dans ma précédente entreprise pendant 4 ans, etc.

Aujourd’hui, c’est un nouveau chapitre de ma vie qui s’ouvre. J’ai créé une startup qui se nomme Skriv, et dont le produit sera un logiciel de gestion de projets. Eh oui, on ne se refait pas.

Merci à Solène Tessier pour le logo

Pourquoi vouloir se lancer sur ce secteur, où il y a déjà beaucoup de concurrents ? Pour 3 raisons toutes simples :

  • C’est un sujet que j’aime.
  • C’est un sujet que je maîtrise.
  • C’est un sujet auquel je pense pouvoir apporter quelque chose de différent.

Un sujet que j’aime

Oui, la gestion de projets, c’est quelque chose que j’apprécie. Ce n’est pas nouveau. Si ce n’était pas le cas, je n’aurais sûrement pas fait ce blog 😉

Si j’aime ça, c’est sûrement parce que c’est un mélange de process et de structuration d’un côté, et de management de l’autre. Ces deux aspects sont intrinsèquement liés, il faut se sentir à l’aise avec l’ensemble si on veut être capable de faire du bon boulot.
Car souvenez-vous, la gestion de projets ça n’existe pas : on ne gère pas des projets, on gère des gens qui travaillent sur des projets.

Un sujet que je maîtrise

La gestion de projet, j’en ai appris des notions de base durant mes études d’ingénieur, que j’ai mises en pratique en étant chef de projets dans plusieurs startups.
J’ai participé à la création de la société Fine Media en tant que directeur technique. Ce rôle m’a amené à mettre en place des processus dans l’entreprise et à réfléchir à l’ensemble de la manière dont on gérait les projets de développement.
J’ai fait un Executive MBA en “Management et Entrepreneuriat”, qui m’a permis d’approfondir mes connaissances.
J’ai fait une certification de 8 mois en “Software Product Management” à l’Université d’Alberta, qui m’a conforté dans ce que je savais, et ce que je savais faire.

Concernant les logiciels de gestion de projet, j’en ai testé et évalué un assez grand nombre, que ce soit pour les besoins de ce blog ou pour ceux des entreprises dans lesquelles j’ai travaillé.
J’ai développé sur mon temps libre le logiciel de gestion de projets qui était utilisé chez Fine Media. C’était au début un wiki sous stéroïdes, puis j’y ai ajouté la gestion de tâches, puis j’y ai intégré la gestion de tout notre workflow. Ce logiciel était utilisé par des gens aux profils très différents (des chefs de projets, des informaticiens, des content managers, des commerciaux, des account managers…) et il a fallu faire en sorte qu’il soit manipulable le plus simplement possible.

Cette expérience a une grande valeur. Aujourd’hui, je ne développe pas le premier prototype de mon logiciel ; j’en suis à la cinquième version !

Les trois premières versions n’étaient pas très belles, mais elles étaient efficaces et simples d’utilisation :

La quatrième version était déjà une réécriture totale :

Soyez patients pour voir à quoi ressemblera la cinquième version 😉

Un sujet auquel je pense pouvoir apporter quelque chose de différent

Oui, il existe un certain nombre de logiciels de gestion de projets sur le marché. Certains sont assez gros ; il y a eu de belles levées de fond, des rachats et même des entrées en bourse… Est-ce que ça veut dire que ce marché est bouché ? Je ne le pense pas. Le nombre d’entreprises qui ont besoin d’outils performants est énorme, il y a toujours une place à se faire. Par contre, il faut savoir se différencier des autres.

Si on regarde à quoi ressemble le marché :

Image provenant de https://www.inflectra.com/company/article/452.aspx

Pour moi, le but est d’être là :

Ne pas être celui qui a le plus de fonctionnalités, mais celui qui apporte la meilleure plus-value.

Alors en quoi Skriv est-il différent des autres ? Eh bien là où ils sont tous orientés “tâches”, Skriv est orienté “workflow”. Pour avoir travaillé plusieurs années en utilisant cette vision (après avoir travaillé auparavant de manière plus conventionnelle), je peux vous assurer que cela permet d’être bien plus efficace. Plus de projets, mieux gérés (plus vite, avec moins d’erreurs), moins de stress…
Et cela est tellement éloigné de l’ADN des autres logiciels (souvenez-vous que JIRA a même commencé en n’étant qu’une buglist) que je pense pouvoir me faire une place.

J’ai quelques idées supplémentaires quant au positionnement et au pricing… mais il faudra attendre un peu avant que je dévoile tout ça 😉

Et la suite ?

Pour faire simple, je suis en plein développement. Les formalités administratives m’ont pris du temps et de l’énergie, mais je continue à avancer à un bon rythme.

Le but est de lancer une version bêta dans quelques mois, avec un nombre réduit d’entreprises/équipes qui accepteront de jouer le jeu (c’est-à-dire vraiment utiliser l’outil pour me faire des retours pertinents) en échange d’un accès gratuit pendant un bon bout de temps. Quelques mois plus tard, ce sera le lancement commercial, dont le succès dépendra de tant de critères (qualité de la réalisation, efficacité du marketing mis en place, etc.) que je n’ose faire le moindre pronostic pour le moment. Il faut mettre le curseur au bon endroit entre humilité et ambition 😀

Je vais évidemment continuer à parler de ma création d’entreprise sur ce blog ; on est en plein dans le sujet, que ce soit l’aspect entrepreneurial ou tout ce qui concerne la gestion de projets elle-même.

Si vous souhaitez être prévenu lors du lancement, je vous invite à entrer votre adresse email dans le formulaire sur le site skriv.com.

Ouverture des extensions du SkrivML

Dans le cadre du Skriv Markup Language, j’ai prévu qu’il soit possible de faire évoluer le langage grâce à un système d’extensions. Je viens de terminer la partie du site qui permet de proposer des extensions, de les commenter et de voter pour/contre.

Pour l’instant, quatre extensions sont proposées au vote public. J’en suis l’auteur, mais j’espère sincèrement que d’autres personnes vont se prendre au jeu et proposer à leur tour des idées d’évolutions.
À noter que je suis susceptible d’ajouter dans l’interpréteur PHP SkrivMarkup des extensions, même si elle n’ont pas été validées officiellement dans le langage ; elles ne seront juste pas activées par défaut. Le corollaire, c’est évidemment que les contributions en code source sont très appréciées elles aussi.

Toutes les personnes ayant une utilisation ou un besoin d’un système de balisage léger comme SkrivML (ou l’un des autres systèmes équivalents) sont invitées à venir participer, à voter pour les extensions, bref à créer une communauté visant à construire les meilleurs outils wiki-like.

Pour ceux qui avaient déjà voté sur les propositions d’extensions, je suis désolé mais j’ai dû tout remettre à zéro. Tout a été recodé, et il est maintenant obligatoire d’écrire un commentaire quand on vote sur une proposition. Encore toutes mes excuses, et je vous demande de bien vouloir revenir partager vos avis.

J’en profite pour lancer deux appels à l’aide :

  • Si vous avez en tête des outils qui pourraient être utiles, associés au SkrivML, n’hésitez pas à m’écrire pour m’en faire part. On m’a déjà suggérer de faire une définition de syntaxe pour des éditeurs de texte, c’est une bonne idée. Autre chose ?
  • Est-ce que vous connaissez des forums, des newsgroups ou d’autres espaces de discussion où il pourrait être utile de faire parler du SkrivML ? Je cherche évidemment à le faire connaître, mais je n’ai pas vu passer sur mon radar de tel lieu d’échange numérique…

Merci d’avance pour vos contributions.

Lancement officiel du SkrivML

Il y a quelques temps, j’ai écrit un article dans lequel je présentais le Skriv Markup Language, une syntaxe de type wiki permettant d’écrire facilement des textes mis en forme. Inspiré par tous ses prédécesseurs (MediaWiki, Creole, Markdown, Textile, reStructuredText, AsciiDoc, …), ce langage essaye d’être le plus simple à mémoriser tout en offrant des possibilités d’évolution grâce à un syntaxe dédiée aux extensions.

Après y avoir travaillé pas mal ces derniers temps, je lance maintenant officiellement plusieurs sites et outils autour de ce langage.

Skriv Markup Language

Sur le site http://markup.skriv.org, vous trouverez toutes les informations sur le langage SkrivML : Ses principes fondateurs, ses sources d’inspiration, sa syntaxe complète et détaillée (avec des explications sur les choix effectués), ses extensions.

Comme je l’ai dit plus haut, SkrivML reprend un certain nombre de concepts des autres syntaxes similaires, en essayant d’être le plus homogène possible. Les éléments de syntaxe doivent être évidents à comprendre, pour être faciles à se rappeler.

Le principe général est que SkrivML cherche à être rapide à utiliser. Si c’est pour que la saisie soit lente, autant utiliser des éditeurs WYSIWYG. SkrivML ne cherche pas à gérer des cas ultra-particuliers de mise-en-page, mais plutôt à répondre le mieux possible aux cas d’utilisation les plus courants.
Le langage apporte quand même quelques idées qui me semblent novatrices, comme les blocs de texte stylisés, les smileys et les symboles, ou encore les extensions.

Si vous avez des idées d’extensions, un formulaire permet d’en proposer de nouvelles. Vous pouvez aussi voter pour les extensions qui ont déjà été proposées.

Enfin, une interface permet de tester la syntaxe SkrivML, avec une interprétation en temps réel de ce que vous tapez.

SkrivMarkup

J’ai développé une bibliothèque en PHP pour transformer du texte SkrivML en code HTML. Elle est basée sur le projet WikiRenderer (un impressionnant projet mené par Laurent Jouanneau). J’ai reçu la précieuse aide de Renaud Littolff, qui m’a aidé à débugguer et améliorer SkrivMarkup.

Cette bibliothèque est très facile à installer, notamment grâce à Composer. Elle peut prendre un grand nombre de paramètres de configuration, qui sont expliqués sur le site du projet.

Elle est publiée sous licence libre, et son code est disponible sur GitHub.

Skriv.io

Pour faciliter l’utilisation de SkrivML, j’ai mis en place un webservice qui permet à tout le monde de réaliser des interprétations du langage, sans avoir besoin d’installer le moindre logiciel. Il est très facile à appeler ; j’ai mis en ligne des exemples de code dans plusieurs langages (PHP, Javascript, Ruby, Python, Lua).
Voici un exemple d’appel en PHP :

$skriv = '**bold** text __italic__';
$url = 'http://api.skriv.io/convert/html';
$html = file_get_contents("$url?text=" . urlencode($skriv));

Il est possible de configurer les paramètres d’interprétation.

Son utilisation est complètement gratuite. Elle le restera toujours pour la conversion en HTML. Peut-être qu’un jour j’ajouterai des fonctionnalités supplémentaire, et je peux imaginer que certaines soient payantes ; mais l’utilisation de base restera toujours complètement gratuite.

Ark

Ce projet avait pour but de démontrer les capacités de SkrivML. C’est une sorte de wiki, dans lequel les pages de texte sont organisées de manière hiérarchique. Ainsi, chaque page peut contenir des sous-pages, avec une navigation à côté du corps de texte.

Une version de démonstration est accessible. Le code source est publié sous licence libre et disponible sur GitHub.

Documentation Atoum

Je ne pourrais pas parler de SkrivML sans citer la documentation d’Atoum, le framework de tests unitaires créé par Frédéric Hardy. Le mainteneur de cette documentation, Renaud Littolff, s’est intéressé à SkrivML dès que j’en ai parlé sur ce blog, et à commencé à utiliser la bibliothèque SkrivMarkup dès que j’en ai publié le code. Il a vraiment été exemplaire, aussi bien dans ses remontées de bug que dans ses propositions d’améliorations, et je suis impressionné par la qualité du site qu’il a créé.

Le futur

J’ai quelques surprises dans les tuyaux.

Je pense améliorer le système de propositions d’extensions, pour permettre de commenter et de discuter réellement les propositions avant de les accepter ou de les refuser.

D’ailleurs, il y a quelques extensions que j’ai proposées, que je compte bien implémenter parce que j’en ai besoin.

J’aimerais trouver le temps pour faire évoluer la bibliothèque SkrivMarkup, pour qu’elle soit capable de générer du DocBook ou encore du RTF.

Je réfléchis à plusieurs évolutions du service skriv.io comme la génération de PDF, l’utilisation de templates CSS, et quelques autres joyeusetés.

Je travaille sur quelques outils, qui utilisent tous la syntaxe SkrivML. Je ne sais pas encore jusqu’à quel point je vais les pousser, ou encore lesquels vont être publiés sous licence libre. Mais il y a de belles choses à faire.

Skriv Markup Language

Il y a quelques temps, j’ai écrit un article au sujet des syntaxes wiki-like de Creole et Markdown. Au fil des commentaires, j’ai expliqué que j’avais développé ma propre syntaxe, principalement inspirée par Creole.

J’ai récemment développé un outil de gestion de projets, interne à mon entreprise. Je l’ai nommé Skriv, du nom de mon projet-arlésienne. Je ne désespère d’ailleurs pas d’en faire une version open-source que je pourrais publier ; ça en vaudrait la peine, je suis très fier du résultat − mais j’aurais l’occasion de vous en reparler sur ce blog.

Bref, au sein de ce projet, j’ai fait évoluer ma syntaxe wiki. L’interpréteur est développé sur la base de la bibliothèque WikiRenderer, créée par Laurent Jouanneau. Je vais bientôt publier cet interpréteur, mais pour le moment je vais surtout présenter les éléments de la syntaxe.

À terme, je pense mettre en place un site dédié, avec une explication détaillée de chaque éléments de la syntaxe (et des raisons qui ont conduit à chaque choix), et un système d’extension permettant d’ajouter des nouvelles fonctionnalités.

Base

Styles de base

Skriv Résultat Origine
**gras**
gras txt2tags, Creole
''italique''
italique MediaWiki
--barré--
barré txt2tags
__souligné__
souligné txt2tags, Creole
##monospace##
monospace Creole, AsciiDoc
texte ^^exposant^^
texte exposant Creole
texte ,,indice,,
texte indice Creole

Continuer la lecture de « Skriv Markup Language »

Skriv : Droits utilisateurs

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

Ça fait un bout de temps que je n’ai pas parlé de Skriv, mais je continue à travailler dessus (c’est une des raisons de ma faible productivité sur ce blog).

J’avais écrit un article concernant l’organisation de l’information. C’était intéressant, mais j’étais parti dans une direction bien trop complexe pour être envisageable ; je m’empêtrais dans un système de tags tentaculaire. J’ai continué à réfléchir à tout ça, cette fois-ci en partant du besoin fonctionnel pour aller jusqu’aux droits d’accès des utilisateurs. L’air de rien il s’agit d’un point très important, qui influe directement sur la philosophie de l’outil.

Organisation de l’information

Pour commencer, parlons du découpage des données :

  • Il existe des projets, auxquels les utilisateurs ont accès.
  • Les utilisateurs possèdent des groupes de projets, dans lesquels ils peuvent placer leurs projets. Ainsi, j’imagine que je mettrai le projet «IT» dans le groupe «Professionnel», alors qu’un de mes collègues le mettra peut-être dans son groupe «Informatique».
  • Les projets contiennent des sous-projets. Chaque sous-projet peut contenir un ensemble de listes, de fichiers, de documents écrits, etc. C’est LE moyen de regrouper des informations connexes (par exemple une spécification fonctionnelle, des maquettes graphiques, une spécification technique, une liste de tâche et une liste de bugs) au sein d’un même ensemble logique.

L’idée est de permettre à chacun d’organiser les données de la manière qui lui convient le mieux. Habituellement, les logiciels de gestion de projet sont assez binaires : Ils servent à gérer les projets de l’entreprise, et donc les projets qu’on y crée sont visibles par les membres de l’entreprise ; les systèmes de gestion des droits empêchent d’ailleurs souvent de créer des projets quand on n’est pas soi-même un administrateur ou un chef de projet. Pour ma part, j’ai une vision très différente des choses. Continuer la lecture de « Skriv : Droits utilisateurs »

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).

Continuer la lecture de « Skriv : Organisation de l’information »

Skriv : Partage de fichiers

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

Je suis en train de réfléchir à la meilleure manière de gérer le partage de fichiers dans un projet.

Moyens de stockage

Pour commencer, je veux faire en sorte que chaque projet puisse stocker ses fichiers sur un espace géré (et payé) par l’utilisateur. Cela pourrait être un serveur FTP, un serveur WebDAV ou un espace sur Amazon S3.
Comme déjà dit auparavant, cela permet d’offrir des fonctionnalités complètes, sans avoir à se mettre dans une relation client/fournisseur. La plupart des entreprises ont déjà un serveur FTP ou WebDAV. Et plutôt que de faire payer pour « sous-louer » un espace sur Amazon S3, avec des paliers tarifaires en fonction de forfaits d’espace disque, autant laisser les gens s’abonner par eux-même et payer en fonction de leur utilisation.

Toutefois, je pense finalement offrir un tout petit espace disque (5 MO, par exemple) à ceux qui veulent découvrir le service sans se prendre la tête.

Principe général

Donc voilà en gros ce que j’imagine :

  1. Quand on crée un projet, on spécifie les paramètres d’accès à un stockage distant de données (FTP, WebDAV ou S3).
  2. Sur la page de projet, on peut créer plusieurs « groupes de fichiers ». Pour chaque groupe est créé un nouveau dossier sur le stockage distant.
  3. On peut uploader des fichiers dans un groupe. Le fichier apparaîtra dans ce groupe avec toutes ses caractéristiques (miniature si c’est une image, nom du fichier, nom du créateur, date d’ajout, taille du fichier, commentaires éventuels), et son binaire sera ajouté dans le dossier dédié sur le stockage distant.

Je me pose une question : Faut-il se contenter d’afficher le nom du fichier tel qu’il a été uploadé ? Ne vaudrait-il pas mieux proposer un champ libre, pour décrire son contenu mieux que ne le fait son nom ?
Hum, je pense que si… mais cela doit rester optionnel. Si on ne remplit pas ce champ, le nom du fichier sera affiché tel quel.

Idéalement, il faudrait pouvoir créer une sous-organisation à l’intérieur des groupes de fichiers. Cela pourrait prendre la forme simple de sous-dossiers. Mais cela pourrait aussi être des tags (je préfère le terme “label”) que l’on affecterait aux fichiers. On pourrait ainsi trier par label, par date ou par nom.

Par contre, il n’y a rien de plus pénible que de devoir systématiquement taper les noms de labels au clavier. Même avec un système de complétion, c’est chiant.
Je pense donc qu’il faudrait, pour chaque groupe de fichiers, pouvoir créer des labels à l’avance. Ainsi, au moment d’ajouter un fichier, il n’y aurait qu’à cocher le ou les labels à lui affecter (et éventuellement la possibilité d’en ajouter à ce moment-là). Pour l’affichage des fichiers, cela simplifierait aussi les choses : il suffirait là encore de cocher le ou les labels qui nous intéressent pour voir la liste des fichiers qui y correspondent.

Continuer la lecture de « Skriv : Partage de fichiers »

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 ?