Les tâches « gazeuses »

Est-ce que vous connaissez la particularité fondamentale de l’état gazeux ? Wikipédia le dit très bien :

Dans l’état gazeux, la matière n’a pas de forme propre ni de volume propre : un gaz tend à occuper tout le volume disponible.
 

Ce que j’appelle les « tâches gazeuses », ce sont les projets − ou les éléments d’un projet − qui ont la capacité de durer aussi longtemps que vous le permettez. Quel que soit le temps que vous pouvez y passer, ça ne sera jamais terminé ; il y a toujours un dernier truc à fignoler, quelque chose sur lequel il faut réfléchir, un point important qui nécessite d’y consacrer encore un peu de temps.

J’ai tendance à séparer ces tâches en 3 types : celles qui sont intrinsèquement gazeuses, celles qui ont été mal préparées, et celles qui sont mal gérées.

Les tâches intrinsèquement gazeuses

Il existe tout un tas de tâches dont la nature même implique qu’elles ne se terminent jamais. Il s’agit principalement de celles qui nécessitent du jus de cerveau, de la réflexion, de la cogitation. On peut passer un temps infini à réfléchir à une spécification, à penser une ergonomie, à échafauder des méthodes de travail.

Mais cela peut aussi concerner des choses qui sont plus concrètes, mais qui n’ont pas forcément une ligne d’arrivée bien visible : écrire une documentation la plus complète possible, chercher un code coverage de 110% sur ses tests unitaires, optimiser du code pour grappiller un dixième de seconde supplémentaire.

Dans ces cas-là, il existe deux solutions :

  • Se créer des objectifs atteignables et s’en satisfaire. Un design peut toujours être amélioré, mais il faut être capable de converger vers une version « suffisamment » bonne.
  • Se donner un budget-temps. Quoi qu’on en dise, une tâche possède toujours une valeur spécifique. Si on y passe plus de X heures, son coût devient trop élevé pour qu’elle vaille la peine d’être réalisée.

Les tâches mal préparées

Ça paraît super-évident. Quand une tâche ou un projet a mal été préparé, on est certain de générer de l’effet tunnel. Même avec de bonne spécifications fonctionnelles, il est assez facile de croire qu’on maîtrise techniquement son sujet, et qu’on peut se jeter dans le code de manière rock’n roll. C’est le meilleur moyen pour ne pas anticiper d’éventuels problèmes, voire simplement des choix techniques qui devraient être pensés en amont.

Fatalement, ce n’est qu’une fois qu’on est face aux questions techniques qu’on commence à y réfléchir. Ça fait perdre un temps précieux.
Mais surtout, on se retrouve ainsi à résoudre les points bloquants au fur et à mesure qu’ils apparaissent. On se dit tout le temps « Je résous ce truc, et après c’est bon !« , mais l’ennui c’est qu’on va ensuite tomber sur un autre truc à résoudre, puis un autre, etc. Aucune visibilité sur l’étendue du travail à réaliser, on nage en plein brouillard.

Dans ce cas-là, il n’y a pas tente-six solutions : Il faut se pencher sur la tâche et la décortiquer méthodiquement avant de commencer à travailler réellement dessus.

Les tâches mal gérées

Vous vous souvenez du triangle qualité-coût-délai ? L’enseignement principal qu’il nous apporte est qu’on peut fixer deux des trois paramètres d’un projet, et que le troisième en découle forcément.

Lorsqu’un projet est mal géré, cela provient rarement de la qualité du travail effectué dessus ou de la précision des spécifications fournies. Non, trop souvent le problème réside dans l’impulsion initiale du projet, dans la manière dont le client appréhende ses objectifs et qu’il les communique.

Si on veut faire un POC, on voudra créer un prototype rapidement et à faible coût. Mais trop souvent, le prototype donne satisfaction et se retrouve en production. Il faut alors gérer des contraintes qui avaient été laissées de côté. Au lieu de tout redévelopper (comme il aurait fallu le faire avant de mettre en production, c’est pour ça que ça s’appelle un prototype), on passe son temps à maintenir en vie le projet, qui devient alors gazeux : on ne sait pas combien de temps chaque évolution prendra à être ajoutée, car la base même n’est pas prévue pour recevoir ces évolutions.

Autre exemple, le projet qui a été fait dans les règles de l’art au niveau de sa réalisation, mais sur lequel on a pris quelques raccourcis pour réduire les délais de livraison. Tout va bien jusqu’au jour où le projet interne est ouvert à des partenaires, et qu’on s’aperçoit qu’aucune interface n’est prête. On se dépêche de les ajouter, pour se rendre alors compte que la documentation nécessaire n’a pas été écrite. Et ainsi de suite…

Il est donc important de communiquer avec son client (qu’il soit interne ou externe), pour s’assurer que sa vision des choses est suffisamment pragmatique pour éviter les déconvenues et les déceptions.

Manymoon

Manymoon est un web-logiciel de gestion de projet. Il a fait un peu parler de lui ces derniers jours, suite à l’ouverture de la plateforme Google Apps à des applications tiers ; Manymoon y est montré en exemple d’application très utile pour les entreprises qui utilisent Google Apps.

Il n’en reste pas moins que Manymoon peut s’utiliser directement, sans passer par la plate-forme de Google.

Fonctionnalités

Manymoon est à la base assez classique dans son approche : On y crée des projets, auxquels on peut ensuite ajouter des éléments.

Tâches : Chaque tâche possède au minimum un titre, et on peut y ajouter une pièce-jointe (voir plus loin), un ordre de priorité, une date limite (voir plus loin), des tags, et un commentaire. Les tâches sont ensuite listée de manière à pouvoir facilement ajouter des commentaires, réassigner la tâche ou la remettre à plus tard. L’édition d’une tâche se fait en cliquant sur son titre, ce qui fait apparaître une pop-up contenant tous les champs modifiables.

Manymoon - Tâches

(image © Manymoon)

Jalons : Il est possible de créer des jalons, constitués d’un titre et d’une date limite. Ils agissent comme des groupes de tâches, permettant de voir d’un coup d’œil les grandes étapes d’un projet. On déplace les tâches d’un jalon à l’autre (ou en-dehors de tout jalon) par drag’n drop.

Manymoon - Jalons

(image © Manymoon)

Micro-blogging : C’est à la mode, et c’est au centre de l’utilisation de l’outil. Il est possible d’ajouter facilement des messages, en y ajoutant une pièce-jointe, un lien ou un événement. Il est aussi possible de juste signifier que l’on travaille sur un projet, voire une tâche. Ces messages s’affichent dans le “bulletin” du projet, qui affiche en plus toutes les actions effectuées (ajout ou modification de tâche, création de jalon, etc.).

Manymoon - MicroBlog

(image © Manymoon)

Continuer la lecture de « Manymoon »

Découper les tâches comme un gnome

Peut-être connaissez-vous l’auteur anglais Terry Pratchett, connu ses romans de science-fiction et de fantasy à succès.

J’aime beaucoup son ouvrage Le grand livre des gnomes. Et entre autre, il contient une phrase toute simple, pensée par le héros principal :

“ Pour accomplir une tâche impossible, on la débite en petits bouts de tâches simplement très difficiles, qu’on divise ensuite en tâches horriblement pénibles, qu’on segmente à leur tour en travaux délicats et ainsi de suite… ”

Pour le coup, Masklinn (c’est le nom du gnome) se fait cette réflexion en réfléchissant à la manière de découper et ramener à sa tanière un rat qu’il vient de tuer… Mais c’est en appliquant la même méthode qu’il finit par sauver son peuple en l’emmenant dans l’espace.

Je répète sans cesse que les listes sont à la base de toute organisation personnelle. Mais avant même de pouvoir placer des tâches sur une liste, il faut déjà définir le niveau de granularité nécessaire.

Pourquoi découper

Trop souvent, j’ai vu des gens qui se satisfaisaient d’une todo-list contenant des tâches dont les intitulés résumaient à eux seuls un projet entier. C’est complètement insensé !
Ce type de comportement a plusieurs effets pervers :

  • On a une mauvaise vision de l’ensemble des actions nécessaires pour la réalisation du projet. Cela laisse la porte ouverte à de mauvaises interprétations. Arrivé aux trois-quart de la réalisation de la tâche, on peut découvrir qu’elle nécessite un développement imprévu, qui va durer à lui seul 3 fois plus longtemps que la tache initiale. Si on l’avait anticipé, cette tâche aurait peut-être été planifiée différemment, voire même abandonnée.
  • Cela participe à l’effet tunnel : Comme on ne sait pas précisément ce qu’il va falloir faire, il est impossible d’évaluer la charge de travail correctement. Ça va peut-être prendre 3 jours, peut-être 3 semaines…
  • Et quand on ne voit pas le bout d’un projet, on se démotive rapidement.

Comment découper

Si tout le monde s’accorde habituellement sur la nécessité de découper ses tâches, on ne sait pas toujours comment s’y prendre. Ce n’est pourtant que du bon sens :

Continuer la lecture de « Découper les tâches comme un gnome »

Pas de productivité miracle

Il existe un grand nombre de soit-disant « méthodes », qui sont censées nous enseigner tout ce que nous avons besoin de savoir pour augmenter notre productivité de manière incroyable. Qu’ils s’agisse de livres ou de sites web, vous les trouverez sous des noms plus tentants les uns que les autres : « 101 trucs pour booster votre productivité« , « Travaillez à 400%« , « Soyez 10 fois plus productif« .

Évidemment, il existe des vraies méthodes d’organisation personnelle qui permettent d’augmenter notre efficacité et donc notre productivité, comme la très connue méthode GTD.

Il faut comprendre la différence entre ces deux approches.
Les méthodes d’organisation personnelle offrent des outils qui aident à faire les bons choix dans le traitement des tâches qui nous incombent. Elles se focalisent principalement sur la définition et l’identification des priorités, et le tri rapide des tâches. Leur efficacité est réelle, même si elle est inversement proportionnelle à l’organisation « naturelle » de la personne qui en applique les principes.

A contrario, les méthodes de « productivité miracle » font miroiter la possibilité de traiter plus de tâches sur la même période de temps.
Cela peut être atteint en agissant sur deux fronts : traiter les tâches plus rapidement, et réduire les périodes non consacrées au travail directement productif. C’est très honorable, et au final assez naturel quand on essaye d’optimiser notre productivité. Mais espérer multiplier sa productivité par 3, 4 ou 10, semble plutôt naïf.

  • La plupart du temps, quand on traite une tâche on le fait avec une efficacité relativement satisfaisante. Même s’il est toujours possible d’améliorer les choses (par exemple en supprimant les éléments perturbateurs, afin d’améliorer la concentration), il est souvent vain de vouloir traiter une tâche deux fois plus vite que d’habitude. On est surtout sûr de la traiter deux fois moins bien.
  • Réduire le temps non productif est une très bonne idée. Une partie de ce temps est nécessaire et relativement incompressible : tout le temps qu’on passe en formation (à en donner et à en recevoir), à réfléchir à des spécifications, à encadrer son équipe, …
  • Reste le temps pendant lequel on se gratte la tête, on joue avec des trombones, on touille son café, on va lire le journal au toilettes… Hum. Même en imaginant que vous perdiez ainsi 2 heures par jour (grosse feignasse !), et en espérant diviser ce temps par trois − ce qui constitue déjà un bonne optimisation − vous ne gagnerez que 40 minutes par jour. On est loin de la productivité décuplée !

Donc oubliez les solutions miracles. Faites votre boulot posément et dans le bon ordre. Identifiez les urgences. Déléguez.

Ne pas faire confiance à sa mémoire

Je vais le marteler une nouvelle fois : les listes sont la base de toute organisation, qu’elle soit personnelle ou d’équipe.

L’une des erreurs qu’on voit le plus souvent, que ce soit que les juniors que chez les gens désorganisés, est de faire confiance à sa mémoire.

Par exemple, un jeune développeur qui ne prend pas de notes. On lui donne 3 choses à faire pour la journée, et il revient le soir tout fier de lui. Malheureusement, il en a oublié une en cours de route.
Ou encore, un graphiste qui doit corriger une création, sans utiliser une buglist. Évidemment, il faut alors plusieurs itérations pour lui rappeler les petits détails qui lui ont déjà été remontés.
J’ai même vu une DRH qui n’avait établi aucune procédure, pensant avoir tout bien en tête. Régulièrement, il fallait lui rappeler qu’on était en attente d’un justificatif qu’elle n’avait pas préparé.

Le fondement de cette erreur, c’est qu’au moment où on reçoit une information, notre attention se focalise dessus. Elle remplit toutes nos « cases mémoire ». On a naturellement l’impression qu’à tout moment cette donnée sera disponible dans un coin de notre tête.
Malheureusement, il faut composer avec 2 choses :

  • Chaque nouvelle information pousse les précédentes vers la sortie.
  • Les informations se périment en mémoire avec le temps, et toujours plus vite qu’on ne le croit.

La conjonction de ces deux facteurs fait qu’il est difficile de se souvenir de plusieurs choses bénignes (qui ne sont pas d’une importance marquante) plus de quelques heures d’affilée.

Dans certaines disciplines, comme en ergonomie ou en présentation, on considère habituellement qu’il ne faut pas présenter plus de 7 éléments à la fois. C’est la limite au-delà de laquelle le cerveau humain ne peut pas tout retenir instantanément. Une liste comportant plus de 7 choix demandera plusieurs lectures successives avant qu’une personne puisse s’en faire une représentation mentale.
Sachant cela, combien de ces 7 éléments vont s’envoler de votre mémoire avant la fin de la journée ?

La solution pour remédier à ce problème, c’est de noter toutes les informations qu’on ne peut pas traiter dans la seconde, et qui nécessitent une action. Ce ne sont pas les moyens qui manquent : dans un cahier, un outil de gestion de projet, une buglist, une feuille de papier volante, un wiki, etc.
C’est simple, c’est facile. Pas d’excuse.

Forcedo

ForceDo est un web-logiciel qui sert uniquement à gérer des listes de choses à faire. C’est une todo-list, tout simplement. Mais ForceDo intègre des fonctionnalités qui vous aident à traiter les tâches, ou plus précisément qui vous forcent à les exécuter. D’où le nom du service.

La création d’un compte est très simple. Une adresse email et un mot de passe, ou plus simplement un identifiant OpenId, et vous pouvez commencer immédiatement à ajouter vos tâches.

ForceDo - écran principal

L’organisation des tâches

En colonne de droite, vous avez les listes. Cela correspond à ce que d’autres sites appelleraient des « catégories » ; ce sont des groupes de tâches. Il est aussi possible de voir à tout moment l’ensemble des tâches créées.

Par défaut, on voit les tâches qui sont ouvertes. Les tâches déjà terminées (mais pas encore effacées) sont disponibles sous un second onglet.

Les tâches s’affichent par ordre de priorité temporelle. C’est-à-dire que les tâche dont la deadline est la plus proche s’affichent en premier, même si leur priorité générale est moins importante que les tâches dont la deadline est plus lointaine.

Continuer la lecture de « Forcedo »

Retrospectiva

Retrospectiva est un web-logiciel de gestion de projets. Placé sous licence libre, il n’est pas possible de l’utiliser « directement » ; par contre, il est téléchargeable gratuitement et s’installe assez facilement sur n’importe quel système de type Unix (Linux, Mac OS X, BSD, …) pour peu que vous ayez un minimum de connaissances en administration de serveur.
Ce mode de fonctionnement est similaire à ce qu’on peut trouver du côté de Collabtive.

Fonctionnalités

Les fonctionnalités de Retrospectiva sont réparties en deux groupes : les fonctions de base, et celles qui sont apportées par des plug-ins.

Fonctions de base :

  • Gestion de tickets.
  • Revue de code.
  • Gestion de versions, avec deadlines et étapes d’avancement.

Fonctions additionnelles :

  • Wiki.
  • Blog.
  • Gestion de projet adaptée à la méthode Scrum.

On peut considérer que les fonctionnalités apportées par les plug-ins font parties intégrantes du logiciel. Parce que, de nos jours, un outil de gestion de projet qui ne contient même pas un wiki, c’est trop limité pour être intéressant.

Gestion de tickets

(image © retrospectiva.org)

Les tickets de Retrospectiva permettent de gérer aussi bien l’affectation de tâches (au sens classique du terme) que les relevés de bugs. C’est un des rares logiciels qui fournisse un système de gestion des tâches qui peut aussi convenir à la gestion des bugs, sans que l’ergonomie n’en souffre.

Continuer la lecture de « Retrospectiva »

Gantter

Gantter est un logiciel de gestion de projets très étrange. C’est un outil web, mais il offre les fonctionnalités basiques (les plus utiles) de Microsoft Project. Il ne faut pas y chercher la moindre capacité de travail collaboratif. En plus de cela, il n’y a pas besoin de se créer un compte pour l’utiliser : connectez-vous sur le site, et vous tombez immédiatement sur l’interface du logiciel. Quand vous avez terminé, vous sauvegardez et enregistrez en local un fichier que vous pourrez réimporter par la suite.

(image © Gantter.com)

Les fonctions sont celles qu’on attend :

  • Créer des tâches et gérer leur état d’avancement.
  • Créer des ressources (humaines et matérielles), les affecter aux tâches et gérer leurs calendriers.
  • Gérer les priorités des tâches et leurs dépendances les unes par rapport aux autres.
  • Définir des jalons et des deadlines.
  • Afficher le planning sous forme de diagramme de Gantt.

À cela s’ajoutent un import/export au format Microsoft Project, qui facilite la transition pour les équipes qui l’utilisent et qui souhaitent changer. Il faut noter que l’interface est traduite en français ; si votre navigateur est correctement configuré, tout s’affichera automatiquement dans votre langue.

Au premier abord, Gantter semble être un outil très sympatique. On ajoute des tâches, on les ordonne, on les trie, en gère leur avancement. Et l’affichage du Gantt est facilement compréhensible par tout le monde. Cela paraît être le complément idéal pour des outils qui n’offrent pas de visualisation graphique des tâches, comme Basecamp, Taskii ou Collabtive.

Mais après l’avoir utilisé un peu, on finit par y trouver plus d’inconvénients que d’avantages. Principalement, je lui reproche le manque d’édition « à la souris ». Chaque fois que l’on veut modifier une tâche, il faut cliquer dessus et éditer des valeurs au clavier. C’est affreux, alors qu’on voudrait pouvoir déplacer les tâches à la souris ; on voudrait changer leur durée ou leur ordre en un simple cliqué-déplacé. Ce serait facile et rapide ; mais là, on est sans cesse freiné.

Sans parler de quelques bugs mineurs. Je n’ai pas réussi à créer de résumé de tâches (pourtant indiqué dans la documentation)

En l’état actuel des choses, il est donc difficile d’utiliser Gantter pour un réel usage professionnel. Mais c’est un service encore assez jeune, qui a le potentiel pour s’améliorer rapidement. L’idée initiale est assez bien trouvée, reste à voir vers quoi elle va conduire

Edit du 26 mai

Après avoir échangé quelques emails avec Volodymyr Mazepa, le créateur de Gantter, il apparaît que la création de résumés de tâches est très simple. Il suffit d’indenter les sous-tâches. La tâche « parente » devient alors un résumé.

5pm

Dans le groupe des logiciels de gestion de projet qui font parler d’eux actuellement, et qui tentent de dépasser Basecamp, 5pm fait partie du groupe de tête et sa notoriété semble croître.

Interface principale

L’interface de 5pm est à la fois impressionnante et déroutante. Contrairement aux autres outils du même genre, elle fait un grand usage du Flash pour proposer un dynamisme et une réactivité améliorés.

La fenêtre principale est séparée en 2 parties :

  • À gauche, la liste des projets (et des tâches « autonomes », non attachées à un projet).
  • À droite, les informations concernant le projet sélectionné, ses activités (toutes les actions qui ont été effectuées sur le projet), et les fichiers qui y sont liés.

5pm - écran principal

L’affichage dans le panneau de gauche permet de voir rapidement les projets et leurs tâches, dans une vue arborescente à 2 niveaux facile à comprendre. On y voit par défaut l’état de progression des tâches et le nombre de jours qui reste pour les accomplir.

Continuer la lecture de « 5pm »

L’estimation du travail

Quand on veut planifier son travail ou celui de son équipe, il faut obligatoirement commencer par faire une estimation du temps nécessaire pour réaliser chacune des tâches qui sont listées. Et c’est souvent un casse-tête, car on ne sait jamais par quel bout s’y prendre.

Nous allons voir les raisons qui doivent vous pousser à réaliser des estimations, les réactions les plus récurrentes, et les pistes à suivre pour y arriver.

À noter : J’avais commencé à écrire ce texte au sein d’un article consacré à la planification et aux approches top-down et bottom-up. Mais un article présent dans le dernier numéro du magazine PHP Architect (très bon magazine canadien, en anglais) m’a convaincu d’y consacrer un billet à part entière. Le sujet est intéressant.

Les motivations

On peut voir plusieurs aspects qui conduisent à la nécessité d’estimer préalablement la durée d’une tâche ou d’un projet :

Continuer la lecture de « L’estimation du travail »