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.