Si on parlait autrement d’indicateurs de productivité dans le développement de produits numériques
En tant que consultante et coach agile, je suis souvent confrontée à une question récurrente : comment mesurer la productivité dans le développement de produits numériques ? Et si cette question est légitime, elle n’est pas pour autant facile à répondre : nous ne produisons pas toujours la même chose, à la chaine, comme dans une usine, donc mesurer seulement le nombre de chose faite par unité de temps n’aurait pas de sens. Pourtant à chaque fois que j’entends cette question, je trouve primordiale de participer à sa recherche de solution : en effet mettre une mesure impacte les comportements, car beaucoup voudront faire que cette mesure s’améliore. En changeant les comportements, vous ferez évoluer la culture d’entreprise, et l’objectif reste de la faire évoluer dans le bon sens, c’est-à-dire vers une culture qui permet de produire plus de valeur pour l’entreprise. À l’heure actuelle, les entreprises les plus performantes sont souvent identifiées comme des organisations génératives selon la classification de Westrum. Par conséquent, mon objectif lors de l’implémentation d’indicateurs est de promouvoir les comportements inhérents à ce type de culture.
Je ne suis certes pas la première à aborder ce sujet, néanmoins, il n’existe pas de cadre préétabli offrant une solution définitive. Si vous estimez que DORA ou SPACE répondent à la question, je vous invite néanmoins à poursuivre votre lecture. En effet, bien que je m’aligne sur leurs principes, mon objectif est de démontrer qu’ils ne sont pas pleinement suffisants et de proposer une manière de les compléter.
Il est important de souligner qu’il est nettement plus complexe d’estimer la productivité d’une organisation regroupant plus de 100 personnes que celle d’une équipe autonome responsable d’un produit unique mis en production. Cette complexité accrue découle de la nature de la solution mise en œuvre ainsi que de la structure de l’organisation.
La suite de cet article s’inscrit principalement dans le contexte d’organisations utilisant des frameworks (cadre de travail) d’agilité à grande échelle. Ainsi, lorsque je fais référence à une organisation, je fais allusion à une chaîne de valeur comprenant toutes les personnes et typologies de métiers nécessaires à la réalisation d’un produit.
Lorsqu’on aborde la productivité, la tentation est forte de se focaliser sur les livrables, dont la quantité et même la qualité sont facilement mesurables. Cependant, je suis convaincue que nous devons adopter une approche plus pragmatique, orientée vers les résultats. En effet, l’instauration d’indicateurs basés sur le nombre de livrables encourage la production en masse de ces derniers, souvent au détriment de la collaboration entre les différentes compétences et métiers, et par conséquent de la valeur apportée. Ceci peut conduire à la réalisation d’un produit qui ne “réussit” pas, voire qui ne se vend pas, s’il ne répond pas à toute la complexité inhérente (fonctionnalité, performance, sécurité, conformité, évolutivité, etc.). La complexité du produit et la structure de l’organisation qui le crée, auront inévitablement un impact sur cette productivité.
En fin de compte, lorsqu’on parle d’indicateurs, j’aime rappeler cette citation de Charles Goodhart dans le domaine de l’économie : « Lorsqu’une mesure devient une cible, elle cesse d’être une bonne mesure. »
A quoi ça sert ?
Avant de poursuivre, il est essentiel de comprendre “le pourquoi” de la mesure ! Si votre objectif est d’améliorer la valeur produite en identifiant des pistes d’amélioration grâce à une réflexion basée sur ces mesures, alors la lecture de cet article s’avère pertinente pour vous. En effet, le domaine que nous cherchons à mesurer est complexe, et ne PEUT pas être évalué par une mesure unique. C’est plutôt un ensemble de mesures qui nous permettra de réfléchir à ce que nous pourrions faire pour améliorer la situation :
Si vous constatez un nombre important de bugs, le problème peut évidemment provenir de la qualité du travail de vos développeurs, mais il pourrait aussi être lié à une volonté de livrer au plus tôt toutes les fonctionnalités définies, en négligeant la mise en place de tests automatiques pour vérifier les régressions. Il pourrait s’agir de la conjonction de cette première raison avec un taux de rotation du personnel important… Peut-être objecterez-vous que vous êtes contraints de sortir toutes ces fonctionnalités et dans un certain temps, sinon le client ne sera pas satisfait… Il ne sera certainement pas satisfait avec les bugs non plus. C’est le rôle du Product Manager de déterminer s’il a les moyens de livrer le produit avec la qualité exigée, et si ce n’est pas possible, alors peut-être ne faut-il pas investir sur cette ligne de produit. La transparence reste le maître mot pour prendre les bonnes décisions.
Comment notre Product Manager peut-il gérer la complexité des produits et parvenir à chiffrer le coût pour savoir s’il est économiquement viable de continuer dans cette voie ? En collaborant avec les différentes parties de la chaîne de production, et en disposant de métriques qui renseignent sur la manière dont on produit de la valeur. Cette collaboration est cruciale !
Élargir le scope de la mesure
Mon objectif n’est pas de réinventer la roue. Je reconnais la pertinence des DORA métriques, mais leur champ d’application est principalement axé sur le domaine DevOps, c’est-à-dire qu’elles se situent à l’interface entre le développement et la gestion de la production. Les DORA métriques ne mesurent pas l’adéquation du produit aux besoins de nos utilisateurs et ne fournissent pas d’informations sur la valeur ajoutée. Il est donc primordial d’élargir notre champ de vision et d’intégrer d’autres métriques pour obtenir une image globale de la productivité.
SPACE a étendu le spectre en introduisant des notions de culture, de satisfaction et de collaboration. Toutefois, SPACE n’aborde pas non plus cette dimension du « bon produit au bon moment avec un retour de valeur ». Et pourtant, en intégrant les sprint plannings, les PI plannings et les séances de raffinement (quelque soit le nom qu’on donne à ces réunions de synchronisation), on implique les acteurs du développement pour garantir la capacité de produire le bon produit au bon coût. Une part de la productivité des équipes est dédiée à cet aspect et doit continuer à l’être, comme le suggèrent le DevOps et les pratiques Agile.
Comme l’a souligné Peter Drucker, un théoricien du management : « Ce qui est mesuré s’améliore ». Si l’on se limite à mesurer la productivité du développement, on mesure alors principalement la capacité à produire un code de qualité sans erreurs, et moins à élaborer un produit qui répond aux besoins des utilisateurs. Cet indicateur encourage une culture où les domaines métiers et développement sont séparés, nous replongeant dans nos silos du cycle en V ou waterfall (cascade) et des livrables par phases.
C’est pourquoi j’aimerais vous persuader, si nécessaire, qu’il est indispensable dans nos entreprises de définir AUSSI des indicateurs de productivité centrés sur la réalisation du bon produit. J’aimerais également vous proposer une réflexion sur la définition de ces indicateurs dans votre contexte spécifique.
Dans ce premier article, je vais aborder le concept de productivité en termes de valeur du produit réalisé, et dans un second article, j’aborderai la qualité du travail effectué. Ce dernier sujet est déjà plus largement exploré et nous y retrouvons des indicateurs tels que les DORA metrics et SPACE (Satisfaction, Performance, Activity, Communication/Collaboration, Efficiency) ().
La valeur du produit réalisé
Je suis convaincue que dans la majorité des cas, la valeur apportée par un produit peut être résumée selon les axes suivants. (N’hésitez pas à suggérer d’autres axes en commentaires).
1 Qualité : Cela correspond à la durabilité, la fiabilité, la conception et la performance globale du produit. Un produit de haute qualité offre une valeur significative à l’utilisateur. Pour un produit numérique, on peut ajouter sa maintenabilité, son évolutivité, et tous les critères non fonctionnels (Nonfunctional requirements) tels que la performance, la sécurité…
2 Coût : Le prix d’un produit est souvent corrélé à sa valeur. Les produits à faible coût qui offrent des fonctionnalités et des avantages similaires à ceux de produits plus coûteux peuvent offrir une valeur supérieure. Il est donc nécessaire de mesurer le coût de création et/ou le coût de maintenance de notre produit.
3 Utilité : Elle représente le degré auquel un produit répond aux besoins ou résout les problèmes de l’utilisateur. Un produit qui répond efficacement à un besoin spécifique a une grande valeur.
4 Satisfaction des utilisateurs : La satisfaction des clients est une mesure importante de la valeur d’un produit. Si les clients sont satisfaits du produit, cela indique qu’il apporte une valeur significative. J’ajouterais ici les notions d’accessibilité. Cette satisfaction peut être due à l’innovation apportée ou pas, son nouveau design…
5 Impact environnemental : De plus en plus, la valeur d’un produit est également liée à son impact environnemental. Les produits durables et respectueux de l’environnement peuvent être considérés comme ayant une valeur supérieure.
Si la valeur d’un produit dépend de ces critères, la productivité d’une équipe indépendante, ou d’un programme entier, devrait mesurer sa capacité à réaliser cela (et pas seulement la production de lignes de code), favorisant ainsi la collaboration sur la valeur produite.
Le défi réside dans la manière de mesurer ces paramètres de valeur.
Les métriques de valeur
De mon point de vue, qui est partagé par de nombreux autres experts, et selon mes différentes lectures, notamment le livre “Accelerate” de Nicole Forsgren, PhD, Jez Humble et Gene Kim, pour mesurer la productivité, nous ne pouvons pas nous contenter d’un seul indicateur unique, car le sujet est beaucoup trop complexe. Dans cet article, je soutiens qu’il existe, à ce stade de ma réflexion, deux axes principaux, à savoir la qualité du travail accompli et la valeur du produit réalisé. Je m’efforce de les dissocier autant que possible, afin d’obtenir des indicateurs qui nous renseignent le plus précisément possible.
J’ai précédemment énuméré les domaines de mesure pour la partie “valeur réalisée”. La question suivante est de savoir quelles métriques nous mettons en place pour valoriser ces domaines.
Et bien, c’est à ce stade qu’il faudra probablement adapter en fonction de votre type de produit, qu’il s’agisse d’un produit web, d’un logiciel, d’un code embarqué, etc.
Cependant, certaines métriques me semblent génériques et je vous propose et je vous propose de les partager.
Qualité intrinsèque du produit :
Pour mesurer cet aspect, je suggère de se baser sur les NFR (Non-Functional Requirements), SLA (Service Level Agreement) … propres à votre type de produit. Je fais référence ici à la sécurité, à la performance… Tout cela dépend de votre produit et devrait probablement être décrit par vos architectes (pour les NFR) et vos responsables métiers (pour les SLA) dès la phase d’élaboration du besoin. Disposer de critères de performance dès le début fournira à vos équipes davantage d’informations pour prendre les bonnes décisions au cours du développement de la solution, augmentant ainsi leur efficacité.
Coût de développement du produit :
Nous priorisons le travail en fonction de la valeur apportée, au sens large, et inversement proportionnelle au temps nécessaire pour le développer. Ainsi, entre deux fonctionnalités apportant la même valeur, nous privilégions celle qui est la plus rapide à implémenter. Cela nous permet de maximiser la valeur produite. Mais, si nous ne vérifions jamais nos estimations de rapidité de développement ou de valeur du produit, comment pouvons-nous nous améliorer pour mieux prioriser et rendre ainsi l’ensemble de la chaîne de valeur plus efficace ?Dans certains cas, et probablement au début d’un produit, il peut être intéressant de suivre notre capacité à prévoir l’avenir, même si nous ne cherchons pas à être parfaits. L’objectif est plutôt de vérifier que nous ne nous trompons pas trop dans nos choix de sujet et leur priorisation !
Un autre paramètre de coût important à suivre est le coût de fonctionnement de nos solutions et son évolution au fil du temps. Suivre cet indicateur peut permettre d’éviter l’ajout d’une fonctionnalité qui augmenterait trop ce coût, en particulier dans des solutions embarquées. Cependant, une fois encore, cet indicateur peut avoir plus de sens dans certaines typologies de produits que dans d’autres.
Utilité du produit :
Le produit a été défini pour une cible potentielle. L’objectif de cette métrique est de vérifier que nos utilisateurs cibles utiliseront bien la fonctionnalité ; sinon, pourquoi la produire ? Une métrique envisageable est donc le taux d’utilisateurs réels par rapport au taux d’utilisateurs envisagés. Si le taux est bas, les raisons peuvent être diverses, mais cela indique qu’il est nécessaire d’agir pour améliorer la productivité de votre chaîne de valeur. Par exemple il se pourrait que nos utilisateurs ne connaissent pas la présence de cette fonctionnalité, ou qu’ils ne savent pas comment l’utiliser…
Satisfaction des utilisateurs
Je suggère dans un premier temps de suivre le taux de fonctionnalités avec un indicateur implémenté de valeur apportée par rapport à l’ensemble des nouvelles fonctionnalités: le taux de couverture d’indicateur de valeur. Par exemple si vous faites un nouveau moyen de paiement sur un site marchand, vous pourriez suivre l’évolution de l’utilisation de ce moyen de paiement par rapport aux autres. Vous avez alors une nouvelle fonctionnalité avec un indicateur. Si c’est votre 4eme fonctionnalité et la première avec un indicateur, votre taux est alors de 25%.
Vous remarquez que je propose ici de vérifier la pratique de définir ces indicateurs, à la place de vérifier sa justesse. Celle-ci serait beaucoup plus compliqué à suivre et surtout nous voulons encourager des pratiques d’amélioration et pouvoir les déceler. Comme l’a écrit Voltaire : “Le mieux est l’ennemi du bien”. A tout vouloir mesurer on risque d’avoir des tableaux de bord trop complexe, indéchiffrables, inmaintenable. Commençons donc simplement. La qualité de la mesure sera de la responsabilité des auteurs tout comme la pertinence des tests de régression est de la responsabilité de l’équipe de développement (au sens large c’est à dire qui contient les compétences de qualité produit comme dans une Scrum Team).
Je trouve que cet indicateur, le taux de couverture d’indicateur de valeur, est crucial surtout sur les produits avec plusieurs cibles possibles. Chacun des responsables de cible cherche en général à augmenter sa part de marché…, et pour prioriser son produit, essaie de le mettre en avant par rapport à d’autres fonctionnalités qu’il ne connaît pas. Parfois, cela entraîne des luttes de pouvoir, de notoriété au sein de l’entreprise pour prioriser ses sujets.
Cependant, il faut prioriser les sujets qui apporteront le plus de valeur avec le moins d’effort possible.
Il est donc nécessaire de vérifier en fin de cycle de création si la valeur estimée est au rendez-vous, et par conséquent si les priorités sont bien gérées.Dans ce contexte, il est donc crucial de mettre en place ces indicateurs de valeur.
Comment faire ? Seuls ceux qui définissent la nouvelle fonctionnalité peuvent le faire, donc probablement nos Product Managers, et y réfléchir dès l’exploration du besoin leur permettra certainement de cibler plus précisément le besoin. La mise en place de ces nouveaux indicateurs réduira certainement le nombre de fonctionnalités livrées (en raison du coût supplémentaire de production pour les définir et les implémenter), mais vous permettra de ne livrer que les plus utiles et de valider vos processus de priorisation, améliorant la productivité de la chaine de valeur en augmentant la valeur produite
Impact environnemental
Aujourd’hui beaucoup d’entreprises se posent la question de leur impact, et beaucoup de campagnes s’axent sur cette valeur. Dans ce cas il est utile de connaitre l’impact initial et ce qu’apportera chacune des nouvelles fonctionnalités. Cependant le sujet débute, est vaste et pourrait faire le sujet d’un article à lui seul. Sur ce sujet je vous renvoie pour le moment au livre blanc de Publicis Sapient, et notamment sur la « Good Tech ».
J’espère que cet article vous aura aidé à soulever des questions pertinentes qui vous permettront de définir des indicateurs capables d’induire les comportements appropriés. Le second volet de cet article, axé sur la qualité du travail réalisé et ayant un impact sur toute la durée de vie du produit, abordera les métriques DORA et SPACE et proposera certaines solutions.
La rédaction de cet article m’a permis de rationaliser les différents types d’indicateurs qu’il est crucial de suivre pour garantir le succès du produit que nous créons. Le chemin vers le succès ne sera certainement pas linéaire, mais je suis convaincue que ces indicateurs nous aideront à trouver la bonne voie. Et si ce n’est pas le cas, nous devrons conserver un esprit critique pour évaluer si la mesure représente bien l’indicateur défini.
