Blog

Utiliser correctement les estimations

Pour la plupart des projets, une estimation préalable est requise pour pouvoir chiffrer le coût et définir le délai du développement. Définissant la base contractuelle qui va permettre ou pas au client de s’engager dans le projet, il est impossible d’y échapper et ceci dans le respect du client.

Pour autant ces estimations vont souvent s’avérer pendant le développement une épée de Damoclès pour les développeurs. Ils vont subir une pression pour les respecter par leur management et indirectement par le client. Cette situation est intenable et beaucoup de développeurs crient leur peine. Pourtant peu de solutions sont proposées.

Cette situation douloureuse est encore fraîche dans la mémoire collective de l’équipe Occitech et cet article permet de donner notre retour, bien que nous n’ayons toujours pas fini d’avoir « des problèmes » avec nos estimations.

Plutôt que de remettre en cause l’acte d’estimation en soi qui n’est pas selon moi optionnel (« Mr le client, merci de nous faire un chèque en blanc, on vous rappellera quand on aura fini »), voici comment nous utilisons les estimations chez Occitech.

Pourquoi fait-on des estimations ?

Qu’on travaille au forfait ou en régie, le client doit avoir de la visibilité sur le coût de ses demandes. C’est le rapport valeur/coût qui va définir les priorités de ses demandes. Il n’est pas honnête d’empêcher le client d’avoir cette vision si on attend de lui qu’il prenne les bonnes décisions. Au contraire, en lui montrant qu’une petite fonctionnalité annexe coûte très cher, on favorisera son choix vers des développements plus pertinents et on l’incitera à tester le besoin plutôt que de faire directement le développement.

Au forfait, les estimations serviront à calculer le coût global du projet et son délai. Comme nous le verrons plus bas, l’erreur existe et il faut absolument prévoir une marge de manœuvre. C’est le prix à payer pour le client puisqu’en échange il aura un engagement ferme sur le prix. Il ne peut pas tout avoir !

La négociation commerciale pourra amener à dévaluer l’estimation, mais ce n’est pas aux développeurs d’en subir les conséquences. L’équipe commerciale doit prendre conscience qu’elle fait un sacrifice sur sa partie et que cela ne doit pas avoir d’impact sur le temps requis pour faire le travail.

C’est ceux qui font qui doivent estimer

Les pires estimations sont celles faites par les commerciaux (entendre non-techniques). Elles vont avoir tendance à aller dans le sens du client pour favoriser l’obtention du marché. Ou pire être complètement délirantes souvent dans le mauvais sens, en acceptant des demandes infaisables, ou faisables autrement plus simplement. C’est l’équipe de développement, ou au moins plusieurs développeurs qui doivent faire les estimations pour prétendre à un minimum de justesse. Évitez les estimations faites par un développeur seul qui ne sera pas au fait de tous les outils ou expériences disponibles par l’équipe. La discussion d’équipe affine fortement les estimations.

Une estimation requiert les bonnes informations préalables

On peut respecter la surprise voire l’indignation du client lorsque les estimations sont dépassées. Encore faut-il avoir eu toutes les informations pour pouvoir les faire. Si le client veut de la précision, il doit en apporter également en amont. Foncer tête baissée avec un cahier des charges de deux pages est une hérésie. Il faut exiger un document précis, fonctionnalité par fonctionnalité. Il ne faut pas accepter des phrases du type « fonctionnalités habituelles sur ce type d’application ». Il faut anticiper les effets de bord entre les différentes demandes. Vous pouvez demander au client d’utiliser le format « user stories » : En tant que [type utilisateur] je peux [action / constat] afin de [besoin]. La partie besoin est la plus dure à définir pour le client, mais la plus importante pour s’assurer de la valeur de la story et de la recherche de solutions pertinentes.

Si le client n’a pas pu fournir un tel document, il faut impérativement l’inciter à le concevoir. Soit par un prestataire spécialisé, soit par vous-même mais les dés seront un peu pipés si il y a appel d’offre derrière, pas très éthique. La définition du besoin est une phase primordiale qui demande du temps et constitue donc une prestation à part entière.

Quand faut-il estimer ?

Au forfait, on estime tout à la fois en amont et puis après, le temps nous (contre)dira….mais on reste prisonnier de cette toute première estimation tout le long du projet.

L’eXtreme Programming prône plusieurs niveaux d’estimation dans la vie du projet afin que tous (client et développeurs) aient toujours une vision pertinente sur le futur.
Au démarrage, une estimation globale permettra à tous d’avoir une vision sur le projet et isoler les principales difficultés.
L’estimation des fonctionnalités unitaires à l’approche de leur développement permettra d’affiner les lots fonctionnels et prendre en compte les développements déjà réalisés.
La mise à jour en cours de développement des estimations par fonctionnalité permettra de remonter au plus tôt les bonnes ou mauvaises surprises et ajuster le périmètre de l’itération en fonction.

Vous pourrez trouver que cela fait beaucoup d’estimations, certes ! Mais en revanche, personne ne pourra se plaindre de manquer de vision et de ne pas avoir été prévenu des éventuelles difficultés rencontrées. Cela améliore grandement le relationnel entre toutes les parties prenantes en offrant de la transparence. Enfin, comme nous le verrons plus bas, les estimations sont des phases de réflexion productives qui apportent de la valeur au projet. Ce n’est donc pas du temps perdu et il n’y a pas de raison de se limiter.

La granularité des estimations

Selon l’importance du projet (ou de l’évolution), chaque équipe adopte son unité d’estimation. Bien sûr, beaucoup utilisent les heures ou les jours. L’inconvénient est que cette mesure est très précise alors qu’on est en train d’estimer, donc avec une dose d’incertitude. Nous avons donc pris le parti d’utiliser des valeurs prédéfinies qui vont automatiquement placer la fonctionnalité dans des « moules » : 0,5h, 1h, 2h, 4h, 8h. Nous vous invitons à fixer une limite haute. Si l’estimation dépasse celle-ci, elle doit être découpée en petits morceaux.

D’autres équipes utilisent des valeurs plus abstraites comme des tailles de t-shirt : XS, S, M, L, XL, XXL. C’est encore mieux pour se soustraire à la valeur horaire, mais il faudra trouver un moyen pour rendre tangible ces valeurs au client.

planning poker

Séance de planning poker chez Occitech

Nous avons vu que l’estimation doit se faire à plusieurs. Elle doit rester courte, comme une réunion. Nous utilisons un moyen ludique pour les faire : le planning Poker. Chaque développeur a en main des cartes symbolisant les valeurs que vous aurez choisies et pour chaque fonctionnalité chaque développeur dévoile la valeur qu’il estime. Tant que tout le monde n’a pas posé la même valeur, on discute et on recommence.

Comme on sait qu’une estimation est plus souvent dépassée que trop large, il convient d’introduire dans l’estimation une marge de manœuvre et penser aux tests et déploiements.

L’estimation est un moment où l’équipe commence déjà à travailler : elle analyse, pense à des solutions, consulte de la documentation. C’est pourquoi nous facturons cette étape rapide bien que mobilisant plusieurs personnes mais qui fera ensuite gagner du temps à tous, donc de l’argent au client. De plus, cela permet aussi de calmer les ardeurs des clients qui font estimer 100 fonctionnalités pour n’en faire faire finalement que 10.

Une estimation n’est pas un engagement

Sémantiquement « estimation » parle de soi-même. La forfaitisation amène à transformer une estimation en engagement…absurde ? (Nous reviendrons à cette réflexion juste en dessous.) Mais si vous travaillez au forfait, blindez vos spécifications à mort, faites les signer (c’est stupide à dire mais pourtant…) et soyez intransigeant avec les dérives. Une fois de plus, le client vous demande un engagement, le périmètre doit être lui aussi ferme et définitif. Et cela se voit, certes dans les grandes agences, de revenir sur un chiffrage dans des cas exceptionnels. Si on explique au client clairement le problème et que celui-ci est intelligent et souhaite avoir une relation durable avec vous, vous pourrez négocier. Par contre les clients ayant acheté un prix seront déjà préparés à exploiter toutes vos faiblesses pour avoir le maximum de rendement.

Mais même en agilité, l’estimation garde une très forte importance pour le client qui doit tout de même pouvoir sélectionner les fonctionnalités chaque itération. Si il y a de trop forts dépassements à chaque fois, sa confiance dans la méthode et dans l’équipe va faiblir, ce serait dommage ! Une fois de plus, soyez réaliste : faites des estimations arrondies vers le haut. Le client sera ravi si finalement son itération coûte moins cher.

Il n’est toutefois pas aisé de faire de bonnes estimations, même avec toutes les informations requises. Il faudra donc faire évoluer continuellement les méthodes internes pour être toujours plus précis.

Notre solution : passage à l’agilité (ou du moins à la régie)

Nous avons fait du forfait pendant des années. Rédiger des spécifications n’a jamais été une passion et cela motive rarement le client qui lui n’y comprend souvent pas grand chose, seul le concret lui parle. Nous sommes donc souvent toujours partis avec des spécifications très légères ouvrant plein de brèches dans lesquelles les clients s’engouffrent toujours, sincèrement ou parfois avec des intentions calculées. Mais ce qui n’est pas précisé sera toujours vital pour lui et il pensait que c’était « du bon sens » ou « induit » à travers les spécifications. Notre dernier projet  au forfait vendu 374 H avec 10% de remise nous aura pris finalement plus de 1000 H…Une partie du dépassement est liée a de mauvaises estimations de notre part, mais la plus grosse partie aux dérives du forfait.

Nos clients sont généralement satisfaits de notre travail (excepté pour ce dernier projet au forfait qui s’est mal terminé vous vous en doutez) mais nous stagnions dans une situation financière inconfortable voire dangereuse, vu qu’au final nous vendions qu’un fragment des heures de l’équipe et générions une dette technique notable lorsque les dépassements devenaient trop lourds par le force des choses. C’était incroyable de se retrouver à corriger des bugs sur des fonctionnalités pour lesquelles nous n’avions même pas été payés !

De plus nous avons constaté que nous n’avons JAMAIS livré un produit correspondant aux spécifications initiales, si pauvres soient-elles. En fait par gentillesse nous acceptions des modifications non prévues, et en fait ces modifications étaient légitimes : le client en avait vraiment besoin car le besoin était mal compris ou avait évolué depuis le départ, à la rédaction des spécifications ! Techniquement ces modifications sont simples à faire, elles ne sont juste pas prévues donc pas payées (un quart d’heure, plus une demi-heure, plus cinq minutes, plus….(trois semaines après) ah mais on a fait 100 H de plus !). Soit on dit « non » à tout et la relation humaine devient lourde, soit on est gentil et on galère, soit on écoute Thibault Jouannic à Sudweb 2012 nous raconter comment il vend l’agilité et se dire « bah ouais ! C’est ça qu’il faut faire ! ». Notons tout de même que Pierre avant préalablement mis en place plusieurs outils nous permettant de l’envisager (il avait tout prévu…).

Finalement, puisque nos estimations sont inexactes car trop en amont des développements, que nos clients voudront de toutes façons modifier plusieurs points et reconnaissons-le c’est légitime et faisable, et que certains clients abusent volontairement des failles contractuelles, c’est tout le système « forfait » qui s’est écroulé pour nous.

Je reste persuadé que les forfaits rentables restent ceux dont le périmètre est inflexible donc avec une grosse phase de rédaction, et incluant une bonne marge de manœuvre. C’est donc possible quand on a vendu des compétences et non un prix. Quand bien même, les relations avec le client seront tendues et le livrable éloigné de l’attente du client de par ces satanées spécifications qui ne seront jamais parfaites puisque rédigées trop tôt et intangibles.

Avec l’agilité, nous avons trouvé un terrain contractuel dans lequel le mot « estimation » garde tout son sens et gagne en valeur, et ça change tout.

Pour les Toulousains…

Dans la continuité de l’article, inscrivez-vous à l’atelier XP Game le mardi 24 juin pour aller plus loin dans les estimations.

Vous voulez en savoir plus sur nos pratiques internes ? Echanger avec notre équipe ? Instaurer certaines pratiques dans votre équipe ? Contactez-nous.

4 Comments

  1. agaidot

    Merci de partager votre expérience sur ce sujet. J’en avais déjà discuté avec Pierre, ça me rassure de savoir que je ne suis pas le seul à exploser mes chiffrages ;) Je me suis reconnu dans beaucoup de ce qui est dit : moi aussi, je vais souvent (trop) vite sur la phase de spécifications parce que c’est du temps et donc de l’argent pour le client; moi aussi, je suis « gentil » et j’accepte les petites modifications en cours de projet, qui effectivement, mises bout à bout, peuvent faire enfler de manière importante le budget et le planning du projet. Effectivement, vendre de l’agilité est probablement la bonne option, encore faut-il y arriver : merci pour la vidéo !

  2. […] Les estimations sont incontournables dans le développement. Mais sont-elles correctement utilisées ?  […]

  3. Hadrien Lanneau

    Les clients sont vraiment tous pareil en fait :D

  4. […] Les estimations sont incontournables dans le développement. Mais sont-elles correctement utilisées ?  […]