Les R&D sont souvent frileuses à communiquer des délais de livraison. Le business en a besoin. Le Product Management se doit de jouer le médiateur entre deux mondes aux impératifs divergents.
Plusieurs posts sont parus sur un réseau professionnel dans lesquels des développeurs s’agaçaient que l’on exige d’eux des délais de livraison. Cette posture ne trahit en rien de la mauvaise volonté mais plutôt probablement un problème managérial voire de culture d’entreprise. Le fond du problème réside dans la peur de l’engagement. Et la peur de l’engagement repose essentiellement sur la peur de la sanction.
Le Product Management, en première ligne vis à vis des forces de vente internes et des clients se doit de gérer une réticence sur laquelle il n'a pas totalement la main (il n'est pas en charge de la résolution des problèmes culturels et managériaux internes) mais dont il peut atténuer l'expression.
Le PM/PO est souvent décrit comme la voix du client. A ce titre, il est en droit de se poser lui-même en client de la R&D. Cependant, cette conception de la relation PM/R&D est un peu réductrice : le PM/PO ne doit pas seulement porter les attentes du marché et des clients et les spécifier, il doit également le faire dans le contexte des ressources disponibles et donc prendre en compte les contraintes de production. Ce serait trop facile.
In fine, il est celui qui s’engage. Le jour ou « ça ne sort pas », il aura beau pointer du doigt les développeurs, il sera en première ligne pour devoir le justifier. Et il pourra difficilement s’en tirer en expliquant à ses clients et distributeurs que « c’est la faute au dev, Mesdames et Messieurs».
On pourra se renvoyer la patate chaude à l’infini, elle ne refroidira pas, et la détérioration des relations PM/R&D susbséquente ne permettra en rien de gagner en productivité. Elle aura plutôt un effet inverse.
Se poser en simple client est un peu plus confortable sur le moment mais pas plus efficace dans le temps. S'inscrire dans une démarche solidaire et raisonnable avec la R&D et plus efficace pour atteindre ses objectifs
A l’adresse des équipes de développement : s’engager n’est pas une mauvaise chose et peut même s’avérer indispensable. Un éditeur n’est pas un association philanthropique et le business dépend tout de même de ce qu’il y a à vendre. C’est pour ça qu’il y a des roadmaps et des délais.
Un certaine conception de l’agilité voudrait que le développement livre au fur et à mesure de ses réalisations, et qu’à un moment le Marketing fasse un arrêt sur image pour la mise sur le marché. Cela ne répond en rien aux attentes des clients qui, quand ils souscrivent une offre, veulent non seulement connaître son contenu existant mais aussi s sa trajectoire d’évolution cadencée dans le temps . On en revient aux fameuses roadmaps.
La visibilité est également un impératif interne :
– comment organiser un lancement marketing percutant autour d’une fonctionnalité majeur si on ne sait pas quand elle sort ?
– comment mettre le bon niveau de ressource de formation au bon moment dans l’incertitude ?
– comment rassurer et donner aux forces de vente l’envie de vendre s’ils ne sentent pas d’engagement du côté de la production ?
Bref, il n’est pas seulement question de prise de risque mais plus simplement d’alignement des planètes pour garantir une efficacité commerciale et opérationnelles maximale.
A l’adresse du commerce et des opérations : la R&D n’a pas toujours tort d’être frileuse. Voire a souvent de bonnes raisons.
La peur de s’engager provient en partie du fait que le niveau d’incertitude, lorsque l’on entame un développement, peut être grand et multifactoriel. Chaque nouveau développement n’ayant, pas essence, jamais été réalisé, c’est une équation à plus ou moins beaucoup d’inconnus qu’il va falloir résoudre et qui fait intervenir :
– les ressources disponibles et leur niveau de compétence
– les technologies utilisées et l’incertitude quant à leur apport réel
– la maîtrise du socle de développement
– la complexité de la demande
– la qualité des spécifications
– la testabilité
– etc
La prise de risque est donc bien réelle et doit être assumée collectivement. Il est contre-productif de la faire reposer sur les seules épaules de la R&D.
Construire une roadmap nécessite donc la compréhension des contraintes de chacun. Le rôle du PM/PO ne consiste pas seulement à émettre et réceptionner des demandes. Il est également le négociateur qui va faire l’interface entre le business et la R&D pour atteindre l’objectif attendu au meilleur coût et le co-réalisateur de la solution. Pour cela, il doit remonter à la source du problème et se montrer imaginatif dans sa résolution.
Il peut également s’appuyer sur les outils proposés par l’agilité, notamment en matière de traçabilité : traçabilité de l’estimation initiale du « coût » des développements, du réalisé, du nombre de points produits sur une période. A partir de là, il est possible de reconstituer une « bande passante » et un niveau d’incertitude.
En fonction des circonstances, ce niveau d’incertitude se situe généralement entre 20% et 100% (oui, 100%) du coût des développements annoncé par la R&D. Et généralement, on parle en plus…les réalisations moins coûteuses que prévu sont un rêve rarement exhaussé.
La roadmap à horizon proche (6 mois – 1 an) doit donc comporter deux typologies d’items :
– des « must have » à hauteur des efforts effectivement livrables en tenant compte de la marge d’incertitude, et qui seront les items qui feront l’objet d’un engagement de roadmap.
– de « nice to have » priorisés pour le cas où il resterait de la capacité de production. Ceux là sont gérés de manière plus confidentielle pour éviter la survente et les déceptions qui s’en suivent.
La mise en place de cette méthode ne coule pas de source : le PM va se trouver en première ligne pour défendre une roadmap moins rutilante que l’attendu. Il va devoir se justifier devant ses interlocuteurs internes et sa direction et risque de se voir reprocher un « excès » de réalisme.
Elle implique aussi que la R&D soit honnête dans ses estimations de charge puisqu’une décote d’incertitude est appliquée. Elle induit aussi que cette dernière, toutes précautions prises, fasse tout son possible pour délivrer ce qui ressemble désormais à un engagement raisonnable et collectif.
Plusieurs posts sont parus sur un réseau professionnel dans lesquels des développeurs s’agaçaient que l’on exige d’eux des délais de livraison. Cette posture ne trahit en rien de la mauvaise volonté mais plutôt probablement un problème managérial…
Je gère mes abonnements push
Les informations recueillies sont destinées à CCM Benchmark Group pour vous assurer l’envoi de votre newsletter.
Elles seront également utilisées sous réserve des options souscrites, par CCM Benchmark Group à des fins de ciblage publicitaire et prospection commerciale au sein du Groupe Le Figaro, ainsi qu’avec nos partenaires commerciaux.
Le traitement de votre email à des fins de publicité et de contenus personnalisés est réalisé lors de votre inscription sur ce formulaire. Toutefois, vous pouvez vous y opposer à tout moment
Plus généralement, vous bénéficiez d’un droit d’accès et de rectification de vos données personnelles, ainsi que celui d’en demander l’effacement dans les limites prévues par la loi.
Vous pouvez également à tout moment revoir vos options en matière de prospection commerciale et ciblage. En savoir plus sur notre politique de confidentialité ou notre politique Cookies.
