Il existe une loi (la loi de Parkinson) qui s’applique merveilleusement bien à l’informatique. Cette loi affirme que « peu importe le temps affecté à une tâche, la tâche prendra effectivement tout le temps alloté ». À cette première loi s’ajoute une autre observation qui ne fait jamais sourire les clients mais qui est bien connu des équipes de développement : les premiers 90% du code prennent 90% du temps. Les 10% restants prennent, eux aussi, 90% du temps.
De ces deux observations (intéressantes conceptuellement mais énervante dans la vraie vie), on peut tirer quelques conclusions :
- Il faut toujours avoir un chef de projet. Son rôle est de cadrer le développement et de le faire avancer au bon rythme. Charge à lui d’estimer au plus juste les temps de développement (en prenant en comptes les 2 spécificités listées plus haut) et à tenir bon face aux équipes trop optimistes en interne et aux exigences de rapidité du client de l’autre côté.
- Il faut prévoir large. Si un projet est estimé à X unités de temps, il est raisonnable de le doubler. Effrayant ? peut-être mais il vaut mieux partir tôt et avancer à un bon rythme plutôt que de courrir et de manquer la ligne d’arrivée (ça ressemble un peu à la fable du lièvre et de la tortue…). Si vous devez absolument disposer de l’outil à une date précise, il faut être très vigilant et prévoyant.
- La pression est positive dans une certaine mesure. Des délais trop serrés entraînent forcément des arbitrages et des choix non raisonnables (sur l’interface, sur les tests, sur les fonctionnalités, sur l’évolutivité et la maintenance) : autant de coûts cachés qui ressortiront plus tard.