D'après une étude, les managers croiraient à six grands mythes sur le développement produit. Il s'agit d'une série d'idées reçues visant à rendre le processus efficace, mais qui, en réalité, auraient plutôt l'effet inverse. Néanmoins, l'application de quelques règles simples peut apporter une amélioration notable.
Pour la plupart des managers du développement produit, la livraison des projets à temps et en respectant le budget est un combat de tous les instants. Les ressources ne sont jamais suffisantes et leurs supérieurs attendent une planification fiable et des résultats tangibles. C'est pourquoi ils mettent leurs équipes sous pression pour qu’elles soient encore plus économes, qu'elles élaborent des plannings encore plus détaillés et réduisent au minimum les écarts par rapport au planning. Cette approche peut sans doute donner des résultats avec les départements de production qui n'atteignent pas leurs objectifs, mais elle peut faire du tort aux efforts déployés pour le développement produit.
Les différences critiques entre le développement produit et la sous-évaluation d'une production sont à l'origine de plusieurs raisonnements erronés qui minent le planning, l’exécution et l'évaluation des projets de développement produit. Telle est la conclusion que tirent Stefan Thomke, professeur à la Harvard Business School, et Donald Reinertsen après une étude de la question pendant plus de 50 ans. Sur base de leur étude, ils ont dégagé six mythes qui affectent les projets de développement produit. Dans cet article, nous abordons les deux premiers mythes. Un prochain article de la série abordera les autres mythes.
Mythe 1 : l’utilisation intensive des ressources permet d’améliorer les performances
Il ressort de leur étude et de leur travail de consultant que la grande majorité des entreprises chargent entièrement leurs développeurs produit d’un projet de développement produit. Elles sont d’avis que les projets durent plus longtemps quand les intéressés ne consacrent pas la totalité de leur temps à leur projet.
Dans la pratique, cette logique ne tient pas : la vitesse de réalisation d’un projet, la qualité de la sortie diminuent inévitablement quand les dirigeants veulent que leurs développeurs s’y consacrent à 100% de leur temps. Un taux d’occupation élevé présente d'importants effets secondaires négatifs mal évalués par les managers pour trois raisons :
- L'effet d’un taux d'occupation élevé sur le délai de réalisation est fortement sous-évalué. De nombreux aspects du développement produit sont difficilement prévisibles alors que les entreprises ne connaissent bien que des processus répétitifs prévisibles comme les processus de production et administratifs. Les processus très variables tels que le développement produit se comportent de manière totalement différente. Avec de tels processus, le délai de réalisation va augmenter fortement dès que la charge de travail augmente : une augmentation de travail de 5 pour-cent peut provoquer un doublement du délai de réalisation. Cet effet de la théorie de la file d'attente est peu connu. Pire encore, la plupart des équipes de développement produit sont complètement débordées, ce qui fait que pour terminer les projets à temps demande parfois jusqu'à 50 pour-cent de ressources en plus que prévu.
- L'impact économique de longs délais de réalisation est systématiquement sous-évalué. Un taux d'occupation élevé des ressources conduites inévitablement à de longs délais de réalisation des projets. Les entreprises ont ainsi du mal à s'adapter aux besoins changeants du marché et à découvrir à temps les faiblesses de leur produit.
- Dans le développement produit, le volume de “work-in-process” est en grande partie invisible. Dans une usine, les files d'attente de production sont constituées d'objets physiques et quand le volume de work-in-process double, cela se voit. Ce n'est pas le cas avec le développement produit, car celui-ci est constitué en grande partie d’informations, comme la documentation de conception, des procédures d'essais et les résultats et les instructions pour fabriquer des prototypes. Si le volume de work-in-process double dans un processus d'ingénierie, on n'en voit pas les signes physiques. Comme les normes comptables imposent d'attribuer la valeur zéro au « stock R&D », les résultats financiers ne donnent aucune indication de graves anomalies dans le work-in-processs du développement produit.
Il est très difficile d'apporter une réponse à un problème qui n'est pas visible ni mesurable. Une des solutions est de prévoir une capacité tampon dans les processus qui présentent des variations importantes. Certaines entreprises d'avant-garde l'appliquent depuis déjà un certain temps : depuis des décennies, 3M n'occupe ses développeurs produit qu'à 85 pour-cent de leur capacité et Google est connu pour ses « 20 pour-cent de temps libre », ce qui permet aux ingénieurs de travailler un jour par semaine à ce qu'ils veulent, ce qui donne une capacité supplémentaire quand un projet est en retard. La mise en œuvre d'une telle solution demande néanmoins du courage : peu d’entreprises résistent à la tentation d'exploiter la moindre capacité disponible.
D'autres solutions sont également possibles :
- Changer les systèmes de contrôle de la direction, par exemple en récompensant le département d'essais pour ses résultats rapides (le temps mesuré entre la demande et l'achèvement de l’essai), plutôt que pour l'utilisation efficace des ressources.
- Augmenter la capacité de manière sélective : accorder des ressources supplémentaires aux départements où l’utilisation des ressources est supérieure à 75 pour-cent permet de réduire de manière significative les temps d'attente. Dans les environnements de test qui utilisent la modélisation et la simulation informatiques, l'augmentation de la capacité est souvent relativement bon marché, du fait qu'elle revient généralement à acheter des ordinateurs et des licences logicielles supplémentaires.
- Limiter le nombre de projets en cours : une certaine discipline pour appliquer une limite stricte au nombre de projets en cours se traduit souvent par une vision plus nette et des priorités plus claires.
- Rendre plus visible le volume de work-in-process : cela peut se faire par exemple à l'aide de tableaux de bord graphiques. Un tableau de bord doit présenter tout le travail actif et indiquer à quel stade en est chaque partie du projet. Ce tableau de bord doit occuper une place centrale dans le développement produit. Les équipes peuvent alors se réunir quotidiennement pour faire brièvement le point et coordonner les efforts et continuer de faire avancer le travail.
Mythe 2 : plus on ajoute d’options à un projet, plus il aura de la valeur pour les clients
Les équipes de développement produits ont tendance à croire que l'ajout d'options crée de la valeur pour les clients et que les supprimer en réduit la valeur. Cette approche explique pourquoi les produits de tous les jours, comme les ordinateurs, les automobiles et même les télécommandes, sont souvent si complexes. Et pourtant, les produits qui ont du succès brillent plutôt par leur élégante simplicité et leur facilité d'emploi. Néanmoins, cette théorie « less is more » demande davantage d'efforts sur deux plans du développement produit :
- Bien définir le problème à résoudre : la délimitation du problème à résoudre est une des parties les plus mésestimées du processus d'innovation à laquelle beaucoup d’entreprises consacrent trop peu de temps. Cette phase est néanmoins importante, car elle permet aux équipes de développement d'avoir une vision claire des objectifs et de rédiger les hypothèses qui devront être vérifiées et affinées par des expérimentations. Se pencher sur une question centrale, comme le fait de savoir où est la différence avec la concurrence, demande du temps, des recherches et de la réflexion pour parvenir à la bonne réponse.
- Masquer ou laisser tomber certaines choses : les développeurs ont souvent tendance à vouloir impressionner leurs collègues et la direction par des solutions techniques brillantes. Mais le plus souvent, les clients préfèrent un produit qui fonctionne sans problème à un produit sophistiqué et complexe. Du point de vue du client, les meilleures conceptions sont celles qui apportent une réponse à un problème de manière simple et elles doivent masquer les choses dont les développeurs sont fiers.
Déterminer les options à laisser tomber est au moins aussi important que rechercher les options à retenir. Malheureusement, dans leur tentative de faire preuve d'innovation, de nombreuses entreprises ajoutent toutes les fonctions possibles sans réellement prendre en compte les facteurs importants, comme la valeur pour le client ou la facilité d'emploi. Si elles décident quand même de supprimer une fonctionnalité prévue, c'est parce qu'elles doivent réduire les coûts, résorber un retard ou qu'il y a un problème quelque part.
Au lieu de cela, les managers devraient se demander dans quelle mesure la suppression des options prévues peuvent améliorer ou non le produit et laisser l'équipe se concentrer sur des éléments qui améliorent vraiment l'expérience d'utilisation pour le client.
