Jouer à la poule est une traduction littérale de l'américain "play chicken" et qui désigne ces défis dangereux dans lequel le perdant (la "poule mouillée") est celui qui se débine le premier.
L'exemple emblématique est le duel de deux voitures lancées à grande vitesse l'une en face de l'autre sur une ligne droite. Le premier conducteur qui engage la manœuvre d'évitement a perdu.
En matière de développement, jouer à la poule revient à taire ou à dissimuler un problème - des retards essentiellement - dans l'espoir qu'un autre développeur ou partie prenante du projet confesse son propre retard en premier.
Ce faisant, la responsabilité du retard incombe au premier qui le reconnaît et les autres bénéficient d'un délai supplémentaire pour tenter de rattraper leur propre retard, en passant inaperçus.
Jouer à la poule est un pari, un jeu pervers. Rien ne garantit qu'une poule se déclare et la dissimulation dans l'espoir d'un événement providentiel ne fait en général qu'empirer les choses.
Au lieu de chercher une solution pour limiter les effets indésirables en toute transparence avec le donneur d'ordres, le retard empire et dans la plupart des cas entraîne une conséquence irréversible qui aurait pu être évitée, ou tout du moins minimisée.
Aux chefs de projets et développeurs on ne peut que recommander l’adoption des meilleures pratiques telle que le management de projet par la chaîne critique, le suivi visuel des tâches ou projets à l’aide d’une fever chart, etc. et le respect d’une certaine éthique pour éviter de devoir jouer à la poule.
On ne peut néanmoins exclure “l’obligation” de jouer à la poule sous la pression hiérarchique, politique ou commerciale.
Côté clients et donneurs d’ordres c’est la vigilance qu’il convient d’adopter, mais la marge est faible entre une confiance éventuellement mal placée et la tentation du micro-management.
| < Précédent | Suivant > |
|---|
