Product management et développement : quelles relations dans l'engagement ?

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 Product Manager / Product Owner : simple client ou co-acteur de la R&D?

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

Pourquoi s’engager ?

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.

Cela dit, le Développement n’a pas (toujours) tort d’être frileux

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.

S’engager ensemble

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.

Cette approche demande un peu de courage

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.