Estimer le temps de travail

Impossible de passer à côté de cette question difficile, que l’on soit développeur, graphiste, chef de projet ou même commercial :

 

Dans combien de temps ce sera fini ?

Eh oui, le client a besoin de savoir quand le projet sera fini et combien ça va lui coûter, car le temps c’est de l’argent ! Le chef de projet a besoin de savoir combien de personnes il a besoin pour finir dans les temps et quelle est la durée des tâches afin de bien planifier le tout et faire un joli GANTT. Le développeur quant à lui doit pouvoir répondre à son chef dans combien de temps il pense pouvoir finir sa tâche. Une question qui revient donc qu’importe le poste que l’on occupe. Qu’importe la méthode de gestion de projet utilisée d’ailleurs, il va falloir à un moment estimer le temps de réalisation d’une tâche que ce soit pour SCRUM, XP ou linéaire.

Il n’est pas toujours aisé d’estimer son propre temps de travail surtout quand on a peu d’expérience. Je vais essayer de donner quelques voies pour arriver à réaliser ce tour de passe-passe que l’on vous réclamera je suis sûr durant toute votre vie.

Comme exemple concret, je vais prendre la réalisation d’un pot-au-feu. (Pourquoi je ne sais pas, je pense toujours à de la nourriture :))

 

1 – Découper plus encore et toujours

Quand on ne sait pas combien de temps va prendre un travail on le découpe en tâches nécessaires à sa réalisation. Il est plus facile d’estimer le temps d’épluchage des légumes que toute la préparation de notre pot-au-feu. Et quand on ne sait toujours pas, n’hésitez pas à découper encore plus vos tâches. Pour éplucher nos légumes, nous allons devoir éplucher nos pommes de terre. Cela peut vous paraître une perte de temps de tout découper et effectivement ça va vous prendre un peu plus longtemps pour estimer, mais cela vous rendra la vie plus facile et votre estimation plus juste, en étant sûr de ne rien oublier. Puis avec l’expérience, vous n’aurez plus besoin d’entrer autant dans les détails.

 

2 – Demander à ceux qui réaliseront la tâche

Delegate

Copyright Vlue | Dreamstime.com

La grosse erreur des chefs de projet est d’essayer d’estimer la durée de chaque tâche seule. Même en appliquant toutes les méthodes possibles et imaginables, il y a de fortes chances de se tromper, voir d’être totalement à côté de la plaque car vous êtes passé à côté d’un point qui vous a paru trivial ou carrément d’un truc infaisable. On ne fait pas cuire tous les légumes en même temps en 10 minutes ! Demander l’avis de votre équipe, faites-leur estimer les tâches qu’ils vont réaliser car après tout ce sont eux qui devront les produire dans le temps imparti. Faites ensuite valider votre planification. Cela permet d’être plus juste et d’éviter les situations critiques qui peuvent semer la discorde du genre : « Oh la vache le chef il me laisse 2 heures pour une tâche de 5 jours ! C’est un gros débile ou quoi ?! » ou même « Ahah je vais pouvoir me tourner les pouces, il m’a filé 2 jours pour modifier une ligne de code ».

 

3 – Ajuster selon la personne qui sera en charge de la tâche

Un stagiaire qui débute en PHP ne codera pas aussi vite qu’un développeur sénior justifiant de 15 ans de métier. De même qu’un grand chef va couper les carottes 10 fois plus vite que le commis qui vient d’arriver. Quelqu’un qui monte en compétence sur la technologie qui sera utilisée pour la tâche à effectuer va demander de 50 à 75% de temps en plus alors qu’un développeur confirmé va en demander 25% de moins. Mais ne voyez pas les montées en compétence comme une perte de temps ! Rappelez-vous que l’expert a dû aussi passer par là. Et plus vous laissez de temps au débutant pour apprendre à maîtriser les bonnes pratiques et plus il ira vite par la suite car il aura acquis les bons réflexes. Ne mettez donc pas de pression, l’avancement du projet ne s’en portera que mieux.

4 – Se baser sur les projets précédents

On apprend de ces erreurs et expériences. Un projet quel qu’il soit est composé de tâches que l’on a déjà éprouvées pour d’autres projets. On en maitrise alors le temps passé, mieux qu’une estimation on a ici une certitude. De plus, les personnes ayant effectuées ces tâches n’en seront pas à leur coup d’essai et parviendront donc plus facilement à réaliser celle-ci, voir reprendre celle déjà faite : gain de temps et d’efficacité. Vous m’aurez compris il est alors judicieux de garder une trace de tous les temps passés sur les tâches que nous sommes en train de faire afin de ne pas oublier. Le Time tracking ce n’est pas rigolo et ça prend du temps, mais c’est un investissement sur l’avenir qui permettra d’en économiser par la suite.

5 – Une marge de sécurité

Attention la marge de sécurité ne doit pas devenir un abus en soi ! Demandez explicitement aux personnes pour qui vous planifiez le projet de ne pas ajouter de marges mais d’être réalistes. Car 4h – 1 jour de marge sur chaque tâche va vite vous faire allonger votre projet de quelques mois. Soyez juste, prenez-vous une marge de risque globale sur le projet afin de pouvoir respirer car Shits happens !

Un pépin arrive toujours en cours de projet. Le développeur sénior qui se casse le petit doigt 10 jours avant la date limite, ça plombe un projet ! Imaginez globalement que vous allez avoir une mauvaise nouvelle par mois. Elles peuvent arriver à tout moment et surtout au moment où les tâches vont dépendre des 3-4 autres précédentes qui ont été faite en parallèle. Prenez un peu de marge à ce moment-là. Et si rien n’arrive, jackpot \o/. De même, il peut arriver que certaines tâches prennent du retard mais sans pour autant retarder le projet car réalisées en parallèles d’autres. Seul un schéma vous permettra de voir tout ça.

Pourquoi est-il important de ne pas prendre trop de marge ? Tout simplement car vous allez être plus cher et que votre client ne sera pas content. Simplement aussi car vos ressources seront mobilisées pendant ce temps-là et que potentiellement vous allez louper des contrats ou projets que vous auriez pu prendre.

 

6 – Un beau schéma

Maintenant que tout est compté, il ne vous reste plus qu’à dessiner ! Mettez en ordre vos tâches, lesquelles dépendent desquelles ? Quelles sont celles que l’on peut paralléliser ? Planter ensuite vos jalons et mettez tout ceci sur un diagramme en fonction du temps en veillant que personne n’a deux trucs à faire en même temps. Voilà, vous avez fait un beau GANTT. Personnellement j’utilise Redmine en ce moment pour ce faire, mais je ne pense pas que ce soit le plus facile d’utilisation.

Un visuel du planning est important car il permettra à tous de savoir où le projet en est (retard, avance), quels seront les points critiques (goulot d’étranglement des tâches, coups de bourre) et les dates clés (livraison du lot 1, recette).

Pour en savoir plus sur GANTT : http://www.commentcamarche.net/contents/projet/gantt.php3 ou http://fr.wikipedia.org/wiki/Diagramme_de_Gantt

Bonne planification à tous, j’espère vous avoir été utile à ne pas oublier les points importants.

Enregistrer

Vous aimerez aussi...

  • Très bonne explication d’une bonne méthode… un seul bémol : je pense qu’à utiliser une comparaison culinaire, la paella s’applique peut être mieux au Gantt. Tu ajoute les ingrédients dans un ordre, que tu peux modifier en fonction des contraintes et des ressources disponibles, mais tu en as certains de liés, tu ne peux mettre le riz avant l’eau…

    • Va donc pour la paëlla si tu préfères :). J’espère que tout le monde aura compris tout de même. Dans tous les cas, une méthode qui touche à la gestion de projet doit pouvoir s’appliquer à toutes les recettes :p

  • manu

    Super article mais pour moi GANTT a une seule utilité : c’est vachement beau en format A3 sur un mur !!

  • ash

    Une bonne solution aussi c’est de noté précisément les charges utilisées pour d’anciens projet, ça permet d’aller pioché par ci par là les infos nécessaire et de les aplliquer à l’estimation

    • Cela a pris du temps mais j’ai ajouté effectivement le fait qu’il est bon de profiter des expériences passées. Merci de votre commentaire constructif.

  • Pingback: Quelques astuces pour chef de projet qui sont toujours bonnes à savoir()