L’estimation de projets web est une partie de bataille navale – Partie 1

PARTIE 1

Si l’estimation de projet est une élaboration progressive au mieux, elle demeure surtout à la base une approximation.

On se surprend souvent qu’un projet dépasse les coûts et les délais: un nombre de 20% (et parfois davantage) n’est pas rare. La réaction facile du profane est de douter de la compétence des intervenants… Mais comment peut-on réellement être surpris? N’y a-t-il pas justement plus grande évidence que les synonymes d’estimation comprennent approximation et imprécision?

Je tenterai de vulgariser simplement l’estimation de projet web par une comparaison de ses principales difficultés et contraintes à celles d’un jeu de Battleship.

Préambule: dans la cour des grands

D’abord, soyons clairs: il sera ici question de longues parties: les grands projets. Ceux qui approchent ou dépassent les 100 torpilles (heures) au minimum et qui requièrent des navires (ou fonctionnalités) multiples. En effet, il est relativement simple de mener à bon port un projet qui ne compte que 15 heures de travaux et qui ne vise qu’une ou deux technologies. Le risque de dépassement est minime et les erreurs de planification négligeables: un ou deux coups dans l’eau n’entraînera pas l’échec de la partie.

Débuter la partie

Ainsi, au commencement de tout gros projet en général (mais particulièrement en Web du fait de ses processus abstraits et de ses livrables virtuels), la planification se compare à une partie de bataille navale:

  • Le cadre du projet est la planche de jeu
  • La besogne à abattre sont les navires
  • Les heures allouées sont les torpilles

D’aucuns penseront que contrairement au jeu, en estimation de projet nous ne nageons pas dans le noir absolu. Dans un projet, nous possédons habituellement dès le départ des détails sur les navires (fonctionnalités) et leurs positions possibles (place dans le cadre du projet). Cependant, un projet web demeure bel et bien comparable à une partie de bataille navale… et évidemment même plus complexe! En effet, pourriez-vous réellement énumérer des projets dont:

  • La quantité de fonctionnalités n’a pas changé
  • L’ampleur des fonctionnalités se s’est pas élargit
  • L’ordre de développement n’a pas été re-priorisé
  • Les contextes d’utilisation des fonctionnalités étaient tous connus et cités au départ
  • Les intervenants d’une part et d’autre sont toujours restés les mêmes
  • L’utilisation finale des fonctionnalité respectera toujours le besoin initial

…et ce, autant du côté client que fournisseur?

Précisions = contraintes

Pensez maintenant à un jeu de Battleship. Les navires changent-ils de place en cours de partie? Changent-ils d’axe, s’allongent-ils, y en a-t-il qui s’ajoutent? Et la planche de jeu quant à elle: des rangées s’ajoutent-elles en cours de partie?

Et pourtant… Les suppositions de la liste ci-haut sont toutes des règles à respecter dans une saine gestion de projet. L’exactitude d’une estimation et donc par extension, la réputation d’un estimateur, découle d’abord d’un cadre de projet détaillé et bien fixé.

Un projet web devrait respecter les règles de la bataille navale. Le bon sens le plus élémentaire le dicte: les navires ne doivent ni changer de position en cours de partie, ni de taille ou d’orientation. Sinon, la partie est vouée à une infernale déconfiture.

Lorsqu’il est question de gros budgets, pouvoir limiter et fixer l’ampleur et les délais est souvent la norme. Il faut cependant savoir que ces contraintes fixées d’avance dans certains projets (entre autre, ceux impliquant de nouvelles technologies) est une épée à deux tranchants: la contrainte bien qu’elle semble nous rassurer, pose un carcan autant chez le client que chez le fournisseur! Elle peut tout aussi bien sauver un projet… qu’en être une cause d’échec.

Flou en entré = flou en sortie

Mais encore faut-il avoir établi clairement les règles au départ: le nombre de cases sera de 100, les navires seront au nombre de 7, chacun ayant X longueur, etc. Ainsi, les inclusions et les exclusions au projet sont essentielles à préciser avant de pouvoir l’estimer. On confond trop souvent la marge d’erreur d’une estimation (et par extension, des développeurs) avec le laxisme initial de la signature du contrat!

Outre les inclusions et exclusions, l’indication claire des incertitudes et des hypothèses à prévoir au projet (rares sont ceux qui n’en contiennent pas!) peut très bien se faire sous forme de plage ou d’intervalles.

Approximation = latitude.

Même avec les meilleurs plans établis, les impondérables sont inévitables: techniques, légaux, logistiques, monétaires, humains… Les changements s’imposent autant du côté du client que du fournisseur de services. Ni l’un ni l’autre n’est nécessairement fautif: les projets évoluent, et avec eux, les besoins, les contraintes et les moyens. Plus un projet est grand, qu’il a d’intervenants et qu’il est longuement étalé dans le temps… plus il est difficile d’en estimer les paramètres finaux. Tout simplement parce qu’ils ne peuvent qu’être estimés, avec leur degré d’inconnu et d’évolution implicite.

On peut donc limiter le cadre (planche de jeu), le nombre de navires et leur taille… On ne pourra jamais réaliser deux fois un même grand projet exactement de la même façon. Chaque partie est une nouvelle partie. Le nombre de torpilles reste un nombre à estimer constamment.

Une estimation initiale de 254 heures qui s’arrêtera pile à 254 heures à la fin du projet n’est ni plus ni moins qu’un coup de chance, ou plus souvent qu’autrement, un habile rééquilibrage budgétaire masqué.

Faut-il alors s’abandonner à la fatalité? Non.

…lire la Partie 2 de cet article

 

Laissez un commentaire