Embauché il y a 2 ans pour digitaliser les process, Alexandre Aubry raconte tous les changements que cela a induit : transformation de l'organisation, de l'infrastructure matérielle et réseau, ouverture et décommissionnement progressif de l'ERP Cobol...
Nous avons assisté à la conférence client de l'entreprise Orange à Agile en Seine. Cet article vous propose de découvrir comment l'IA Gen devient déjà un atout incontournable chez certains clients.
Un bon mix d'indicateurs - des KPI classiques ainsi que des KPI personnalisés - devrait vous aider, à condition de respecter un principe essentiel : faites simple !
Considérer le SI sous l'angle produits + data + plateforme est un enjeu majeur pour moderniser son approche. Le thème #Produits devrait être prépondérant en 2023.
Penser produit plutôt que projet
La différence entre projets et produits est souvent ignorée, ou mal perçue. Or, elle est fondamentale.
Un produit est une offre matérielle ou immatérielle qui répond à un besoin ou satisfait une envie. Il est le résultat de la stratégie commerciale d'une entreprise et doit être conçu, développé et géré afin d'apporter de la valeur au client. Il est ensuite mis au catalogue, et est régulièrement mis à jour dans le cadre de son cycle de vie - jusqu’à ce qu’il soit retiré du marché - en fonction d’une roadmap établie pour répondre aux besoins des clients, qui évoluent au fil du temps. Le produit vise un objectif, et chaque itération s’en rapprochera.
De son côté, un projet est un effort temporaire qui a pour but de répondre à un besoin unique : il s’agit de créer un livrable spécifique, pour une date précise et un budget fixé à l’avance. Ce qui ne laisse pas de place à l’imprévu, et va donc à l’encontre des principes agiles ; cette façon de faire est une source évidente de frustration lorsque cet imprévu arrive (ce qu’il fait immanquablement).
La différence peut parfois paraître ténue, mais voir les choses sous l’angle du produit amène à changer de perspective. Typiquement :
Un produit a des clients, il faut donc comprendre leurs besoins et chercher à les satisfaire.
Un produit nécessite des matières premières, il faut donc négocier avec les fournisseurs (par exemple des producteurs d’API ou des data owners).
Un produit doit être réalisé de façon industrialisée, il faudra donc penser plateforme (comme pour une voiture, où plusieurs modèles peuvent s’appuyer sur une plateforme commune), mais aussi DevOps, DataOps, etc.
Un produit a droit à une stratégie marketing, des canaux de distribution (API, marketplace, revendeurs…), une campagne de communication…
Un produit a un coût de fabrication, et un objectif business, qu’il faudra bien définir de façon à pouvoir en mesurer la valeur.
MVP vs MLP : créer de l’émotion
L’expérience utilisateur dépend en grande partie des fonctionnalités offertes mais, in fine, ce qui fera qu’un utilisateur reviendra vers son produit, c’est l’émotion (satisfaction, joie, curiosité, rire…) qu’on aura pu susciter. D’où l’émergence de la notion de MLP. Minimum Viable Product (MVP) et Minimum Lovable Product (MLP) sont des concepts similaires dans le développement de produits, mais ils ont quelques différences essentielles.
Un MVP est une version d'un produit qui possède l'ensemble minimal de fonctionnalités nécessaires pour être utilisable par les clients. L'objectif d'un MVP est de recueillir les commentaires des clients et d'itérer sur le produit en fonction de ces commentaires. L'accent est mis sur le test de la viabilité du produit et de ses fonctionnalités de base, plutôt que sur la création d'un produit complet.
Un MLP, en revanche, est une version d'un produit qui possède l'ensemble minimum de fonctionnalités nécessaires pour être aimée des clients. L'objectif d'un MLP est de créer un produit que les clients trouveront agréable et engageant, même dans ses premiers stades. L'accent est mis sur la création d'un lien émotionnel positif avec les clients, plutôt que de simplement faire tester les aspects fonctionnels du produit.
En résumé, la principale différence entre MVP et MLP est l'accent mis sur le retour d'information des clients et l'engagement émotionnel. Un MVP se concentre sur la collecte de commentaires et l'itération sur le produit, tandis qu'un MLP se concentre sur la création d'un lien émotionnel positif avec les clients du produit.
Du Value Stream Management au Value Stream Analytics
Le Value Stream Management vise à fluidifier la création d’un produit offert à un client, en identifiant les différentes étapes nécessaires (Value Stream Identification ) et en cherchant à optimiser le flux de l’ensemble de la chaîne de valeur (Value Stream Mapping). Cette technique issue de la pratique industrielle du lean est un formidable outil qui force à s’interroger sur les produits que propose l’entreprise et sur les process et outils logiciels mis en œuvre pour les délivrer. Le VSM met en lumière ce qui peut être optimisé, ce qui peut être écarté…
La méthodologie gagne en importance, notamment du fait de l’utilisation de frameworks d’agilité à l’échelle tels que SAFe, pour mettre en place les trains de livraison (exploration en continu, développement, intégration en continu, déploiement en continu, mise en service à la demande…). Cependant, même s’il s’agit d’une étape indispensable, cela reste une étape. In fine, sauf cas particulier, l'objectif de l’entreprise n’est pas de produire un logiciel mais un produit intégrant ou s’appuyant sur ce logiciel (des voitures, des cosmétiques, des produits chimiques ou industriels…). 2023 devrait donc voir arriver la notion de Value Stream Analytics, pour mesurer la création de valeur de ces chaînes en termes business - un impératif rendu d’autant plus fort par des perspectives économiques peu encourageantes.
Les acteurs du produit pilotent la création de valeur
PM et CPO jouent un rôle pivot
Les rôles de Product Managers et Chief Product Officers ont émergé et gagné de l’importance avec la montée en puissance des méthodologies et frameworks agiles. Toutefois, leur rôle est souvent réduit à la portion congrue d’un PO, Product Owner, en particulier la rédaction de user stories et l’alimentation du backlog. La nécessité de monter rapidement en maturité sur l’agilité devrait amener les entreprises à accentuer le rôle du CPO et des PM, mais aussi des PO, qui doivent intégrer à leur périmètre la notion de “customer experience”, dont ils sont in fine responsables.
On lit souvent qu’un PO est un chef de projet agile, ou digital. Cette confusion entre produit et projet n’aide pas à l’émergence d’une compréhension commune des enjeux d’une organisation orientée produits. En mode produits, PM et PO détiennent, sous l’autorité du CPO, une véritable responsabilité dans la création de valeur pour le business. Ce sont des chefs de produits, qui ont des redevabilités envers les clients, envers les développeurs et envers les métiers de l’entreprise.
Les PM tech émergent
Les clients des produits de l’entreprise ne sont pas nécessairement externes à l’entreprise.
Lorsqu’une équipe d’ingénierie crée et opère une plateforme, ses clients sont les développeurs des produits basés sur cette plateforme. Typiquement, la création d’une plateforme Cloud doit simplifier la tâche des équipes développant des produits qui bénéficieront des services amenés par cette plateforme : bases de données, conteneurs, système de diffusion de données au fil de l’eau…
Ces plateformes ont donc besoin d’être pilotées par des Product Managers, qui vont établir une roadmap en fonction des besoins des équipes produits, en coordination avec les architectes de l’entreprise. Ces “PM Tech” s’assureront que l’équipe de “platform engineering” crée la “thinnest viable platform”, mutualisant juste ce qu’il faut de services pour booster la productivité des équipes produit. Eux aussi devront mesurer la valeur, pour s’assurer du résultat de leurs investissements.