Estimer le temps juste

À la question du « combien de temps ça va prendre », la réponse est toujours délicate. C’est vrai dans le développement informatique comme dans le webmarketing.

Si c’est trop long, le client peut prendre peur pour le prix, avoir des doutes sur les compétences, ou ne pas trouver que ça rentre dans son délai.

Si c’est trop rapide, le client peut se demander si on a compris, se questionner sur notre emploi du temps (trop vite = pas d’autres projets en cours = pas bon), le prix peut paraître disproportionné.

estigator estimateur temps
L’outil Estigator permet de simuler le temps passé en prenant en compte l’incertitude lié à la durée de chaque tâche

Un peu de gestion de projet

  1. Demander au prospect ses dates butoirs. Il a peut-être d’autres impératifs de dates à connaître et sa demande s’intercale certainement dans un projet de plus grande ampleur. En connaissant ses contraintes de temps, il est possible de proposer une solution qui satisfera son agenda.
  2. Être très clair sur les contours de la mission. Qu’est-ce qui doit être fait ? Qui fait quoi ?
  3. Spécifier les livrables et mettre en place des livraisons cliquets. Une fois qu’une étape est franchie, on passe à la suivante sans retour en arrière possible (les modifications sont toujours possibles mais il faudra revoir le planning, le budget, le délai).
  4. Segmenter le travail pour les chantiers les plus conséquents pour avoir des livrables plus courts, garder le rythme et rester dans le projet.
  5. Bloquer le temps nécessaire.

Estimer au plus juste le temps nécessaire pour une prestation

À la question « combien de temps » la plupart des gens vont répondre leur meilleur délai. Celui si tout va bien. Or, tout ne va jamais bien. Il y a toujours des petits grains de sable pour gripper la machine. C’est particulièrement vrai lorsqu’on travaille sur des technos pas très fiables ou pas suffisamment matures, (typiquement le web), lorsqu’on travaille avec des profils jeunes (typiquement le web) et lorsqu’il faut faire intervenir des tiers.

À la question « combien de temps », pour une estimation à la louche, il faut faire x4 par rapport à l’estimation initiale. Ça fait vraiment beaucoup et ce n’est pas très sérieux comme approche ! Pour se protéger et livrer dans les délais, certains font x6 et se targuent de toujours livrer avant la date butoir. L’approche est certainement un peu extrême…

Pour les projets simples ou pour les projets de routine, l’expertise et l’expérience permettront d’estimer de façon beaucoup plus juste, et surtout de faire ressortir les tâches qui risquent de déborder. Ce qui m’emmène au point suivant.

Ça risque de déborder, mais de combien ?

Il y a donc le temps estimé théorique et la réalité sur laquelle on a pas vraiment prise. Le fameux grain de sable.

Exemple : la tâche X est estimée à 4h. Si tout va très bien, elle sera faite en 3h. Si va mal, elle prendra 10h. Quel timing faut-il annoncer ? Maintenant, s’il n’y a pas une tâche mais une vingtaine, avec des dépendances entre certaines d’entre elles, comment prendre en compte les variations sur chacune des tâches pour les répercuter sur le timing final ?

C’est là que les probabilités viennent à notre secours et les fameuses lois de distribution. Comment additionner des durées variables tout en restant plausible ? La solution est élégamment résolue avec 2 sites : getguesstimate.com (payant) et estigator.com (gratuit).

Expliquer le temps alloué

Prévoir le temps nécessaire n’est pas suffisant. Comment la notion de temps est-elle transmise au prospect ? Est-ce que l’on s’engage sur des dates de livraison (livraison le 3 septembre) ? Est-ce que l’on vend du temps (12 jours) ? Est-ce que l’on alloue du temps sur une période de donnée (intervention sur 3 mois) ?

Les mots ont leur importance :

  • Est-ce une prévision (comme une prévision météo qui donne une tendance mais qui va changer) ? Dans ce cas, la variable d’ajustement est la durée. L’offre doit bien stipuler le coût par jour mais aussi noter que la durée sera variable. Le prospect sait combien coûtera un jour de travail mais pas combien de jours seron nécessaires.
  • Est-ce une estimation ? Ici, la durée et le prix sont écrits noir sur blanc. Si l’estimation n’est pas bonne, tant pis pour le prestataire (s’il déborde) ou pour le client (si le prestataire travaille plus vite que prévu).

Dépendances à d’autres

Lorsque la prestation dépend d’éléments extérieurs, est-ce que c’est bien précisé ? Est-ce que le client a conscience que certaines tâches ne peuvent pas avancer si d’autres ne sont pas finalisées (le fameux chemin critique de Gantt) ? Évidemment oui. Mais ce qui se comprend bien de façon abstraite peut faire mal confronté à la réalité.

  • 1er exemple : Pour une mission, j’ai spécifié dans mon devis que le client devait libérer 1 jour par semaine pour travailler sur la rédaction de contenus pour son site. Analyse SEO faite. Plan de contenus fait. Rédaction pas faite. Projet qui patine parce que le client ne débloque pas le temps dont il a besoin.
  • 2ème exemple : Chez le client, le chef de projet est en congé les 2 dernières semaines de juin et les 2 premières de septembre. Chez le client, les 2 personnes chargés de faire des tests de recettes ne sont pas là en juillet. Le développeur principal chez l’agence web est en congé les 3 premières semaines d’août. quand est-ce que le projet sera livré ? Réponse dépitée : certainement pas avant octobre alors que dans un monde parfait, ça aurait dû être en juillet.
  • 3ème exemple : Sur une refonte ecommerce, j’ai un plan de redirection d’URLs conséquent à faire. J’ai pu récupérer les anciennes URLs à migrer mais pas les nouvelles. Parce que les nouvelles URLs ne sont pas encore connues. L’agence web a encore des choix techniques à faire et le nouveau catalogue produit n’est pas encore finalisé. On a bien des patterns d’URLs spécifiés, une arborescence à suivre et un cahier des charges SEO mais… j’attends de voir ce qui va réellement en sortir avant de finaliser les redirections.
  • 4ème exemple : il est nécessaire de prévoir 1 rendez-vous de travail préparatoire (3h) et 2 ateliers (3h chacun) pour un projet. Fastoche, ça fait 9h. 1 grosse journée. Sauf que le rendez-vous préparatoire ne peut se faire que les lundis et mardis en matinée pour des contraintes d’agenda et que les personnes nécessaires en ateliers n’ont pas beaucoup de créneaux libres en ce moment. Le RDV initial sera fera donc lundi dans 15 jours et les ateliers dans les 3 semaines qui suivent. Ou comment passer de 9h à plus d’un mois grâce à la magie des agendas…

Pour se rassurer, 90% des projets informatiques sont des échecs (besoin non satisfait, budget dépassé, timing non respecté). Ce n’est pas une raison pour s’en contenter mais ça doit quand même interroger sur nos méthodes et sur notre confiance à estimer un projet. Sur ce, bonnes estimations à venir et bons dépassements contrôlés dans vos futurs projets.

Illustration : capture d’écran d’Estigator

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.