Comment estimer une tâche?

Il m’est arrivé à plusieurs reprises d’estimer des tâches (évolutions ou pas) ou projets (dans le cadre d’avant-ventes) et j’avoue que la première fois qu’on m’a demandé de faire une estimation j’étais perdu car je ne savais pas par où commencer !!!

Faire un chiffrage est une lourde responsabilité dans le sens où s’il n’est pas correct plusieurs conséquences peuvent en découler.

Nous notons par exemple, un dépassement conséquent de la charge allouée au développement d’une fonctionnalité en cas de sous chiffrage (Il s’agit du cas le plus fréquent).

Dans cet article, je partage avec vous mon approche (basée sur mon expérience professionnelle) du chiffrage d’une fonctionnalité et d’un projet.

L’objectif est que vous puissiez vous poser les bonnes questions lorsqu’on vous demande de faire un chiffrage et d’être plus précis sur vos estimations.

Pour ce faire, j’expliquerais combien il est important d’avoir une bonne connaissance du contexte, de bien décortiquer la fonctionnalité et de la borner, de bien choisir la personne dans l’équipe qui effectuera le chiffrage, de pouvoir se justifier et d’être cohérent, et pour finir quelles sont les conséquences d’un mauvais chiffrage.

  1. Prise de connaissance du contexte

La prise de connaissance du contexte est une étape très importante car si vous ne comprenez pas la fonctionnalité ou projet à chiffrer, votre chiffrage ne sera JAMAIS bon !

Dans le cadre d’une avant-vente, votre support est le cahier des charges et pour être franc avec vous, il faut le lire, relire autant de fois qu’il le faut. Il est impératif que vous vous imprégniez du contexte.

Vous devez le lire en profondeur et faire très attention aux termes ou fonctionnalités ambigus, l’idéal est de constituer un FQR (Fichier Questions Réponses) à partager avec le client (bien sûr tout dépend du contexte du projet. Vous n’aurez pas tout le temps la possibilité de mettre en place ce fichier, surtout en cas de chiffrage d’un appel d’offre).

Le FQR est un fichier (idéalement un fichier Excel) que vous partagez avec le client. Son but est de lister l’ensemble de vos interrogations / suggestions (fonctionnelles, techniques,…) sur le projet pour que le client puisse y apporter des réponses précises qui vous permettront de mieux comprendre les fonctionnalités du projet et de mieux les chiffrés.

Dans le cas où vous devez chiffrer une évolution, votre support sera les SFD (Spécifications Fonctionnelles Détaillées). Votre rôle sera de bien comprendre le contexte actuel et de vous projeter vers la nouvelle fonctionnalité. Il faudra donc évaluer toutes les répercussions fonctionnelles et techniques  qu’engendreront l’implémentation de l’évolution afin d’être plus précis dans votre chiffrage.

L’avantage d’avoir une bonne maitrise du contexte est que vous pourriez non seulement être force de propositions envers le client (si le besoin se présente) mais également dans le cas d’une évolution l’informer de la complexité de la faisabilité de celle-ci.

  1. Décortiquer et borner la fonctionnalité

Une fois que vous avez la maitrise du contexte, la seconde étape consiste à décortiquer la fonctionnalité.

La précision de votre chiffrage dépendra de la finesse du découpage de votre fonctionnalité.

Pour éviter des deltas très importants entre votre chiffrage et la charge qui sera consommée pour le développement de la fonctionnalité, il est très important de borner votre chiffrage.

Ce que je suis en train de vous dire est peut-être flou ???!!! J…prenons un cas concret.

Le client demande un chiffrage sur un formulaire d’inscription. Certes il s’agit d’une demande très basique mais voilà comment j’aborderais le sujet :

  • Décortiquer la fonctionnalité :
    • Un ensemble de zones de saisies (textes, mots de passes, email, date…) et des boutons de validations.
    • Service de validation et d’enregistrement des données saisies.
    • Gestions d’erreurs et d’annulation.
  • Borner la fonctionnalité :
    • Le formulaire d’inscription contient 5 champs de saisies maximum et 2 boutons (Valider et Annuler).
    • Faut – il prévoir des formatages complexes sur les champs de saisies ? Si oui, lesquels ? (Il faut les préciser pour être transparent avec le client).
    • Affichage des messages d’erreurs natif
    • Aucun style spécifique n’est attribué aux champs de saisies en cas d’erreur.
    • Le service d’enregistrement des données saisies ne contient aucun cryptage des données envoyées.

Comme vous pouvez le constater, une simple demande peut soulever plusieurs questionnements qui affineront votre chiffrage et vous permettra d’être plus précis.

  1. Vous êtes un expert technique mais pas toute l’équipe?

Il n’y a pas de profil X pour chiffrer une fonctionnalité. En effet, cela dépend de la composition et organisation de l’équipe de développement ou de l’entreprise.

Ce peut être soit le leader technique de l’équipe, l’expert technique, le chef de projet technique, le développeur le plus expérimenté de l’équipe ou celui qui a une bonne maitrise de l’application que ce soit sur l’aspect fonctionnel et technique.

Le cas le plus fréquent en entreprise est que, ce sont les personnes les plus fortes techniquement ou expérimentées qui chiffrent. Malheureusement dans la majorité des cas, ces personnes oublient que dans l’équipe il y a les bons développeurs comme les moins bons.

C’est pour cela que la personne chargée de chiffrer doit prendre en compte que ce ne sera peut-être pas elle qui développera la fonctionnalité. Et que surtout elle sera probablement développée par un développeur junior ou qui n’a pas une maitrise de l’environnement technique voir même aucune connaissance du projet.

  1. Justification et cohérence du chiffrage.

Une fois que la fonctionnalité est chiffrée, votre chiffrage devra être justifié auprès du client ou de votre supérieur, surtout s’il s’avère que la charge allouée pour le développement de celle-ci est importante.

Si c’est le cas, il est préférable de se servir du découpage de la fonctionnalité pour mieux argumenter votre estimation et de mieux la borner (en diminuant les règles de gestions) si le client / votre supérieur pense que la charge est toujours importante.

S’il s’avère que vous devez chiffrer plusieurs fonctionnalités, faites en sorte que le chiffrage soit cohérent (par exemple avoir le même chiffrage pour tous les boutons « Annuler » qui répondent aux mêmes règles de gestions) ou de ne pas sur chiffrer car  le client comme votre supérieur s’en rendra compte.

  1. Conséquences d’un mauvais chiffrage.

Chiffrer une fonctionnalité n’est pas évident dans le sens où son prix de facturation dépendra de son chiffrage.

Un mauvais chiffrage a beaucoup de conséquences sur un projet, à savoir :

  • Perte de rentabilité sur le projet (en cas de sous chiffrage).
  • Chez certains développeurs des coups de pressions qui auraient pu être évités si le chiffrage était correct.
  • Des livraisons incomplètes à la fin de chaque sprint.

La liste des conséquences est certainement plus longue donc pour éviter de mal chiffrer, il faut toujours avoir une certaine hauteur et recul lors du découpage d’une fonctionnalité et de surtout bien la borner.

En conclusion, pour être efficace en chiffrage, il faut retenir les points suivants :

  • Bien comprendre le contexte et la fonctionnalité à chiffrer.
  • Découper et borner minutieusement la fonctionnalité pour être sûr que le chiffrage réponde aux besoins du client voir même aux éventuels changements.
  • Avoir une visibilité sur le degré de complexité technique pour son développement.
  • Prévoir une marge d’imprévus sur votre chiffrage car n’oubliez pas que celui qui chiffre n’est pas forcément celui qui développe.