Métiers versus utilisateurs

 

La question est provoquante. Là normalement une grimace doit se lire sur votre visage et vous pensez très fort « mais non quelle horreur ! ». L’agilité ne se nomme-t-elle pas ainsi (« agile ») pour s’adapter et répondre rapidement aux besoins des Métiers ? En fait, plutôt ceux des utilisateurs.

Lean, UX comme agile cherchent à multiplier les feedbacks loops, les retours d’utilisations réelles pour informer de plus en plus précisément les équipes IT sur ce qu’il est utile ou pertinent de développer. Ou de laisser tomber. Scrum parle bien de « User story », d’histoire utilisateur, c’est-à-dire de quelqu’un qui interagit vraiment avec le système, qui utilise réellement le produit. UX signifie bien « eXpérience Utilisateur » et cherche à identifier, trouver puis observer ces utilisateurs.

Mais alors, que sont ces métiers ?

 

Souvent les équipes de développements IT ont pour interlocuteurs des acteurs métiers, par exemple le marketing qui veut lancer un nouveau produit, la SIRH ou la compta qui doivent adapter leurs règles à la réglementation légale, d’autres entités supports et parfois très techniques…Derrière ces Métiers se trouvent probablement les utilisateurs réels (parfois appelés utilisateurs finaux). Les Métiers sont donc souvent des intermédiaires entre les équipes, qui développent le produit, et les utilisateurs qui utilisent le produit. A ces intermédiaires s’ajoutent parfois de la Maitrise d’Ouvrage (MOA), voire de l’Assistance à MOA (AMOA, Business Analysts).

En somme, les intermédiaires s’additionnent entre l’IT et les utilisateurs. Est-ce souhaitable ? Oui en général puisque les Métiers sont des « Sachants » qui apportent une connaissance d’ensemble des réglementations, des stratégies et des enjeux que les utilisateurs à eux seuls n’ont pas.

Mais il faut alors bien souligner ces faits :

• Les Métiers apportent une vision, une roadmap d’évolutions visées à moyen/long termes des produits – c’est du stratégique
• Les Utilisateurs fournissent leurs feedbacks instantanés sur ces Produits – c’est du factuel

 

Prioriser

 

En Scrum, le framework agile le plus répandu, existe un rôle de Product Owner. On pense comme une vérité acquise qu’il doit être issu des Métiers.

Initialement ce rôle a pour but de maximiser la valeur générée par le produit en identifiant des utilisateurs, leurs usages et en priorisant des services / utilisations qu’il faudra développer. Cela se traduit par la quantification d’une Business Value (valeur « commerciale » ou marchande, au sens général) qui permet de prioriser les développements et de s’adapter au mieux à la capacité de travail de l’équipe IT. Pour le dire autrement : ne pouvant pas tout faire en même temps, par quoi commencer ? qu’est ce qui va « appâter » les utilisateurs, leur faire utiliser le produit ?

Ainsi cette BV (Business Value) est-elle un mixte d’utilité ou d’intérêt utilisateur (on peut parler de désirabilité), d’intérêt métier parce que cela doit rapporter un bénéfice et non être fourni à perte (on parle de viabilité) et enfin de faisabilité technique, c’est-à-dire que le coût de développement soit en rapport avec les autres valeurs et non disproportionné.

C’est-à-dire que BV = quelque chose comme Désirabilité x Viabilité x Faisabilité.

Si l’une de ces composantes est nulle (impossible, introuvable) ou négative (à perte, coûteuse), la BV s’en ressent.

SAFe – l’autre framework très populaire également et qui décrit l’agilité à grande échelle – préconise d’utiliser le WSJF (Weighted shortest job firt) = Cost of delay / Job duration (or size).

Il s’agit de la même idée où le Cost of delay est la somme de la Désirabilité, de l’urgence (une fonctionnalité pour le Black Friday qui arriverait le lendemain de sa date perd beaucoup en intérêt…) et de la réduction de risque. Et le Job duration (ou taille) = 1 / Faisabilité.

Alors BV = (Désirabilité + urgence à faire + réduction de risque) x Viabilité / Taille

Cette formule est fausse ? Oui et non, mais son intérêt est de nous montrer les acteurs qui peuvent utilement déterminer la BV :

• La désirabilité est typiquement le travail des UX qui identifient et testent les utilisateurs ou lorsque les utilisateurs sont connus, de quelqu’un de l’équipe capable de les solliciter
• L’urgence à faire est souvent une donnée brute (deadline commerciale ou réglementaire) que l’équipe IT connait (souvent parce que le Métier le lui a indiqué, il est vrai, mais Noël, le Black Friday ou le 1^er janvier sont des deadlines assez simples à saisir)
• La réduction de risque est plus ouverte mais l’équipe doit avoir une opinion pertinente dessus
• La Viabilité est plus typiquement une question à résoudre par les Métiers justement : quel CA, quel bénéfice, quel avantage en terme d’image espère-t-on ?
• Enfin la taille ou complexité est estimée par l’équipe

On pourrait dire que l’équipe aura du mal à estimer la complexité de quelque chose d’encore confus ou de non précisément décrit (par ex. une user story pas prête). Mais l’équipe peut faire des hypothèses et même doit en faire. Elle estime l’US sur la base de ces hypothèses et les feedbacks obtenus par la mise à disposition aux utilisateurs permettront de corriger ces hypothèses.

On le voit, la Business Value, la priorisation des évolutions sont essentiellement dirigées par :

• Les hypothèses et estimations de l’équipe de développement elle-même
• Sa capacité à obtenir des Users feedbacks pour corriger ces hypothèses en livrant différentes « versions » d’évolutions aux utilisateurs cibles

 

Et plus ces feedbacks – ces livraisons – sont fréquentes, plus l’équipe pourra faire converger rapidement ses hypothèses vers une version pertinente.

Présenté ainsi, nous n’attendons donc pas tout des Métiers, loin de là. Ceux-ci ont plutôt une sorte de droit de veto pour stopper des initiatives d’évolutions qui seraient peut-être désirables et faisables, mais sans bénéfice à espérer, voire même génératrices de pertes.

Allons même un peu plus loin : nous attendons des Métiers une sage distanciation d’avec l’équipe. Trop d’acteurs métiers voulant bien faire font du micro management et surtout décident des priorités sur des bases non factuelles, déconnectées des feedbacks utilisateurs.

 

Alors, peut-on être Agile en se passant des métiers ?

 

Pas complétement, mais dans un premier temps, un peu quand même. Les Métiers apportent de la valeur au travers de leurs connaissances des business model des produits, de la vision stratégique de ces mêmes produits et des utilisateurs. Mais ceci est vrai qu’on vise d’être agile ou non, alors je dirais que pour être agile il faut surtout :

1. Des utilisateurs connus, identifiés, dont on ne peut pas se passer
2. Une équipe de développement qui sait solliciter ces utilisateurs
3. Des moyens techniques qui permettent à l’équipe de livrer fréquemment de petites évolutions à tester (et là on rejoint DevOps) et génératrices de feedbacks

 

Un PO idéal ?

 

Et bien on aura compris que je remets en question qu’il ou elle soit nécessairement issue des Métiers. On aura aussi compris de ce qui précède que l’étalon de vérité ce sont les retours utilisateurs (feedbacks) sur ce qui est livré. Il ne s’agit pas « d’opinions » ou de « ressentis », fusse d’un représentant très doué.

Le Product Owner qui doit prioriser les développements vers un produit pertinent n’a donc pas tant à être « du métier » ou génial que de savoir échanger avec des utilisateurs, puis avec les équipes. Et cela vaut aussi pour les Product Managers. De ce fait, un tel Product Owner et ses choix doivent être respectés par les Métiers, car il ou elle a la connaissance des Utilisateurs, c’est-à-dire du réel.

D’un autre point de vue, cela nous aide à mieux comprendre ce qui est attendu des Métiers : non pas tant diriger l’équipe que l’aider à accéder aux Utilisateurs.

Conclusion : avec les métiers, c’est tout de même mieux

 

Un PO « user centric » est une clé de l’agilité. Mais indépendamment de l’agilité, il est certain que des Métiers stratèges, qui développent une vision long terme des produits, est fondamental. Et pour aller plus loin tout en modérant le propos un peu contre intuitif et provoquant de ce papier, les Métiers feront gagner tout le monde (eux-mêmes, l’entreprise) s’ils s’agilisent aussi. Et pour « agiliser » les Métiers, des coachs métier peuvent les accompagner pour les aider à mieux développer des visions Produits, leurs connaissances des Utilisateurs (au sens d’identifier ces utilisateurs et d’entretenir des relations avec eux, de mesures, de tests) et mieux cerner les chaines de valeurs.

Ainsi, par exemple, apprendre à mesurer cette valeur en identifiants des KVI (Key Value Indicators) ou d’OKR (Objectives and Key Results) permettra au Métier de progresser dans l’exploitation des Users Feedbacks pour orienter les évolutions.