3 méthodes redoutables pour définir le temps de réalisation d’une tâche

Une des grandes problématiques dans la gestion de projet est de définir le temps que prendra chaque tâche lors de sa réalisation. Cette estimation du temps est primordiale pour pouvoir planifier les délais de réalisation et définir les jalons du projet.

 

1. Bannir le concept de rétro-planning

Le principe du rétro-planning est très simple : nous définissons une date de fin du projet et en fonction de cette date de fin, nous nous arrangeons pour faire tenir toute la charge de travail. Quand nous procédons ainsi, nous classons les tâches par ordre chronologique et nous évaluons grosso modo les échéances de réalisation de chaque tâche.
C’est la pire des façons, car en faisant ainsi vous êtes sur que l’évaluation du temps sera erronée !

Une idée pour corriger cela consiste à définir l’ensemble des tâches d’un projet et de les noter séparément sur un post-it. Ensuite, il s’agira de les prendre au hasard une par une et de demander le temps de réalisation aux personnes qui devront les réaliser.

En procédant ainsi, nous supprimons tout biais induit par un respect de date ce qui fait que chaque personne estimera au plus juste le temps de réalisation de la tâche. Ensuite, il suffira de remettre les tâches dans le bon ordre pour définir de bout en bout le temps que prendra le projet… Et chose importante : se cantonner à ce timing sans chercher à le réduire !

 

2. Comme Goldratt, soyez un dictateur des coupes franches

Dans son excellent ouvrage « Critical Chain » sur la TOC (Théorie des contraintes) appliquée à la gestion de projet, Goldratt dévoile les biais cognitifs qui nous incitent à nous donner un peu de souplesse en prévoyant plus large… Par exemple, un développeur qui se rappellera d’une récente déconvenue sur un projet aura tendance à demander plus de temps la prochaine fois pour réaliser la même tâche. Le problème c’est qu’en nous gardant une marge de manœuvre comme celle-ci nous perdons énormément de temps !

Pourquoi ? Simplement parce que la loi de Parkinson nous indique que le temps pris à la réalisation d’une tâche varie en fonction du temps accordé pour la réaliser. Nous pouvons donc avoir quelqu’un qui en toute bonne foi annonce qu’il lui faudra 5 jours pour réaliser la tâche, pensant que si 3 jours suffisent il passera les 2 autres à avancer sur la suite. Mais finalement quand la tâche se présentera avec 5 jours pour la réaliser, la loi de Parkinson faisant il y passera bel et bien 5 jours.

Voilà comment insidieusement les tâches prennent toujours plus de temps qu’elles ne devraient !

Pour répondre à cette problématique, Goldratt propose de diviser ce temps alloué par deux. Par exemple si quelqu’un annonce 5 jours pour réaliser une tâche, nous retiendrons que celle-ci devra être réaliser en 2 jours 1/2. Mais la grande subtilité consiste à garder les 2,5 jours comme stock tampon de temps. Ainsi, nous aurons l’ensemble des tâches dont le temps de réalisation sera divisé par deux et il nous restera un temps quasiment équivalent à utiliser au cas où !

Si vous souhaitez en savoir davantage sur cette méthode je vous invite à consulter le site de Philip Marris : http://www.chaine-critique.com/fr/La-methode-en-action-4.html

 

3. Ou alors vous pouvez jouer au Planning Poker ! ;-P

Non non, ça n’est pas une plaisanterie ! Le planning poker est une méthode redoutable pour définir le temps de réalisation d’une tâche. Cette méthode est utilisée dans les projets Scrum de développement de logiciel pour définir le niveau de complexité d’une fonctionnalité, le niveau de complexité étant souvent corrélé du temps à accorder à son développement.

1. Chaque participant reçoit l’ensemble de carte que vous pouvez voir ci-dessus.
2. Chaque fonctionnalité est passée en revue pour être décrite une par une dans le détail. C’est également l’occasion pour l’équipe pour échanger dessus.
3. Chaque participant estime dans sa tête le niveau de complexité de la fonctionnalité puis choisit la carte pour la poser face vers le bas sur la table.
4. Lorsque tous les participants ont fait leur estimation, les cartes sont retournées en même temps de façon à ce que tout le monde puisse les voir.
5. En cas d’écart entre les estimations fournies, les équipiers échangent ensemble pour comprendre leurs écarts d’estimation (ainsi, l’équipe se met à niveau sur la compréhension du besoin à couvrir par la fonctionnalité).
6. Après échange, le processus d’estimation redémarre jusqu’à l’obtention de l’unanimité sur le nombre de points à affecter à la fonctionnalité.

A noter qu’il n’y a pas de notion de temps dans les projets scrums. Lors de la fin de chaque itération du projet, une capacité de nombre de points qu’il est possible de développer est définie en fonction de ce qui aura été réalisé lors de la précédente itération. Exception faite pour la première itération du projet ou un équivalent temps idéal (temps de développement sans dérangement) / nombre de point est définis.

 

Et vous ? Comment arrivez-vous à définir la charge et le temps des tâches à réaliser sur un projet pour être certain que les échéances de livraison seront respectées ? 😉