Avant de chercher la solution, achetez de l'information

Quand un projet technique bloque, la tentation est naturelle : chercher immédiatement une solution.

Combien de temps pour corriger le problème ?

Combien cela va coûter ?

Quel prestataire peut le faire ?

Quelle technologie faut-il utiliser ?

Le problème, c’est qu’à ce stade, ces questions arrivent parfois trop tôt.

Parce que le symptôme est connu, mais pas nécessairement sa cause.

Un prototype manque de fiabilité.

Une industrialisation prend du retard.

Une architecture ne tient plus la charge.

Une équipe n’arrive plus à avancer.

Un produit coûte trop cher à fabriquer.

Dans chacun de ces cas, on peut immédiatement chercher à corriger ce qui semble poser problème.

Ou commencer par acheter quelque chose de beaucoup moins spectaculaire : de l’information.

L’incertitude a un coût #

Lorsque la cause d’un problème est mal connue, quelqu’un doit porter cette incertitude.

En régie, c’est principalement le client : plus l’investigation dure, plus la facture augmente.

Au forfait, c’est le prestataire qui doit intégrer le risque de découvrir quelque chose qu’il n’avait pas prévu. Il le facture, le sous-estime ou finit par perdre de l’argent.

Dans les deux cas, vouloir contractualiser trop tôt la résolution d’un problème encore mal compris oblige quelqu’un à parier.

Il existe pourtant une troisième possibilité :

réduire d’abord l’incertitude.

Le diagnostic n’est pas encore la solution #

Quelques heures ou quelques jours passés à observer, mesurer, questionner l’architecture, confronter les hypothèses et comprendre les contraintes peuvent ne produire aucune fonctionnalité supplémentaire.

Vu de loin, rien n’a avancé.

Et pourtant, la nature économique et technique du projet peut avoir complètement changé.

On sait désormais ce qu’on cherche.

On sait quelles hypothèses ont été éliminées.

On sait quelles inconnues restent importantes.

On peut commencer à estimer un périmètre, un risque et une trajectoire.

Et parfois, on découvre surtout que le problème pour lequel on s’apprêtait à dépenser beaucoup d’argent n’était pas le bon.

En R&D, une expérience n’a pas besoin de réussir pour avoir de la valeur #

C’est quelque chose que nous acceptons assez naturellement en R&D.

Une expérience qui invalide une hypothèse peut être extrêmement utile.

Elle n’a pas produit la solution.

Elle a réduit l’espace des solutions possibles.

Autrement dit, elle a acheté de l’information.

Cette logique mérite peut-être d’être appliquée beaucoup plus largement aux projets techniques.

Avant d’engager beaucoup de temps, d’argent ou de ressources dans une solution, il peut être rationnel d’engager une petite partie de ces ressources pour comprendre le problème.

Toutes les incertitudes ne méritent pas d’être levées #

L’objectif n’est évidemment pas de tout savoir avant d’agir.

Ce serait simplement remplacer la précipitation par la paralysie.

La vraie question est plutôt :

Quelle information pourrait encore changer ma décision ?

Si une information ne change ni la solution envisagée, ni le risque accepté, ni l’investissement nécessaire, il n’est probablement pas utile de la chercher.

En revanche, si elle peut faire basculer la décision, son acquisition possède une valeur.

La première livraison peut donc être de la connaissance #

Nous avons tendance à mesurer l’avancement d’un projet à ce qui a été produit : code, prototype, électronique, mécanique, fonctionnalités.

Mais sur un problème complexe, la première chose utile à produire est parfois simplement une meilleure compréhension du système.

Pas pour retarder la décision.

Au contraire.

Pour pouvoir enfin en prendre une.