Cet article a pour objectif d’expliquer que chez Imagile nous ne sommes pas systématiquement opposés à estimer le temps que prendrait le développement d’une fonctionnalité. Que nous y voyons même parfois un moyen de nouer une véritable relation de collaboration avec nos clients. Même si la réponse peut être « c’est trop compliqué en l’état à estimer ». Qui plus est, le manifeste agile proclamant plus le respect de principes, l’agilité peut s’appliquer de multiples façons, nous ne prétendons donc pas que notre manière d’oeuvrer est la meilleure.
Le développement des outils informatiques fait partie intégrante de la stratégie de développement d’une entreprise. Au même titre que le téléphone ou l’email, un site Internet et une application web métier sont des outils de production, d’acquisition client et de fidélisation clientèle. Pour entretenir une relation durable avec chacun de nos clients, nous avons fait le choix d’une démarche centrée à la fois sur leurs utilisateurs et sur leur business.
C’est pourquoi les échanges réguliers avec le client se fondent sur des éléments tangibles, des chiffres permettant de vérifier l’évolution de marqueurs-clefs préalablement définis. Pour constater une progression, on ne peut en effet faire l’économie de mesurer régulièrement.
Les développements sont ainsi pensés pour constituer de véritables outils de travail et de puissants leviers commerciaux ; il s’agit dans certains cas de réels investissements, tant sur le plan humain (formation, recrutement, etc.) que sur le plan financier. Et c’est pourquoi les différentes évolutions de ces outils numériques font souvent l’objet d’arbitrage. Juger de la pertinence d’une évolution dépend de nombreux facteurs, tous soumis à une appréciation (au sens donner un prix) :
- Tout d’abord, estimer le degré d’utilité d’une fonctionnalité. Cette évaluation de l’utilité peut paraître simple au premier abord. Mais on peut déjà s’interroger sur la légitimité de ceux qui jugent la pertinence des fonctionnalités : s’agit-il de l’équipe dirigeante au sein de la société cliente ? Des utilisateurs eux-mêmes au quotidien (les end-users) ? Le bien-fondé des fonctionnalités et du degré d’importance a-t-elle fait l’objet de sondages auprès de potentiels futurs utilisateurs ? On le constate tous les jours dans nos projets, le degré d’utilité se fonde sur une estimation plus ou moins fiable.
- Ensuite, et c’est certainement cet aspect qui laisse perplexe souvent le développeur : estimer le temps de développement que va prendre une fonctionnalité. Ceux qui établissent des contrats commerciaux se basant sur un cahier des charges strict cherchent à définir des algorithmes sûrs pour ne pas se tromper d’estimation (et donc en être de sa poche). D’autres estiment qu’il faut se passer purement et simplement des estimations. Il y a certainement un juste milieu. Car les estimations sont loin d’être des outils totalement inutiles. Si tant est que l’on sache bien les employer.
Souvent, le client arrive avec un projet mais également avec un planning. Quelques fois, la date que le client a en tête n’est pas vraiment justifiée. Parfois, la date de livraison souhaitée est sinon judicieuse du moins impérative (arrêt du service jusqu’à présent utilisé, date de salon, recrutement, etc.). Et c’est pourquoi il est capital que l’équipe de développement soit en mesure d’estimer ce qu’elle pourra livrer dans le cadre d’une première version, compte tenu du temps imparti. Evidemment, on s’attachera à ce que la priorisation des tâches permette de mettre en ligne une version opérationnelle de l’outil même si tout ce qui était prévu n’est finalement pas réalisé. Cela a pour le moins le mérite de rassurer le client.
Et c’est bien-sûr ici que l’on attend l’expertise d’un professionnel du numérique. Car nous nous situons bien dans une logique de partenariat. L’entrepreneur, lui, pilote sa propre entreprise, gère déjà des équipes, des budgets, alloue des sommes appropriées à différents projets pour atteindre des objectifs fixés. S’il fait appel à une entreprise spécialisée dans le développement d’outils numériques, c’est qu’il a besoin d’être accompagné : pour avoir une meilleure connaissance des périmètres de faisabilité, des délais de réalisation et des solutions envisageables…
En bonne intelligence, le client doit pouvoir entendre que ce qu’il envisage est considérable et qu’il faut prévoir au moins 120, 200, 300 jours homme. C’est ce genre de conseil qui lui permet de réviser ses ambitions ou d’adapter ses budgets. A contrario, il se trouve également qu’après avoir expliqué son besoin, le client peut être agréablement surpris d’entendre que l’on peut déployer une première solution dans un temps moindre que ce qu’il envisageait.
Qui peut mieux estimer sinon quelqu’un qui possède une meilleure expertise ? Dans le contexte métier, c’est bien souvent le client qui sait. Mais lorsqu’il s’agit de considération informatique, c’est bien à l’informaticien de se mouiller.
Certains voudraient s’affranchir de ce dur exercice qu’est estimer ; et on le comprend, ce n’est jamais facile pour un développeur – dont le métier repose sur une grande rationalité – de se perdre dans des conjectures, des suppositions. Bien souvent, un développeur a peur de s’avancer sur une durée de réalisation car il s’est auparavant heurté à des imprévus, il n’avait pas pensé à tel aspect des choses, n’avait pas eu accès à l’ensemble des informations nécessaires, etc. La peur de décevoir et surtout qu’on lui tienne rigueur de son estimation le conduit soit à sur-estimer soit à ne pas vouloir estimer. Cependant, dans l’exercice global d’un accompagnement numérique, ne pas être en mesure d’estimer c’est botter en touche.
Pourquoi est-il si important de faire attention au temps ? Eh bien parce qu’on peut faire n’importe quoi aussi en « mode agile ». Auparavant, dans les spécifications fonctionnelles des cahiers des charges des projets gérés en cycle en V, on parlait de jalons. Et c’était déjà l’esprit de découper pour livrer par tranche et ainsi pouvoir bénéficier des premiers travaux sans attendre une recette finale. Le principal souci dans ce type de contrat est la non-flexibilité et le manque de visibilité sur l’utilité fonctionnelle.
À contrario, nous avons pu constater que des projets gérés « à la mode agile » pouvaient également ne plus en finir. Sans échanges réguliers avec le client dans lesquels sont discutés le temps passé, le travail effectué, le temps restant et la priorisation du travail restant, l’équipe de développement peut dépiler des fonctionnalités les unes après les autres sans se préoccuper de livrer un produit utilisable par le client.
LOI DE HOFSTADTER
« Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. »
Douglas Hofstadter
Les estimations ne sont pas « fausses ». Ce sont juste des estimations. C’est la compréhension que le client a d’une estimation qu’il faut changer, non supprimer les estimations. Estimer est le fruit d’une expérience. Nos interlocuteurs qui font appel à nos services pensent que nous sommes en mesure de mieux estimer qu’eux le temps que prendrait le développement numérique de tel ou tel besoin : et ils ont raison !
Estimer n’est pas prédire certes, mais ne pas estimer c’est s’interdire de prévoir. Si estimer ce n’est évidemment pas tout connaître, tout circonscrire et n’omettre aucune zone d’ombre, ne pas estimer c’est alors moins connaître encore. Car l’estimation est un moyen supplémentaire pour décider.
Cela dit, nous pensons que les estimations ne peuvent pas être précises. Nous utilisons pour quelques-uns de nos clients une matrice à double entrée :
- l’utilité de la tâche
- l’estimation du temps de développement
On peut aussi se tromper dans une estimation. Il s’agit alors d’en comprendre la raison et expliquer au client pourquoi cela a pris plus (ou moins !) de temps.
La confiance qui s’installe entre le client et le prestataire est le fruit d’une relation sincère et d’une transparence sur tous les aspects du projet commun.
Le client est capable de comprendre qu’une estimation n’est pas fiable à 100%, voire que le temps passé finalement ne correspond pas à l’estimation initiale. Il sait entendre les explications et admettre que les éléments inconnus au départ ont eu un grand effet sur le temps de réalisation.
Qui plus est, la réponse qui consiste à dire au client « c’est trop compliqué pour estimer » doit normalement conduire à deux actions :
– simplifier, découper en parties, envisager un périmètre plus restreint,
– demander au client de quoi il a vraiment besoin pour commencer à construire une solution efficace.
Cette confiance naît d’un rapprochement, de la création d’un langage commun : il faut bien-sûr éduquer le client au web mais surtout mettre le développeur dans une position d’écoute et d’imprégnation, d’implication dans le business du client.