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éresssant.

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 :

• Savoir combien de temps il va durer. C'est absolument nécessaire pour réaliser un planning et pour organiser le travail d'une équipe. Si une tâche dépend d'une autre, il ne faut pas avoir à attendre que la première soit terminée pour savoir quand la seconde pourra commencer. À plus forte raison si cela implique le planning de plusieurs personnes.
• Savoir combien il va coûter. Cette information est, la plupart du temps, un corollaire du point précédent. En informatique, les coûts sont souvent directement induits par les durées (plus un projet dure longtemps, plus longtemps il faut payer le salaire du développeur qui travaille dessus). C'est une donnée vitale, car le client doit pouvoir choisir d'abandonner un développement si celui-ci n'est pas rentable. Sans estimation du coût, il est impossible de prendre ce genre de décision.
• Définir des jalons sur un projet. Une fois que l'on a estimé la durée des tâches qui composent un projet, il est possible de prévoir les étapes d'avancement , les moments auxquels on pourra vérifier que le rythme de progression est conforme à celui attendu. On pourra ainsi tenter d'anticiper les dérives. Si une tâche prend plus de temps à être réalisée que ce qui avait été estimé, on pourra prendre des mesures correctrices avant que le projet dans son ensemble soit en danger.
• Aider à la définition du projet. Très souvent, une estimation n'est pas une simple information à sens unique ; cela peut devenir un débat, voire une négociation au cours de laquelle le client va pouvoir revenir sur ce qu'il demande (modifier son besoin) en fonction de l'estimation qui a été faite. Dans certains cas, c'est aussi le moment où l'on s'apperçoit d'un décalage complet de perception entre les différents intervenants ; par exemple, le patron pense que la tâche est faisable en 4 heures, le développeur dit qu'il lui faudra 2 semaines. C'est le symptôme d'une mauvaise expression de besoin, ou d'une mauvaise interprétation qui en aurait été faite. Il faut alors prendre le temps d'apporter le même niveau d'information à tout le monde.
• Montrer l'exemple. C'est presque anecdotique par rapport aux précédents points, mais cela reste bien réel. Les "exécutants" sont souvent les premiers à se plaindre lorsque le travail n'a pas été réalisé en amont, que les spécifications n'ont pas été faites correctement. Mais quand ce n'est pas le cas, il faut montrer que l'on est capable de faire sa propre partie du boulot.

De manière générale, estimer les durées permet d'optimiser le travail de toute l'équipe.

Les réactions habituelles

Il existe globalement 2 types de personnes, chez ceux qui n'ont pas l'habitude de faire des estimations : les sous-dimensionneurs et les sur-dimensionneurs.

Les sous-dimensionneurs sont ceux qui se laissent embarquer par leur passion ou par la bonne image qu'ils ont d'eux ou de leur équipe.

• Dès qu'on leur parle d'une tâche technique, ils y voient un défi à relever, et pensent (sincèrement et inconsciemment) être capable d'y arriver rapidement. Même s'il s'agit d'une technique qu'ils ne maîtrisent pas...
• Ils peuvent n'avoir en tête que le dépassement de la difficulté technique. Ainsi, leurs estimations correspondront au temps nécessaire pour écrire un hack, un prototype qui validera un concept. Mais n'en attendez pas un logiciel fonctionnel et correctement testé.

Les sur-dimensionneurs sont ceux qui gonflent systématiquement leurs estimations, faussant complètement les coûts présentés et rendant inutile la gestion de planning.

• Certains se voient comme des pragmatiques qui ne veulent pas devenir des sous-dimensionneurs, mais qui vont trop loin dans l'excès inverse.
• D'autres ont un tel manque de confiance en eux ou dans leur équipe, que la moindre tâche dont l'environnement technique n'est pas entièrement maîtrisé est vue comme étant quasi-insurmontable et donc très longue à réussir.
• Certaines personnes cachent leur incapacité à estimer leur travail est doublant systématiquement le temps prévu par la moindre estimation préalable. Cela est d'autant plus improductif que ça fini par se voir, et leur avis n'est rapidement plus écouté.
• Enfin, il y a ceux qui n'ont pas vraiment envie de travailler sur une tâche et se débrouillent, sans s'en rendre compte, pour qu'elle soit retirée du planning en majorant sa durée au point de la rendre incongrue.

Certaines personnes résolvent la question très simplement en ne faisant jamais d'estimation. Mais ces gens se retrouvent rapidement à ne gérer que des tâches subalternes ; qui voudrait confier des projets critiques à une personne qui ne veut pas prendre la responsabilité de dire s'ils vont prendre 3 jours ou 3 mois ?

Quelques conseils

Il faut garde à l'esprit que l'estimation fait partie de votre travail. Vous devez être capable d'estimer le temps qu'il vous faudra pour réaliser un projet, et utiliser cette estimation pour suivre l'avancement de votre propre travail. C'est la base de la gestion de planning.

Il existe un cas très particulier, qui est celui de la résolution de problèmes. Quand on investigue sur un bug, il est souvent impossible d'estimer la durée par avance. Un bug qui semble mineur peut se retrouver à prendre une semaine entière à résoudre, alors qu'un problème plus important pourrait être résolu en un rien de temps.
Le plus souvent, le problème n'est pas vraiment d'estimer la durée d'un débuggage, mais plutôt celle d'un ensemble de débuggages. Il faut alors tenter d'estimer les choses au mieux en espérant que la moyenne reste correcte sur l'ensemble de la tâche. Une autre technique consiste à se planifier des plages de temps consacrées à cette activité, sans obligation de résultat. Par exemple, y consacrer tous les vendredis après-midi ; les bugs résolus pourront passer en production durant la semaine suivante, alors que ceux qui sont toujours en suspens seront traités le vendredi d'après.

Il existe un principe fondamental quand on traite des listes de tâches : toujours découper les trop grosses tâches en unités plus réduites

Ce principe est aussi valable quand on tente d'estimer la durée de réalisation des tâches. Cela permet d'estimer plus facilement, mais aussi de rendre les estimation plus fiables, et plus concrètes.
Si une tâche comprend de la recherche et du développement, séparer ces deux aspects permet de les estimer plus sûrement. Plus une tâche est précisément définie, mieux on saura l'évaluer.
En séparant les choses, on peut indiquer les tâches pour lesquelles existe un risque de dérive. Si la recherche est plus longue que prévu, cela n'implique pas un temps de développement différent ; ce n'est pas l'ensemble de l'évaluation qu'il faut reprendre.

Apprenez à écouter votre instinct. Il nous arrive souvent de nous dire « Ah, ce projet, il ne sera pas fini avant le mois prochain ! ». Mais sous la pression, on fait un planning prévisionnel qui tente de tout faire tenir en moins de 10 jours. Et concrètement, le projet se termine effectivement à la fin du mois suivant.
Si cela vous arrive fréquemment, il ne faut pas hésiter à faire valoir votre expérience à ce niveau. Prenez le temps de découper le projet en tâches raisonnables, et n'oubliez pas d'ajouter du temps de test et de débuggage, voire même du temps de "buffer" additionnel (si tous vos projets rencontrent systématiquement un changement de dernière minute, ou un problème technique imprévisible).
À l'inverse, si tous les plannings semblent réalistes mais n'arrivent jamais à être suivis, n'hésitez pas à découper finement les tâches et à en raccourcir la durée. La plupart des équipes travaillent mieux sous la pression qu'avec la bride sur le cou ; elles ont besoin que le planning joue un rôle de métronome, les forçant à aller de l'avant.